Claude Code répète « court » puis « Response stalled mid-stream » : causes et solutions

Vous travaillez depuis longtemps dans Claude Code lorsque, soudain, la réponse se met à répéter des dizaines, voire des centaines de fois le même mot « court court court court… », puis s'arrête sur « API Error: Response stalled mid-stream. The response above may be incomplete. » — avez-vous déjà rencontré ce phénomène ?

Ce n'est pas une erreur de votre prompt ni de votre environnement : le plus souvent, deux dysfonctionnements distincts s'enchaînent. ① Une boucle de répétition (dégénérescence) où le modèle continue de produire le même token, et ② un « Response stalled mid-stream » où le flux s'arrête à cause de cette production massive ou d'un problème de connexion. Les deux sont des dysfonctionnements connus qui font l'objet de plusieurs tickets (issues) sur le dépôt officiel d'Anthropic. Dans cet article, nous détaillons la nature de ces deux couches, leurs conditions déclenchantes, comment les arrêter immédiatement, comment les prévenir côté développeur et comment les distinguer d'erreurs similaires — le tout en nous appuyant sur la documentation officielle et sur les issues réelles.

1. Que se passe-t-il ? Deux phénomènes distincts qui s'enchaînent

Il faut d'abord bien démêler les choses. À l'écran, vous voyez « la répétition de court » et « Response stalled mid-stream », mais il s'agit de deux problèmes de couches différentes.

• ① Boucle infinie « court » : un phénomène de répétition où Claude (le modèle lui-même), au lieu de produire la réponse ou l'appel d'outil attendu, continue de générer indéfiniment le même token. C'est le cas de l'issue GitHub #68740 (Output enters an infinite loop repeating the token "court") ou de #65823 (répétition d'une chaîne fixe des milliers de fois qui épuise les tokens de sortie).
• ② « Response stalled mid-stream » : une erreur côté transfert où le flux (l'envoi progressif) de la réponse s'arrête en cours de route. Elle est mentionnée dans la référence officielle des erreurs de Claude Code et signalée dans l'issue #70840.

Quand ① s'emballe, il produit une sortie massive qui déclenche l'arrêt du flux de ② — cet enchaînement apparaît à l'écran comme un seul et même phénomène. Mais comme la cause et la solution diffèrent, les comprendre séparément est le chemin le plus rapide.

2. La vraie nature de la boucle infinie « court » — la répétition (dégénérescence)

« court » n'a aucun sens particulier. Il s'agit d'un des modes d'échec bien connus de longue date, la « répétition » (repetition / degeneration), où un modèle de langage se fige sur une même sortie ; il se trouve simplement que ce point de fixation est le token « court ». Ce pourrait être un autre mot ou une autre suite de symboles.

Caractéristiques rapportées (#68740 et autres) :

• Survient avec des modèles comme claude-opus-4-8, dans l'extension VS Code ou la CLI de Claude Code.
• Démarre en cours de session et récidive plusieurs fois au sein de la même session (dépendant de l'état).
• D'après les rapports, se déclenche plus facilement dans les situations où du texte (en japonais, par exemple) est généré juste avant un appel d'outil (comme Edit).
• Quand il s'emballe, il consomme massivement les tokens de sortie (#65823), avec des cas où la session se bloque (#66950).

Le label area:model (comportement du modèle) lui est attribué : il est donc classé comme un problème de génération côté modèle, et non côté harnais (Claude Code). Autrement dit, corriger une commande ou un réglage ne l'éradique pas ; l'approche de base consiste à « l'arrêter et fuir dès qu'il survient ».

3. La vraie nature de « Response stalled mid-stream » — l'arrêt du flux

De l'autre côté, « API Error: Response stalled mid-stream. The response above may be incomplete. » est une erreur côté transfert qui apparaît lorsque le flux de réponse cesse d'envoyer des données en cours de route. Comme l'indique l'avertissement « la réponse ci-dessus est peut-être incomplète », ce qui a été transmis jusque-là n'est pas perdu — il manque seulement les dernières phrases ou le dernier appel d'outil.

Facteurs principaux rapportés et analysés :

• Réponse longue : la génération est plus susceptible de survenir quand elle s'étire, par exemple lire plusieurs gros fichiers pour produire un rapport structuré. La production massive due à l'emballement « court » entre aussi dans cette catégorie.
• Instabilité du réseau / de la connexion : la probabilité augmente avec les connexions transfrontalières, les lignes grand public, ou à travers une session tmux.
• Absence de délai de lecture (timeout) : selon les observations, l'API en amont cesse d'envoyer des paquets tandis que le client continue d'attendre indéfiniment (issue #70840).

À noter, l'erreur très ressemblante « Connection closed mid-response » (la connexion s'est fermée pendant la réponse) (#69415) est une erreur différente : le flux n'est pas « arrêté » mais « coupé ». Les symptômes sont proches, mais celle-ci relève davantage de la rupture de connexion.

4. À ne pas confondre avec la « fuite de balise court/invoke » — comment les distinguer

On les confond facilement, mais le phénomène de cet article, « court boucle à l'infini », et le phénomène « court fuit à l'écran avec une balise invoke » sont deux choses distinctes. Ce dernier est détaillé dans un autre article de notre site.

Pour le type où « court » fuit avec une balise et fait échouer l'appel d'outil, consultez Erreur « court » ou balises invoke affichées dans Claude Code : causes et solutions. La cause comme la solution diffèrent en partie.

5. Conditions déclenchantes

Aucune condition de reproduction « systématique » n'a été identifiée pour ces deux phénomènes, mais les rapports font ressortir des facteurs communs qui augmentent la probabilité.

6. Corriger tout de suite (côté utilisateur)

Comme la répétition côté modèle ne peut pas être éradiquée par un réglage, le plus sûr est de « l'arrêter vite et réinitialiser l'état ». Voici l'ordre de priorité.

1. Arrêter immédiatement (Esc) : dès que vous repérez une boucle ou un blocage, interrompez la génération avec Esc. Vous stoppez ainsi le gaspillage de tokens de sortie.
2. Fuir vers une nouvelle session : comme le dysfonctionnement dépend de l'état, démarrer une nouvelle session résout souvent le problème. Réessayer dans la même session favorise la récidive.
3. Réinitialiser le contexte avec /clear : si vous voulez poursuivre la session, effacez le contexte pour alléger l'état (/compact conserve l'état, donc la résolution est incertaine).
4. Appeler les outils sans préambule : selon les rapports, ne pas faire écrire un long texte juste avant un Edit ou similaire, mais appeler l'outil sans aucun préambule, aide à éviter la boucle.
5. Découper la tâche en sessions courtes : une tâche = une session, pour garder le temps de génération et le contexte courts ; répétition comme arrêt du flux surviennent alors moins.
6. Stabiliser la connexion : si les stalled se multiplient, revoyez la stabilité de la ligne ou du chemin proxy. Ce qui a déjà été transmis reste disponible ; il suffit de reprendre les instructions à partir de là.

✅ À retenir : « Après deux échecs, ne vous acharnez pas : passez à une nouvelle session ». Réessayer dans le même état corrompu pousse le modèle à imiter la répétition précédente et à récidiver.

7. Pour les développeurs — prévenir via l'API/le SDK

Si vous avez votre propre implémentation avec la Messages API ou le SDK, les mesures suivantes limitent les dégâts.

• Définir un délai de lecture (timeout) sur le streaming : si aucun paquet n'arrive pendant un certain temps, interrompez et réessayez. Cela évite l'attente infinie (traite la cause profonde du stalled).
• Garde de détection de répétition : si un même token / une courte chaîne se répète un nombre anormal de fois dans la sortie récente, interrompez la génération. Cela évite la consommation emballée des tokens de sortie.
• Réessai des réponses incomplètes : vérifiez stop_reason et, en cas d'arrêt prématuré, recommencez sans conserver la sortie corrompue dans l'historique (un historique corrompu favorise la répétition au tour suivant).
• Fixer une limite max_tokens : gardez la possibilité de plafonner le coût et le temps même en cas d'emballement.
• Arguments d'outils et préambules courts : de longs arguments ou de longs préambules peuvent être des conditions déclenchantes.

8. Distinguer des erreurs similaires

9. État officiel de la prise en charge

Voici la situation en juillet 2026, avec le niveau de certitude indiqué.

• ✅ Reconnu comme dysfonctionnement connu : la répétition « court » comme le stalled font l'objet de plusieurs issues sur le dépôt officiel d'Anthropic, et la répétition « court » porte les labels area:model et bug.
• 🟡 Correctif définitif non confirmé : au moment de la rédaction, aucun correctif officiel dont on puisse affirmer « voilà, c'est réglé » n'a été confirmé. Une mise à jour de version pouvant améliorer les choses, il vaut mieux garder Claude Code à jour.
• 🟡 Cause dépendante de l'état et de l'environnement : plusieurs facteurs s'entremêlent (longue durée, gros contexte, qualité de connexion), et aucune procédure de reproduction unique n'a été identifiée.

※ La situation peut évoluer. Pour les dernières informations, consultez la liste des issues de Claude Code et la référence officielle des erreurs.

FAQ

Q1. Le mot « court » a-t-il un sens ?

Non. Il s'agit de la « répétition (dégénérescence) », où le modèle de langage se fige sur une même sortie ; il se trouve simplement que le point de fixation est le token « court ». Ce pourrait être un autre mot ou une autre suite de symboles. Ce n'est pas un problème de votre prompt ni de vos données.

Q2. Si « Response stalled mid-stream » apparaît, la sortie partielle est-elle perdue ?

Non. Comme le dit le message, « la réponse ci-dessus est peut-être incomplète » — ce qui a été transmis jusque-là reste disponible. Il peut manquer les dernières phrases ou le dernier appel d'outil, alors il suffit de reprendre les instructions à partir de là.

Q3. Un simple réessai suffit-il à corriger le problème ?

Dans les cas légers, cela peut suffire, mais réessayer dans la même session favorise la récidive, car le modèle imite la sortie corrompue précédente (la répétition). Après deux échecs, mieux vaut ne pas s'acharner et basculer sur une nouvelle session.

Q4. Est-ce que /compact corrige le problème ?

Ce n'est pas sûr. /compact résume le contexte mais conserve l'état, si bien que la cause de la répétition peut subsister. Pour réinitialiser l'état, /clear ou une nouvelle session est plus fiable.

Q5. Est-ce le même dysfonctionnement que la « fuite de balise court/invoke » de l'autre article ?

C'est lié, mais distinct. Cet article traite du type répétition + arrêt du flux, « court boucle à l'infini puis s'arrête sur stalled ». Le type fuite de balise, lui, est « court ou une balise invoke brute fuit à quelques reprises et l'appel d'outil échoue » ; pour les détails, consultez l'autre article.

Q6. Comment le prévenir en profondeur en tant que développeur ?

Trois mesures sont efficaces : définir un délai de lecture (timeout) sur le streaming, interrompre les répétitions anormales grâce à la détection de répétition, et en cas d'arrêt prématuré réessayer sans conserver la sortie corrompue dans l'historique. Une limite max_tokens évite aussi l'emballement du coût et du temps.

Q7. Dans quelles situations est-ce le plus fréquent ?

La probabilité augmente avec les sessions continues de plusieurs heures ou plusieurs jours, les contextes lourds de plusieurs centaines de milliers à environ un million de tokens, la génération d'un long texte juste avant un appel d'outil, les connexions instables (transfrontalières, lignes grand public, via tmux) et les tâches à sortie longue. Garder les choses courtes avec une tâche = une session est une bonne prévention.

Articles liés

• Erreur « court » ou balises invoke affichées dans Claude Code — type fuite de balise (distinct de cet article)
• Output blocked by content filtering policy : causes et solutions — erreur du filtre côté sortie
• Qu'est-ce que la commande /loop de Claude Code — le bon usage de l'exécution répétée