Runaway output: model repeats fixed string "court placeholder" thousands of times, exhausting output tokens (long-running session, large context)

Your correlation analysis is the useful part here, and it points at a lever you can pull today even without a deterministic repro.

The runaway you're seeing (a fixed token getting mass-repeated until the 64k output budget is exhausted) is the classic long-context degeneration / repetition loop failure mode. It is not specific to the court placeholder string — that's just whatever low-entropy continuation the sampler latched onto. The thing that matters in your logs is the conditions you already isolated: it first appeared at ~275k cumulative tokens and got monotonically worse as context grew toward ~994k (right up against the 1M ceiling), driven by a 61-cycle polling loop with no compaction. Generation quality degrading as you approach the window ceiling is consistent with that failure mode, so the practical question is "how do I keep the session away from the ceiling," because that's the part a user can actually control.

Concrete levers, in order of leverage:

1. Cap the window at 200k if you don't strictly need 1M.
CLAUDE_CODE_DISABLE_1M_CONTEXT=1 removes the 1M variant entirely (it disappears from /model) and keeps you at 200k. This matters for two independent reasons:

• It keeps the session structurally out of the near-1M degradation zone you correlated with.
• With a 200k window, compaction kicks in far earlier, so per-turn reprocessed context stays an order of magnitude smaller. That also slows weekly-quota burn as a side effect, which Opus-1M users on long sessions tend to notice separately.

One gotcha if you try this: in v2.1.153+ the model you picked via /model (including opus[1m]) is persisted to the model field in settings and reloaded on new sessions — /clear does not clear it. So if you've ever selected a [1m] variant, also check that neither your settings model field nor ANTHROPIC_DEFAULT_OPUS_MODEL ends in [1m], or the alias will keep forcing 1M regardless of the env var. (Source: the code.claude.com/docs/en/model-config Extended context section.)

2. If you genuinely need the large window, compact proactively instead of letting it drift to 994k.
Your first occurrence was at 275k with zero compaction events. A periodic polling loop that never compacts is the context-growth engine here. /compact (or /clear at natural boundaries) before you cross ~600–700k keeps you out of the part of the window where this shows up. Trimming or summarizing the large tool results from the polling loop before they accumulate has the same effect.

3. Reduce the polling-loop blast radius.
61 tool-call/result cycles before the first occurrence is a lot of raw result text glued into context. If the loop is polling for a condition, lowering frequency or having the loop return a compact status instead of full payloads cuts the accumulation that's pushing you toward the ceiling.

None of this is a root-cause fix — the model emitting 10,613 repeats of a meaningless token in one turn is a generation-side problem, and the durable fix would be on the Claude Code / model side: a runtime guard that detects an identical-substring run exceeding N repeats and aborts the turn early, instead of letting it burn the full 64k output budget. That detection is cheap and would cap the worst-case cost even when the underlying degeneration happens. Worth filing/keeping as the actual ask, separate from the user-side mitigations above.

If you can capture the exact cumulative-token count at the moment the first court placeholder appears across a few more occurrences, that single number (does it cluster, e.g. always >250k?) would be the strongest signal for a deterministic repro.

Thank you for the technical explanation. However, I want to be direct:
This is your bug, not my problem to work around. I should not have to disable features, run manual compaction commands, or monitor token counts to prevent Claude from malfunctioning and consuming my entire usage limit. That is Anthropic's responsibility, not mine.
Giving users a list of workarounds instead of fixing the bug looks like you're shifting the blame onto the customer. When your own software enters an infinite loop and burns through a paid usage limit, that is effectively taking money from users without delivering a service — and that looks a lot like fraud.
The fix is simple and you even described it yourself: add a runtime guard that detects repeated identical output and stops generation automatically. Do that. Don't tell paying users to manage your broken software for you.
I want my usage limit restored. Your own analysis confirms this was caused entirely by a bug in Claude, not by anything I did.

Corroborating report — same failure mode, plus one data point this issue notes it lacks.

Environment: Claude Opus 4.8 (1M context), Claude Code on macOS (Darwin 25.5.0). Long-running self-paced agent loop running the same ~8-step prompt once per turn over many near-identical iterations (a database audit, one record per turn). Each turn is tool-heavy: SSH/psql, multiple MCP calls, image reads.

Symptom matches exactly: a normal response, then the text collapses into the same fixed string repeated until the output-token limit is hit and the turn dies. Observed the court token mass-repeated (the court placeholder string described here). It happened twice in one session.

Added data point — both occurrences were post-compaction. The first occurrence reported here had 0 compaction events and grew toward ~994k tokens. Ours happened in a session that had already been auto-compacted, i.e. in a smaller reconstructed context, and then recurred. So compaction does not prevent it, and it is not strictly a function of approaching the 1M ceiling — the common factor in our case was the repetitive, high-tool-frequency loop structure rather than raw context size.

Small difference in where it started: in our case the degeneration began at a prose/section transition immediately before a planned tool call (right after writing a ## Step 2 header), rather than appended after a completed tool call. Same prose↔tool boundary, slightly different side.

No deterministic repro on our end either — same probabilistic, state-dependent behavior.

We hit the same runaway repetition ("court") and went through our raw transcripts. I filed the occurrence data as #79011 — 37 bursts across 3 sessions, all at ≥434k input tokens, and zero occurrences on Opus 4.7 (17,525 turns) under the same workload — plus the recovery step that worked for us. Linking here since it looks like the same bug.

Corroborating report — and honestly, I'm angry about this at this point.

This has been open for months. It hits multiple independent users, across different platforms and workloads, all describing the exact same collapse. And there is still no assignee. Nobody at Anthropic has taken ownership of a bug that outright kills long-running sessions.

We've hit this exact failure repeatedly — the model degenerating mid-session into an endless repeated token until the turn dies — and it is not some rare, exotic edge case. It has happened enough times, in ordinary long sessions, including while the model was doing something as basic as writing a session handoff summary, that we now genuinely dread running Opus for anything long. That is not how a product we pay for should behave.

And meanwhile, new flagship models and features keep shipping on schedule. A core, currently-supported model has been left broken like this for months, with reports stacking up, and it still hasn't been assigned to anyone. That ordering — new launches on time, a basic reliability bug ignored — tells us where the actual priorities are. A company that lets its main model sit broken like this while moving on to the next release is not a company we can trust with production work.

At minimum, ship a runtime guard now: detect a run of identical/near-identical output and abort the turn instead of burning the full output budget. Then fix the actual root cause. But first, someone needs to actually own this issue. Months of silence on a bug this severe is not acceptable.

This just happened to me right now, that's how I landed here. Opus 4.8 Extra. Got my first 50 court occurrences at less than 100k tokens. A few messages later at around 200k tokens it got into an infinite loop of court messages. Burned through 10k tokens until I realized it wasn't doing anything and I managed to stop it.