Repository navigation
Bug: claude-opus-4.7 via GitHub Copilot fails with 'output_config: Extra inputs are not permitted' #24527
Description
Activity
This issue might be a duplicate of existing issues. Please check:
- claude-opus-4.7 via GitHub Copilot fails with thinking.type.enabled not supported #23500: Same model (claude-opus-4.7) and provider (GitHub Copilot) failing with unsupported request body fields — root cause is the same (opencode sending fields that GitHub Copilot's claude-opus-4.7 proxy rejects)
- 1.4.10 breaks Haiku through GitHub Copilot #23342: Same error pattern ("Extra inputs are not permitted") via GitHub Copilot, different field (eager_input_streaming)
- Copilot: output_config.effort "max" is not supported by model claude-opus-4.6 #22788: Related output_config issue with GitHub Copilot rejecting unsupported output_config values
If these don't fully cover your case, please add a note on what's different so maintainers can track it separately.
Reacted by jimicze@github-actions no, its different bug
Response to Duplicate Check
After thoroughly investigating all three referenced issues, I can confirm this is not a duplicate of any of them. Here is a detailed breakdown:
#23500 —
claude-opus-4.7+thinking.type.enabled not supportedSuperficially similar: Same model (
claude-opus-4.7) and same provider (github-copilot).Why it is NOT the same:
- Different error message: claude-opus-4.7 via GitHub Copilot fails with thinking.type.enabled not supported #23500 errors with
"thinking.type.enabled" is not supported for this model. Use "thinking.type.adaptive" and "output_config.effort" to control thinking behavior.Our issue errors withoutput_config: Extra inputs are not permitted. - Different trigger condition: claude-opus-4.7 via GitHub Copilot fails with thinking.type.enabled not supported #23500 only occurs when using a reasoning/thinking variant (effort level
highormax). Our issue occurs on every single request, regardless of reasoning settings — no thinking/reasoning mode was configured at all. - Different root cause: claude-opus-4.7 via GitHub Copilot fails with thinking.type.enabled not supported #23500 is caused by
claude-opus-4.7being missing from theisAnthropicAdaptivelist inpackages/opencode/src/provider/transform.ts. OpenCode sends the legacythinking.type=enabledformat, but opus-4.7 requiresthinking.type=adaptive. The fix would be to addopus-4.7to that list. Our issue is aboutoutput_configbeing sent unconditionally (even without any reasoning mode), and the model rejecting the entire field as unknown. - Different API field rejected: claude-opus-4.7 via GitHub Copilot fails with thinking.type.enabled not supported #23500 rejects
thinking.type=enabled; ours rejectsoutput_configitself.
In short: #23500 is a reasoning-mode misconfiguration. Our issue is
output_configbeing sent to a model that does not accept it at all, even without reasoning.
#23342 — Haiku 4.5 +
eager_input_streaming: Extra inputs are not permittedSuperficially similar: Same error pattern (
Extra inputs are not permitted).Why it is NOT the same:
- Different model entirely: 1.4.10 breaks Haiku through GitHub Copilot #23342 affects Claude Haiku 4.5, not
claude-opus-4.7. - Different rejected field: 1.4.10 breaks Haiku through GitHub Copilot #23342 is about
tools.0.custom.eager_input_streaming— a field injected into the tool definitions in the request body. Our issue is aboutoutput_config— a top-level field in the request body. - Different OpenCode version / regression: 1.4.10 breaks Haiku through GitHub Copilot #23342 was introduced in OpenCode 1.4.10 as a regression (worked in 1.4.9). Our issue is not version-specific in that way.
- Different root cause: 1.4.10 breaks Haiku through GitHub Copilot #23342 is caused by OpenCode adding
eager_input_streamingto tool schemas, which GitHub Copilot's proxy strips or rejects. Our issue is about a top-leveloutput_configparameter being sent unconditionally.
In short: The only commonality is the generic Pydantic error text
Extra inputs are not permitted. The field, model, and root cause are all different.
#22788 —
claude-opus-4.6+output_config.effort "max" not supportedSuperficially similar: Both involve
output_configand GitHub Copilot.Why it is NOT the same — this is the most important distinction:
- Fundamentally different API rejection type:
- Copilot: output_config.effort "max" is not supported by model claude-opus-4.6 #22788: The
output_configfield is accepted by the API. The error is about an invalid value inside it:output_config.effort "max" is not supported; supported values: [low medium high]. The field itself is fine, just the valuemaxis disallowed. - Our issue: The
output_configfield is entirely rejected as an unknown/extra field (output_config: Extra inputs are not permitted). The model does not acceptoutput_configat all, regardless of its value.
- Copilot: output_config.effort "max" is not supported by model claude-opus-4.6 #22788: The
- Different model: Copilot: output_config.effort "max" is not supported by model claude-opus-4.6 #22788 is
claude-opus-4.6; ours isclaude-opus-4.7. - Different implication for fix: Copilot: output_config.effort "max" is not supported by model claude-opus-4.6 #22788 can be fixed by capping
efforttohighinstead ofmax. Our issue requires not sendingoutput_configat all forclaude-opus-4.7in non-reasoning contexts. - Different trigger: Copilot: output_config.effort "max" is not supported by model claude-opus-4.6 #22788 occurs specifically when the user selects the
maxreasoning variant. Our issue occurs on every request with no reasoning mode selected.
In short: Same field name, completely different error semantics. #22788 = wrong value in an accepted field. Ours = field not accepted at all.
Summary Table
#23500 #23342 #22788 Our issue #24527 Model claude-opus-4.7 claude-haiku-4.5 claude-opus-4.6 claude-opus-4.7 Provider github-copilot github-copilot github-copilot github-copilot Rejected field thinking.typeeager_input_streamingoutput_config.effort(value)output_config(field itself)Error type Wrong format Unknown field in tools Invalid value Unknown top-level field Requires reasoning mode Yes (high/max) No Yes (max) No — fails always Root cause Missing model in isAnthropicAdaptivelisteager_input_streamingadded to tool schemasmaxeffort not supported by copilotoutput_configsent unconditionally without reasoningFix Add opus-4.7to adaptive listRemove eager_input_streamingfrom toolsCap effort at highOmit output_configwhen model rejects it / not in reasoning mode
Additional Technical Detail for Our Issue
From the OpenCode log (
~/.local/share/opencode/log/2026-04-26T174704.log):- The error occurs twice per message attempt (first try + immediate retry), both failing identically
- The request body includes
max_tokens: 32000— this is the orchestrator agent, not a simple query - No thinking/reasoning was configured in the session
- The error is thrown synchronously before any tokens are streamed:
+1699ms/+1869ms— immediate API rejection, not a mid-stream failure - Stack trace points to
chunk-3f8tjbdd.js:6:14583(bundled OpenCode core) - After two failures the session enters
idlestate and the user must retry manually
The fix should conditionally omit
output_configfrom the request when:- No reasoning/thinking mode is active, OR
- The model is
claude-opus-4.7(or similar) which does not accept this field without reasoning context, OR - Implement graceful retry without
output_configupon receiving this specific error response
- Different error message: claude-opus-4.7 via GitHub Copilot fails with thinking.type.enabled not supported #23500 errors with
can confirm I'm seeing the exact same issue with
1.14.26Reacted by Maxence Rossignol and jimiczeHow are you hitting it? Does github copilot not support setting reasoning for opus 4.7 at all?
How are you hitting it? Does github copilot not support setting reasoning for opus 4.7 at all?
I'm under the impression they've removed being able to set reasoning for opus 4.7, even via
copilot-clithey've removed being able to change it.There was an option to set it only to medium.
But users are pissed off... By this limitation, they were unable to see this option, because it's the only one, and set 'medium' as the default, hiding the options to see it / change it.
Clarification for @rekram1-node — How We Hit It + Config Details
To directly answer your question: No, GitHub Copilot no longer supports setting reasoning for
claude-opus-4.7at all.How We Were Hitting It
At the time of the bug, our OpenCode config had:
"agent": { "plan": { "model": "github-copilot/claude-opus-4.7", "reasoningEffort": "medium" } }
reasoningEffort: "medium"— not because we chose medium, but because it was the only option GitHub Copilot exposed forclaude-opus-4.7. There was nohighormaxavailable for this model via Copilot.This causes OpenCode to include
output_configin the API request body. GitHub Copilot then silently removed all reasoning support forclaude-opus-4.7, includingmedium— and now rejectsoutput_configentirely withExtra inputs are not permitted.The Timeline
- GitHub Copilot exposed only
mediumreasoning effort forclaude-opus-4.7 - Users set
reasoningEffort: "medium"as it was the only available option - GitHub Copilot removed reasoning support entirely for
claude-opus-4.7— includingmedium - Now any request with
output_configin the body is rejected, breaking all sessions using this model with anyreasoningEffortsetting
Why This Is an OpenCode Issue (Not Just a User Config Error)
The failure mode is silent and confusing:
- OpenCode accepts
reasoningEffort: "medium"in config without warning - When GitHub Copilot removes support, the session fails with a cryptic API error
- There is no fallback, no warning, no graceful degradation
- The user has no indication from the error that removing
reasoningEffortfrom config would fix it
Suggested Fix
- Retry without
output_config: On receivingExtra inputs are not permittedforoutput_config, retry without it and emit a user-visible warning - Capability detection: Track which models/providers support
output_configand skip it when not supported - Config validation warning: When
reasoningEffortis set for a model/provider known not to support it, warn at startup rather than failing silently at runtime
Workaround for Affected Users
Remove
reasoningEffortfrom theclaude-opus-4.7agent config inopencode.json:"agent": { "plan": { "model": "github-copilot/claude-opus-4.7" } }
This stops OpenCode from sending
output_configin the request and the model works normally.- GitHub Copilot exposed only
@jimicze undo whatever config change u made to get around bug and show me
opencode debug configI think a plugin or soemthing is causing errors for you, output_config should work@rekram1-node Here is
opencode debug config:{ "$schema": "https://opencode.ai/config.json", "agent": { "plan": { "model": "github-copilot/claude-opus-4.7", "reasoningEffort": "medium", "options": { "reasoningEffort": "medium" }, "permission": {} }, "build": { "model": "github-copilot/claude-sonnet-4.6", "reasoningEffort": "high", "options": { "reasoningEffort": "high" }, "permission": {} }, "general": { "model": "github-copilot/claude-sonnet-4.6", "reasoningEffort": "high", "options": { "reasoningEffort": "high" }, "permission": {} }, "explore": { "model": "github-copilot/claude-sonnet-4.6", "reasoningEffort": "medium", "options": { "reasoningEffort": "medium" }, "permission": {} } }, "provider": { "lmstudio": { "name": "LM Studio (local)", "npm": "@ai-sdk/openai-compatible", "options": { "baseURL": "http://127.0.0.1:1234/v1" }, "models": { ... } } }, "mcp": { "playwright": { "type": "local", "command": ["npx", "@playwright/mcp@latest"] }, "context7": { "type": "local", "command": ["npx", "-y", "@upstash/context7-mcp@latest"] } }, "compaction": { "auto": true, "prune": true, "reserved": 20000 }, "plugin": [], "username": "xxxx" }No plugins installed (
"plugin": []). Only MCP servers (Playwright and Context7).The only non-default things are:
- Custom agents with
reasoningEffortsettings - LM Studio as a local provider (not used for
claude-opus-4.7) - Two MCP servers
- Custom agents with
This may fix your issue:
0acac21I'm just not really sure how this is even possible?
Maybe you can send me a session you hit it in or soemthing?
Session has some extra log?
Here's the relevant session log excerpt (two attempts — first try + immediate retry, both fail identically):
Attempt 1 (+1699ms — immediate API rejection):
ERROR service=llm providerID=github-copilot modelID=claude-opus-4.7 agent=orchestrator mode=primary stream ERROR service=llm providerID=github-copilot modelID=claude-opus-4.7 agent=orchestrator mode=primary url: https://api.githubcopilot.com/v1/messages requestBodyValues: { model: "claude-opus-4.7", max_tokens: 32000, output_config: { effort: "medium" }, ... } AI_APICallError: output_config: Extra inputs are not permitted ERROR service=session.processor error=output_config: Extra inputs are not permitted stack: AI_APICallError at chunk-3f8tjbdd.js:6:14583Retry (+1869ms — identical failure):
ERROR service=llm providerID=github-copilot modelID=claude-opus-4.7 agent=orchestrator mode=primary url: https://api.githubcopilot.com/v1/messages requestBodyValues: { model: "claude-opus-4.7", max_tokens: 32000, output_config: { effort: "medium" }, ... } AI_APICallError: output_config: Extra inputs are not permitted ERROR service=session.processor error=output_config: Extra inputs are not permitted stack: AI_APICallError at chunk-3f8tjbdd.js:6:14583Both attempts reject instantly before any tokens stream. Session goes idle after the retry.
Also — does the fix in 0acac21 address this? From reading the patch it looks like it now reads
reasoning_effortfrom the Copilot API response dynamically, so if Copilot reports no reasoning support foropus-4.7, no variants are built andoutput_configwon't be sent. That matches exactly what we're seeing.Additional context on the agent config — at the time of the error, the
orchestratoragent was set to:"agent": { "orchestrator": { "model": "github-copilot/claude-opus-4.7", "reasoningEffort": "medium", "mode": "primary" } }
(custom
promptomitted — the rest of the spec is standard)This is why the log shows
agent=orchestrator modelID=claude-opus-4.7— it was a custom primary agent backed byopus-4.7withmediumreasoning effort. Theoutput_config: { effort: "medium" }was being sent on every request because of thereasoningEffort: "medium"setting.I unfortunately cant test this at all but I thought medium reasoning effort and adaptive reasoning are supported for that copilot model
If you use the model without a variant selected, does it work as expected?
You can try the patch using
bunx opencode-ai@devOK i will try both cases
Tested both cases:
Test A — current release,
claude-opus-4.7withoutreasoningEffort:
Works fine. Nooutput_configerror.Test B — dev build (
bunx opencode-ai@dev),claude-opus-4.7+reasoningEffort: medium:
Fix confirmed. NoExtra inputs are not permittederror.Side note: noticed slightly laggy output rendering in the dev build — output appeared character by character with noticeable delay. Not sure if that's expected or a separate regression.
Looking at the original session log, the prompt that triggered the bug was simply:
What did we do so far?No special content needed — any prompt sent to the orchestrator agent configured with
claude-opus-4.7+reasoningEffort: mediumwould reproduce it. The error fired consistently on every request (first attempt + retry, both failed withoutput_config: Extra inputs are not permitted).In case it's useful for a regression test.
Tested on both
v1.14.29(current latest) andbunx opencode-ai@dev— both seem to be working fine.@rekram1-node just noticed that it also seems to work fine on
v1.14.29(not just the dev build). Wondering if the fix from PR #24574 ("split up reasoning transforms", merged 2026-04-27) already addressed this — it landed betweenv1.14.26(where @elsammykins confirmed the bug) andv1.14.29. Was that intentional, or was there another related change?Nah that wouldnt have done anything
Alr ig we fixed it feel free to ping me on discord if it continues but ill try to monitor issue
Reacted by jimicze
Bug Report
Description
When using
claude-opus-4.7model via thegithub-copilotprovider, every LLM request fails immediately with:The model is completely unusable — no response is ever generated.
Steps to Reproduce
github-copilotprovider withclaude-opus-4.7modelExpected Behavior
The request should succeed and the model should respond normally.
Actual Behavior
The API call to
https://api.githubcopilot.com/v1/messagesis rejected with a Pydantic validation error. OpenCode includes anoutput_configfield in the request body thatclaude-opus-4.7does not accept.Log Evidence
From
~/.local/share/opencode/log/:The error occurs on every request attempt, twice per attempt (first try + retry).
Root Cause (Hypothesis)
OpenCode unconditionally includes an
output_configfield in the Anthropic Messages API request body. Theclaude-opus-4.7model as exposed via GitHub Copilot proxy (api.githubcopilot.com/v1/messages) does not support this parameter and rejects it with Pydantic strict-mode validation error.output_configappears to be a newer/experimental Anthropic API feature (possibly for extended thinking or output format configuration) not yet supported by all models or provider proxies.Suggested Fix
Conditionally omit
output_configfrom the request body when the model/provider does not support it, or implement a fallback retry without the parameter when this specific error is received.Test Results
v1.14.29claude-opus-4.7withoutreasoningEffortv1.14.18claude-opus-4.7+reasoningEffort: mediumdev (0.0.0-dev-202604281959)claude-opus-4.7+reasoningEffort: mediumEnvironment
v1.14.18(latest at time of report; current latest isv1.14.29)github-copilotclaude-opus-4.7https://api.githubcopilot.com/v1/messages