API Error: The response stopped arriving : sens et solutions — quand les données de réponse de Claude Code s'arrêtent en cours de route

« API Error: The response stopped arriving » signale qu'au milieu d'une réponse en cours de diffusion, les données ont cessé d'arriver alors que la connexion restait ouverte, et que le minuteur de surveillance de Claude Code lui-même a coupé cette connexion. Tout ce qui avait été terminé avant ce moment reste affiché à l'écran. Dans une session interactive, il suffit de répondre continue pour reprendre à partir du dernier point terminé.

API Error: The response stopped arriving. The response above may be incomplete.

Avant la v2.1.227, ce message s'affichait sous la forme Response stalled mid-stream. La référence officielle des erreurs indique explicitement ce changement de nom, et ce qui se passe est identique. Si vous cherchez des informations ou des rapports de bug rédigés avec l'ancien libellé, faites la recherche avec les deux formulations.

1. Ce que signifie ce message — un silence, pas une coupure

La référence officielle des erreurs de Claude Code explique ce message ainsi : la connexion est restée ouverte mais a cessé de transmettre des données, et la surveillance d'inactivité du streaming (idle watchdog) l'a donc coupée. Ce n'est pas le corps d'une erreur renvoyée par l'API, mais une mention que Claude Code ajoute lui-même pendant qu'il reçoit la réponse.

Même pour un simple « arrêt en cours de route », Claude Code change de formulation selon la cause. La documentation officielle en liste quatre, qui se terminent toutes par la même phrase : « The response above may be incomplete. » (la réponse ci-dessus est peut-être incomplète).

API Error: Server error mid-response. The response above may be incomplete.
API Error: Connection lost mid-response. The response above may be incomplete.
API Error: Your computer went to sleep mid-response. The response above may be incomplete.
API Error: The response stopped arriving. The response above may be incomplete.

La première ligne apparaît quand le serveur renvoie une erreur de surcharge ou une erreur 5xx en cours de réponse, la deuxième quand la connexion est rompue, la troisième quand l'ordinateur se met en veille pendant la réponse. Seule la quatrième, le message traité ici, indique que les données ont cessé d'arriver alors qu'il n'y a eu ni erreur ni coupure.

Quatre minuteurs de surveillance se chargent de couper

D'après la documentation officielle sur la configuration réseau, Claude Code dispose de quatre minuteurs qui interrompent un flux devenu silencieux. Le but est qu'une connexion morte ne reste pas bloquée indéfiniment et soit traitée comme un échec. Les trois premiers du tableau ci-dessous s'appliquent une fois que la réponse a commencé à arriver.

Si vous êtes connecté directement à l'API Anthropic, le seuil à retenir est celui de la surveillance au niveau de l'octet : 180 secondes. Autrement dit, l'écran semble figé pendant quelques minutes avant que ce message n'apparaisse. D'après la documentation officielle, lorsqu'une requête est toujours vivante mais qu'aucune donnée n'est arrivée depuis 20 secondes, la bannière suivante s'affiche d'abord. Elle signifie « ce n'est pas encore un échec », et le compte à rebours va jusqu'au moment de la coupure (avant la v2.1.185, le seuil était de 10 secondes et le libellé était différent).

Waiting for API response · will retry in … · check your network

Si les données reprennent, la bannière disparaît d'elle-même. Le message de cet article apparaît quand elle ne disparaît pas, que le délai arrive à son terme et qu'une partie de la sortie était déjà terminée.

2. Renommé en v2.1.227 depuis « Response stalled mid-stream »

Juste après avoir décrit les quatre messages, la référence officielle des erreurs précise qu'avant la v2.1.227, Connection lost mid-response s'affichait sous la forme Connection closed mid-response, et The response stopped arriving sous la forme Response stalled mid-stream. La même version a aussi changé le libellé du message affiché avant le début de toute sortie.

Un cas où l'ancien message Response stalled mid-stream est apparu en même temps qu'un modèle répétant sans fin le même mot est traité dans notre article sur Response stalled mid-stream et la boucle infinie de « court ». Pour le message côté coupure, les signalements de l'époque de l'ancien libellé sont réunis dans l'article sur Connection closed mid-response, et le libellé renommé est expliqué dans l'article sur Connection lost mid-response.

3. Les différences avec les messages voisins

Le message affiché dépend de l'endroit où en était la réponse au moment de l'arrêt. Si l'on suit l'explication officielle « Automatic retries » dans l'ordre de progression d'une réponse, on obtient ceci.

La raison pour laquelle ③ n'est pas renvoyé est elle aussi documentée. Renvoyer la requête après la fin d'un bloc de texte ou d'un appel d'outil risquerait d'exécuter deux fois le même appel d'outil. Claude Code conserve donc ce qui est terminé et ajoute une mention, au lieu de jeter le tour.

La différence avec Connection lost mid-response : coupure ou silence

Les deux messages apparaissent après qu'une partie de la sortie a été produite, et dans les deux cas la sortie est conservée et l'on reprend avec continue. Ce qui diffère, c'est la manière dont tout s'est arrêté. Lost signifie que la connexion a été perdue : on soupçonne alors une micro-coupure du réseau local, une reconnexion du VPN ou un équipement sur le trajet qui a coupé la connexion. Stopped arriving signifie que la connexion est toujours là mais que rien n'y circule, et la coupure n'intervient qu'après avoir attendu toute la durée du minuteur de surveillance. C'est pourquoi le réglage des minuteurs abordé en section 6 ne peut avoir d'effet que du côté de stopped arriving.

La différence avec Streaming response ended… : arrêtée ou terminée à vide

D'après la documentation officielle, Streaming response ended before any complete data was received est un avertissement affiché quand une réponse s'est terminée sans avoir transmis la moindre donnée exploitable. Claude Code abandonne alors le streaming, renvoie la même requête et poursuit le tour. L'avertissement n'apparaît qu'une fois par session interactive (avant la v2.1.239, le renvoi se faisait en silence). La documentation indique qu'une cause fréquente est un proxy ou une passerelle sur le trajet qui consomme ou transforme le corps de la réponse. Avec stopped arriving, la réponse est arrivée en partie puis s'est arrêtée, et elle n'est pas renvoyée automatiquement.

4. Ce que devient le travail déjà fait

Selon l'explication officielle, Claude Code conserve tous les blocs terminés et, à la fin du tour, jette le dernier bloc resté inachevé. C'est pour cela que les dernières phrases à l'écran, ou le dernier appel d'outil, peuvent manquer. Les appels d'outil qui étaient terminés sont exécutés, et le tour se poursuit à partir de leurs résultats. Ce qui se passe après l'arrêt dépend de l'environnement d'exécution.

La sortie de -p en cas d'arrêt, et comment continuer

Avec la sortie texte par défaut du mode non interactif, Claude Code affiche le dernier bloc de texte terminé dans ce tour, suivi de ce message (avant la v2.1.219, seul le message s'affichait et la réponse était jetée). En revanche, s'il ne reste aucun texte terminé — par exemple parce que la conversation a été compactée en plein tour et que ce texte a disparu —, seul le message s'affiche (ajouté après vérification dans la référence officielle des erreurs le 26 septembre 2026). Avec --output-format json ou stream-json, ce message est placé dans le champ result. La procédure officielle consiste à attendre que la connexion se stabilise, puis à reprendre la session et à envoyer continue.

# Continuer la conversation la plus récente
claude -p "continue" --continue

# Continuer une session précise par son ID
claude -p "continue" --resume "$session_id"

À propos de la reprise automatique par hook, l'auteur de l'issue #87972 écrit qu'à l'époque de l'ancien libellé, le hook Stop se déclenchait et permettait de continuer automatiquement, mais que cela a cessé de fonctionner à peu près au moment du changement de nom. C'est une observation de l'auteur, et la documentation officielle ne dit pas si l'ancien comportement était voulu. Si l'on s'en tient à la documentation officielle actuelle, un hook peut journaliser ou notifier, mais pas relancer le tour.

5. Les causes — ce qui est documenté et ce qui est signalé

Ce message ne fait que constater un résultat — « les données ont cessé d'arriver » — et ne dit pas pourquoi. Voici les informations, classées selon leur degré de certitude.

La documentation officielle range ce message dans la section « Server errors » de la référence des erreurs. Cette section commence en indiquant que la plupart de ces erreurs viennent du fournisseur d'inférence, comme le service d'Anthropic, mais pour ce libellé précis, l'explication officielle s'arrête au mécanisme décrit ci-dessus. La documentation officielle ne précise pas si l'arrêt s'est produit sur votre réseau, sur un équipement du trajet ou sur le serveur.

#88900 et #90005 disent tous deux que l'arrêt s'est produit alors que rien d'anormal n'apparaissait sur leur réseau. Cela ne suffit pas pour autant à conclure que le serveur est en cause. Comme le note aussi l'auteur de #90005, des tests sur des échanges courts ne reproduisent pas une connexion qui reste ouverte plusieurs minutes puis devient silencieuse en cours de route.

6. Que faire quand la réponse s'arrête

Les étapes sont classées de la moins coûteuse et la plus efficace à la plus lourde. Si c'est arrivé une seule fois, vous en avez fini après l'étape 2.

Exemple à écrire dans ~/.claude/settings.json (surveillance au niveau de l'octet portée à 10 minutes) :

{
  "env": {
    "CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS": "600000"
  }
}

7. Vérifier que c'est réglé

Ne considérez pas le problème comme réglé parce que le message n'est pas apparu une fois. Lancez un travail de taille comparable et vérifiez les quatre points suivants.

# Vérifier la version
claude --version

# Lancer avec le journal de débogage
claude --debug

# Compter les fichiers de conversation contenant ce libellé (macOS, Linux)
grep -rl "The response stopped arriving" ~/.claude/projects/ | wc -l

# De même, compter les lignes contenant ce libellé (PowerShell)
Get-ChildItem "$HOME\.claude\projects" -Recurse -Filter *.jsonl | Select-String -SimpleMatch "The response stopped arriving" | Measure-Object

Servez-vous de ce nombre comme d'un ordre de grandeur. L'auteur de #90005 écrit que, sur une période de 85 minutes, la réponse s'est arrêtée 15 fois à l'écran, mais qu'un seul enregistrement subsistait dans les journaux de conversation. Même si les journaux affichent 0, noter vous-même le nombre d'arrêts vus à l'écran est plus fiable.

8. Les informations à garder pour un signalement

La référence officielle des erreurs indique les quatre recours suivants quand le problème n'est pas résolu.

• Exécuter /feedback dans Claude Code. La transcription de la conversation et votre description sont envoyées à Anthropic, et il est aussi possible d'ouvrir une issue GitHub préremplie. Avec des fournisseurs comme Bedrock ou Vertex, le tout est enregistré localement au lieu d'être envoyé
• Exécuter claude doctor dans le shell pour obtenir un diagnostic en lecture seule de l'installation
• Vérifier les incidents sur status.claude.com
• Chercher dans les issues GitHub existantes, avec l'ancien et le nouveau libellé

9. Ce qui est confirmé et ce qui ne l'est pas

10. En résumé

« API Error: The response stopped arriving » signale qu'après la diffusion d'une partie de la réponse, les données se sont arrêtées alors que la connexion restait ouverte, et que le minuteur de surveillance de Claude Code a coupé. C'est la même chose que Response stalled mid-stream avant la v2.1.227, et la sortie terminée est conservée. Vérifiez d'abord l'état de votre travail, puis répondez continue.

Si le message revient souvent, essayez dans cet ordre : mettre à jour la version, isoler le VPN, le proxy ou la passerelle, puis raccourcir chaque réponse. Allonger la surveillance au niveau de l'octet n'est une option que dans les environnements où le trajet reste longtemps silencieux. Avec Connection lost mid-response, où la connexion elle-même est rompue, ce n'est pas au même endroit qu'il faut chercher : comparez donc d'abord le libellé du message. Les autres erreurs sont réunies dans notre récapitulatif des erreurs courantes de Claude Code et de leurs solutions.

FAQ

Q. Que signifie « API Error: The response stopped arriving » ?
A. Cela signifie qu'au milieu d'une réponse en cours de diffusion, les données ont cessé d'arriver alors que la connexion restait ouverte, et que le minuteur de surveillance de Claude Code a coupé cette connexion. C'est le message affiché pour un arrêt survenu après la fin d'un bloc de texte ou d'un appel d'outil, et la sortie produite jusque-là est conservée.

Q. Est-ce une erreur différente de « Response stalled mid-stream » ?
A. Non, c'est la même. La référence officielle des erreurs indique explicitement qu'avant la v2.1.227, ce message s'affichait sous la forme Response stalled mid-stream. Seul le libellé a changé ; cela ne signifie pas qu'un nouveau type de panne est apparu.

Q. Que répondre pour reprendre là où ça s'est arrêté ?
A. Répondez continue. La suite reprend à partir du dernier bloc terminé. Si l'arrêt est survenu au milieu d'une opération sur des fichiers ou d'une commande, il est plus sûr de vérifier d'abord l'état réel avec git status ou un outil équivalent avant de répondre.

Q. Augmenter le nombre de nouvelles tentatives fera-t-il disparaître le message ?
A. Non. Dans cette situation, Claude Code est conçu pour ne rien renvoyer du tout, afin de ne pas exécuter deux fois le même appel d'outil. CLAUDE_CODE_MAX_RETRIES s'applique aux échecs survenus avant le début de la sortie.

Q. Quelle différence avec « Connection lost mid-response » ?
A. Lost signifie que la connexion elle-même a été rompue ; stopped arriving signifie que la connexion est restée en place mais que les données ont cessé d'arriver. Dans les deux cas, la sortie terminée est conservée et l'on peut reprendre avec continue, mais seul stopped arriving peut bénéficier d'un réglage de la durée de surveillance.

Sources primaires consultées

• Claude Code — Error reference (documentation officielle) : les quatre messages « The response above may be incomplete » et le changement de nom de la v2.1.227, les fausses alertes avant la v2.1.222, Automatic retries, la bannière d'attente, No response from API, Streaming response ended before any complete data was received, Report an error
• Claude Code — Enterprise network configuration (documentation officielle) : les quatre minuteurs de surveillance et leurs durées par défaut, les variables d'environnement de réglage, les journaux de débogage, la transmission des réglages aux agents en arrière-plan
• Claude Code — Environment variables (documentation officielle) : description de CLAUDE_STREAM_IDLE_TIMEOUT_MS, CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS et API_FORCE_IDLE_TIMEOUT
• Claude Code — Référence des hooks (documentation officielle) : StopFailure pour les tours qui se terminent sur une erreur d'API
• Claude Code — Run Claude Code programmatically (documentation officielle) : reprise avec --continue et --resume
• anthropics/claude-code — CHANGELOG (officiel) : les entrées v2.1.222, v2.1.227, v2.1.229, v2.1.232, v2.1.246 et v2.1.257
• Issues GitHub : #88900, #90005, #89027, #87246, #87972 (toutes des signalements d'utilisateurs, consultées le 22 septembre 2026)