[vimtor]

Why

Org admins can now set which reasoning controls a model accepts in the OpenCode Console (anomalyco/opencode-console#3690): none, fixed, effort levels, or a token budget. The Console sends these controls in the pulled config, but OpenCode had no config field for them. So a team couldn't fix a custom model's reasoning variants without writing raw request bodies for each provider.

What changes

• Config: adds providers.*.models.*.capabilities.reasoning in models.dev v2's shape: { supported, toggle?, effort?, budget?: { min?, max? } }.
• Variants:
  • When capabilities.reasoning is set, OpenCode builds the model's variants from it for the model's package. These replace the base variants.
  • supported: false, or supported: true with no controls ("fixed"), means no variants.
  • The default effort adds no variant, since it means the provider's own default.
  • Configured variants still apply on top.
• Console config: the OpenCode Console provider applies the same reasoning and release date to the models it loads, so Console edits reach signed-in users. Before this, the Console provider kept the catalog variants.
• Model metadata: the Console also sends metadata the 1.x config already had, so V2 reads it too:
  • releaseDate (YYYY-MM-DD or YYYY-MM) sets the model's release time.
  • capabilities.temperature records whether the model accepts a temperature. Model capabilities now carry it as optional metadata.
  • The reasoning field already worked through compatibility.reasoningField; the Console now sends it.
• Generated files: regenerated the client types and OpenAPI files.
• Docs: documented the field in Models and Providers.

Verification

• bun run check passes.
• Added tests for Variant.supports, for the config plugin with effort, fixed, and unsupported models, and for the release date, temperature, and reasoning field. Tests run in CI. Checked end to end against a local Console: a GPT-5.2 override of effort: ["low", "high"] gave exactly low and high variants, while the unchanged branch kept all five catalog levels.

---

Added by the opencode bot (AI-generated).

Related: #53202, #51846, #50257

Public API: adds the optional config key providers.*.models.*.capabilities.reasoning and the Config.Model.Reasoning schema to the OpenAPI spec and client types (backwards compatible)

[opencode-agent]

I found nothing that should block this. I ran serve from source on the base and on this branch with one config for a custom aisdk:@ai-sdk/openai provider and checked GET /api/model:

• On the base, capabilities.reasoning is ignored and every model gets the full default variant list.
• On this branch, effort: ["default","low","high"] gives low/high, and supported: true with no controls gives no variants. A model without reasoning keeps the default list.

The new tests in packages/core and the typecheck scripts in packages/core and packages/schema pass. The change reuses Variant.resolve the same way the models.dev loader does.

Public API: this adds the optional config key providers.*.models.*.capabilities.reasoning ({ supported, toggle?, effort?, budget?: { min?, max? } }). It also adds the schema Config.Model.Reasoning to the OpenAPI spec and the generated client types. Nothing is removed or renamed, so it is backwards compatible: existing configs behave as before. Model.mergeCapabilities still drops reasoning, so GET /api/model does not report capabilities.reasoning.

Related: #53202, #51846, #50257