目录
在 Claude Code 中长时间工作时，应答突然开始 「court court court court…」反复输出同一个单词几十到数百次，最后打出 「API Error: Response stalled mid-stream. The response above may be incomplete.」 然后停下——你是否遇到过这样的现象？
这并不是你的提示词或环境出了错，而多半是两个各自独立的缺陷连锁触发所致。①模型不断吐出同一个 token 的重复循环（退化，degeneration），以及②因这类海量输出或连接问题导致流停止的「Response stalled mid-stream」。两者都是在 Anthropic 官方仓库中有多条 Issue 记录的已知缺陷。本文将基于官方文档和真实 Issue，梳理这两层现象的真相、诱发条件、当下的止损方法、面向开发者的预防手段，以及与相似错误的区分方式。
无休止地重复同一个 token 的重复（退化）。把输出 token 耗尽。
应答流不再发送数据而停止。处于「中途被截断」的状态。
※ 也可能只发生其中一个。court 失控产生海量输出、进而诱发流停止是典型情形。
1. 到底发生了什么——两个独立现象连锁触发
首先，区分现象很重要。屏幕上看到的是「court 的反复」和「Response stalled mid-stream」，但它们是层次不同的两个问题。
- ① 「court」无限循环：Claude（模型本体）没有生成预期的应答或工具调用，而是持续反复生成同一个 token的重复现象。GitHub Issue #68740（Output enters an infinite loop repeating the token "court"）以及 #65823（把固定字符串重复数千次、耗尽输出 token）等都属于此类。
- ② 「Response stalled mid-stream」：应答的流（逐步发送）在中途停止的传输侧错误。Claude Code 官方错误参考中亦有记载，Issue #70840 中也有报告。
①一旦失控就会产生海量输出，进而诱发②的流停止——这种连锁在用户的屏幕上看起来像是一个现象。但由于成因和处置都不同，分开理解才是捷径。
2. 「court」无限循环的真相——重复（退化）
「court」本身没有含义。这是语言模型固着于同一输出的「重复（repetition／degeneration）」这一由来已久的失败模式之一，只是固着的落点恰好是「court」这个 token 而已。也可能变成别的词或符号串。
已报告的特征（#68740 等）：
- 模型为 claude-opus-4-8 等，在 Claude Code 的 VS Code 扩展／CLI 中发生。
- 从会话中途开始，并在同一会话内多次复发（状态依赖）。
- 据报告，在工具调用（如 Edit）之前生成中文等文本的场景下更容易被诱发。
- 失控时会大量消耗输出 token（#65823），也有会话被锁死的案例（#66950）。
该问题被打上 area:model（模型行为）标签，被定位为模型侧生成的问题，而非框架（Claude Code）的问题。也就是说，修改命令或设置也无法根除，「一旦发生就止住并撤离」的处置才是基本方针。
3. 「Response stalled mid-stream」的真相——流中断
另一侧的 「API Error: Response stalled mid-stream. The response above may be incomplete.」，是应答流在中途不再发送数据时打出的传输侧错误。正如「上面的应答可能不完整」这条警告所示，已经流式送达的部分并未丢失——只是缺了最后几句话或工具调用而已。
被报告和解读为主要因素的有：
- 较长的应答：例如读取多个大文件并生成结构化报告等，生成拖得越久越容易发生。court 失控产生的海量输出也属于此类。
- 网络/连接不稳定：跨境连接、家用宽带、经由 tmux 会话等会提高概率。
- 缺少读取超时：有观点指出，当上游 API 停止发送数据包、而客户端持续等待时便会陷入此状态（Issue #70840）。
另外，与之非常相似的 「Connection closed mid-response（应答中途连接被关闭）」（#69415）是流并非「停止」而是「被切断」的另一种错误。症状接近，但它更偏向连接中断。
4. 与「court/invoke 标签泄漏」不同——如何区分
虽然容易混淆，但本文的「court 无限循环」现象，与「court 连同 invoke 标签一起泄漏到屏幕上」的现象是两回事。后者在本站的另一篇文章中有详解。
| 角度 | 本文：court 无限循环 → stall | 另一篇：court/invoke 标签泄漏 |
|---|---|---|
| 可见症状 | 「court」反复几十到数百次／最后 stalled | 「court」或原始的 <invoke> 标签泄漏几个 |
| 真相 | 重复（退化）＋流停止 | 工具调用的控制标签生成受损 |
| 工具调用 | 根本固着在生成上无法推进 | 标签损坏而未发出 |
| 终止方式 | Response stalled mid-stream／挂起 | 标签以文本形式显示后停止 |
「court」连同标签一起泄漏、导致工具调用未发出的类型，请参阅 Claude Code 输出「court」或 invoke 标签错误的原因与对策。成因和处置有部分不同。
5. 诱发条件
两种现象都尚未确定「必定发生」的复现条件，但从报告中可以看出共同会提高概率的因素。
数小时到数日的连续会话，数十万到约 100 万 token 的沉重上下文。状态积累越多越容易发生。
据报告，在 Edit 等之前写中文等前置文字的场景下更容易进入循环。
跨境连接、家用宽带、经由 tmux 等会提高流停止的概率。
读取多个大文件并输出长篇报告等、生成拖得较久的任务。
6. 立即修复（面向用户）
模型侧的重复无法靠设置根除，因此「迅速止住并重置状态」最为可靠。优先级如下。
- 立即止住（Esc）：一旦察觉循环或挂起，用 Esc 中断生成。可以止住输出 token 的浪费。
- 撤到新会话：由于是状态依赖的缺陷，开启新会话往往就能解决。在同一会话中重试容易复发。
- 用
/clear重置上下文：若想继续该会话，清空上下文以减轻状态负担（/compact会继承状态，能否解决并不确定）。 - 工具调用不加前置文字：据报告，不在 Edit 等之前让它写长段文字、而是零前置地直接调用工具，更容易避开循环。
- 把任务拆成短会话：一任务＝一会话，让生成时间和上下文保持短小，重复和流停止都更不易发生。
- 让连接稳定：如果 stalled 频繁出现，就重新审视线路或代理路径的稳定性。已流式送达的内容仍在，从中断处重新下达指令即可。
✅ 要点：「失败两次就别硬撑，换新会话」。在同一个损坏状态下重试，模型会模仿刚才的重复而容易复发。
7. 面向开发者——用 API/SDK 预防
如果你用 Messages API 或 SDK 自行实现，以下对策可以减轻损害。
- 为流式设置读取超时：一定时间内没有数据包到来就中断并重试。避免无限等待（stalled 的根因对策）。
- 重复检测的守卫：若最近的输出中同一 token／短字符串被异常次数地重复，就中断生成。防止输出 token 的失控消耗。
- 对不完整应答重试：检查
stop_reason，若为中途结束则不把损坏的输出留在历史中重来（损坏的历史会诱发下一轮的重复）。 - 设置 max_tokens 上限：以便万一失控也能给计费和时间设上限。
- 缩短工具参数与前置文字：过长的参数或长篇前置文字可能成为诱发条件。
8. 与相似错误的区分
| 症状/消息 | 真相 | 主要对策 |
|---|---|---|
| court 反复几十次 → stalled | 重复循环＋流停止（本文） | 用 Esc 停止→新会话/clear |
| court 或原始 invoke 标签泄漏几个 | 工具调用标签的生成受损（另一篇） | 失败两次就换新会话 |
| Connection closed mid-response | 流被「切断」（#69415） | 检查连接・重试 |
| Prompt is too long | 输入超出上下文上限 | 削减上下文・/clear |
| usage limit / 429 | 用量・速率上限 | 间隔一段时间・确认套餐 |
| Output blocked by content filtering policy | 输出侧的安全过滤（另一篇） | 避开逐字复制、改用改写 |
9. 官方处理进展
下面明示确信度，梳理截至 2026年7月 的状况。
- ✅ 已被认定为已知缺陷：court 重复与 stalled 在 Anthropic 官方仓库都有多条 Issue，court 重复被打上
area:model・bug标签。 - 🟡 永久修复尚未确认：截至本文撰写时，尚未确认到可以断言「这样就修好了」的官方修复。版本更新有改善的可能，因此最好把 Claude Code 保持在最新版。
- 🟡 成因依赖状态与环境：长时间、大上下文、连接质量等多种因素交织，尚未确定单一的复现步骤。
※ 状况可能变化。最新信息请查阅 Claude Code 的 Issue 列表 与 官方错误参考。
FAQ
Q1. 「court」有什么含义吗？
没有。这是语言模型固着于同一输出的「重复（退化）」，只是固着的落点恰好是「court」这个 token 而已。也可能变成别的词或符号串。这不是你的提示词或数据的问题。
Q2. 出现「Response stalled mid-stream」后，之前的部分输出会消失吗？
不会消失。正如消息所言，只是「上面的应答可能不完整」，已经流式送达的内容仍然保留。可能缺了最后几句话或工具调用，从中断处重新下达指令即可。
Q3. 重试一下就能立刻修好吗？
症状轻时也有可能修好，但在同一会话中重试容易复发。因为模型会模仿刚才那段损坏的输出（重复）。失败两次就别硬撑，切换到新会话更可靠。
Q4. /compact 一下就能修好吗？
不确定。/compact 会把上下文摘要化并继承状态，因此重复的成因可能残留。若想重置状态，用 /clear 或新会话更可靠。
Q5. 这和文章里提到的「court/invoke 标签泄漏」是同一个缺陷吗？
有关联但是两回事。本文是「court 无限循环、最后以 stalled 停止」的重复＋流停止型。标签泄漏型则是「court 或原始 invoke 标签泄漏几个、导致工具调用未发出」，详情请参阅另一篇。
Q6. 作为开发者，如何从根本上预防？
为流式设置读取超时，用重复检测中断异常的反复，并在中途结束时不把损坏的输出留在历史中而重试——这三点很有效。max_tokens 上限也能防止计费和时间的失控。
Q7. 什么时候容易发生？
长时间、跨越数日的连续会话，数十万到约 100 万 token 的沉重上下文，工具调用前的长段文本生成，跨境・家用宽带・经由 tmux 的不稳定连接，长篇输出任务——这些情况下概率会上升。一任务＝一会话、保持短小是有效的预防。
相关文章
- Claude Code 输出「court」或 invoke 标签的错误 — 标签泄漏型（与本文不同）
- Output blocked by content filtering policy 的原因与对策 — 输出侧过滤的错误
- Claude Code 的 /loop 命令是什么 — 反复执行的正确用法
