desktop: custom provider models always show reasoning badge as not supported despite capabilities.output #50608

Summary

Custom OpenAI-compatible providers configured via providers.<id>.models always show "reasoning: not supported" in the OpenCode Desktop 2.0.13 model picker, even when capabilities.output: ["text", "reasoning"] is set per the current docs. Related (but separate source): built-in catalog providers such as minimax-cn/MiniMax-M3 also display as non-reasoning because models.dev lacks the reasoning flag for them, and a config-level override cannot fix the badge either (see below).

Rechecking the actual streaming behavior: the models do reason and stream reasoning tokens — this is a display/metadata gap, not a functional regression.

Environment

• opencode version: 2.0.13 (OpenCode Desktop, latest channel)
• OS: Windows 11 (10.0.26200, win32 x64)
• Shell: PowerShell 5.1
• Active plugins: none (V1 config had no working plugin entries)

Reproduction

1. Add a custom OpenAI-compatible provider in ~/.config/opencode/opencode.jsonc:

   "providers": {
     "my-ark": {
       "package": "aisdk:@ai-sdk/openai-compatible",
       "settings": {
         "baseURL": "https://example.invalid/v3",
         "apiKey": "redacted"
       },
       "models": {
         "reasoner-model": {
           "name": "Reasoner Model",
           "capabilities": { "tools": true, "input": ["text"], "output": ["text", "reasoning"] }
         }
       }
     }
   }

2. Restart OpenCode Desktop and open the model picker.

3. All such config-declared models show "reasoning not supported" (Tooltip model.tooltip.reasoning.none), including reasoning models (DeepSeek V4 Pro, Kimi K2 Thinking, Doubao Seed 2.1 Pro, etc.).

Expected Behavior

Per https://v2.opencode.ai/docs/models (Aliases section), a model not in the catalog defaults to "Tool support, text and image input, and text output" and explicit capabilities should replace those fallbacks. The picker should honor capabilities.output containing reasoning when computing the reasoning badge, or document that the badge cannot express reasoning for config-defined models.

Actual Behavior

The reasoning badge is always "not supported" for config-declared models. In the bundled desktop code (app.asar, v2.0.13), the config-defined model mapping hardcodes these booleans:

id: e.id,
providerID: e.providerID,
api: { id: e.modelID, url: ``, npm: e.package ?? t.id },
name: e.name,
family: e.family,
capabilities: {
  temperature: !1,
  reasoning: !1,          // <-- hardcoded; never derived from e.capabilities.output
  attachment: e.capabilities.input.some(e => e !== `text`),
  toolcall: e.capabilities.tools,
  input: { text: ..., audio: ..., image: ..., video: ..., pdf: ... },
  output: { text: ..., audio: ..., image: ..., video: ..., pdf: ... },
  interleaved: !1,        // <-- also hardcoded false
},
cost: { ... },
limit: e.limit,
status: e.status,
options: e.settings ?? {},
headers: e.headers ?? {},
release_date: ...,
variants: Object.fromEntries(e.variants.map(e => [e.id, e.settings ?? {}])),

So the documented capabilities.output values (only text/audio/image/video/pdf are ever read) never reach capabilities.reasoning, and there is no config field to override it — the V1 provider-model reasoning field is intentionally ignored per the migration guide, so there is no escape hatch either.

The consumer of the badge (rendered model picker tooltip) is:

c = () =>
  e.model.capabilities
    ? e.model.capabilities.reasoning
      ? t.t(`model.tooltip.reasoning.allowed`)
      : t.t(`model.tooltip.reasoning.none`)
    : ...

Additional Context

• A related upstream-metadata symptom: bytedance-seed/minimax-family entries on models.dev (e.g. MiniMax-M3, interleave-thinking models) lack the reasoning flag, so those built-in provider models also render as non-reasoning. A config-level providers.minimax-cn.models["MiniMax-M3"].capabilities override does not change the badge either, because it still flows through the same hardcoded mapping above (only input/output/toolcall dims are honored).
• Suggested fix options:
  1. Derive capabilities.reasoning from e.capabilities.output.includes("reasoning") for config-declared models, and/or
  2. Extend the V2 model schema with an explicit reasoning (and interleaved) override, and/or
  3. Document that the reasoning badge cannot be enabled for custom providers.

Happy to test a fix; my desktop build reports 2.0.13.