Contents
- 1. What is actually happening — two separate problems chaining together
- 2. What the "court" infinite loop really is — repetition (degeneration)
- 3. What "Response stalled mid-stream" really is — a stalled stream
- 4. Not the same as the "court/invoke tag leak" — how to tell them apart
- 5. Trigger conditions
- 6. Fix it right now (for users)
- 7. For developers — prevent it via the API/SDK
- 8. Telling it apart from similar errors
- 9. Official status
- FAQ
Have you ever been working in Claude Code for a long stretch when the response suddenly starts repeating the same word — "court court court court…" — dozens or even hundreds of times, and finally halts with "API Error: Response stalled mid-stream. The response above may be incomplete."?
This is not a mistake in your prompt or your environment. More often than not, two separate bugs are chaining together: (1) a repetition loop (degeneration) where the model keeps emitting the same token, and (2) "Response stalled mid-stream," where that flood of output or a connection problem causes the stream to stall. Both are known issues with multiple open tickets in Anthropic's official repository. This article breaks down these two layers — what each one really is, what triggers them, how to stop them right now, how developers can prevent them, and how to tell them apart from similar errors — based on the official documentation and the actual issues.
Repetition (degeneration) that endlessly repeats the same token. It burns through your output tokens.
The response stream stops sending data and halts. It is "cut off partway through."
* Either one can occur on its own. The classic case is a court runaway generating a flood of output, which then triggers the stream to stall.
1. What is actually happening — two separate problems chaining together
The first thing that matters is separating the two. What you see on screen is "court repeating" and "Response stalled mid-stream," but these are two problems at different layers.
- ① The "court" infinite loop: A repetition phenomenon where Claude (the model itself) keeps generating the same token over and over instead of the intended response or tool call. GitHub issues such as #68740 (Output enters an infinite loop repeating the token "court") and #65823 (a fixed string repeated thousands of times, using up the output tokens) fall into this category.
- ② "Response stalled mid-stream": A transport-side error where the response stream (incremental delivery) stops partway through. It is documented in Claude Code's official error reference and reported in issue #70840.
When ① runs away it produces a flood of output, which in turn triggers ②'s stream stall — a chain that looks like a single phenomenon on the user's screen. But the causes and the fixes are different, so understanding them separately is the fastest route.
2. What the "court" infinite loop really is — repetition (degeneration)
"court" means nothing. It is a variant of a long-known failure mode called "repetition / degeneration," where a language model gets stuck on the same output — it just happens that the token it fixated on this time is "court." It can just as easily be a different word or a run of symbols.
Reported characteristics (#68740 and others):
- Occurs with models such as claude-opus-4-8, in Claude Code's VS Code extension / CLI.
- It starts partway through a session and recurs repeatedly within the same session (state-dependent).
- Reported to be triggered most easily when the model generates prose (e.g., in Japanese) right before a tool call (such as Edit).
- When it runs away it consumes a large amount of output tokens (#65823), and in some cases locks up the session (#66950).
It carries the area:model (model behavior) label, positioning it as a problem in the model's generation, not in the harness (Claude Code). In other words, you cannot eradicate it by fixing a command or a setting; the basic approach is "stop it and get out when it happens."
3. What "Response stalled mid-stream" really is — a stalled stream
The other one — "API Error: Response stalled mid-stream. The response above may be incomplete." — is a transport-side error that appears when the response stream stops sending data partway through. Just as the warning "the response above may be incomplete" says, everything that was streamed up to that point is not lost — only the last few sentences or a tool call are missing.
The main factors that have been reported and explained:
- Long responses: Reading several large files and generating a structured report, and other cases where generation drags on, are prone to it. The flood of output from a court runaway also falls here.
- Unstable network/connection: Cross-border connections, home internet lines, and running over a tmux session all raise the odds.
- No read timeout: It has been pointed out that the client can end up waiting indefinitely while the upstream API has stopped sending packets (issue #70840).
Note that the very similar "Connection closed mid-response" (#69415) is a different error where the stream is not "stalled" but "severed." The symptoms are close, but this one leans more toward an outright disconnection.
4. Not the same as the "court/invoke tag leak" — how to tell them apart
They are easy to confuse, but the "court infinite loop" of this article and the "court leaking onto the screen together with invoke tags" phenomenon are two different things. The latter is covered in detail in a separate article on this site.
| Aspect | This article: court infinite loop → stall | Separate article: court/invoke tag leak |
|---|---|---|
| Visible symptom | "court" repeated dozens to hundreds of times / stalled at the end | A few "court" or raw <invoke> tags leak out |
| What it really is | Repetition (degeneration) + a stalled stream | Corruption in generating the tool-call control tags |
| Tool call | Stuck on generation and never progresses | Tags break and the call misfires |
| How it ends | Response stalled mid-stream / hang | Tags are shown as text and it stops |
For the type where "court" leaks together with tags and the tool call misfires, see Claude Code outputs "court" or invoke tags: causes and fixes. Some of the causes and fixes differ.
5. Trigger conditions
No reproduction condition that "always" triggers either phenomenon has been pinned down, but the reports reveal common factors that raise the odds.
Continuous sessions running hours to several days, and heavy contexts of hundreds of thousands up to roughly a million tokens. The more state accumulates, the more likely it is.
Reported to be prone to entering the loop when it writes an introductory sentence (e.g., in Japanese) right before an Edit or similar.
Cross-border connections, home internet lines, running over tmux, and the like raise the odds of a stream stall.
Tasks where generation drags on, such as reading several large files and producing a long report.
6. Fix it right now (for users)
Because the model-side repetition cannot be eradicated with a setting, "stop it quickly and reset the state" is the most reliable approach. The priority order is as follows.
- Stop it immediately (Esc): The moment you notice a loop or a hang, interrupt generation with Esc. This stops the waste of output tokens.
- Escape to a new session: Because it is a state-dependent bug, starting a new session often resolves it. Retrying within the same session tends to make it recur.
- Reset the context with
/clear: If you want to keep going in the session, clear the context to lighten the state (/compactcarries the state over, so it is unreliable as a fix). - Call tools with no preamble: There are reports that instructing it to call the tool with zero preamble, rather than writing a long sentence right before an Edit or similar, helps avoid the loop.
- Split the task into short sessions: Keeping it to one task = one session keeps generation time and context short, making both repetition and stream stalls less likely.
- Stabilize the connection: If stalls happen frequently, review the stability of your line or proxy route. Whatever was already streamed remains, so you can just re-issue instructions from where it left off.
✅ Key point: "Miss twice, don't push it — go to a new session." Retrying in the same broken state makes the model imitate the preceding repetition and recur.
7. For developers — prevent it via the API/SDK
If you are building your own implementation on the Messages API or an SDK, the following measures can limit the damage.
- Set a read timeout on streaming: If no packet arrives for a set period, abort and retry. Avoid waiting forever (a root-cause measure for stalls).
- A repetition-detection guard: If the same token or a short string is repeated an abnormal number of times in the recent output, abort generation. This prevents the runaway consumption of output tokens.
- Retry incomplete responses: Check
stop_reason, and if it ended partway, retry without keeping the broken output in the history (broken history triggers repetition on the next turn). - Set a max_tokens cap: So that even if it does run away, you can cap the billing and the time (
max_tokens). - Keep tool arguments and preambles short: Long arguments and long-winded preambles can be trigger conditions.
8. Telling it apart from similar errors
| Symptom / message | What it really is | Main fix |
|---|---|---|
| court repeated dozens of times → stalled | Repetition loop + stream stall (this article) | Stop with Esc → new session / clear |
| A few court or raw invoke tags leak out | Corruption in generating tool-call tags (separate article) | Miss twice, go to a new session |
| Connection closed mid-response | The stream is "severed" (#69415) | Review connection, retry |
| Prompt is too long | Input exceeds the context limit | Reduce context, /clear |
| usage limit / 429 | Usage or rate limit | Wait, check your plan |
| Output blocked by content filtering policy | Output-side safety filter (separate article) | Rephrase to avoid verbatim copying |
9. Official status
Here is the situation as of July 2026, with confidence levels made explicit.
- ✅ Recognized as known issues: Both court repetition and stalled have multiple open issues in Anthropic's official repository, and the court repetition carries the
area:modelandbuglabels. - 🟡 No confirmed permanent fix: As of writing, there is no official fix we can definitively say "resolved it." Version updates may improve it, so keep Claude Code on the latest version.
- 🟡 Cause is state- and environment-dependent: Multiple factors are involved — long sessions, large context, connection quality — and no single reproduction procedure has been identified.
* The situation may change. For the latest, check the Claude Code issue list and the official error reference.
FAQ
Q1. Does "court" mean anything?
No. It is "repetition (degeneration)," where the language model fixates on the same output — it just happens that this time the fixation landed on the token "court." It can also be a different word or a run of symbols. It is not a problem with your prompt or your data.
Q2. When "Response stalled mid-stream" appears, is the output so far lost?
No. As the message says, "the response above may be incomplete" — that is all; whatever was streamed up to that point remains. The last few sentences or a tool call may be missing, so just re-issue instructions from where it left off.
Q3. Will retrying fix it right away?
In mild cases it can, but retrying in the same session tends to make it recur, because the model imitates the broken output (the repetition) that came right before. If you miss twice, don't push it — switching to a new session is the reliable move.
Q4. Will /compact fix it?
It is unreliable. Because /compact summarizes the context and carries the state over, the cause of the repetition can remain. If you want to reset the state, /clear or a new session is more reliable.
Q5. Is this the same bug as the "court/invoke tag leak" article?
They are related but different. This article is the repetition + stream-stall type where "court loops infinitely and finally halts as stalled." The tag-leak type is "a few court or raw invoke tags leak out and the tool call misfires"; for details, see the separate article.
Q6. As a developer, how do I fundamentally prevent it?
Three things are effective: set a read timeout on streaming, cut off abnormal repetition with repetition detection, and on a partway ending, retry without keeping the broken output in the history. A max_tokens cap also prevents billing and time from running away.
Q7. When is it most likely to happen?
The odds rise with long, multi-day continuous sessions; heavy contexts of hundreds of thousands up to roughly a million tokens; long prose generation right before a tool call; unstable connections over cross-border, home, or tmux links; and long-output tasks. Keeping it short with one task = one session is good prevention.
Related articles
- Claude Code outputs "court" or invoke tags: causes and fixes — the tag-leak type (different from this article)
- Output blocked by content filtering policy: causes and fixes — an output-side filter error
- What is Claude Code's /loop command — the correct way to use repeated execution
