Не сталкивались ли вы с таким явлением: при долгой работе в Claude Code ответ внезапно начинает повторять одно и то же слово «court court court court…» десятки или сотни раз, а в конце выводит «API Error: Response stalled mid-stream. The response above may be incomplete.» и останавливается?

Это не ошибка вашего промпта или окружения — чаще всего сцепляются два отдельных сбоя. ① Цикл повторения (дегенерация), когда модель продолжает выдавать один и тот же токен, и ② «Response stalled mid-stream», когда из-за этого огромного объёма вывода или проблем с соединением останавливается поток. Оба — известные баги, по которым в официальном репозитории Anthropic заведено несколько Issue. В этой статье мы на основе официальной документации и реальных Issue разбираем суть обоих слоёв, провоцирующие условия, способ немедленно остановить сбой, меры предотвращения для разработчиков и то, как отличить его от похожих ошибок.

Сцепляются два разных явления
① Сторона модели
Бесконечный цикл «court»

Бесконечное повторение одного и того же токена (дегенерация). Пожирает токены вывода.

② Сторона потока
Response stalled mid-stream

Поток ответа перестаёт передавать данные и останавливается. Состояние «оборвалось на полпути».

※ Иногда происходит только одно из двух. Типичный случай — когда разгон court порождает огромный объём вывода и провоцирует остановку потока.

1. Что происходит — сцепляются два разных явления

Прежде всего важно разделить проблемы. На экране видно «повторение court» и «Response stalled mid-stream», но это две проблемы разных уровней.

  • ① Бесконечный цикл «court»: явление повторения, при котором Claude (сама модель) вместо задуманного ответа или вызова инструмента продолжает генерировать один и тот же токен. Сюда относятся GitHub Issue #68740 (Output enters an infinite loop repeating the token "court") и #65823 (фиксированная строка повторяется тысячи раз и исчерпывает токены вывода).
  • ② «Response stalled mid-stream»: ошибка на стороне передачи, когда поток ответа (последовательная отправка) останавливается на полпути. Она упомянута и в официальном справочнике ошибок Claude Code, и о ней сообщается в Issue #70840.

Когда ① идёт вразнос, порождается огромный объём вывода, который провоцирует остановку потока ②, — эта сцепка на экране пользователя выглядит как одно явление. Но и причины, и меры разные, поэтому быстрее всего понять их по отдельности.

2. Что такое бесконечный цикл «court» — повторение (дегенерация)

Слово «court» не несёт никакого смысла. Это разновидность давно известного режима сбоя — «повторения (repetition / degeneration)», когда языковая модель застревает на одном и том же выводе, и точкой застревания просто случайно оказался токен «court». Это может быть и другое слово или последовательность символов.

Отмеченные особенности (#68740 и др.):

  • Возникает при модели claude-opus-4-8 и др., в расширении Claude Code для VS Code / в CLI.
  • Начинается с середины сессии и многократно повторяется в рамках той же сессии (зависит от состояния).
  • По сообщениям, легко провоцируется в моменты, когда прямо перед вызовом инструмента (например, Edit) генерируется текст на японском или другом языке.
  • При разгоне потребляется огромное количество токенов вывода (#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. Условия, провоцирующие ошибку

Для обоих явлений не выявлено условий гарантированного воспроизведения, но по сообщениям видны общие факторы, повышающие вероятность.

🕒 Долгая работа и большой контекст

Непрерывные сессии от нескольких часов до нескольких дней, тяжёлый контекст в сотни тысяч — около миллиона токенов. Чем больше накапливается состояние, тем выше вероятность.

🔧 Генерация текста прямо перед вызовом инструмента

По сообщениям, легко войти в цикл, когда прямо перед Edit и т. п. пишется вступительный текст на японском и т. д.

📡 Нестабильное соединение

Трансграничные соединения, домашние каналы, работа через tmux и т. п. повышают вероятность остановки потока.

📄 Длинный вывод

Задачи с затяжной генерацией — например, чтение нескольких больших файлов и вывод длинного отчёта.

6. Как исправить прямо сейчас (для пользователей)

Повторение на стороне модели нельзя искоренить настройками, поэтому самое надёжное — «быстро остановить и сбросить состояние». Приоритет действий такой.

  1. Немедленно остановить (Esc): заметив цикл или зависание, прервите генерацию клавишей Esc. Это остановит расход токенов вывода.
  2. Сбежать в новую сессию: поскольку баг зависит от состояния, запуск новой сессии часто решает проблему. Повторная попытка в той же сессии склонна к рецидиву.
  3. Сбросить контекст через /clear: если хотите продолжить сессию, очистите контекст, чтобы облегчить состояние (/compact сохраняет состояние, поэтому решение неопределённо).
  4. Вызывайте инструменты без вступления: есть сообщения, что цикла проще избежать, если не заставлять писать длинный текст прямо перед Edit и т. п., а давать указание вызывать инструмент вообще без вступления.
  5. Дробите задачи на короткие сессии: правило «одна задача = одна сессия» держит время генерации и контекст короткими, и тогда реже возникают и повторение, и остановка потока.
  6. Стабилизируйте соединение: если stalled случается часто, пересмотрите стабильность канала или маршрута прокси. Уже переданное по потоку содержимое сохраняется, поэтому достаточно дать указание продолжить с места обрыва.

✅ Ключевой момент: «Промахнулись дважды — не упорствуйте, переходите в новую сессию». Если повторять попытки в том же испорченном состоянии, модель склонна подражать недавнему повторению и снова срываться.

7. Для разработчиков — как предотвратить в API/SDK

Если вы реализуете всё сами через Messages API или SDK, ущерб можно снизить следующими мерами.

  • Задайте тайм-аут чтения для стриминга: если в течение заданного времени пакеты не приходят, обрывайте и повторяйте попытку. Избегайте бесконечного ожидания (мера против корня stalled).
  • Защита с детекцией повторения: если в недавнем выводе один и тот же токен / короткая строка повторяется аномальное число раз, обрывайте генерацию. Это предотвращает разгонный расход токенов вывода.
  • Повтор при неполном ответе: проверяйте 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 г. приводим с явным указанием степени достоверности.

  • Признано известным багом: и по повторению court, и по stalled в официальном репозитории Anthropic заведено несколько Issue, а повторению court присвоены метки area:model и bug.
  • 🟡 Постоянное исправление не подтверждено: на момент написания статьи не удалось найти официального исправления, о котором можно было бы уверенно сказать «вот это починило». Обновление версии может улучшить ситуацию, поэтому стоит держать Claude Code в актуальной версии.
  • 🟡 Причина зависит от состояния и окружения: переплетаются несколько факторов — долгая работа, большой контекст, качество соединения, — и единой процедуры воспроизведения не выявлено.

※ Ситуация может измениться. Актуальное смотрите в списке Issue Claude Code и официальном справочнике ошибок.

FAQ

Q1. Имеет ли слово «court» какой-то смысл?

Нет. Это «повторение (дегенерация)», когда языковая модель застревает на одном и том же выводе, и точкой застревания случайно оказался токен «court». Это может быть и другое слово или последовательность символов. Проблема не в вашем промпте или данных.

Q2. Если появилось «Response stalled mid-stream», пропадает ли вывод, полученный до этого момента?

Не пропадает. Как и сказано в сообщении, «ответ выше может быть неполным» — не более того, а содержимое, переданное по потоку до этого момента, сохраняется. Возможно, не хватает последних нескольких фраз или вызова инструмента, поэтому достаточно дать указание продолжить с места обрыва.

Q3. Достаточно ли повторить попытку, чтобы сразу починить?

В лёгких случаях иногда помогает, но повторная попытка в той же сессии склонна к рецидиву. Причина в том, что модель подражает недавнему испорченному выводу (повторению). Промахнулись дважды — не упорствуйте и надёжнее переключиться на новую сессию.

Q4. Починит ли /compact?

Неопределённо. /compact резюмирует контекст и сохраняет состояние, поэтому причина повторения может остаться. Если хотите сбросить состояние, надёжнее /clear или новая сессия.

Q5. Это тот же баг, что и «утечка тега court/invoke» из статьи?

Связаны, но это разные вещи. Эта статья — о типе «повторение + остановка потока», когда «court» уходит в бесконечный цикл и в конце останавливается на stalled. Тип с утечкой тега — это когда «court» или сырой тег invoke просачивается несколько раз и вызов инструмента не срабатывает; подробнее см. другую статью.

Q6. Как разработчику предотвратить это в корне?

Эффективны три вещи: задать тайм-аут чтения для стриминга, обрывать аномальные повторения детекцией повторения, и при обрыве на полпути повторять попытку, не оставляя испорченный вывод в истории. Лимит max_tokens также предотвращает разгон расходов и времени.

Q7. Когда это возникает чаще всего?

Вероятность растёт при долгих, многодневных непрерывных сессиях, тяжёлом контексте в сотни тысяч — около миллиона токенов, генерации длинного текста прямо перед вызовом инструмента, нестабильном соединении (трансграничном, по домашнему каналу, через tmux), задачах с длинным выводом и т. п. Профилактика — держать всё коротким по принципу «одна задача = одна сессия».

Похожие статьи