Reasoning channel can exhaust the whole output budget — turns end with stop_reason=max_tokens, zero text and zero tool calls

[LLLLLQ-4]

Summary

I have occured a wierd senario, the thinking channel can enter a repetition
attractor at the reasoning → action boundary. The model repeats a single short sentence —
its pending action, e.g. Let me write. / Let me run. — thousands of times until the
output budget is exhausted. The turn then ends with stop_reason: "max_tokens" and
no text and no tool call at all.

Observed behaviour:

• The repetition is confined to the tail: the reasoning prefix is coherent, then it
  locks onto one sentence and never returns.
• The repeated sentence is always the pending action verb.
• The model is aware it is looping — the text contains lines like
  I need to stop this loop. and I'm looping again. Let me just output the tool call. —
  but self-diagnosis does not break the cycle.
• Nothing bounds the thinking channel: the endpoint accepts but does not enforce
  thinking.budget_tokens (a request with budget_tokens: 64 produced the same ~10 000
  characters of thinking as sending no budget at all), and DSH does not send a thinking
  parameter for a hand-declared route. max_tokens is the only cap, and it counts
  thinking and answer together — so a runaway thinking channel consumes the whole
  allowance and leaves nothing for the answer.
• The truncated reasoning-only message is then replayed into the next request, which
  re-primes the same loop and turns one bad attempt into a self-sustaining turn.

The user-visible symptom is a turn that silently burns the full output budget and stops
mid-thought, requiring a manual "continue". In several sessions the user pasted the
looped text back and asked the agent to stop.

This also reproduces against the endpoint directly, with no DSH involved: a trivial
arithmetic word problem with max_tokens: 3000 returned 10 384 characters of thinking,
0 characters of text, and stop_reason: max_tokens.

Impact

Measured over 29 local session files:

• 44 / 135 turns ended with reason.kind: max-tokens (32.6%).
  (71 completed, 44 max-tokens, 19 aborted, 1 error.)
  • worst session: 26 / 55 (47%)
  • then 8 / 16, 6 / 16, 2 / 2, 1 / 4, 1 / 2
• 19 degenerate reasoning blocks (a single sentence repeated ≥ 100 times and a
  reasoning block > 20 000 characters). Every one produced 0 text blocks and 0 tool
  calls.
• Worst single block: one sentence repeated 7 993 times (Let me run.), 107 102 chars.
  Let me write. appears at 7 970 and 7 928 repeats in two other blocks (122 728 and
  123 155 chars). The largest block is 123 833 chars with 7 393 repeats. One block is
  114 298 chars containing only 20 distinct sentences.
• Total reasoning text across just those 19 blocks: 2 038 204 characters
  (≈ 0.5 M tokens of pure waste).

For reference, the same scan found 503 reasoning blocks ≥ 2 000 chars overall, of which
only 19 met the strict degeneration test — so this is a distinct tail, not ordinary long
thinking.

[argszero]

Thanks for the careful measurements — the distinction between "ordinary long thinking" (503 blocks ≥ 2 000 chars) and the 19 degenerate ones is the part that makes this actionable, and the per-shell/route reproduction detail is what let me check my own understanding of the mechanism against your data rather than against a guess.

The reasoning-repetition half already has a shipped remedy, and I want to be precise about what it does and does not cut, because your 19 blocks are not all the same shape.

@argszero/cordis-plugin-thinking-loop-guard@0.2.0 added exactly this last week (its source thread is #9524, a Chinese-language variant of the same collapse: 好。好。好。, Go. Go. Go.). It is an intra-call breaker: it watches the reasoning-delta stream of one model call and ends the call the moment the tail of the accumulated thinking is an exact repetition of one short period — nothing has to wait for the call to finish, so the budget is not spent first.

- insert:
    - id: thinking-loop-guard
      name: '@argszero/cordis-plugin-thinking-loop-guard'

Two numbers matter for your shape: maxRepeatedReasoningCycleChars (default 64) and minRepeatedReasoningCycleChars (default 256). Let me run. is a 12-character period and your bleeds are tens of thousands of characters, so the reported condition is inside those defaults with a wide margin. The reasoning rule differs from the plugin's visible-output rule in exactly one place, and your report is the case that forced it: a one-character period is admitted when the repeated character is a letter or a digit, because the mechanism collapses onto the shortest standalone unit, not onto a line. A bleed of a purely punctuation character is the documented miss.

The plugin ships an offline analyzer (tools/analyze-session.mjs) whose output includes a reasoningCycleSpan column per step and a coverage block naming every line type it did not parse. Running it over your 29 session files answers the useful question directly: which of the 19 degenerate blocks this rule cuts and which it does not — instead of me asserting it from the two examples in the report.

Where 0.2.0 will not help, stated plainly. The rule is exact periodicity at the tail with a period of at most 64 characters. Your "one block is 114 298 chars containing only 20 distinct sentences" is a different shape on both counts: a cycle of twenty sentences has a period far longer than 64 characters, and an irregular re-emission of the same sentence is not periodic at all. Neither is cut mid-call. The only rule that can see those is the plugin's per-call judgement (repeatRatio, 0.5, over a call of at least minReasoningChars = 2 048), which runs after the call has ended and then requires maxThinkingSteps = 3 consecutive stalled calls before it reacts. By your own classification a max_tokens turn with zero text and zero tool calls counts as one stalled call, so the first bad call still spends its whole budget — the "worst call of a session is the one nothing can interrupt" gap, one step further along. That is a real gap in the shipped rule and I am recording it as the next thing to close rather than presenting 0.2.0 as complete.

On the budget half, three readings that shape what a fix can be:

1. max_tokens counting thinking and answer together is provider-side accounting. Nothing on the client can separate the two, so no client change makes a runaway reasoning channel leave room for the answer.
2. An endpoint accepting and ignoring thinking.budget_tokens is a provider behaviour — a client can only send the parameter. It is worth knowing, though, that DSH does have an opt-in compat surface for this, so "DSH does not send a thinking parameter for a hand-declared route" is a default rather than a limitation: supportsThinkingTokenBudget together with thinkingTokenBudgetField (accepted spellings thinking_token_budget, thinking_budget, thinking_budget_tokens — packages/llm/llm-pi-ai/src/catalog.ts:130-142), and chatTemplateKwargs / chatTemplateArgs accept the template variables thinking.enabled, thinking.effort and thinking.budget (catalog.ts:158-160; the compat section is packages/llm/llm-pi-ai/README.md:105). Whether a value reaches the wire on your route is worth one experiment, but your own 64-vs-none measurement says this endpoint will not honour it either way.
3. stop_reason: max_tokens with zero text and zero tool calls is a legitimate terminal state, not a misclassification: the model genuinely emitted that many tokens. So nothing in the built-in recovery path engages, and a rule that renamed this to a context-overflow error would be stating something false about the request. That is why the only lever that works here is preventive — cut the loop while it is still being written.

One detail that matters for the replay half you raised: the break is applied through the shipped llm/invariant, with the reasoning block still open, and the interrupted blocks are preserved (this is covered by test/reasoning-breaker.spec.mjs). So the cut does not turn a reasoning-only turn into an empty one, and the truncated material is not what gets replayed to re-prime the loop.

It is a guard, not a fix: it ends the degenerate call and steers the resumed turn, and it deliberately offers no fallback model and no automatic retry. If you can share one of the 19 blocks — or the analyzer's output over those files — I will calibrate the longer-period and non-periodic shapes against it rather than against my own sessions only.

[argszero]

A plugin now cuts exactly this call: @argszero/cordis-plugin-thinking-loop-guard@0.3.1

Thanks for the numbers — the shape you measured (114,298 characters of thinking holding only twenty distinct sentences) is the one family the shipped guards cannot see. First why, then what is now available.

Why every shape rule misses it. A periodicity rule looks for a repeating cycle in the tail; your cycled layout has a period of 489 characters and the shipped cycle rule caps the period at 64, so it reports 0 at every span, and your irregular layout has no period at all. The per-call stall rules ask whether a step is stalled, and a call like this emits text, so from the outside it looks like progress. A call can therefore keep producing sentences while having nothing new to say.

What the plugin does. It measures density as a second statistic over the same characters: distinct sentence units / total sentence units, counted over the whole call. A unit is the text between sentence terminators (. ! ? 。 ！ ？ … or a newline), trimmed; units shorter than 8 characters are dropped; a call must reach 64 units before it is judged; and the rule fires below a novelty of 0.05. The measure is order-independent, which is the point — your cycled and irregular layouts measure the same.

The calibration, so you can check it rather than trust it. Your two layouts measure 0.0001 (one repeated sentence) and 0.0043 (the twenty-sentence cycle, either order). 4,043 real texts — 60 recorded reasoning blocks plus 3,983 long assistant messages — never fell below 0.885 once they reached the unit floor, and this plugin's own generated-document controls (markdown table, CSS, JSON dump, log listing, code stubs, bullet list) never below 0.35. The two sets are two orders of magnitude apart and 0.05 sits in the gap. Counting is over whole units, never substrings: on the text in #5976 the substring 好。 occurs four times while the text holds three units, because 完好。 contains it inside an ordinary word.

- insert:
    - id: thinking-loop-guard
      name: '@argszero/cordis-plugin-thinking-loop-guard'

npm: https://www.npmjs.com/package/@argszero/cordis-plugin-thinking-loop-guard

Two things it deliberately does not do, so you do not read more into it than is there:

1. It watches the reasoning channel only. The visible channel legitimately carries generated documents whose lines repeat, so its rules stay the two exact-period ones.
2. It does not reach [Bug] Agent 在超长上下文 + max reasoning effort 下陷入思考退化循环：回合零产出、无自动熔断，需手动中止（v4.1-flash；同配置 v4-flash 3000+ 步未复发） #5976's fifth form — short two-character fragments interleaved among ordinary sentences. That statistic is fragment density, not repetition share: the fragments fall under the unit floor and the ordinary sentences around them keep the share high. Pinning it needs a per-call reasoning sample to calibrate against, and a threshold picked without one would be a guess.

If the affected session file is still around, the package ships an offline analyzer that replays it through the same detector the plugin runs:

node node_modules/@argszero/cordis-plugin-thinking-loop-guard/tools/analyze-session.mjs ~/.dsh/sessions/<session>.jsonl

It prints a novelty column per call next to the existing repetition columns, so the numbers for that session can be reported directly — which is also what would let me pin the fragment case instead of estimating it.

[LLLLLQ-4]

Thanks. My DSH now can detect such loop and terminate it.