Description
Description
On the v2 CLI (opencode2, @opencode-ai/cli beta) requests to @ai-sdk/openai-compatible models go out without max_tokens, regardless of limit.output in the provider config. Stable opencode 1.18.20 with the same config sends max_tokens: 32000.
Because the field is missing, the upstream applies its own default budget. In my setup (DeepSeek V4 with thinking enabled, behind an OpenAI-compatible proxy) the effective cap was 4096 tokens: long-thinking turns spend the whole budget on reasoning and finish with finish_reason: length and empty content, at exactly 4096 output tokens. Same symptom as #46595 (Bedrock), different route.
Captured outbound body from the beta (sanitized, messages/tools omitted):
{
"model": "combo-deepseek-v4-flash",
"stream": true,
"stream_options": { "include_usage": true },
"store": false,
"prompt_cache_key": "ses_…"
}
Same session on opencode/1.18.20:
{ "model": "combo-deepseek-v4-flash", "stream": true, "max_tokens": 32000, … }
Where it goes wrong, as far as I can tell:
packages/core/src/session/runner/llm.tsbuildsLLM.request({ model, http, providerOptions, system, messages, tools, toolChoice })with nogenerationblock.packages/llm/src/protocols/openai-chat.tsfromRequestemitsmax_tokens: generation?.maxTokens, which isundefined, so the key is dropped.packages/core/src/session/runner/model.ts(withDefaults) does putlimit.outputintoroute.defaults.limits, but nothing projects it intogeneration.maxTokens. v1 did this viaProviderTransform.maxOutputTokens(min(limit.output, 32000) || 32000).
The Anthropic route (anthropic-messages.ts) is built from the same request, so it is likely affected too, but I only verified the openai-compatible path.
Related: #46595 (same root cause on Bedrock), #29363 (v1 32K cap of limit.output).
Plugins
none
OpenCode version
@opencode-ai/cli 0.0.0-beta-19086 (opencode2). Not reproducible on opencode 1.18.20.
Steps to reproduce
- Config:
"provider": { "my-proxy": { "npm": "@ai-sdk/openai-compatible", "options": { "baseURL": "https://…/v1", "apiKey": "…" }, "models": { "combo-deepseek-v4-flash": { "limit": { "context": 1000000, "output": 131072 } } } } } - Point the base URL at anything that logs request bodies (a local proxy is enough).
- Send a prompt from
opencode2: the body has nomax_tokens. Send the same prompt fromopencode1.18.20:max_tokens: 32000is present. - With a thinking model, long turns end at the provider's default output cap, reasoning only, no text.
Screenshot and/or share link
n/a (request bodies above)
Operating System
macOS 15.7.9
Terminal
n/a (not terminal-specific)
Activity
clopca commentedon Sep 5, 2026
Opened #47532 for the shared code site (
SessionModelRequest.prepareinpackages/core/src/session/model-request.ts, which is where the runner's request gets itsgenerationblock). It projectsresolved.limit.outputintogeneration.maxTokenswith hook → model defaults → route defaults → catalog limit precedence, so it covers the openai-compatiblemax_tokenspath as well as BedrockinferenceConfig.maxTokens. If you can verify it against DeepSeek V4 with thinking enabled, that would be a useful second data point.fix(core): propagate resolved output limit into model request generation
famewolf commentedon Sep 24, 2026
Additional evidence from a live v2.0.12→v2.0.15 desktop installation (2026-09-23):
Confirmed the output cap is completely dropped in both v2.0.12 and v2.0.15. With
limit.output: 4096in config, the v2 sidecar sendsmax_tokens: -1(uncapped) to the backend.Observed responses from a local llama-server (Qwen3-27B with thinking enabled via
--reasoning-format deepseek):For comparison, v1 (1.18.31) with the same config sends
max_tokens: 4096and completes in seconds.The impact with a thinking model behind an OpenAI-compatible proxy is severe: the model spends the entire (uncapped) budget on reasoning tokens, producing multi-MB responses that take minutes, then the client aborts and retries in a loop. This is the root cause of the "hang" behavior — the model IS working, just with no output cap.
Related: #51020 (part persistence wedge — a separate but compounding v2 bug where the responses are never persisted to DB).
opencode-agent commentedon Sep 27, 2026
Fix merged into
v2in #51271. It landed afterv2.0.18and will be included in the next V2 release,v2.0.19. Primary requests now send a context-fitted output-token limit to OpenAI-compatible providers, instead of omittingmax_tokensand leaving the provider to use its own default.peterxh7 commentedon Oct 26, 2026
I have the same issue.
OpenCode v2.1.4
rekram1-node commentedon Oct 27, 2026
@peterxh7 max tokens is always sent by default so either ur using a provider that doesnt support them or ur config is missing some settings