You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
v2 (opencode2): max_tokens never sent for @ai-sdk/openai-compatible models, limit.output ignored, thinking turns truncate at provider default #47398
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):
packages/core/src/session/runner/llm.ts builds LLM.request({ model, http, providerOptions, system, messages, tools, toolChoice }) with no generation block.
packages/llm/src/protocols/openai-chat.tsfromRequest emits max_tokens: generation?.maxTokens, which is undefined, so the key is dropped.
packages/core/src/session/runner/model.ts (withDefaults) does put limit.output into route.defaults.limits, but nothing projects it into generation.maxTokens. v1 did this via ProviderTransform.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.
Opened #47532 for the shared code site (SessionModelRequest.prepare in packages/core/src/session/model-request.ts, which is where the runner's request gets its generation block). It projects resolved.limit.output into generation.maxTokens with hook → model defaults → route defaults → catalog limit precedence, so it covers the openai-compatible max_tokens path as well as Bedrock inferenceConfig.maxTokens. If you can verify it against DeepSeek V4 with thinking enabled, that would be a useful second data point.
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: 4096 in config, the v2 sidecar sends max_tokens: -1 (uncapped) to the backend.
Observed responses from a local llama-server (Qwen3-27B with thinking enabled via --reasoning-format deepseek):
1.65MB response body over 7m38s
1.63MB over 4m9s
586KB over 8m15s
Multiple 499 client aborts at ~5-6min (opencode client timeout)
For comparison, v1 (1.18.31) with the same config sends max_tokens: 4096 and 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).
Fix merged into v2 in #51271. It landed after v2.0.18 and 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 omitting max_tokens and leaving the provider to use its own default.
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