API Error: The response stopped arriving — What It Means and How to Fix It When Claude Code's Response Data Stops Midway

"API Error: The response stopped arriving" means that, partway through a streaming response, data stopped coming in even though the connection was still open, and Claude Code's own watchdog timer cut that connection off. Any output that finished before that point is still on screen. In an interactive session, reply continue and Claude picks up from the last completed point.

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

Before v2.1.227, this message read Response stalled mid-stream. The official error reference states the rename explicitly, and what is happening is the same. When you look for information or bug reports written under the old wording, search for both strings.

1. What the message means—silence, not a disconnect

Claude Code's official error reference explains this message as follows: the connection stayed open but stopped delivering data, so the streaming idle watchdog cut it off. It is not an error body returned by the API; it is a note that Claude Code itself attaches while receiving the response.

Even for "it stopped partway," Claude Code words the message differently depending on the cause. The official reference lists the four below, all ending with the same "The response above may be incomplete."

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.

The first line appears when the server returns an overload or 5xx error partway through the response, the second when the connection drops, and the third when your computer goes to sleep mid-response. Only the fourth, the message this article covers, means that data stopped coming even though there was neither an error nor a disconnect.

Four watchdog timers do the cutting off

According to the official network configuration documentation, Claude Code has four timers that abort a stream that has gone quiet, so that a dead connection fails instead of hanging indefinitely. The first three in the table below apply once the response has started streaming.

If you connect directly to the Anthropic API, the threshold to keep in mind is the byte-level watchdog's 180 seconds. In other words, the screen appears frozen for a few minutes before this message shows up. According to the official reference, when a request is still alive but no data has arrived for 20 seconds, the following banner appears first. It means "this has not failed yet," and the countdown runs to the moment the connection would be cut off (before v2.1.185 the threshold was 10 seconds and the wording was different).

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

If data resumes, the banner goes away on its own. This article's message appears when it does not go away, the timer runs out, and part of the output had already been completed.

2. Renamed from "Response stalled mid-stream" in v2.1.227

Right after describing the four messages, the official error reference says that before v2.1.227, Connection lost mid-response was shown as Connection closed mid-response and The response stopped arriving was shown as Response stalled mid-stream. The same release also relabeled the message for stalls before any output begins.

A case where the old Response stalled mid-stream message appeared together with the model repeating the same word over and over is covered in our article on Response stalled mid-stream and the endless "court" loop. For the disconnect-side message, reports from the old-wording era are in the Connection closed mid-response article, and the renamed wording is explained in the Connection lost mid-response article.

3. How it differs from similar messages

Which message you get depends on how far the response had progressed when it stopped. Laying out the official "Automatic retries" explanation along the progress of a response gives the following.

The reason ③ is not retried is also documented. Resending the request after a block of text or a tool call has completed could run the same tool call twice. So Claude Code keeps what was completed and attaches a note instead of discarding the turn.

The difference from Connection lost mid-response: a disconnect or silence

Both appear after some output has been produced, and both keep the output and let you resume with continue. What differs is how it stopped. Lost is a judgment that the connection was lost, so suspect a brief drop in your own network, a VPN reconnecting, or a device along the path cutting the connection. Stopped arriving is a judgment that the connection is still there but nothing is flowing through it, and it is cut off only after waiting out the watchdog timer. That is why the timer tuning covered in section 6 can only help on the stopped arriving side.

The difference from Streaming response ended…: stopped or ended empty

According to the official reference, Streaming response ended before any complete data was received is a warning shown when a response ended without delivering any usable data. Claude Code stops streaming, resends the same request, and continues the turn. The warning appears only once per interactive session (before v2.1.239 it resent silently). The reference says a common cause is a proxy or gateway along the path consuming or transforming the response body. Stopped arriving is a response that got partway and then stopped, and it is not resent automatically.

4. What happens to the work done so far

According to the official explanation, Claude Code keeps every completed block and discards the last, unfinished block at the end of the turn. That is why the last few sentences on screen, or the last tool call, may be missing. Tool calls that had completed are executed, and the turn continues from their results. What happens after the stop depends on the environment it runs in.

Output from -p when it stops, and how to continue

With the default text output in non-interactive mode, Claude Code prints the last completed text block from that turn, followed by this message (before v2.1.219 it printed only the message and the response was discarded). However, if no completed text is left—for example, because the conversation was compacted mid-turn and that text was removed—only the message is printed (added after checking the official error reference on September 26, 2026). With --output-format json or stream-json, the message goes into the result field. The official procedure is to wait until the connection settles, then resume the session and send continue.

# Continue the most recent conversation
claude -p "continue" --continue

# Continue a specific session by ID
claude -p "continue" --resume "$session_id"

On automatic resumption through hooks, the reporter of Issue #87972 writes that in the old-wording era the Stop hook fired and could continue automatically, but it stopped working around the time of the rename. This is the reporter's observation, and the official documentation does not say whether the earlier behavior was intended. Going by the current official documentation, a hook can log or notify, but it cannot resume the turn.

5. Causes—what is documented and what is reported

This message only reports the result—"data stopped coming"—and does not tell you why it stopped. Below, the information is sorted by how certain it is.

The official reference places this message in its "Server errors" section. That section opens by saying most of these come from the inference provider side, such as Anthropic's service, but for this particular wording the official explanation goes only as far as the mechanism above. The official documentation does not pin down whether it stopped in your own network, a device along the path, or the server.

#88900 and #90005 both say it stopped even though nothing was wrong with their own network. That alone, however, does not establish that the server is the cause. As the #90005 reporter also notes, tests of short connections do not reproduce a connection that stays open for several minutes and then goes quiet partway through.

6. What to do when it stops

These are ordered from least effort and most effect. If it happened only once, you are done after step 2.

An example for ~/.claude/settings.json (setting the byte-level watchdog to 10 minutes):

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

7. Confirming that it is fixed

Do not call it fixed just because it did not appear once. Run a task of similar size and check the following four points.

# Check the version
claude --version

# Start with debug logging
claude --debug

# Count the conversation log files containing this wording (macOS, Linux)
grep -rl "The response stopped arriving" ~/.claude/projects/ | wc -l

# Likewise, count the lines containing this wording (PowerShell)
Get-ChildItem "$HOME\.claude\projects" -Recurse -Filter *.jsonl | Select-String -SimpleMatch "The response stopped arriving" | Measure-Object

Treat the count as a rough guide. The #90005 reporter writes that in one 85-minute stretch it stopped 15 times on screen, but only 1 record was left in the conversation logs. Even if the logs show 0, keeping your own tally of on-screen stops is more reliable.

8. What to record when you report it

The official error reference lists the following four channels for when the problem is not resolved.

• Run /feedback inside Claude Code. It sends the conversation transcript and your description to Anthropic, and can also open a pre-filled GitHub issue. With providers such as Bedrock or Vertex, it saves locally instead of sending
• Run claude doctor in your shell to see a read-only diagnosis of your installation
• Check status.claude.com for incidents
• Search existing GitHub issues, using both the old and the new wording

9. What is confirmed and what is not

10. Summary

"API Error: The response stopped arriving" means that after a response had partly streamed, data stopped while the connection stayed open, and Claude Code's watchdog timer cut it off. It is the same thing as Response stalled mid-stream before v2.1.227, and completed output is kept. First check the state of your work, then reply continue.

If it keeps happening, try in this order: update your version, isolate the VPN, proxy, or gateway, and keep each response shorter. Only in environments where the path goes quiet for long periods is lengthening the byte-level watchdog an option. Connection lost mid-response, where the connection itself drops, points to different places to investigate, so compare the wording of the message first. Other errors are collected in our roundup of common Claude Code errors and fixes.

FAQ

Q. What does "API Error: The response stopped arriving" mean?
A. It means that partway through a streaming response, data stopped arriving while the connection was still open, and Claude Code's watchdog timer cut that connection off. It is the message for a stop after one block of text or one tool call has completed, and the output up to that point is kept.

Q. Is it a different error from "Response stalled mid-stream"?
A. It is the same one. The official error reference states that before v2.1.227 this message was Response stalled mid-stream. Only the wording changed; it does not mean a new kind of failure has started.

Q. What should I reply to resume where it left off?
A. Reply continue. It resumes from the last completed block. If it stopped in the middle of a file operation or command, it is safer to check the actual state with git status or similar before replying.

Q. Will raising the retry count make it go away?
A. No. In this situation Claude Code is designed not to resend at all, so that the same tool call does not run twice. CLAUDE_CODE_MAX_RETRIES applies to failures before output begins.

Q. How is it different from "Connection lost mid-response"?
A. Lost is a judgment that the connection itself dropped; stopped arriving is a judgment that the connection remained but data stopped coming. In both cases completed output is kept and you can resume with continue, but only stopped arriving can be helped by adjusting the watchdog time.

Primary sources

• Claude Code — Error reference (official documentation): the four "The response above may be incomplete" messages and the v2.1.227 rename, false alarms before v2.1.222, Automatic retries, the waiting banner, No response from API, Streaming response ended before any complete data was received, Report an error
• Claude Code — Enterprise network configuration (official documentation): the four watchdog timers and their default times, the environment variables for configuring them, debug logs, and how to pass settings to background agents
• Claude Code — Environment variables (official documentation): descriptions of CLAUDE_STREAM_IDLE_TIMEOUT_MS, CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS, and API_FORCE_IDLE_TIMEOUT
• Claude Code — Hooks reference (official documentation): StopFailure for turns that end in an API error
• Claude Code — Run Claude Code programmatically (official documentation): resuming with --continue and --resume
• anthropics/claude-code — CHANGELOG (official): the entries for v2.1.222, v2.1.227, v2.1.229, v2.1.232, v2.1.246, and v2.1.257
• GitHub issues: #88900, #90005, #89027, #87246, #87972 (all user reports; checked on September 22, 2026)