# Claude Code 2.1.229: Keep Vertex and Bedrock Gateway Streams Alive > Source: > Published: 2026-08-13 01:21:02+00:00 Claude Code 2.1.229 adds SSE keepalive pings to gateway streaming responses during long model-thinking pauses. Anthropic says the change prevents idle-timeout disconnects on Google Vertex AI and Amazon Bedrock upstreams. Upgrade the Claude Code client that actually opens the provider stream, then replay one workload that previously failed with `Stream idle timeout` . Do not declare success because a short prompt works. Record a quiet interval longer than the old failure threshold and prove that the same request later resumes content and reaches a terminal result without a new request. The patch is a liveness fix, not a universal timeout override. It does not repair expired credentials, provider quotas, a buffering reverse proxy, a total request timeout, or a broken network path. This guide is for platform and developer-experience teams routing Claude Code through Vertex AI or Bedrock, directly or through an enterprise LLM gateway. It is especially useful when high-effort reasoning pauses long enough for a proxy, load balancer, or client watchdog to assume the stream is dead. If your problem is runner isolation, credentials, hooks, or repository access, use the [Claude Code self-hosted environment checklist](https://dev.to/blogs/claude-code-2-1-224-self-hosted-environments-rollout-checklist/). This page covers one narrower task: proving streaming liveness across a provider gateway. The August 12 UTC release states that gateway streaming responses now emit SSE keepalive pings during long thinking pauses, preventing idle-timeout disconnects on Vertex and Bedrock upstreams. Claude Code's gateway documentation defines three supported API shapes: Anthropic Messages, Bedrock `invoke-with-response-stream` , and Vertex `streamRawPredict` . A gateway must preserve the provider-specific streaming request and required version or beta fields. Claude Code also sends `X-Claude-Code-Session-Id` , which lets operators correlate a session without reading prompt bodies. That boundary matters. A keepalive can prove that 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 converts streaming into one buffered response can still fail. | Layer | What to record | Typical failure that 2.1.229 does not prove fixed | |---|---|---| | Claude Code client | Version, provider mode, model, effort | Old binary, wrong launcher, total API timeout | | Local or enterprise gateway | API shape, route, session ID, buffering | SSE buffered or transformed | | Load balancer / proxy | Idle limit, upstream and downstream logs | Connection closed before a ping passes | | Vertex or Bedrock | Region, model ID, request ID, terminal status | Auth, quota, model access, provider error | | User session | Prompt, start, quiet interval, completion | Retry mistaken for one continuous response | Do not change several layers at once. If you upgrade the client, raise proxy limits, change models, and move regions in one test, you cannot attribute the result. Run `claude --version` from the same launcher used by developers, CI, or the IDE. Require 2.1.229 or later. Inside the session, use `/status` to confirm Vertex or Bedrock and the intended model. Inventory configuration names without printing secret values: ``` env | cut -d= -f1 | rg '^(CLAUDE_CODE_USE_(VERTEX|BEDROCK)|ANTHROPIC_(VERTEX|BEDROCK).*BASE_URL|CLOUD_ML_REGION|AWS_REGION|API_TIMEOUT_MS)$' ``` If a wrapper, IDE, container image, or self-hosted runner launches a different binary, upgrading your interactive shell proves nothing. Choose a non-destructive task that previously produced a long quiet thinking interval. Pin the repository revision, model, effort, provider route, region, input, and gateway policy. Do not use a trivial prompt; it may never cross the old idle boundary. Record the previous failure threshold from logs rather than guessing a new one. If no reproducible baseline exists, classify the result as a smoke test, not proof that the patch fixed your incident. Capture the `X-Claude-Code-Session-Id` in gateway access logs and the provider request ID where available. Scrub authorization headers and prompt bodies. The evidence timeline should contain: ``` php request accepted -> content/thinking activity -> quiet interval -> keepalive activity observed at each controlled hop -> content resumes -> terminal success ``` The release does not document a public ping interval or guarantee a particular textual payload. Test observed stream activity and continuity; do not hard-code an invented SSE comment. `API_TIMEOUT_MS` is Claude Code's total API request timeout; the documented default is ten minutes. The 2.1.229 change addresses an idle stream during a request that is still alive. Raising the total timeout cannot make a proxy forward keepalives, while a healthy keepalive cannot authorize an unlimited total duration. Retain your existing total request budget for the first canary. Change it only if the evidence shows the request is ending at that separate boundary. | Observation | Likely layer | Next action | |---|---|---| | Stream ends at the old idle threshold; gateway saw no keepalive | Client or gateway route | Verify the active 2.1.229+ binary and streaming API shape | | Gateway saw activity, downstream client did not | Reverse proxy or buffering | Disable buffering for the SSE route and inspect downstream idle policy | | Provider returns 401/403 | Credentials or model access | Repair auth; do not label it an idle-timeout regression | | Provider returns 429 or quota error | Capacity or limits | Follow provider retry guidance; do not extend timeouts blindly | | One request exceeds the total timeout despite stream activity | Total request budget | Decide whether the workload or budget should change | | Content resumes and completes with one request ID | Liveness path passes | Proceed to a bounded rollout | Start with one gateway route, one provider region, and a small user cohort. Compare idle disconnects, retries, duplicate tool calls, completion rate, and p95 request duration before and after. Keep the previous client package or image available for rollback, but do not downgrade if the old version reintroduces a confirmed reliability or security defect. The [Claude Code Action sandbox recovery guide](https://dev.to/blogs/claude-code-action-2-1-227-bash-sandbox-fix-checklist/) shows the same release discipline for CI: prove the intended capability while keeping unrelated safety controls unchanged. ``` date / owner / change: claude_code_version / launcher: provider: vertex | bedrock model / effort / region: gateway_api_shape / route: proxy_idle_policy / total_api_timeout: canary_commit / task / input_hash: session_id / provider_request_id: request_started_at: last_content_before_quiet: keepalive_seen_at_gateway / downstream: content_resumed_at: terminal_state / completed_at: retry_or_new_request_seen: yes | no pre_upgrade_result / post_upgrade_result: rollout_decision: pass | hold | rollback remaining_risk / next check: ``` `API_TIMEOUT_MS` ? No. It controls total request duration. First prove whether an idle hop, total budget, authentication, quota, buffering, or network loss ended the request. The 2.1.229 release specifically describes gateway streaming responses and Vertex/Bedrock upstream idle timeouts. Do not generalize that statement to every transport without a canary. Use the session correlation header, timestamps, byte or event activity, provider request IDs, and terminal status. Authorization values and prompt bodies are unnecessary. No. The acceptance condition is one continuous logical request that survives the quiet interval and completes. A retry can duplicate cost or tool effects and must be recorded separately.