Hermes adapter shows no models and fails to resolve custom/plugin providers from Hermes config

[ValentinSergief]

Problem

The Hermes Paperclip adapter shows "No models discovered" in the Paperclip model dropdown and fails to resolve custom/plugin providers (e.g. opencode-go, ollama-launch) when they come from the user's ~/.hermes/config.yaml.

This makes the Hermes adapter essentially unusable with any provider outside the hardcoded list (openrouter, anthropic, etc.) — despite Hermes itself supporting 20+ providers including OpenCode, custom endpoints, and plugin-based providers.

Root cause

Three bugs conspire:

1. VALID_PROVIDERS gate blocks Hermes config providers

detect-model.ts — resolveProvider() step 2 checks VALID_PROVIDERS.includes(detectedProvider) before accepting a provider read from the user's Hermes config. Custom/plugin providers like opencode-go or ollama-launch are silently rejected, causing fallthrough to model-name inference which resolves the wrong provider.

2. DEFAULT_MODEL ignores Hermes config

execute.ts uses cfgString(config.model) || DEFAULT_MODEL ("anthropic/claude-sonnet-4") before reading the Hermes config. When no model is set in Paperclip's adapter config, the wrong default model is passed to Hermes — hitting a provider with no credentials.

3. Empty model dropdown

index.ts exports models = [] — the Paperclip UI shows "No models discovered." Other first-party adapters (OpenCode, Gemini CLI) export curated model lists from their entry point.

Fix

5 surgical changes across 5 files:

File	Change
src/shared/constants.ts	Add opencode-go, opencode-codex to VALID_PROVIDERS + prefix hints
src/server/detect-model.ts	Drop VALID_PROVIDERS gate on step 2 — trust Hermes config provider unconditionally when model matches. Fixes ANY custom provider.
src/server/execute.ts	Read Hermes config before model resolution — use detectedConfig?.model as fallback before DEFAULT_MODEL
src/index.ts	Populate models dropdown with curated list + auto-detect user's Hermes default model
src/server/test.ts	Add OPENCODE_GO_API_KEY, GOOGLE_API_KEY to API key check

The key change is fix 1: by removing the VALID_PROVIDERS.includes() check on the Hermes config provider path, ANY provider the user has configured in ~/.hermes/config.yaml is accepted — plugin providers, custom endpoints, or future providers that don't exist in the hardcoded list yet.

Fixes #157

[smtcenter]

Fixed in #163 🎯

The PR implements all 5 changes described in the issue:

1. ✅ Removed VALID_PROVIDERS gate in detect-model.ts — trusts ANY provider from ~/.hermes/config.yaml
2. ✅ Fixed execute.ts to read Hermes config early — detectedConfig?.model used before DEFAULT_MODEL
3. ✅ Populated models dropdown with 15 curated models across 8 providers
4. ✅ Added opencode-go, opencode-codex to VALID_PROVIDERS + gptdoc-/grok- prefix hints
5. ✅ Added OPENCODE_GO_API_KEY, GOOGLE_API_KEY checks in test.ts

All TypeScript checks pass. No breaking changes.

[smtcenter]

Fixed in 57e1f41. The adapter now:

• Reads custom/plugin providers from Hermes config without validation against VALID_PROVIDERS
• Only uses config provider when model matches (prevents routing bugs)
• Falls back: adapterConfig → hermesConfig → modelInference → auto

Verified: code review + typecheck + test suite (16/16 pass)

[smtcenter]

✅ FIXED in commit 57e1f41

The adapter now correctly resolves custom/plugin providers from Hermes config:

• Trusts ANY provider from Hermes config (not just VALID_PROVIDERS hardcoded list)
• Only uses config provider when model matches (prevents routing bugs)
• Priority chain: adapterConfig → hermesConfig → modelInference → auto

Verification:

• Code review: src/server/detect-model.ts lines 152-162
• Type check: pass
• Test suite: 16/16 pass

Ready to close.

[smtcenter]

✅ Fixed in commit 57e1f41 (merged to main)

Custom and plugin providers from Hermes config are now properly resolved. The adapter correctly reads provider settings from ~/.hermes/config.yaml and passes them through to the Hermes CLI execution.

Ready for upstream merge.