OpenRouter provider returns 0 supported models, leaving Goose stuck in needs_setup

Title

OpenRouter provider returns 0 supported models, leaving Goose stuck in needs_setup

Summary

In Berd 0.6.3-dev.15+g977d35fc, using Goose with OpenRouter in a BYO-key build, OpenRouter can be successfully configured and authenticated, but Goose remains not_ready because the default provider/model selection flow cannot load supported models.

The issue appears to originate in the pinned Goose backend: OpenRouterProvider implements fetch_recommended_models() but does not implement fetch_supported_models(). The default trait implementation returns an empty vector, so Berd receives zero models from:

_goose/unstable/providers/supported-models/list

As a result, Berd cannot persist the default providerId + modelId, readiness stays needs_setup, and selecting Goose from the model picker redirects back to provider settings.

Environment

* Berd: 0.6.3-dev.15+g977d35fc
* Platform: macOS
* Architecture: Apple Silicon
* Build profile: BYO-key providers enabled
* Harness: Goose
* Model provider: OpenRouter
* Goose commit pinned by Berd: 063694cf7

Actual behavior

OpenRouter is configured successfully:

* API key stored
* provider reports configured=true
* UI shows OpenRouter as connected

However:

defaults/read
→ { providerId: null, modelId: null }

and:

DefaultProviderReadiness
→ { status: "needs_setup", reason: "missing_defaults" }

Runtime ACP calls show:

providers/list
→ openrouter: 335 models

but:

providers/supported-models/list { providerId: "openrouter" }
→ models: []

No backend error is returned; the list is simply empty.

Expected behavior

After configuring OpenRouter, Berd should:

1. retrieve supported OpenRouter models;
2. select/persist a valid default model;
3. update Goose readiness to ready;
4. allow Goose to be selected from the model picker;
5. show OpenRouter models in the model selector.

Root cause

The ACP endpoint for supported models calls:

provider.fetch_supported_models()

For OpenRouter, fetch_supported_models() is not overridden.

OpenRouterProvider only overrides:

fetch_recommended_models()

The default Provider trait implementation of fetch_supported_models() returns:

Ok(vec![])

Therefore the two model-discovery paths diverge:

providers/list
→ fetch_recommended_models()
→ 335 OpenRouter models

versus:

providers/supported-models/list
→ fetch_supported_models()
→ []

This propagates into Berd:

providerModelCacheStore
→ fetchProviderSupportedModels("openrouter")
→ []

then:

saveDefaultProviderSelection()
→ models.length === 0
→ "Could not load models for provider"

The error is caught in the frontend and the default model is never persisted.

Relevant files

Goose:

goose/src/acp/server/providers.rs
goose/src/providers/openrouter.rs
goose-provider-types/src/base.rs

Berd:

src/features/providers/defaultProviderConfig.ts
src/features/providers/defaultProviderReadiness.ts
src/features/providers/hooks/useCredentials.ts
src/features/providers/hooks/useAgentProviderStatus.ts
src/features/chat/ui/AgentModelPicker.tsx

Workaround confirmed

Manually saving valid defaults unblocks Goose:

providerId: openrouter
modelId: deepseek/deepseek-v4-flash

After saving:

defaults/read
→ {
providerId: "openrouter",
modelId: "deepseek/deepseek-v4-flash"
}

and readiness becomes:

ready

Goose then works correctly with OpenRouter and can access local tools/files.

However, the model selector still cannot enumerate OpenRouter models because supported-models/list remains empty.

Suggested fix

Implement fetch_supported_models() in OpenRouterProvider, ideally reusing the same OpenRouter models endpoint / helper used by fetch_recommended_models().

Alternatively, Berd could temporarily fall back to the models already returned by providers/list when supported-models/list returns an empty list.

The backend fix seems preferable because the ACP endpoint itself currently reports an incorrect empty supported-model list for OpenRouter.