fix(translate): add qwen/qwen3.8-max output-token cap (32768) - #974
fix(translate): add qwen/qwen3.8-max output-token cap (32768)#974Symbiomancer wants to merge 1 commit into
Conversation
qwen/qwen3.8-max was onboarded to the catalog (#907) and promoted to the high cluster as claude_code's rank-1 AA Agentic Index arm, but never got a modelMaxOutputTokens entry. Claude Code requests max_tokens=64000, which the emit layer then clamped to the 8192 OSS fallback; Qwen3-Max thinking consumes most of that budget, so every agentic turn ended in finish_reason=length and the client entered an auto-resume loop until it surfaced 'Claude's response exceeded the 64000 output token maximum' (prod session 5842e58e-0d13-4901-addd-8afb5b31965d, 2026-08-20 ~22:10Z, two consecutive turns truncated at ~2.9k visible output tokens). Qwen3-Max family serves 32k output on Fireworks (qwen3p8-max); add the cap entry so large requests pass through instead of being truncated 4x. Same bug class as the kimi-k3 fix; other still-absent OSS rows (deepseek-v4-pro/flash, minimax-m3) keep the 8192 fallback until their real ceilings are verified.
|
Claude finished @Symbiomancer's task —— View job Posted one advisory comment-length suggestion on |
workweave-bot
left a comment
workweave-bot
left a comment
There was a problem hiding this comment.
Advisory only — comment-length nits. Won't block merge.
| // Claude Code turn requesting max_tokens=64000 was clamped to the 8192 | ||
| // fallback. Qwen3-Max serves 32k output on Fireworks (qwen3p8-max); every | ||
| // agentic turn ended in finish_reason=length and an auto-resume loop until | ||
| // the client surfaced "response exceeded the 64000 output token maximum". | ||
| func TestOpenAISameFormat_ExplicitMaxTokensClampsToQwen38MaxCeiling(t *testing.T) { |
There was a problem hiding this comment.
| // Claude Code turn requesting max_tokens=64000 was clamped to the 8192 | |
| // fallback. Qwen3-Max serves 32k output on Fireworks (qwen3p8-max); every | |
| // agentic turn ended in finish_reason=length and an auto-resume loop until | |
| // the client surfaced "response exceeded the 64000 output token maximum". | |
| func TestOpenAISameFormat_ExplicitMaxTokensClampsToQwen38MaxCeiling(t *testing.T) { | |
| // Regression: absent modelMaxOutputTokens entry clamped max_tokens=64000 to | |
| // the 8192 fallback; every turn truncated (finish_reason=length loop). |
Was 5 lines narrating the full incident; the essential WHY fits in two.
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Want higher recall? High effort reviews run extra passes and find more bugs. A team admin can switch effort levels in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 8ff3f7d. Configure here.
| // Qwen3-Max family serves 32k output on Fireworks (qwen3p8-max). Without | ||
| // this entry a Claude Code max_tokens=64000 turn was clamped to the 8192 | ||
| // fallback and truncated every agentic turn (finish_reason=length loop). | ||
| "qwen/qwen3.8-max": 32768, |
There was a problem hiding this comment.
Wrong Qwen output-token ceiling
Medium Severity
The new qwen/qwen3.8-max entry in modelMaxOutputTokens sets the ceiling to 32768, but the Qwen3.8-Max model card (and Fireworks listings) document a 131072 output limit. Claude Code’s max_tokens=64000 requests still clamp below the real ceiling, so thinking-heavy turns can keep hitting finish_reason=length and the same truncate→resume loop this change aimed to stop.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit 8ff3f7d. Configure here.
|
Reviews (1): Last reviewed commit: "fix(translate): add qwen/qwen3.8-max out..." | Re-trigger Greptile |
|
Reviews (2): Last reviewed commit: "fix(translate): add qwen/qwen3.8-max out..." | Re-trigger Greptile |
2 participants
Incident
Prod Claude Code session
5842e58e-0d13-4901-addd-8afb5b31965d(2026-08-20 ~22:10Z) got a 👎 with:Router telemetry shows the client requested
claude-opus-5with max_tokens=64000; the HMM policy routed toqwen/qwen3.8-maxon Fireworks (hmm_policy(... fallback to 'high'; AA Agentic Index roster arm 'qwen/qwen3.8-max' (harness='claude_code', rank=1, eligible=4/4))). Both observed turns came back truncated:resp_output_tokens≈ 2913 / 2957,upstream_finish_reason: length,resp_stop_reason: max_tokensRoot cause
qwen/qwen3.8-maxwas onboarded in #907 and promoted tohighas claude_code's rank-1 arm, but has nomodelMaxOutputTokensentry, so the emit layer clamps the client's 64000 →defaultMaxOutputTokenCap= 8192. Qwen3-Max thinking consumes most of that budget, leaving ~2.9k visible tokens per turn.Fix
Add
"qwen/qwen3.8-max": 32768(Qwen3-Max family output ceiling on Fireworks'qwen3p8-max; adjust if the model card states otherwise). Same bug class as the kimi-k3 entry — regression test mirrorsTestOpenAISameFormat_ExplicitMaxTokensClampsToKimiK3Ceilingand covers both the over-cap clamp (64000 → 32768) and under-cap passthrough (16384 unchanged). Verified red without the map entry, green with it; fullgo test ./internal/translate/passes.Follow-up (not in this PR)
Other rostered OSS arms still inherit the 8192 fallback:
deepseek/deepseek-v4-pro(medium),deepseek/deepseek-v4-flash+minimax/minimax-m3(low). Their real ceilings need verification before adding entries — same silent-truncation risk applies.