API Error: The response stopped arriving – Bedeutung und Lösung, wenn die Antwortdaten in Claude Code mittendrin stoppen

„API Error: The response stopped arriving“ bedeutet: Während eine Antwort übertragen wurde, kamen keine Daten mehr an, obwohl die Verbindung offen blieb, und ein Überwachungstimer von Claude Code selbst hat die Verbindung daraufhin abgebrochen. Die bis dahin abgeschlossene Ausgabe bleibt auf dem Bildschirm erhalten. In einer interaktiven Sitzung antworten Sie einfach mit continue, und Claude Code macht an der zuletzt abgeschlossenen Stelle weiter.

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

Vor v2.1.227 lautete diese Meldung Response stalled mid-stream. Die offizielle Fehlerreferenz nennt die Umbenennung ausdrücklich; es passiert dasselbe wie vorher. Wenn Sie nach Informationen oder Fehlerberichten suchen, die noch den alten Wortlaut verwenden, suchen Sie mit beiden Formulierungen.

1. Was die Meldung bedeutet – kein Abbruch, sondern „Funkstille“

Die offizielle Fehlerreferenz von Claude Code erklärt diese Meldung so: Die Verbindung blieb offen, lieferte aber keine Daten mehr, deshalb hat der Leerlaufwächter für das Streaming (idle watchdog) sie beendet. Es ist also kein Fehlertext, den die API zurückgegeben hat, sondern ein Hinweis, den Claude Code als Empfänger der Antwort selbst anfügt.

Auch wenn es jedes Mal „mittendrin hängen geblieben“ heißt, formuliert Claude Code die Meldung je nach Ursache anders. Die offizielle Referenz nennt die folgenden vier; gemeinsam ist ihnen der Schluss „The response above may be incomplete.“ (Die Antwort oben ist möglicherweise unvollständig.)

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.

Die erste Zeile steht für den Fall, dass der Server mitten in der Antwort eine Überlastung oder einen 5xx-Fehler meldet, die zweite für eine abgebrochene Verbindung und die dritte dafür, dass der Rechner während der Antwort in den Ruhezustand ging. Nur die vierte, die Meldung aus diesem Artikel, bedeutet: Es gab weder einen Fehler noch einen Verbindungsabbruch, aber es kamen keine Daten mehr an.

Beendet wird die Verbindung von vier Überwachungstimern

Laut der offiziellen Dokumentation zur Netzwerkkonfiguration hat Claude Code vier Timer, die einen verstummten Stream beenden. So bleibt eine tote Verbindung nicht ewig hängen, sondern kann als Fehler behandelt werden. Sobald die Antwort zu fließen begonnen hat, greifen die ersten drei in der Tabelle unten.

Bei direkter Verbindung zur Anthropic API ist der Richtwert die 180 Sekunden der Überwachung auf Byte-Ebene. Bis diese Meldung erscheint, wirkt der Bildschirm also mehrere Minuten lang eingefroren. Laut offizieller Referenz erscheint vorher schon das folgende Banner, wenn die Anfrage noch lebt, aber 20 Sekunden lang keine Daten kommen. Es bedeutet „noch nicht fehlgeschlagen“, und der Countdown zählt bis zum Zeitpunkt des Abbruchs (vor v2.1.185 waren es 10 Sekunden, und der Wortlaut war ein anderer).

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

Kommen die Daten wieder, verschwindet das Banner von selbst. Verschwindet es nicht, läuft der Countdown bis zum Abbruch, und war zu diesem Zeitpunkt bereits ein Teil der Ausgabe abgeschlossen, erscheint die Meldung aus diesem Artikel.

2. In v2.1.227 von „Response stalled mid-stream“ umbenannt

Direkt nach der Erklärung der vier Meldungen schreibt die offizielle Fehlerreferenz: Vor v2.1.227 wurde Connection lost mid-response als Connection closed mid-response und The response stopped arriving als Response stalled mid-stream angezeigt. In derselben Version wurde auch die Meldung für den Fall umbenannt, dass noch keine Ausgabe begonnen hat.

Fälle, in denen der alte Wortlaut Response stalled mid-stream zusammen mit einem Modell auftrat, das endlos dasselbe Wort wiederholte, fassen wir im Artikel zu Response stalled mid-stream und der „court“-Endlosschleife zusammen. Bei der Meldung für eine abgebrochene Verbindung trennen wir die Berichte aus der Zeit des alten Wortlauts im Artikel zu Connection closed mid-response vom neuen Wortlaut im Artikel zu Connection lost mid-response.

3. Unterschiede zu ähnlichen Meldungen

Welche Meldung erscheint, hängt davon ab, wie weit die Antwort gekommen war, als sie hängen blieb. Ordnet man die offizielle Erklärung „Automatic retries“ nach dem Fortschritt der Antwort, ergibt sich folgendes Bild.

Warum bei ③ nicht erneut gesendet wird, steht ebenfalls in der offiziellen Referenz: Wird die Anfrage erneut gesendet, nachdem bereits ein Textblock oder ein Tool-Aufruf abgeschlossen war, könnte derselbe Tool-Aufruf doppelt ausgeführt werden. Deshalb behält Claude Code das Abgeschlossene und hängt einen Hinweis an, statt den Turn zu verwerfen.

Der Unterschied zu Connection lost mid-response: Abbruch oder Funkstille

Beide Meldungen erscheinen, nachdem bereits ein Teil der Ausgabe da war; in beiden Fällen bleibt die Ausgabe erhalten, und Sie machen mit continue weiter. Unterschiedlich ist die Art des Stillstands. lost bedeutet, dass die Verbindung als verloren erkannt wurde; hier kommen kurze Aussetzer der eigenen Leitung, ein neu aufgebautes VPN oder ein Gerät auf dem Weg, das die Verbindung trennt, in Frage. stopped arriving bedeutet, dass die Verbindung zwar noch besteht, aber kein Inhalt mehr fließt; abgebrochen wird erst, nachdem der Überwachungstimer abgelaufen ist. Deshalb kann die in Kapitel 6 beschriebene Anpassung der Timer nur bei stopped arriving etwas bewirken.

Der Unterschied zu Streaming response ended…: hängen geblieben oder leer beendet

Laut offizieller Referenz ist Streaming response ended before any complete data was received eine Warnung für den Fall, dass die Antwort endete, ohne auch nur ein verwertbares Datenstück zu liefern. Claude Code verzichtet dann auf Streaming, sendet dieselbe Anfrage erneut und setzt den Turn fort. In interaktiven Sitzungen erscheint die Warnung nur einmal pro Sitzung (vor v2.1.239 wurde stillschweigend erneut gesendet). Als häufige Ursache nennt die offizielle Referenz einen Proxy oder ein Gateway auf dem Weg, der den Antwortinhalt verbraucht oder umwandelt. stopped arriving dagegen bleibt stehen, nachdem die Antwort schon teilweise angekommen ist, und wird nicht automatisch erneut gesendet.

4. Was mit der bisherigen Arbeit passiert

Laut offizieller Erklärung behält Claude Code alle abgeschlossenen Blöcke und verwirft am Ende des Turns den letzten, unvollständigen Block. Deshalb können die letzten Sätze auf dem Bildschirm oder der letzte Tool-Aufruf fehlen. Abgeschlossene Tool-Aufrufe werden ausgeführt, und der Turn geht mit deren Ergebnissen weiter. Wie es nach dem Stillstand weitergeht, hängt von der Ausführungsumgebung ab.

Ausgabe und Fortsetzung bei -p

Mit der Standard-Textausgabe im nicht interaktiven Modus gibt Claude Code den letzten abgeschlossenen Textblock dieses Turns aus, gefolgt von dieser Meldung (vor v2.1.219 kam nur die Meldung, und die Antwort wurde verworfen). Ist allerdings kein abgeschlossener Text mehr vorhanden, etwa weil das Gespräch mitten im Turn komprimiert und dieser Text dabei entfernt wurde, erscheint nur die Meldung (ergänzt nach Prüfung der offiziellen Fehlerreferenz am 26. September 2026). Mit --output-format json oder stream-json landet die Meldung im Feld result. Das offizielle Vorgehen: Warten Sie, bis sich die Verbindung beruhigt hat, setzen Sie dann die Sitzung fort und senden Sie continue.

# Das letzte Gespräch fortsetzen
claude -p "continue" --continue

# Mit Angabe der Sitzungs-ID fortsetzen
claude -p "continue" --resume "$session_id"

Zur automatischen Fortsetzung per Hook schreibt der Verfasser von Issue #87972: Zur Zeit des alten Wortlauts habe der Stop-Hook ausgelöst und automatisch weitergemacht, doch etwa zeitgleich mit der Umbenennung funktioniere das nicht mehr. Das ist eine Beobachtung des Verfassers; ob das frühere Verhalten beabsichtigt war, steht nirgends offiziell. Folgt man der aktuellen offiziellen Dokumentation, können Sie per Hook zwar protokollieren oder benachrichtigen, den Turn aber nicht fortsetzen lassen.

5. Ursachen – was offiziell dokumentiert und was nur berichtet ist

Die Meldung teilt nur das Ergebnis mit, dass keine Daten mehr kamen; warum, lässt sich an ihr nicht ablesen. Wir ordnen die Ursachen nach ihrer Belastbarkeit.

Offiziell steht diese Meldung im Abschnitt „Server errors“ der Fehlerreferenz. Am Anfang dieses Abschnitts heißt es zwar, die meisten Fehler kämen vom Inferenzanbieter, etwa den Diensten von Anthropic, doch zu genau diesem Wortlaut erklärt die offizielle Referenz nur den oben beschriebenen Mechanismus. Ob der Stillstand in Ihrer eigenen Leitung, bei einem Gerät auf dem Weg oder beim Server entstand, legt die offizielle Referenz nicht fest.

In #88900 und #90005 heißt es, die Antwort sei hängen geblieben, obwohl an der eigenen Leitung nichts Auffälliges zu finden war. Allein daraus lässt sich aber nicht schließen, dass die Ursache beim Server liegt. Wie auch der Verfasser von #90005 schreibt, bilden kurze Verbindungstests die Situation nicht nach, in der eine mehrere Minuten offene Verbindung mittendrin verstummt.

6. Vorgehen, wenn die Antwort hängen bleibt

Die Schritte sind von oben nach unten geordnet: zuerst die mit wenig Aufwand und großer Wirkung. Trat die Meldung nur einmal auf, sind Sie nach Schritt 2 fertig.

Ein Beispiel für ~/.claude/settings.json (Überwachung auf Byte-Ebene auf 10 Minuten):

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

7. Prüfen, ob es behoben ist

Erklären Sie das Problem nicht schon für gelöst, nur weil die Meldung einmal ausblieb. Achten Sie bei einer Aufgabe ähnlichen Umfangs auf die folgenden vier Punkte.

# Version prüfen
claude --version

# Mit Debug-Log starten
claude --debug

# Gesprächsprotokolle mit diesem Wortlaut zählen (macOS, Linux)
grep -rl "The response stopped arriving" ~/.claude/projects/ | wc -l

# Ebenso die Zeilen mit diesem Wortlaut zählen (PowerShell)
Get-ChildItem "$HOME\.claude\projects" -Recurse -Filter *.jsonl | Select-String -SimpleMatch "The response stopped arriving" | Measure-Object

Nutzen Sie die Anzahl nur als Anhaltspunkt. Der Verfasser von #90005 schreibt, dass es in einem Zeitraum von 85 Minuten auf dem Bildschirm 15-mal hängen blieb, im Gesprächsprotokoll aber nur ein einziger Eintrag landete. Selbst wenn die Protokolle 0 Treffer zeigen, ist es sicherer, auch selbst mitzuschreiben, wie oft es auf dem Bildschirm hängen blieb.

8. Was Sie für einen Fehlerbericht festhalten

Die offizielle Fehlerreferenz nennt vier Anlaufstellen, wenn sich ein Problem nicht lösen lässt:

• Führen Sie in Claude Code /feedback aus. Gesprächsverlauf und Beschreibung werden an Anthropic gesendet, und Sie können auch ein vorausgefülltes GitHub-Issue öffnen. Bei Anbietern wie Bedrock oder Vertex wird stattdessen lokal gespeichert
• Führen Sie in der Shell claude doctor aus und sehen Sie sich die schreibgeschützte Diagnose Ihrer Installation an
• Prüfen Sie auf status.claude.com, ob eine Störung vorliegt
• Durchsuchen Sie die bestehenden Issues auf GitHub, mit dem alten und dem neuen Wortlaut

9. Was bestätigt ist und was nicht

10. Zusammenfassung

„API Error: The response stopped arriving“ bedeutet: Nachdem die Antwort bereits teilweise übertragen war, stoppten die Daten, obwohl die Verbindung offen blieb, und ein Überwachungstimer von Claude Code hat abgebrochen. Es ist dieselbe Meldung wie Response stalled mid-stream vor v2.1.227, und die abgeschlossene Ausgabe bleibt erhalten. Prüfen Sie zuerst den Stand Ihrer Arbeit und antworten Sie dann mit continue.

Tritt sie häufig auf, gehen Sie in dieser Reihenfolge vor: Version aktualisieren, VPN, Proxy und Gateway eingrenzen, einzelne Antworten kürzer halten. Nur in Umgebungen, in denen der Netzwerkweg lange verstummt, lohnt es sich, die Zeit der Überwachung auf Byte-Ebene zu verlängern. Bei Connection lost mid-response, wo die Verbindung selbst abbricht, suchen Sie die Ursache an anderer Stelle; vergleichen Sie deshalb zuerst den Wortlaut der Meldung. Weitere Fehler fassen wir unter Häufige Fehler in Claude Code und ihre Lösungen zusammen.

FAQ

F: Was bedeutet „API Error: The response stopped arriving“?
A: Während die Antwort übertragen wurde, kamen keine Daten mehr an, obwohl die Verbindung offen blieb, und ein Überwachungstimer von Claude Code hat die Verbindung beendet. Die Meldung erscheint, wenn die Antwort nach einem abgeschlossenen Textblock oder Tool-Aufruf hängen blieb; die bisherige Ausgabe bleibt erhalten.

F: Ist das ein anderer Fehler als „Response stalled mid-stream“?
A: Nein, es ist derselbe. Die offizielle Fehlerreferenz hält ausdrücklich fest, dass diese Meldung vor v2.1.227 Response stalled mid-stream lautete. Nur der Wortlaut hat sich geändert; es ist keine neue Art von Störung.

F: Was muss ich antworten, damit es weitergeht?
A: Antworten Sie mit continue. Es geht ab dem zuletzt abgeschlossenen Block weiter. Blieb die Antwort mitten in einem Dateivorgang oder Befehl stehen, prüfen Sie sicherheitshalber zuerst mit git status oder Ähnlichem den tatsächlichen Stand.

F: Verschwindet die Meldung, wenn ich mehr Wiederholungsversuche zulasse?
A: Nein. In dieser Situation sendet Claude Code grundsätzlich nicht erneut, damit derselbe Tool-Aufruf nicht doppelt ausgeführt wird. CLAUDE_CODE_MAX_RETRIES wirkt nur bei Fehlern, bevor eine Ausgabe begonnen hat.

F: Was ist der Unterschied zu „Connection lost mid-response“?
A: lost bedeutet, dass die Verbindung selbst abgebrochen ist; stopped arriving bedeutet, dass die Verbindung bestehen blieb, aber keine Daten mehr kamen. In beiden Fällen bleibt die abgeschlossene Ausgabe erhalten, und Sie können mit continue weitermachen, doch nur bei stopped arriving kann es etwas bringen, die Überwachungszeit anzupassen.

Verwendete Primärquellen

• Claude Code — Error reference (offizielle Dokumentation): die vier Meldungen unter The response above may be incomplete und die Umbenennung in v2.1.227, Fehlalarme vor v2.1.222, Automatic retries, das Warte-Banner, No response from API, Streaming response ended before any complete data was received, Report an error
• Claude Code — Enterprise network configuration (offizielle Dokumentation): die vier Überwachungstimer und ihre Standardzeiten, Umgebungsvariablen zur Einstellung, Debug-Log, Weitergabe von Einstellungen an Hintergrund-Agenten
• Claude Code — Environment variables (offizielle Dokumentation): Beschreibung von CLAUDE_STREAM_IDLE_TIMEOUT_MS, CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS und API_FORCE_IDLE_TIMEOUT
• Claude Code — Hooks reference (offizielle Dokumentation): StopFailure bei Turns, die mit einem API-Fehler enden
• Claude Code — Run Claude Code programmatically (offizielle Dokumentation): Fortsetzen mit --continue und --resume
• anthropics/claude-code — CHANGELOG (offiziell): die Einträge zu v2.1.222, v2.1.227, v2.1.229, v2.1.232, v2.1.246 und v2.1.257
• GitHub-Issues: #88900, #90005, #89027, #87246, #87972 (alle Berichte von Nutzern; geprüft am 22. September 2026)