ACP sessions send reasoning effort "none" for gpt-5.6-sol via Zen — upstream rejects it (400: effort must be one of: minimal low medium high xhigh max)

[LucasMoskun]

Summary

When opencode is driven over ACP (opencode acp) with opencode/gpt-5.6-sol (Zen), every prompt fails before the model runs:

Provider request failed with HTTP 400: Error from provider (Console):
Upstream request failed: [400] validation failed: effort must be one of: minimal low medium high xhigh max

The same model works fine via opencode run with zero special config, so this only bites headless/embedded hosts (agent harnesses, editors) that drive opencode through ACP.

Root cause (as best we can tell)

Two mismatched pieces:

1. The models.dev catalog lists gpt-5.6-sol (and -terra, -luna) reasoning effort values as ["none","low","medium","high","xhigh","max"].
2. Zen's upstream ("Console") validates effort against minimal|low|medium|high|xhigh|max — no none.

The ACP session layer defaults the session's reasoning effort to the first catalog value (none) and sends it on every request → guaranteed 400. opencode run doesn't send an effort unless asked, which is why the CLI is unaffected. (Direct Zen POST /zen/v1/chat/completions with no effort, or with reasoning_effort: "high", both return 200 — the 400 only appears on the ACP path.)

We could not override the default from config on the affected builds — neither provider.opencode.models.<id>.options.reasoningEffort nor agent.<name>.variant changed what the ACP session sent. Workaround that worked for us: a shim between the ACP client and opencode that issues one extra call after session/new to set the session's effort to a valid value (high).

Repro

• opencode 1.18.15 (stable release) and @opencode-ai/cli 0.0.0-next-17041 — both affected, verified side by side with a minimal ACP driver
• Linux x86_64 (Ubuntu 24.04), auth via OPENCODE_API_KEY (Zen)
• Config: { "model": "opencode/gpt-5.6-sol" } (nothing else needed)
• Drive opencode via ACP: initialize → session/new → session/prompt with any text → the prompt response is:

1.18.15:    {"code": -32603, "message": "Internal error: Error from provider (Console): Upstream request failed: [400] validation failed: effort must be one of: minimal low medium high xhigh max", "data": {"service": "session", "errorName": "APIError"}}
next-17041: {"code": -32603, "message": "Internal error: Provider request failed with HTTP 400: Error from provider (Console): Upstream request failed: [400] validation failed: effort must be one of: minimal low medium high xhigh max", "data": {"service": "session", "errorName": "provider.invalid-request"}}

• Control: opencode run -m opencode/gpt-5.6-sol "say ok" → works on both builds; --variant high → works

Expected

Either the catalog's first/default effort for these models should be one Zen accepts (minimal instead of none), or Zen should accept/map none, or ACP sessions shouldn't pin an effort the user never chose. Any one of the three fixes it; catalog + gateway agreeing would fix it everywhere at once.

Related

• Opencode Zen Deepseek V4 Flash Free (new) reasoning_effort produces wrong behaviour #40777 (reasoning_effort wrong behaviour on another Zen model) — possibly the same defaulting logic.

[github-actions]

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

• github-copilot/kimi-k2.7-code: reasoning_effort sent to endpoint that rejects it #37728: Same class of bug — reasoning_effort value advertised in the model catalog is rejected by the actual upstream endpoint with a 400. That issue covers the Copilot/Kimi path; this one covers the ACP/Zen path, but the root cause (catalog metadata out of sync with what the provider actually accepts) is the same.
• Opencode Zen Deepseek V4 Flash Free (new) reasoning_effort produces wrong behaviour #40777: Already referenced in the issue — reasoning_effort wrong behaviour on another Zen model, possibly the same defaulting logic.
• --variant silently ignored when the value is not in the model's reasoning_options #40182: --variant silently ignored when the value is not in the model's reasoning_options — related to how variant/effort values are resolved and validated before sending.