¿Alguna vez, tras trabajar mucho rato con Claude Code, la respuesta se pone de golpe a repetir la misma palabra decenas o cientos de veces, «court court court court…», para terminar deteniéndose con «API Error: Response stalled mid-stream. The response above may be incomplete.»? Ese es el fenómeno del que hablamos.

No es un fallo de tu prompt ni de tu entorno: en la mayoría de los casos se trata de dos errores independientes que se encadenan. ① un bucle de repetición (degeneración) en el que el modelo sigue emitiendo el mismo token, y ② la «Response stalled mid-stream», en la que el stream se detiene por esa avalancha de salida o por problemas de conexión. Ambos son fallos conocidos con varias Issues abiertas en el repositorio oficial de Anthropic. En este artículo ordenamos, a partir de la documentación oficial y de las Issues reales, qué son estas dos capas, qué las desencadena, cómo detenerlas al instante, cómo prevenirlas desde el lado del desarrollador y cómo distinguirlas de errores parecidos.

Dos fenómenos distintos que se encadenan
① Lado del modelo
Bucle infinito de «court»

Repetición interminable del mismo token (degeneración). Consume todos los tokens de salida.

② Lado del stream
Response stalled mid-stream

El stream de respuesta deja de enviar datos y se detiene. Queda «cortado a medias».

※ A veces solo ocurre uno de los dos. El caso típico: el descontrol de «court» genera una salida enorme que provoca la detención del stream.

1. Qué está ocurriendo: dos fenómenos distintos que se encadenan

Lo primero es separar bien las cosas. En pantalla ves «la repetición de court» y «Response stalled mid-stream», pero son dos problemas de capas diferentes.

  • ① Bucle infinito de «court»: un fenómeno de repetición en el que Claude (el propio modelo), en lugar de la respuesta o la llamada a herramienta que debería, sigue generando el mismo token una y otra vez. Se corresponde con Issues de GitHub como la #68740 (Output enters an infinite loop repeating the token "court") o la #65823 (repite una cadena fija miles de veces y agota los tokens de salida).
  • ② «Response stalled mid-stream»: un error del lado del transporte en el que el stream (envío progresivo) de la respuesta se detiene a mitad de camino. Aparece también en la referencia oficial de errores de Claude Code y se ha reportado en la Issue #70840.

Cuando ① se descontrola genera una salida enorme, que a su vez desencadena la detención del stream de ② —ese encadenamiento se ve como un único fenómeno en la pantalla del usuario. Pero como la causa y la solución son distintas, entenderlos por separado es el camino más rápido.

2. Qué es en realidad el bucle infinito de «court»: repetición (degeneración)

«court» no significa nada. Es una variante de un modo de fallo conocido desde hace tiempo, la «repetición (repetition/degeneration)», en la que el modelo de lenguaje se queda fijado en la misma salida; simplemente ha dado la casualidad de que esa fijación recae en el token «court». También puede ser otra palabra o una secuencia de símbolos.

Características reportadas (#68740 y otras):

  • Ocurre con modelos como claude-opus-4-8, en la extensión de VS Code y en la CLI de Claude Code.
  • Empieza a mitad de sesión y reaparece varias veces dentro de la misma sesión (depende del estado).
  • Según los reportes, se desencadena con más facilidad cuando el modelo genera texto (por ejemplo, en otro idioma) justo antes de una llamada a herramienta (como Edit).
  • Al descontrolarse consume muchos tokens de salida (#65823), y hay casos en los que la sesión se bloquea (#66950).

Lleva la etiqueta area:model (comportamiento del modelo), lo que lo sitúa como un problema de generación del lado del modelo y no del harness (Claude Code). Es decir, no se puede erradicar arreglando comandos o ajustes, así que la base es una estrategia de «si ocurre, detenerlo y huir».

3. Qué es en realidad «Response stalled mid-stream»: detención del stream

El otro, «API Error: Response stalled mid-stream. The response above may be incomplete.», es un error del lado del transporte que aparece cuando el stream de respuesta deja de enviar datos a mitad de camino. Tal como avisa el mensaje («la respuesta de arriba puede estar incompleta»), lo que se ha transmitido hasta ahí no se pierde: solo faltan las últimas frases o la llamada a herramienta final.

Factores que se han reportado y analizado como principales:

  • Respuestas largas: cuando la generación se alarga —por ejemplo, al leer varios archivos grandes y producir un informe estructurado— es más probable que ocurra. La salida masiva del descontrol de «court» también entra aquí.
  • Conexión de red inestable: la probabilidad sube con conexiones transfronterizas, líneas domésticas o a través de sesiones de tmux.
  • Falta de tiempo de espera de lectura: se ha señalado que el cliente puede quedarse esperando indefinidamente mientras la API upstream deja de enviar paquetes (Issue #70840).

Por cierto, el muy parecido «Connection closed mid-response» (la conexión se cerró a mitad de la respuesta) (#69415) es un error distinto: el stream no «se detiene», sino que «se corta». Los síntomas son parecidos, pero este tira más hacia la desconexión.

4. Es distinto de la «fuga de etiquetas court/invoke»: cómo diferenciarlos

Es fácil confundirlos, pero el fenómeno de este artículo, «court entra en bucle infinito», y el fenómeno de «court se filtra a la pantalla junto con etiquetas invoke» son cosas distintas. Este último lo detallamos en otro artículo de este sitio.

AspectoEste artículo: bucle infinito de court → stallOtro artículo: fuga de etiquetas court/invoke
Síntoma visibleRepite «court» decenas o cientos de veces y al final stalledSe filtran unas pocas «court» o etiquetas <invoke> en crudo
Qué es en realidadRepetición (degeneración) + detención del streamCorrupción en la generación de las etiquetas de control de la llamada a herramienta
Llamada a herramientaNi siquiera avanza: se queda fijada en la generaciónLa etiqueta se rompe y la llamada no llega a ejecutarse
Cómo terminaResponse stalled mid-stream / se cuelgaLa etiqueta se muestra como texto y se detiene

Para el tipo en el que «court» se filtra junto con etiquetas y la llamada a herramienta no se ejecuta, consulta Causas y solución del error en el que Claude Code muestra «court» o etiquetas invoke. La causa y la solución difieren en parte.

5. Condiciones que lo desencadenan

En ninguno de los dos fenómenos se ha identificado una condición de reproducción que lo provoque «siempre», pero los reportes dejan ver factores comunes que elevan la probabilidad.

🕒 Sesiones largas y contexto grande

Sesiones continuas de horas o varios días, contextos pesados de cientos de miles hasta cerca de un millón de tokens. Cuanto más estado se acumula, más probable es.

🔧 Generar texto justo antes de una llamada a herramienta

Según los reportes, es fácil entrar en bucle al escribir un texto introductorio (por ejemplo, en otro idioma) justo antes de un Edit.

📡 Conexión inestable

Las conexiones transfronterizas, las líneas domésticas o el trabajo a través de tmux elevan la probabilidad de detención del stream.

📄 Salida larga

Tareas cuya generación se alarga, como leer varios archivos grandes y producir un informe extenso.

6. Solución inmediata (para usuarios)

Como la repetición del lado del modelo no se puede erradicar con ajustes, lo más fiable es «detenerla rápido y reiniciar el estado». El orden de prioridad es el siguiente.

  1. Detener enseguida (Esc): en cuanto notes el bucle o el cuelgue, interrumpe la generación con Esc. Así frenas el derroche de tokens de salida.
  2. Huir a una sesión nueva: como es un fallo dependiente del estado, iniciar una sesión nueva suele resolverlo. Reintentar en la misma sesión tiende a reproducir el problema.
  3. Reiniciar el contexto con /clear: si quieres seguir en la sesión, limpia el contexto para aligerar el estado (/compact conserva el estado, así que su resolución es incierta).
  4. Llamar a las herramientas sin preámbulo: hay reportes de que instruir para llamar a la herramienta sin ningún preámbulo, sin hacer escribir un texto largo justo antes de un Edit, ayuda a evitar el bucle.
  5. Dividir la tarea en sesiones cortas: con 1 tarea = 1 sesión mantienes cortos el tiempo de generación y el contexto, y tanto la repetición como la detención del stream son menos probables.
  6. Estabilizar la conexión: si el stalled se repite con frecuencia, revisa la estabilidad de la línea o de la ruta del proxy. Como lo ya transmitido por el stream se conserva, basta con volver a dar instrucciones desde donde se quedó.

✅ Clave: «si fallas dos veces, no insistas y pasa a una sesión nueva». Reintentar con el mismo estado roto hace que el modelo imite la repetición anterior y recaiga con facilidad.

7. Para desarrolladores: prevenirlo con la API/SDK

Si tienes tu propia implementación con la Messages API o el SDK, puedes limitar el daño con las siguientes medidas.

  • Poner un tiempo de espera de lectura al streaming: si no llegan paquetes durante cierto tiempo, corta y reintenta. Evita la espera infinita (medida contra la causa raíz del stalled).
  • Guarda de detección de repetición: corta la generación si en la salida reciente un mismo token o una cadena corta se repite un número anómalo de veces. Previene el consumo descontrolado de tokens de salida.
  • Reintentar las respuestas incompletas: comprueba stop_reason y, si terminó a medias, reintenta sin dejar la salida rota en el historial (un historial roto desencadena la repetición en el turno siguiente).
  • Fijar un límite de max_tokens: para poder cortar el gasto y el tiempo aunque se descontrole.
  • Argumentos de herramienta y preámbulos cortos: los argumentos largos y los preámbulos extensos pueden ser condiciones desencadenantes.

8. Cómo distinguirlo de errores parecidos

Síntoma/mensajeQué es en realidadSolución principal
Repite court decenas de veces → stalledBucle de repetición + detención del stream (este artículo)Detener con Esc → sesión nueva /clear
Se filtran unas pocas court o etiquetas invoke en crudoCorrupción en la generación de las etiquetas de la llamada a herramienta (otro artículo)Si fallas dos veces, sesión nueva
Connection closed mid-responseEl stream «se corta» (#69415)Revisar la conexión y reintentar
Prompt is too longLa entrada supera el límite de contextoReducir el contexto / /clear
usage limit / 429Límite de uso o de tasaEsperar un tiempo / revisar el plan
Output blocked by content filtering policyFiltro de seguridad del lado de la salida (otro artículo)Reformular para evitar la copia literal

9. Estado oficial del problema

Ordenamos la situación a julio de 2026, indicando el nivel de certeza.

  • Reconocido como fallo conocido: tanto la repetición de court como el stalled tienen varias Issues abiertas en el repositorio oficial de Anthropic, y la repetición de court lleva las etiquetas area:model y bug.
  • 🟡 Sin corrección definitiva confirmada: al momento de escribir esto no hemos podido confirmar una corrección oficial de la que se pueda afirmar «con esto quedó resuelto». Como podría mejorar con actualizaciones de versión, conviene mantener Claude Code en su última versión.
  • 🟡 La causa depende del estado y del entorno: intervienen varios factores —sesiones largas, contexto grande, calidad de la conexión— y no se ha identificado un único procedimiento de reproducción.

※ La situación puede cambiar. Para lo más reciente, consulta la lista de Issues de Claude Code y la referencia oficial de errores.

FAQ

Q1. ¿«court» significa algo?

No. Es la «repetición (degeneración)» en la que el modelo de lenguaje se fija en la misma salida, y ha dado la casualidad de que esa fijación recae en el token «court». También puede ser otra palabra o una secuencia de símbolos. No es un problema de tu prompt ni de tus datos.

Q2. Si aparece «Response stalled mid-stream», ¿se pierde la salida generada hasta ese punto?

No se pierde. Tal como dice el mensaje, solo «la respuesta de arriba puede estar incompleta»: lo transmitido por el stream hasta ahí se conserva. Como puede faltar las últimas frases o una llamada a herramienta, basta con volver a dar instrucciones desde donde se quedó.

Q3. ¿Se arregla enseguida con solo reintentar?

En casos leves a veces se arregla, pero reintentar en la misma sesión tiende a reproducir el problema, porque el modelo imita la salida rota (la repetición) anterior. Si fallas dos veces, lo más fiable es no insistir y cambiar a una sesión nueva.

Q4. ¿Se arregla con /compact?

Es incierto. /compact resume el contexto pero conserva el estado, así que la causa de la repetición puede quedar. Si quieres reiniciar el estado, /clear o una sesión nueva son más fiables.

Q5. ¿Es el mismo fallo que la «fuga de etiquetas court/invoke» de vuestro artículo?

Están relacionados, pero son distintos. Este artículo es del tipo repetición + detención del stream: «court entra en bucle infinito y al final se detiene con stalled». El tipo de fuga de etiquetas es «se filtran unas pocas court o etiquetas invoke en crudo y la llamada a herramienta no se ejecuta»; para más detalle, consulta el otro artículo.

Q6. Como desarrollador, ¿cómo lo prevengo de raíz?

Tres puntos son eficaces: poner un tiempo de espera de lectura al streaming, cortar las repeticiones anómalas con detección de repetición, y ante una terminación a medias reintentar sin dejar la salida rota en el historial. Un límite de max_tokens también evita que el gasto y el tiempo se descontrolen.

Q7. ¿Cuándo es más probable que ocurra?

La probabilidad sube con sesiones continuas de horas o varios días, contextos pesados de cientos de miles hasta cerca de un millón de tokens, la generación de un texto largo justo antes de una llamada a herramienta, conexiones inestables (transfronterizas, líneas domésticas, a través de tmux) y tareas de salida extensa. Mantenerlo corto con 1 tarea = 1 sesión es la mejor prevención.

Artículos relacionados