Repository navigation
Description
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:
- OpenCode injects GPT-5 defaults in
ProviderTransform.options:reasoningEffort = "medium"reasoningSummary = "auto"
- For
@ai-sdk/openai-compatible, OpenCode usessdk.languageModel(...). - In AI SDK openai-compatible provider,
languageModelmaps to chat model (/chat/completions) rather than OpenAI Responses semantics. reasoningSummaryis 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/responseswith:{ "model": "gpt-5-codex", "input": "ping", "reasoning": { "effort": "high", "summary": "auto" } }succeeds.
-
POST /v1/responseswith 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:
- Do not auto-inject
reasoningSummary/reasoningEffortfor@ai-sdk/openai-compatibleby default. - Add provider capability/compatibility gating before injecting GPT-5 defaults.
- Support a config switch like
wire_api = "responses"for openai-compatible providers and map reasoning to:"reasoning": { "effort": "...", "summary": "..." }
- If staying on chat path, map only to compatible chat fields (e.g.
reasoning_effort) and drop unsupported ones.
Activity
github-actions commentedon Mar 5, 2026
This issue might be a duplicate of existing issues. Please check:
reasoningSummary/reasoningEffortparams that the backend doesn't supportreasoning_effortbeing sent to Azure even when reasoning is disabled via--variant nonePlease review those issues and consider adding a comment there if your situation matches, rather than opening a new one.
tobwen commentedon Mar 8, 2026
I worked on this and made it a bit more generic.
rekram1-node commentedon Mar 10, 2026
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 commentedon Mar 11, 2026
Quick update: this is resolved for me now.
What fixed it:
Suggestion for docs:
This clarification would make custom provider setup much more intuitive and avoid a lot of debugging.
andyWang1688 commentedon Mar 11, 2026
Posted a docs follow-up PR to make this clearer for custom provider setup:
It adds a minimal clarification in both English and zh-CN docs that:
Hope this helps prevent the same confusion for other users.
tobwen commentedon Mar 11, 2026
@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 commentedon Mar 11, 2026
@tobwen I replied to OP I'm not really sure what ur describing tbh.