Problem
packages/opencode/src/provider/provider.ts extends the live models.dev-style catalog with whatever provider.<id> entries exist in the user's opencode.json (~L1424-1520). Settings' generic "Add Provider" dialog (dialog-connect-provider.tsx → use-providers.ts → serverSync().data.provider.all) renders exactly that merged result.
This means a branded first-run preset — like Harmoniqs AI, added in amicode's onboarding_panel.ts (harmoniqs/amicode#951) — only appears anywhere once a user completes onboarding with it selected, because that's the only code path that writes the provider.harmoniqs entry into opencode.json. A user who skips onboarding, or who wants to reconnect the provider later from Settings, sees nothing — they'd have to hand-build it via the raw "Custom Provider" form, typing the base URL and model id themselves and losing the branding, locked-model UX, and secret-safe error classification onboarding gives them.
Why this isn't a placement bug
The one piece of Harmoniqs-provider knowledge that's genuinely runtime behavior — the backend rejects tools, so this provider must not receive them regardless of how its config entry got created — already lives correctly in the engine (NO_TOOLS_PROVIDERS in session/llm/request.ts, opencode#325). The gap is specifically about visibility before any config exists, which no provider has today, not something amicode's onboarding code did wrong.
Proposal
Add a small default-provider-seed layer to Config.Service (or wherever the merge in provider.ts happens) that a distribution (Amicode) can populate with branded presets — base URL, default model id, auth type, display name/icon — which Settings' "Add Provider" flow renders even with an empty opencode.json. Selecting one there should produce the same provider.<id> config shape onboarding writes today, so both entry points converge on one definition instead of two.
Scope note
This is a new mechanism, not a config-writing bug fix — deliberately not half-built as part of harmoniqs/amicode#951. Filing as its own issue.
cc @jack
Problem
packages/opencode/src/provider/provider.tsextends the livemodels.dev-style catalog with whateverprovider.<id>entries exist in the user'sopencode.json(~L1424-1520). Settings' generic "Add Provider" dialog (dialog-connect-provider.tsx→use-providers.ts→serverSync().data.provider.all) renders exactly that merged result.This means a branded first-run preset — like Harmoniqs AI, added in amicode's
onboarding_panel.ts(harmoniqs/amicode#951) — only appears anywhere once a user completes onboarding with it selected, because that's the only code path that writes theprovider.harmoniqsentry intoopencode.json. A user who skips onboarding, or who wants to reconnect the provider later from Settings, sees nothing — they'd have to hand-build it via the raw "Custom Provider" form, typing the base URL and model id themselves and losing the branding, locked-model UX, and secret-safe error classification onboarding gives them.Why this isn't a placement bug
The one piece of Harmoniqs-provider knowledge that's genuinely runtime behavior — the backend rejects
tools, so this provider must not receive them regardless of how its config entry got created — already lives correctly in the engine (NO_TOOLS_PROVIDERSinsession/llm/request.ts, opencode#325). The gap is specifically about visibility before any config exists, which no provider has today, not something amicode's onboarding code did wrong.Proposal
Add a small default-provider-seed layer to
Config.Service(or wherever the merge inprovider.tshappens) that a distribution (Amicode) can populate with branded presets — base URL, default model id, auth type, display name/icon — which Settings' "Add Provider" flow renders even with an emptyopencode.json. Selecting one there should produce the sameprovider.<id>config shape onboarding writes today, so both entry points converge on one definition instead of two.Scope note
This is a new mechanism, not a config-writing bug fix — deliberately not half-built as part of harmoniqs/amicode#951. Filing as its own issue.
cc @jack