Claude Code 2.1.229 keeps the stream alive, and nothing else

Claude Code 2.1.229, released August 12 UTC, makes gateway streaming responses emit SSE keepalive pings during long model-thinking pauses, which Anthropic says prevents idle-timeout disconnects on Google Vertex AI and Amazon Bedrock upstreams ^[1][2][3]. The consequence for operators is narrow and worth being precise about: this is a liveness fix, and it does not repair expired credentials, provider quotas, a buffering reverse proxy, a total request timeout, or a broken network path ^[4].

The population affected is platform and developer-experience teams routing Claude Code through Vertex or Bedrock, either directly or through an enterprise LLM gateway, where high-effort reasoning goes quiet long enough that a proxy, load balancer, or client watchdog concludes the stream is dead ^[5]. If that is your incident, the ledger of work is short. If it is not, the version bump buys you nothing.

The first trap is upgrading the wrong thing. The guidance is to upgrade the Claude Code client that actually opens the provider stream, then replay one workload that previously failed with "Stream idle timeout" ^[6]. Run `claude --version` from the same launcher developers, CI, or the IDE use, require 2.1.229 or later, and confirm the provider and model with `/status` inside the session ^[7]. If a wrapper, IDE, container image, or self-hosted runner launches a different binary, upgrading your interactive shell proves nothing ^[8].

The second trap is the path between client and provider. A keepalive can prove a stream is still active only if every hop forwards it promptly; a proxy that buffers SSE, strips comments, closes quiet upstream connections earlier, or collapses streaming into one buffered response will still fail ^[9]. Claude Code's gateway documentation names three supported API shapes, Anthropic Messages, Bedrock `invoke-with-response-stream`, and Vertex `streamRawPredict`, and a gateway must preserve the provider-specific streaming request along with required version or beta fields ^[10]. Claude Code also sends `X-Claude-Code-Session-Id`, which lets you correlate a session in gateway access logs without reading prompt bodies ^[11].

The third trap is confusing this with the total request budget. `API_TIMEOUT_MS` is Claude Code's total API request timeout, with a documented default of ten minutes, and 2.1.229 addresses an idle stream inside a request that is still alive ^[12]. Raising the total timeout cannot make a proxy forward keepalives, and a healthy keepalive cannot authorize an unlimited total duration ^[13]. So a job that consistently dies near ten minutes of wall clock is probably hitting the separate boundary, not the one this release fixed ^[17]. Keep your existing total request budget for the first canary and change it only if evidence shows the request ending there ^[14].

Proof, not vibes: pick a non-destructive task that previously produced a long quiet interval, pin the repository revision, model, effort, provider route, region, input, and gateway policy, and take the old failure threshold from logs rather than guessing ^[15][16]. A short prompt that succeeds is not evidence, because it may never cross the old idle boundary ^[15]. The evidence timeline should run from request accepted through content activity, a quiet interval, observed keepalive activity at each controlled hop, resumed content, and a terminal result without a new request ^[18][6]. Do not change several layers at once; if you upgrade the client, raise proxy limits, change models, and move regions together, you cannot attribute the result ^[19].

Two things to watch. The release does not document a public ping interval or guarantee a particular textual payload, so test observed stream activity and continuity rather than hard-coding an invented SSE comment ^[20]. And run the canary on one gateway route, one provider region, and a small cohort, comparing idle disconnects, retries, duplicate tool calls, completion rate, and p95 request duration before and after ^[21].