Before filing
Closest existing issue
#304 — same symptom (a provider's models never appear in the picker) but a different cause: there the backend returns an empty list because goose's OpenRouter provider doesn't implement fetch_supported_models, whereas here Berd never asks about the provider at all, because it isn't in the catalog yet.
What's broken
Custom providers are missing from the provider catalog on every launch, so the Goose agent's model picker starts with an empty model list for anyone whose only configured provider is a custom one. Opening Settings → Providers once per launch fixes it for that session.
Steps to reproduce
- Launch Berd with a custom provider as the only configured model provider (mine: an internal OpenAI-compatible vLLM/LiteLLM endpoint, added via Add model provider → Custom).
- Do not open Settings.
- Open the model picker for the default Goose agent.
What you expected to happen
The custom provider's models are listed, the same as after opening Settings.
What actually happened
The picker shows no models. Because the combined list is empty, useAgentModelPickerState.ts falls through to the first error it can find among the catalog's providers, so an unrelated provider's failure is presented as the status message — in my case a stale Anthropic key's 401 API key is invalid, which reads as if the custom provider itself were broken. Opening Settings → Providers makes the models appear immediately, and they stay until the next launch.
Cause, as far as I can tell:
- Goose drops custom providers from its setup catalog: their stored definition has no
setup metadata, and setup_entry_from_metadata returns None for those (goose crates/goose-provider-types/src/canonical/catalog.rs).
chatRuntimeStartup.ts merges only that setup catalog into useProviderCatalogStore (loadSetupCatalog). The only other merge of custom providers is refreshCustomProviders in ProvidersSettings.tsx, which runs on mount of the settings page.- Everything downstream keys off that catalog:
getModelDiscoveryProviderIds (defaultProviderConfig.ts) filters getModelProviders(), and configuredModelProviderIds (useProviderModels.ts) is built from the catalog entries. With the custom provider absent, startup never refreshes its models and the picker never lists them.
A side effect worth noting separately: because the catalog is also what the needs_setup recovery in startup considers, a user whose only configured provider is custom cannot have it auto-selected as the default on first run.
How often does it happen?
Every time — reliably reproducible
Berd version
0.6.4 (release build, Berd_0.6.4_darwin-aarch64.dmg). Also present on main at ce48ca5.
Operating system
macOS (Apple Silicon)
Model and provider
Custom OpenAI-compatible provider (self-hosted endpoint); model beast/big. The bug is in provider/model listing, before any model call.
Relevant log output
No relevant entry in ~/Library/Logs/xyz.block.berd/berd.log — the empty picker
is renderer state, not something the app logs.
What the goose server log shows at startup is the set of providers Berd asks
about, and the custom provider is not among them:
~/.local/state/goose/logs/cli/<date>/<session>.log
"_goose/unstable/providers/supported-models/list" ... copilot / cursor-agent /
pi-acp / ollama / lmstudio / bedrock / anthropic — no request for the custom
provider until the settings page has been opened.
Screenshots, recordings, or other context
Suggested fix (what I ran locally): merge the custom providers into the catalog during startup, right after the setup catalog and before model discovery and the needs_setup recovery, reusing the same mapping the settings page uses. It has to stay sequential after loadSetupCatalog, whose applyRuntimeProviderConfig ends in a setEntries full-replace that would race a concurrent mergeEntries.
Happy to open a PR if that would help, though I understand outside PRs are closed automatically — treating this as a report.
Before filing
Closest existing issue
#304 — same symptom (a provider's models never appear in the picker) but a different cause: there the backend returns an empty list because goose's OpenRouter provider doesn't implement
fetch_supported_models, whereas here Berd never asks about the provider at all, because it isn't in the catalog yet.What's broken
Custom providers are missing from the provider catalog on every launch, so the Goose agent's model picker starts with an empty model list for anyone whose only configured provider is a custom one. Opening Settings → Providers once per launch fixes it for that session.
Steps to reproduce
What you expected to happen
The custom provider's models are listed, the same as after opening Settings.
What actually happened
The picker shows no models. Because the combined list is empty,
useAgentModelPickerState.tsfalls through to the first error it can find among the catalog's providers, so an unrelated provider's failure is presented as the status message — in my case a stale Anthropic key's401 API key is invalid, which reads as if the custom provider itself were broken. Opening Settings → Providers makes the models appear immediately, and they stay until the next launch.Cause, as far as I can tell:
setupmetadata, andsetup_entry_from_metadatareturnsNonefor those (goosecrates/goose-provider-types/src/canonical/catalog.rs).chatRuntimeStartup.tsmerges only that setup catalog intouseProviderCatalogStore(loadSetupCatalog). The only other merge of custom providers isrefreshCustomProvidersinProvidersSettings.tsx, which runs on mount of the settings page.getModelDiscoveryProviderIds(defaultProviderConfig.ts) filtersgetModelProviders(), andconfiguredModelProviderIds(useProviderModels.ts) is built from the catalog entries. With the custom provider absent, startup never refreshes its models and the picker never lists them.A side effect worth noting separately: because the catalog is also what the
needs_setuprecovery in startup considers, a user whose only configured provider is custom cannot have it auto-selected as the default on first run.How often does it happen?
Every time — reliably reproducible
Berd version
0.6.4 (release build,
Berd_0.6.4_darwin-aarch64.dmg). Also present onmainat ce48ca5.Operating system
macOS (Apple Silicon)
Model and provider
Custom OpenAI-compatible provider (self-hosted endpoint); model
beast/big. The bug is in provider/model listing, before any model call.Relevant log output
Screenshots, recordings, or other context
Suggested fix (what I ran locally): merge the custom providers into the catalog during startup, right after the setup catalog and before model discovery and the
needs_setuprecovery, reusing the same mapping the settings page uses. It has to stay sequential afterloadSetupCatalog, whoseapplyRuntimeProviderConfigends in asetEntriesfull-replace that would race a concurrentmergeEntries.Happy to open a PR if that would help, though I understand outside PRs are closed automatically — treating this as a report.