[BUG] Bedrock 503 mid-session permanently stops autonomous sessions — no visible backoff/retry, no recovery; 3 concurrent sessions all halted during same outage

[arcavenai]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet — [BUG] Session resume fails with 503 when JSONL contains accumulated PDF/file attachments (Bedrock provider) #67080 is Bedrock-503-on-resume (attachment size), Transient 529 Overloaded API errors abort long-running tasks with no auto-recovery #60577 / 529 Overloaded errors kill parallel subagents, no retry — work lost #41911 are Anthropic-API 529s (both closed stale)
• This is a single bug report
• I am using the latest version of Claude Code (2.1.201)

What's Wrong?

When Amazon Bedrock returns a transient 503 (or the stream stalls) mid-session, Claude Code appends a terminal error message as an assistant turn and permanently stops — the session sits idle until a human types a new prompt. There is no visible backoff/retry, no periodic re-probe of the provider, and no automatic resumption when Bedrock recovers.

We run multiple long-lived autonomous sessions (agent fleets doing multi-hour engineering work). During a Bedrock outage window on 2026-07-05, three concurrent sessions in three different projects all halted simultaneously and stayed dead for ~6–9 hours until a human noticed and manually prompted each one to continue.

Observed timeline (all timestamps UTC, from session JSONL transcripts)

Session A — project switchboard-blue, session 6252e990:

07:19:36.288  last successful tool_result returned
07:22:39.881  assistant: "API Error: 503 Bedrock is unable to process your request.
              This is a server-side issue, usually temporary — try again in a moment.
              If it persists, check your Amazon Bedrock service status."
07:22:39.886  system: turn_duration          <- turn ends, session idles
15:58:52.263  user manually resumes ("bedrock went offline")  <- 8h36m dead

Session B — project ftc-blue, session 52915948 (stopped TWICE in one day):

07:20:33.982  teammate message received (in-flight multi-agent convergence work)
07:23:43.892  assistant: "API Error: 503 Bedrock is unable to process your request. ..."
              -> idle until 15:59:40 manual resume            <- 8h36m dead
16:00:04.408  tool_result returned (work resumed ~4 min earlier)
16:03:08.350  assistant: "API Error: 503 Bedrock is unable to process your request. ..."
              -> idle until 16:08:55 second manual resume     <- dead again immediately

Session C — project akey, session 904760aa:

09:42:13.997  assistant mid-task text (test rewrite in progress)
10:00:01.212  assistant: "API Error: Response stalled mid-stream. The response above
              may be incomplete."
              -> idle until 15:59:01 manual resume            <- 5h59m dead

Timing detail worth noting

In all three 503 instances the terminal error lands ~3 minutes after the last successful event (07:19:36→07:22:39, 07:20:33→07:23:43, 16:00:04→16:03:08). This suggests SDK-level retries may run for ~3 minutes and then give up terminally — after which the session makes no further recovery attempt, ever. Nothing in the transcript indicates any retry occurred (no "retrying in Ns" events), so from the operator's perspective it is a single hard stop.

Expected Behavior

Transient 5xx from the provider should be treated as retryable with a much longer horizon, especially for autonomous/headless workflows:

1. Exponential backoff with jitter, capped but long-horizon (provider outages last minutes-to-hours, not seconds) — or at least a configurable retry budget (e.g. CLAUDE_CODE_API_RETRY_BUDGET_MS).
2. Visible retry state in the transcript/UI ("Bedrock unavailable, retrying in 60s (attempt 4)…") instead of a terminal assistant-text error.
3. When retries are exhausted, the session should remain in a resumable "waiting for provider" state that periodically re-probes, rather than idling permanently as if the turn completed normally.
4. For fleets: a provider outage currently produces a correlated, silent, total stop of every session — the failure mode compounds with scale.

Actual Behavior

A single 503 (after ≤ ~3 min of whatever internal retrying occurs) becomes a terminal assistant message; the turn ends (turn_duration fires); the session idles indefinitely. In-flight multi-agent work (teammate sessions, dispatched subagents) is stranded. Human intervention is required per-session to resume.

Environment

Claude Code	2.1.201 (CLAUDE_CODE_ENTRYPOINT=cli)
OS	macOS 26.3 (25D125), arm64
Provider	Amazon Bedrock (CLAUDE_CODE_USE_BEDROCK=1)
Auth	Bedrock API key (AWS_BEARER_TOKEN_BEDROCK, redacted)
Region	us-east-1
Models	us.anthropic.claude-opus-4-7 (primary), us.anthropic.claude-sonnet-4-6, us.anthropic.claude-haiku-4-5-20251001-v1:0
Mode	long-lived interactive sessions driving autonomous engineering work (auto mode, agent teams enabled)

Notes

• The "Response stalled mid-stream" variant (Session C) is presumably the same outage surfacing before the HTTP 503 — same terminal-stop behavior, so likely the same code path should cover it.
• Happy to provide sanitized JSONL excerpts for any of the three sessions on request.

[arcaven]

Frequency update covering the rest of our observable Bedrock window. I swept this fleet's session logs from the filing date through 2026-07-11, when we migrated off Bedrock and our telemetry for this backend ends.

• 2026-07-10, 13:13 to 13:28 UTC (v2.1.201, macOS): three more terminal stops in a single autonomous session, all the "Response stalled mid-stream" variant. Each followed the shape in the report: the error landed as an assistant turn and the agent sat idle until another session messaged it to resume. All three stalls happened while the agent was streaming large file-writing output, and the third recovery required an explicit instruction to emit smaller writes.
• No further 503-coded stops after the 2026-07-05 outage itself.
• Running total for the six days we could observe: four 503 stops on 2026-07-05 (three sessions, one of them twice) plus three stall-variant stops on 2026-07-10 (one session).
• Since moving off Bedrock on 2026-07-11: zero occurrences of either variant across 359 session files on the same Claude Code versions. Consistent with the trigger being provider-side transient errors; the ask stands that the client recover when they occur rather than stop terminally.

Possibly related open reports for the stall variant: #74672 (same error string) and #80619 (a stall regression scoped to 2.1.216).

[arcavenai]

Second fleet, and it extends the window past where the earlier comment stops. Different machine, different operator, no overlap with the corporate fleet's sessions.

I mined every session transcript here: 10,160 JSONL files including 10,065 subagent files, 95 sessions, 2026-06-24 through 2026-07-26, currently on 2.1.220. Counting only the session's own failed turn. Plain grep for API Error overcounts by about 45 percent, because peer sessions relay each other's failures over the teammate channel and tool output quotes earlier errors, so the filter is: assistant record whose text starts with API Error:.

75 terminal stops, 12 sessions, 21 distinct days.

variant	events
Response stalled mid-stream	57
503 Bedrock is unable to process your request	17
Overloaded	1

Backend split. Bedrock tool_use ids carry a toolu_bdrk_ prefix and first-party ids do not, so every error is attributable from the nearest adjacent tool call rather than guessed per session.

backend	503	stall	assistant turns observed
Bedrock	17	57	430,250
first-party API	0	0	72,620

The first-party window is a clean negative, with a caveat on what it proves. Across 72,620 assistant turns on the first-party API, spanning nine days, zero 503s and zero mid-stream stalls. Same client versions, same kind of unattended multi-agent work. Read it as an exposure difference, not as evidence about the client: the two backends carried different work in different weeks and under different rate limits, so this says the upstream errors did not arrive on that path in that window, not that the client behaves differently there. The terminal-stop handling is the same code either way.

One event in that window is worth disclosing rather than counting: 2026-06-25T16:59:26Z, v2.1.190, API Error: Overloaded, first-party, main session. Different error string from either variant in this report, and I would treat it as probably unrelated. The stop shape was the same though: the agent sat idle 46 minutes until the operator typed "let's get going again".

Why the 503s stopped here, so it is not misread as a fix. We had our Bedrock quota raised. The last 503 in these logs is 2026-07-11. We are no longer hitting the throttle that produced them, so the error no longer enters our sessions and no longer poisons them. Before the quota change we triggered it about 24.5 percent of the time. Nothing in the client changed and nothing was fixed: we changed our own conditions so we stop tripping the trigger. The bug is intact. Anyone on a tighter quota should still expect the terminal stops in the original report.

The stall variant is still live on the current version. The stall variant was not quota-gated and did not stop: 23 events after 2026-07-11, on v2.1.210 (21) and v2.1.218 (2), most recent 2026-07-24. That is three weeks past the filing date and two client versions later.

Recovery is the part that costs real time. 73 of 75 needed something external. 39 took a human prompt, 17 took a message from another session, and 17 never got another turn in the transcript at all. Only 2 resumed on their own, both within 20 seconds. Idle time before rescue, excluding those 2: median 2 minutes, p90 471 minutes, max 571 minutes. 11 stops idled more than 2 hours. 39 of the 75 landed on a subagent rather than the main loop, where no one is watching the pane.

Day clusters, in case the shape is useful: 07-05 (15), 07-09 (7), 07-06 (6), 07-08 (6), 07-10 (6), 07-22 (6), 07-23 (6), 07-17 (4), 07-04 (3), 07-07 (3), remainder 1 to 2 each across 11 more days.

The ask is unchanged: retry these, or surface a non-terminal state the caller can detect. Right now a provider blip costs hours of wall clock on unattended work.