Your response cuts off mid-sentence and Claude Code prints this:
API Error: Connection closed mid-response. The response above may be incomplete.
If you've seen it once, you've probably seen it a dozen times. That's not a guess — it's what the GitHub issue tracker actually shows.
It's not new, and it's not Opus 5's fault alone
A scan I ran this morning flagged this as an Opus 5 launch problem — a fresh regression tied to the July 29 release. I went to verify it and the story fell apart in a good way: searching GitHub for "connection closed" in the title turns up at least 12 open issues carrying that exact phrase. The oldest one I read in full is from July 7, reporting the same error on Claude Code 2.1.201 and 2.1.202 — weeks before Opus 5 existed — and that report itself cites three even older related issues as prior art.
So the honest headline isn't "Opus 5 has a new bug." It's "this error has been open, unresolved, and recurring for months, across versions, across macOS and Windows, in both the desktop app and the CLI — and nobody from Anthropic has said anything about it on any of the reports I checked."
Two people independently did the math
What's new as of this week isn't the bug. It's that two different users, on two different platforms, both got tired of guessing and parsed their own usage logs.
#83183, filed August 1 —
Windows 11, Claude Code desktop app, someone running roughly 52 scheduled tasks and 10-20
concurrent sessions. They counted 315 occurrences across 130 sessions, 9 to 60 a day.
They also found 254 ECONNRESETs across 250 transcripts in nine days, against only four
HTTP 529s and zero 500s — which argues against plain server overload. Their sharpest point:
in an unattended scheduled run, a truncated response still reports success. The failure is
silent unless someone actually reads the output.
#83657, filed August 3 — macOS, Claude Code CLI, Opus 5 at xhigh effort with a near-1M-token context. They parsed 130,204 total API responses and found 203 occurrences of the error — 0.16% over their whole history, but 1.04% since July 29, the day Opus 5 and client version 2.1.220 both shipped. Their by-model breakdown: Opus 5 at 1.04% (121 of 11,580 requests), Opus 4.8 at 0.01% (8 of 57,242), Sonnet 5 at 0.12%, Haiku 4.5 at 0.17%. Their by-version breakdown is the more interesting number: every version from 2.1.204 through 2.1.217 combined sits under 0.05% (about 28 errors in 78,600 requests); 2.1.220 alone is at 1.04%.
Two unrelated people, two different platforms, two different usage patterns, landed on roughly the same order of magnitude: about 1 in 100 requests, for people who push the tool hard.
Why heavy users see this and light users mostly don't
Buried in #83657 is the mechanism that explains the split. The retry logic is bimodal: a drop that happens before any response block completes gets silently retried and you never see it. A drop that happens after at least one block has already completed surfaces as a visible error, with no retry.
A single-turn, single-block prompt almost never lands in the second bucket. A long xhigh- effort agentic turn — read a file, list a directory, run three shell commands, think for 26 seconds, then get cut off — completes several blocks before it dies, so it's far more likely to land exactly where the retry logic doesn't help. That's the actual reason this reads as an "Opus 5" or "power user" problem: it's not that Opus 5 drops more connections, it's that heavy multi-tool turns have more chances to fall into the branch that doesn't recover on its own.
What the confound actually is
To be fair to the data: #83657's own author flags this clearly. Opus 5 and client 2.1.220 both entered normal usage on the same day. There is no window where you can run Opus 5 on an older client, or an older model on 2.1.220, to isolate which one moved. The by-version table is suggestive — a real jump from under 0.05% to 1.04% — but it cannot, on its own, tell you whether that's the model, the client, or both. Don't let anyone tell you it's definitively been isolated. It hasn't.
What to actually do
- Check for the literal string before you trust unattended output. If you're running
scheduled or background jobs, grep your transcripts for
Connection closed mid-response— #83183's finding is that a truncated run still reports success. A clean exit code doesn't mean a complete response. - If you're on xhigh effort with a big context window, or running many concurrent or scheduled sessions, you're in the exact usage shape both reporters are in. Worth spot-checking your own logs the way they did — both offer their parsing methodology on request in their issues.
- Don't downgrade off Opus 5 hoping to fix it. The by-version data is a real signal, not proof, and giving up Opus 5 access for an unconfirmed fix is a bad trade until someone from Anthropic actually says something.
- There's no patch to wait for that's been announced. I checked the 2.1.221 changelog — one version newer than the primary report — and there's nothing about connection handling, streaming, or this error string. If that changes, I'll update this post.
What not to do
Don't repeat "Opus 5 has a 1% failure rate" as a flat, confirmed fact about the whole product. It's two people's own logs, from unusually heavy usage patterns, and the report that comes closest to isolating the cause explicitly says it can't. The stronger, truer claim is the one that actually held up under checking: this specific error has been open and unaddressed for months, across versions, and now finally has real numbers behind it — twice, independently.
Receipts
- #83657 — open, unconfirmed, filed 2026-08-03. 130,204 responses parsed, 1.04% error rate since 2026-07-29 on Opus 5 + 2.1.220. Confound explicitly stated by the reporter.
- #83183 — open, unconfirmed, filed 2026-08-01. 315 occurrences across 130 sessions, Windows desktop app, silent failure in unattended runs.
- #75318 — open, unconfirmed, filed 2026-07-07, macOS 2.1.201/2.1.202. The oldest report I verified directly; cites three further, older related issues.
- At least nine more open issues carry "connection closed" in the title as of 2026-08-04; I confirmed they exist but did not read each one in full.
- No maintainer (Anthropic team) comment was found on any of the three issues I read.
If Anthropic responds on any of these, I'll come back and update this post.
More fixes like this, before they hit the blog