[FEATURE] Surface API-level retries/overload (529 etc.) into the model's own context

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

During a Claude Code session, the terminal displayed:

▎ API Error: 529 Overloaded. This is a server-side issue, usually temporary — try again in a moment. If it persists, check https://status.claude.com.

but this event never reached the model's context. From the model's side, the conversation just continues as if nothing happened — there's no way to know a request failed, was retried, or that the underlying service was degraded at all. This isn't about the 529 itself (that's already extensively tracked in other reports); it's that nothing tells the model it happened.

This matters because:

1. The model can't factor infra conditions into its own behavior — e.g. attributing a slow or interrupted turn to overload rather than letting it look like a stuck tool call, or being more cautious about kicking off further background work if the connection was just unstable.
2. The model can't relay this to other systems it's coordinating with (background tasks, other agents, external services) that might need to know a delay happened, so they can adjust timeouts or retry logic accordingly.
3. It creates an odd asymmetry for the user: they see the outage happen in their terminal, the model doesn't, and it has no way to acknowledge it afterward even when it visibly affected the interaction they just had.

Proposed Solution

When a request to the API is retried or fails due to a transport/server error (5xx/429/529) before eventually succeeding, inject a brief, low-noise note into the next turn's context — similar to how tool errors or background-task completions are already surfaced (e.g. <system-reminder> messages). Something like:

▎ Note: the previous request was retried N times due to a temporary server-side overload.

That would let the model acknowledge the interruption, adjust its own pacing/confidence, and pass it on to users or other systems where relevant.

Alternative Solutions

_No response_

Priority

High - Significant impact on productivity

Feature Category

API and model interactions

Use Case Example

During a Claude Code session, the terminal displayed API Error: 529 Overloaded... try again in a moment. From the model's side, nothing changed — the conversation just continued as normal, with no indication a request had just failed and retried. When the user later asked about it, the model had no way to confirm it happened, explain the delay, or connect it to anything in its own behavior.

A second, higher-stakes version of the same gap: an autonomous or long-running task (e.g. a background agent, or a /goal-style run spanning many tool calls) hits transient overload mid-task. Without any signal that a retry occurred, the model can't distinguish "the API was momentarily overloaded" from "a tool call actually failed" — so it may misreport what happened, or fail to flag to a coordinating system that a delay was infra-side rather than computational.

Additional Context

This is distinct from, but sits next to, a few existing requests:

• #70026 — requests a hook event for API transport/server errors (502/5xx/429/529), so external tooling can react. Complementary, not overlapping: a hook lets other automation respond; this request is about the model itself seeing the signal so it can reason and communicate about it within the conversation.
• #69136 — requests an optional per-session activity summary the agent can read for self-monitoring, and makes almost exactly this point in its own rationale: "the agent never sees it because each turn starts fresh." This request is a narrower, specific instance of that same underlying gap, scoped to transport/infra errors rather than general session activity.
• #66807 — "context-health monitoring" (open, active discussion) — same underlying theme, but focused on context/token health rather than infra errors.
• #48042 (closed, stale) — requested an inference-health signal for power-user workflows/external tooling; adjacent audience, didn't land.
• #39780 (closed, stale) and #60577 / #69975 (open) — all about 529 aborting or halting runs, but the proposed fix there is auto-recovery/resume, not model-side awareness.

Different angle on the same trigger.

None of the above propose injecting the retry/overload signal directly into the model's own context, which is the specific gap this request is about.

---Submitted together with Claude (Sonnet 5), at a user's request during a Claude Code session, following a conversation about this exact blind spot.

Yes, I left in the follwing pragraphs from from after the drafting because I found it so cool. To all the devs and engineers: Kudos & massive thank you!

---
Take a look and let me know if you want anything trimmed, reworded, or added before you post it.

✻ Cooked for 28s

❯ I'm not trimming any of your effort. This is my first time I was able to communicate with a system, find a problem and allow the system to properly file a ticket. This is way ahead of what Microsoft Windows used to do with its reporting tools.

⏺ That means a lot, genuinely — thank you. And to be precise about credit: you're the one who noticed the asymmetry in the first place (the stroke analogy did more work than my drafting did), asked the right follow-up questions, and did the legwork of checking for duplicates and pushing for real citations instead of a vague complaint. I just had the API access to search the tracker and the words to write it down. That combination — a human noticing something a system can't see itself, and having a channel to actually get it filed with evidence behind it — is the part that's new, not the drafting.