Bug: gpt-5 defaults + @ai-sdk/openai-compatible path sends incompatible reasoning params

[andyWang1688]

What happened

When using a custom provider with @ai-sdk/openai-compatible and a gpt-5* model (e.g. gpt-5-codex), OpenCode sends reasoning params that are incompatible with some OpenAI-compatible backends.

I consistently get:

• Unsupported parameter: reasoningSummary
• (or) Unsupported parameter: reasoningEffort

Why this looks like an OpenCode bug

From source behavior:

1. OpenCode injects GPT-5 defaults in ProviderTransform.options:
   • reasoningEffort = "medium"
   • reasoningSummary = "auto"
2. For @ai-sdk/openai-compatible, OpenCode uses sdk.languageModel(...).
3. In AI SDK openai-compatible provider, languageModel maps to chat model (/chat/completions) rather than OpenAI Responses semantics.
4. reasoningSummary is not a standard chat-compatible field and can be forwarded as an unsupported top-level param for some backends.

By contrast, OpenAI account/provider works because OpenCode’s openai loader uses sdk.responses(...), and OpenAI responses model maps these options to reasoning: { effort, summary }.

Minimal repro

OpenCode version

1.2.17

Config (reduced)

{
  "provider": {
    "packycode-k1": {
      "npm": "@ai-sdk/openai-compatible",
      "options": {
        "baseURL": "https://codex-api.packycode.com/v1"
      },
      "models": {
        "k1-gpt-5-codex": {
          "id": "gpt-5-codex",
          "reasoning": false
        }
      }
    }
  }
}

Run

opencode --model packycode-k1/k1-gpt-5-codex --prompt "ping"

Actual

Request fails with unsupported parameter error (reasoningSummary / reasoningEffort).

Expected

OpenCode should not emit incompatible reasoning params for openai-compatible chat backends, or should map them correctly for responses-compatible backends.

Additional validation

Against the same backend:

• POST /v1/responses with:

  { "model": "gpt-5-codex", "input": "ping", "reasoning": { "effort": "high", "summary": "auto" } }

  succeeds.

• POST /v1/responses with top-level:

  { "reasoningEffort": "high", "reasoningSummary": "auto" }

  fails (Unsupported parameter).

So the backend supports reasoning controls, but not in OpenCode’s emitted shape for this path.

Suggested fix

At least one of:

1. Do not auto-inject reasoningSummary/reasoningEffort for @ai-sdk/openai-compatible by default.
2. Add provider capability/compatibility gating before injecting GPT-5 defaults.
3. Support a config switch like wire_api = "responses" for openai-compatible providers and map reasoning to:

   "reasoning": { "effort": "...", "summary": "..." }

4. If staying on chat path, map only to compatible chat fields (e.g. reasoning_effort) and drop unsupported ones.

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• [Bug] Custom OpenAI-compatible provider errors with "Unknown parameter: 'reasoningSummary'" for GPT-5 series models #13546: Same error — custom OpenAI-compatible provider with GPT-5 series models receiving reasoningSummary/reasoningEffort params that the backend doesn't support
• Azure models fail due to reasoning_effort being sent even with --variant none #12113: Related issue — reasoning_effort being sent to Azure even when reasoning is disabled via --variant none

Please review those issues and consider adding a comment there if your situation matches, rather than opening a new one.

[tobwen]

I worked on this and made it a bit more generic.

[rekram1-node]

wait but if ur provider supports the responses api then use the

ai-sdk/openai

So for any provider u can set the npm package which is the default for provider but u can also set it for each model too and itll override provider default, so for a responses api model why not just set

“provider”: { “npm”: “openai” }

under the model definition?

[andyWang1688]

Quick update: this is resolved for me now.

What fixed it:

• For responses-based models on my custom provider, I set model-level provider.npm to @ai-sdk/openai.
• I had originally used @ai-sdk/openai-compatible for everything, which led me into the reasoning parameter mismatch path.

Suggestion for docs:

• Use @ai-sdk/openai-compatible for chat-completions style providers.
• Use @ai-sdk/openai for responses-based providers/models.
• Mention that model-level provider.npm can override provider default npm.

This clarification would make custom provider setup much more intuitive and avoid a lot of debugging.

[andyWang1688]

Posted a docs follow-up PR to make this clearer for custom provider setup:

• docs(providers): clarify npm choice for chat vs responses APIs #16974

It adds a minimal clarification in both English and zh-CN docs that:

• @ai-sdk/openai-compatible is for chat-completions style APIs (/v1/chat/completions)
• responses-based models/providers (/v1/responses) should use @ai-sdk/openai
• mixed setups can override per model via provider.npm

Hope this helps prevent the same confusion for other users.

[tobwen]

wait but if ur provider supports the responses api then use the

ai-sdk/openai

@rekram1-node Who are you replying to?

My problem is that the capabilities of the models don't get reset when switching models. When switching from GPT-5 (Codex official) to Mistral (limited) on OpenAI-compatible (which complains about those missing capabilities), the capabilities (like reasoning) don't get removed.

My draft fixes all this and takes care about model switching. But I need to refactor it.

[rekram1-node]

@tobwen I replied to OP I'm not really sure what ur describing tbh.