Degenerate repetition loop — single token repeated ~32k times until max_tokens (silent, reproduces across 2 model generations)

Update: this appears to be a duplicate of #68740 and #65823 (same court-token degenerate repetition). Cross-linking for the maintainers.

We found these after filing. This report does add 3 data points not present in those issues, in case they help:

1. Also reproduces on claude-opus-5 — #68740 is opus-4-8 and #65823 does not mention opus-5. The failure mode propagated across the model generation.
2. Repetition count ~31,974 (~3x the 10,613 in #65823), consistent with a different output-token ceiling.
3. Quantified occurrence rate: 1.6% (23 of 1,471 responses in the affected session) — the existing reports give counts without a denominator.

Feel free to close this as a duplicate; flagging the opus-5 propagation as a possibly-new signal for #68740 / #65823. The trigger hypothesis in #68740 (Japanese prose immediately before/around a tool call) matches our situation exactly.

Correction to the figures above. A more complete scan — recursively including subagent logs, which our initial pass missed — shows this is more widespread than first reported:

• 26 occurrences (not 23), across 2 repositories and 2 sessions on different days. The earlier "all in a single session" characterization was incorrect — it was an artifact of not walking subagent log directories (<project>/<uuid>/subagents/agent-*.jsonl).
• On one repository, ~5 occurrences at a regular ~38-minute interval.

The duplicate status (of #68740 / #65823) and the opus-5 propagation still stand. The added signal is the cross-session / cross-repo spread (not a single-session anomaly), which may be useful for the trigger hypothesis. Still no customer/third-party data included.

Follow-up: we built a post-hoc detector, and re-scanning with it surfaced some signals we had not reported. This partly answers our own "detection guidance" question — happy to hand over the script if it is useful to anyone.

Detection recipe (what actually worked)

Scanning our whole local transcript store (~/.claude/projects, 609 sessions / ~1.5 GB) takes about 5 seconds:

1. Match on tail-anchored token repetition, not on response length. Take the last ~4,000 chars, tokenize, flag if the final 8 tokens are all identical. Length thresholds are the obvious first idea but they are a proxy for the wrong property.
2. Do not run a repetition regex over the whole response. (?:(\w+)\s+){8,}$ against a 220,000-char repetition string backtracks catastrophically — one project did not finish in 10 minutes. The collapse is by definition at the tail, so a tail window is both sufficient and linear-time.
3. Recurse into subagent logs. A <project>/*.jsonl glob misses <project>/<session-uuid>/subagents/agent-*.jsonl — in our store that is 491 of 600 files. Our original undercount of 23 came from exactly this.

New signals from the re-scan

• A mid-session model switch did not clear it. Session 52e08c36 collapsed 18× on claude-opus-4-8 (last at 09:13 UTC) and then 3× on claude-opus-5 (11:24 UTC onward) — same conversation, same court token, no change in behaviour across the switch. That points at conversation state rather than model weights, consistent with the trigger hypothesis in #68740.
• A strikingly regular cadence in the other session. dce443a8: 2026-07-18T22:02:37, 22:40:25, 23:18:26, 23:56:42, 2026-07-19T00:34:34 (UTC) — inter-arrival times 37m48s / 38m01s / 38m16s / 37m52s. The first session's spacing is irregular by contrast (8–30 min). A near-constant period suggests something cyclical within the session (context growth / compaction cycle) rather than independent sampling.
• The repetition count saturates the output budget. Range 30,103–32,000 repeats; one response lands on exactly 32,000 (223,998 chars of court\n\n). The three opus-5 occurrences cluster more tightly (31,953–31,974) than opus-4-8.
• The normal prose prefix before the collapse is 0–317 chars, and 3 responses have no prefix at all — repetition from the first emitted token, i.e. it is not always a mid-sentence derailment.
• No new occurrence since 2026-07-26. The detector now runs daily; the 2026-07-31 scan over 609 sessions still reports the same 26.

Aggregate counts are unchanged from the previous comment: 26 occurrences, 2 sessions, 2 repositories, token court in 100% of cases. Still no customer or third-party data included.

Additional occurrence, matches this pattern closely:

• Model: claude-sonnet-5
• Session ID: 6e288ddc-c2d2-45d4-844d-8d592249e67e
• Repeated token: single Thai character ("บ"), not "court" — so the fixated token is session/context-dependent, not a fixed global default.
• Trigger point: immediately after two successful git commit tool calls, in the turn meant to summarize/report those commits back to the user. Response degenerated into thousands of repetitions of the one character with zero real content, ran to the output limit, formally normal (no error).
• Session shape: long-running session that had already gone through at least one prior auto-compaction, heavy structured-JSON tool I/O immediately before (reading/editing a large Python state-machine script and a JSON test file, plus multiple Read calls returning large JSON graph configs), then a git commit sequence, then the degenerate turn.
• Consistent with the "context-triggered fixation, not model-wide" theory in the OP — in our case the fixation point was right after a repetitive-structure-heavy tool-output stretch (many near-identical JSON blocks) followed by a state transition (return to prose summary), which may be a relevant trigger shape worth checking against the other reported instances.

Adding in case it helps correlate trigger conditions across sessions rather than filing a duplicate.