Claude Code 2.1.185 Turns a Retry Message Into a Production-Signal Problem

Sometimes the smallest changelog item is the one that tells you where the product is hurting.

Claude Code 2.1.185 shipped with one public note: the stream-stall message now says “Waiting for API response · will retry in …” instead of “No response from API · Retrying in …”, and the hint appears after 20 seconds of silence instead of 10 seconds. On paper, that is copywriting. In practice, it points at the operational question every serious coding-agent team is about to inherit: when an agent turn is slow, expensive, and partially opaque, can the runtime tell the difference between healthy latency and failure?

That distinction matters because Claude Code is no longer just a clever terminal companion producing small diffs against toy repos. Teams are routing it through custom gateways, running large-context sessions, delegating work to subagents, preserving long conversations, and asking it to retry when infrastructure gets weird. A vague spinner was acceptable when the worst outcome was waiting too long for a chat answer. It is not acceptable when a retry may duplicate a 400,000-token request, lose streaming state, or make an agent continue after the transport layer has already lied to it.

The message changed because the old ambiguity was too expensive

The 2.1.185 release was published on June 20 at 20:59:19 UTC, with the normal spread of binary assets for macOS, Linux, musl Linux, and Windows. It also landed alongside Agent SDK parity releases: TypeScript v0.3.185, Python v0.2.106, and Claude Code Action v1.0.153. The asset download count was still tiny during research — 73 total downloads — which is exactly what you expect from a release barely old enough to have cooled.

The interesting context is not the download number. It is the issue cluster around stream stalls. Issue #69759, opened earlier the same day, reports pre-first-byte streaming aborts on custom ANTHROPIC_BASE_URL gateways for large-context turns around 150k–500k input tokens. The reporter says independent streaming probes through the same proxy returned the first SSE byte in 13–20 seconds at roughly 360k tokens, while Claude Code clients in the 2.1.181–2.1.183 range closed early with load-balancer HTTP 460 and target_processing_time = -1.

That is not a vibes-based bug report. It is the kind of telemetry operators actually need: client version, gateway path, first-byte behavior, load-balancer status, request size, and comparative baselines. In a follow-up, the reporter stratified requests by client version and found 2.1.183 had 128 pre-first-byte aborts out of 1,364 requests, a 9.4% rate, versus 0.7% on 2.1.181, 0.6% on 2.1.179, and 0.1% on non-Claude CLI clients through the same load balancer. That does not prove the client is the only culprit. It does prove the runtime needs to expose more than “still waiting.”

Issue #69358 adds another signal: 18 comments and 55 reactions around repeated “No Response from API” errors on 2.1.181 and 2.1.183, with multiple users reporting rollbacks to 2.1.179. Issue #69788, opened minutes after 2.1.185, reports “Server is temporarily limiting requests (not your usage limit)” on Claude Code 2.1.161, suggesting at least some availability and throttling noise is broader than the latest client line.

Custom gateways turn latency into a control-plane contract

The enterprise angle is the part worth underlining. Serious teams rarely run coding agents as unmanaged desktop toys forever. They put gateways in front for policy enforcement, routing, audit logs, procurement controls, budget caps, data handling, prompt caching, model fallback, and provider abstraction. The moment a vendor supports ANTHROPIC_BASE_URL, it is implicitly supporting that operating model.

That means the test matrix has to include high-context first-byte latency, cache-cold requests, streaming idle timers, retry behavior, header mutations, prompt-cache paths, and load-balancer disconnects under real gateways. “Works against the default API” is table stakes. “Works when a company has built the boring plumbing required to use this safely” is the production bar.

The 10-second-to-20-second hint change is therefore more than UX. Large-context model calls can take longer than ten seconds to produce a first byte, especially when cache misses, gateway hops, and long prompts stack together. If the UI implies failure before a healthy request has had time to breathe, users learn the wrong lesson. If the client aborts or retries too aggressively, they may pay for duplicated work. If the agent silently loses a stream, it may also lose the only evidence needed to understand what happened.

For practitioners, the immediate checklist is straightforward. Pin Claude Code versions during critical project work instead of letting auto-update turn each release into an experiment. If you operate a gateway, log first-byte latency, client disconnects, retry counts, cache hit rates, token totals, provider status codes, and Claude Code client versions in the same place. Separate provider 429s, Anthropic service-side throttling messages, client-side aborts, proxy disconnects, and model-computation latency. If a retry sends hundreds of thousands of tokens, that should show up as a budget event, not as a friendlier line in the terminal.

There is also a product lesson for every coding-agent vendor in the Claude Code vs. Codex vs. Cursor race. Benchmarks tell you whether the model can solve a task. Transport behavior tells you whether a team can operate it. The winning agent runtime will not be the one with the most comforting spinner. It will be the one that can say: the provider accepted the request, first byte has not arrived, gateway latency is within historical bounds, no retry has been sent, cache status is unknown, and here is the request ID you can hand to ops.

That is less magical. Good. Magic is what you call infrastructure before the bill arrives.

Sources: Anthropic Claude Code v2.1.185 release, Claude Code changelog, Claude Code issue #69759, Claude Code issue #69358, Claude Code issue #69788