Repository navigation
providers: custom provider silently skipped when model capabilities omit tools #49912
Description
Description
Custom providers migrated from V1 following the migrate-v1 guide are silently skipped when a model's capabilities omits tools. V1 models only have modalities (no tool_call), so a literal migration yields capabilities: {input, output} without tools — the whole provider is then dropped with only a terse normalization warning. /api/config shows "providers": {}, /api/model has none of its models.
Server log (one line per provider, no field detail):
level=WARN message="configuration normalization diagnostic" path=$.providers.acme kind=invalid action="skipped malformed recognized value" role=server
Either missing capabilities.tools should fall back to the documented default (models doc: unknown models assume tool support), or the migrate-v1 guide should state tools is required and what to use when V1 has no tool_call. At minimum the warning should name the offending field, not just the provider path.
Plugins
none
OpenCode version
v2.0.9 (channel latest)
Steps to reproduce
- Add a custom provider whose model
capabilitieshasinput/outputbut notools:
{
"providers": {
"acme": {
"package": "aisdk:@ai-sdk/openai-compatible",
"settings": { "apiKey": "{env:ACME_API_KEY}", "baseURL": "https://llm.example.com/v1" },
"models": {
"coder": {
"limit": { "context": 262144, "output": 32768 },
"capabilities": { "input": ["text", "image"], "output": ["text"] }
}
}
}
}
}- Start opencode (config hot-reloads).
opencode api get /api/config→providersis{}; log shows the WARN above.- Add
"tools": truetocapabilities→ provider loads, models appear enabled in/api/model.
Screenshot and/or share link
n/a (config/API output above)
Operating System
Windows 10.0.22000
Terminal
WarpTerminal
Activity
cestercian commentedon Sep 19, 2026
Working on a fix so migrated V1 custom providers are not silently skipped when capabilities omit tools.
McNopper commentedon Sep 20, 2026
Still reproduces on v2.0.10 (Windows 11 26200, PowerShell 7), and the trigger is broader than a missing
tools: any incompletecapabilitiesobject drops the whole provider entry.In my case the V1 → V2 migration produced the mirror of your example —
tool_call: truebecamecapabilities: { "tools": true }with noinput/output:→
path=$.providers.<provider> kind=invalid action="skipped malformed recognized value", provider absent from/models, and a session pinned to it failed withModel unavailable: <provider>/k3. Completing it to{ "tools": true, "input": ["text"], "output": ["text"] }makes the provider load immediately.Two additional data points:
providers.ollamaentry (recognized/built-in) with amodelsblock using the same partialcapabilitieswas skipped identically. Built-in Ollama discovery still supplied models, which masked the skipped config entry and made it much harder to spot.aisdk:@ai-sdk/openai-compatibleform from the migrate-v1 guide was rejected (both failing entries happened to use it). After completingcapabilities, I verified thataisdk:@ai-sdk/openai-compatibleand@opencode/ai/providers/openai-compatibleboth load and both serve live requests — the package form was never the problem. Naming the offending field would have made that obvious.The models doc's fallback assumptions ("Tool support, text and image input, and text output" for non-catalog models) read as if a partial
capabilitiesobject should merge with those defaults rather than invalidate the entry.neriousy commentedon Oct 20, 2026
Thanks for the report! Version 2.0.22 fixed custom providers being skipped when model capabilities omit tools, input, or output; omitted fields now inherit the model's defaults. Update with
opencode upgradeornpm i -g @opencode/cli@latest(desktop: update the app). Please reopen or comment if this still happens on 2.0.22 or later.