@qwen-code /triage

Addressed the requested changes in the latest force-push.\n\nWhat changed:\n- GeminiChat now checks the per-request maxOutputTokens before automatic escalation. If the request already uses the escalated limit, it does not emit another identical escalation retry or make a duplicate stream call.\n- The escalation log now reports the actual starting limit when one is present, instead of always saying capped default.\n- Added a core regression test for the sticky-limit case, alongside the existing agent-headless test that verifies the escalated limit is carried into the next agent round.\n- Updated the PR body to the repository template.\n\nValidated on Windows:\n-
pm run test --workspace=packages/core -- src/core/geminiChat.test.ts\n-
pm run test --workspace=packages/core -- src/agents/runtime/agent-headless.test.ts\n-
pm run typecheck --workspace=packages/core\n-
px prettier --check packages/core/src/core/geminiChat.ts packages/core/src/core/geminiChat.test.ts packages/core/src/agents/runtime/agent-core.ts packages/core/src/agents/runtime/agent-headless.test.ts\n-
px eslint packages/core/src/core/geminiChat.ts packages/core/src/core/geminiChat.test.ts packages/core/src/agents/runtime/agent-core.ts packages/core/src/agents/runtime/agent-headless.test.ts --max-warnings 0\n- git diff --check\n\nOne verification attempt ran two coverage-enabled Vitest targets in parallel and hit a coverage temp-file race after the tests had passed. Re-running the affected target by itself passed.

Local verification (merge reference)

I built cd8d4f1b75 and verified the fix live in the real binary — driving a real /fork (which runs AgentCore in-process) through tmux against a local OpenAI-compatible mock that truncates the first response (finish_reason: length → MAX_TOKENS), so I could watch the max_tokens each round actually sends. Linux, Node 22.22.2, head cd8d4f1b75 (merge-base ce4b0cf6).

Verdict: works as designed and reproduces/fixes #4964 on the wire. The escalated output budget is now preserved into the next agent round after a tool call; the re-escalation guard and the warm-escalation logic are both correct. LGTM.

1. Live A/B in the real binary — the headline

Same fork scenario on the pre-fix (merge-base) vs PR binary. The mock records the max_tokens of every request the fork's AgentCore makes:

The only behavioral difference is round 2's budget: pre-fix drops back to the 8K cap (so the next response would truncate again — exactly #4964), and the PR keeps the 64K escalated limit warm. Verified end-to-end through the real AgentCore round loop, not just unit mocks.

2. GeminiChat escalation also confirmed live

A separate headless -p run (mock truncates the first reply) shows the escalation firing in the real binary: request 1 max_tokens=8000 (length) → request 2 max_tokens=64000. So the RETRY event now carrying maxOutputTokensEscalated (which AgentCore reads into its sticky limit) works on the real path.

3. PR test plan — green

4. Mutation — both new tests are non-vacuous

Reverting agent-core.ts + geminiChat.ts to merge-base (keeping the PR's tests) fails exactly the two new tests:

× agent-headless › keeps automatic max token escalation warm for the next agent round
× geminiChat    › should not re-escalate when the request already uses the escalated output limit
   (199 passed | 2 failed)

So the sticky-carry and the re-escalation guard are each genuinely guarded.

Notes

• Re-escalation guard (shouldEscalateMaxOutputTokens: skip when the request already sits at/above the escalated limit): verified via the new geminiChat unit test + the mutation above. It's a within-round GeminiChat decision, so I leaned on the unit test rather than a separate live capture.
• Scope is AgentCore-only, by design. In a plain -p main-loop run the next turn goes back to 8000 (the main loop doesn't carry the sticky limit) — that's expected; this PR targets the agent runtime, which is where Recover from the previous truncation caused by the max_tokens limit. #4964 lives.
• The trailing 8000 request I saw after the fork completed is a post-completion main-loop turn (identical on both builds), not an AgentCore round — it doesn't affect the result.

Good to merge. The behavior is correct, reproduced and fixed on the real wire via the AgentCore fork path, with green and non-vacuous tests.

× agent-headless › keeps automatic max token escalation warm for the next agent round
× geminiChat    › should not re-escalate when the request already uses the escalated output limit
   (199 passed | 2 failed)

@qwen-code /triage

Thanks for the PR!

Template looks good ✓ — all required headings present, bilingual, test plan clear.

On direction: This is a clean bug fix for #4964 — headless agent rounds lose the escalated output-token budget after a tool call, causing repeated truncation. The CHANGELOG has recent related work (stabilize truncated tool retry keys #4970, layered tool-output truncation #4880), confirming this is an active area. Solidly in scope.

On approach: The scope is tight — 150 additions across 4 files, two changes that map 1:1 to the two failure modes:

1. agent-core.ts carries the escalated limit into subsequent rounds via stickyMaxOutputTokens — fixes the round-to-round budget loss
2. geminiChat.ts skips re-escalation when the request already sits at the escalated limit — prevents duplicate API calls

This is about as minimal as it gets. The stickyMaxOutputTokens scoping (AgentCore only, not the main conversation loop) is correct by design. Moving on to code review. 🔍

— Qwen Code · qwen3.7-max

Code Review

Independent proposal matches the PR: track escalated limit across agent rounds via a sticky variable, and guard against duplicate escalation in GeminiChat. The diff implements exactly that.

No blockers. The logic is clean:

• stickyMaxOutputTokens in AgentCore captures maxOutputTokensEscalated from retry events and injects it into subsequent rounds' config. Scoped to _runReasoningLoopInner (agent runtime only), which is correct — the main conversation loop intentionally does not carry it.
• Re-escalation guard in GeminiChat (shouldEscalateMaxOutputTokens) correctly handles three cases: no limit set (escalate), below escalated limit (escalate), at/above escalated limit (skip). Prevents duplicate API calls when the sticky limit from a prior round already matches the escalation target.
• The maxOutputTokensEscalated field on the retry event is a clean signal carrier — no new coupling between layers.

Tests are non-vacuous: the new agent-headless test verifies round-2 gets the escalated limit, the new geminiChat test verifies no duplicate escalation when already at the limit. CI mutation (by maintainer) confirmed both tests fail when the fix is reverted.

Test Results

Real-Scenario Test (tmux)

The bug requires a provider that returns finish_reason: MAX_TOKENS to trigger escalation — not reproducible against a live API without a mock provider. Basic smoke test confirms no CLI regression. The maintainer (wenshao) already performed comprehensive live A/B testing on Linux with a mock provider, confirming the fix end-to-end on the wire:

CLI smoke test output (headless -p 'say hello'):

$ npm run dev -- -p 'say hello'

> @qwen-code/[email protected] dev
> node scripts/dev.js -p say hello

DEV is set to true, but the React DevTools server is not running. Start it with:

$ npx react-devtools

Hello! How can I help you today?

No errors, no regression.

— Qwen Code · qwen3.7-max

Reflection

This is a textbook bug fix. The problem is real and well-documented (#4964), the fix is minimal (150 lines, 2 source files), and the approach is the obvious one — carry the escalated limit forward, don't re-escalate when already there.

Looking back at my independent proposal from Stage 2: the PR matches it exactly. I can't find a simpler path. The two changes (sticky carry in AgentCore, re-escalation guard in GeminiChat) each address one failure mode, and neither adds complexity that doesn't directly solve the problem.

The tests are honest — both new tests fail when the fix is reverted, and the 201-test suite is clean. CI is green across all three platforms. The maintainer's live wire-level A/B testing (documented in a comment on this PR) provides the definitive proof that the fix works end-to-end.

Risk is low: the sticky limit is scoped to AgentCore's reasoning loop, so the main conversation loop is unaffected. The only tradeoff — keeping a truncated partial response instead of making an identical duplicate API call — is clearly the right choice.

Verdict: Approve. Clean fix, real bug, well-tested, ready to ship. ✅

— Qwen Code · qwen3.7-max