You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
config: variants documented as array but schema requires object — provider silently dropped #53744
The models doc shows model variants as an array of { id, settings }
objects, but the published config schema requires variants to be an object keyed by variant ID. Config following the documented array form
fails schema validation, and the failure is silent: the entire provider
is dropped from the model list with no error or warning at config load.
Configure a custom OpenAI-compatible provider, copying the documented variantsarray form from the models guide (https://opencode.ai/v2/docs/models, "Variants" section):
The published schema (https://opencode.ai/config.json) defines the model variants field as {"type": "object", "additionalProperties": {...}} —
i.e. a map of variant ID → config — while the models guide shows an array.
The two official sources contradict each other; one of them needs fixing.
The more dangerous part is the silent failure mode: an invalid variants
shape drops the whole provider with no diagnostic, so the user sees only
"model missing" / "unsupported package" and has no hint to look at the
config. A config-validation error (or a warning naming the offending field)
would make this tractable.
Thanks for the detailed report. I reproduced this on v2.0.24, but in my tests the direction was reversed:
The array form from the models guide ("variants": [{ "id": "low", "settings": { ... } }, ...]) worked. The model showed up in opencode2 models and /models.
The object form ("variants": { "low": { "settings": { ... } } }) caused the whole local provider to be dropped. It didn't show up in /models, and the only trace was a warning in the log file (~/.local/share/opencode/log/opencode.log): configuration normalization diagnostic ... path=$.providers.local kind=invalid. That warning doesn't mention variants, and nothing is shown in the UI.
The contradiction you found is real. https://opencode.ai/config.json currently serves the v1 schema, where variants is an object map. The v2 runtime expects the array form that the docs show. So an editor validating against that $schema points you to the shape v2 rejects. Related: #43748.
The second problem you raised is also confirmed: an invalid variants shape silently drops the entire provider, with no diagnostic that names the field.
If the array form still fails for you, please share the exact providers block that fails, plus the matching configuration normalization diagnostic lines from that log file. You can reply here, or edit the issue and leave a comment saying you've updated it.
Activity
opencode-agent commentedon Oct 7, 2026
Thanks for the detailed report. I reproduced this on v2.0.24, but in my tests the direction was reversed:
"variants": [{ "id": "low", "settings": { ... } }, ...]) worked. The model showed up inopencode2 modelsand/models."variants": { "low": { "settings": { ... } } }) caused the wholelocalprovider to be dropped. It didn't show up in/models, and the only trace was a warning in the log file (~/.local/share/opencode/log/opencode.log):configuration normalization diagnostic ... path=$.providers.local kind=invalid. That warning doesn't mentionvariants, and nothing is shown in the UI.The contradiction you found is real.
https://opencode.ai/config.jsoncurrently serves the v1 schema, wherevariantsis an object map. The v2 runtime expects the array form that the docs show. So an editor validating against that$schemapoints you to the shape v2 rejects. Related: #43748.The second problem you raised is also confirmed: an invalid
variantsshape silently drops the entire provider, with no diagnostic that names the field.If the array form still fails for you, please share the exact
providersblock that fails, plus the matchingconfiguration normalization diagnosticlines from that log file. You can reply here, or edit the issue and leave a comment saying you've updated it.