Every tool call an agent makes sits between two rate limits that have nothing to do with each other. The model API — the request that produced the `tool_use` block in the first place — has its own throughput ceiling, enforced by the provider, that caps how many requests and tokens per minute your account can push through. The tool itself, when it runs, usually calls out to a second system entirely — a payment processor, an internal inventory service, a third-party search API — that enforces its own, completely separate ceiling, on its own infrastructure, with its own outage patterns. An agent that treats these as one undifferentiated "we got rate limited" signal will handle both badly.
The two limits fail differently and recover differently, which is exactly why they need different handling. A model-API 429 means your account, across every concurrent conversation you're running, has outrun the tokens-per-minute or requests-per-minute the provider allocated you — the fix lives at the client SDK layer, often shared across your whole fleet of agents. A downstream 429 from a single tool means that one specific service, called by that one specific tool, is saturated — the fix is local to that tool's call site and has zero bearing on any other tool the same turn might call next. Backing off the model API when only the downstream tool is struggling wastes a resource that was never the bottleneck; backing off a healthy downstream tool because the model API returned a 429 does the same in reverse.
This lesson works through both limits end to end: reading the signal each side actually gives you, computing a wait that doesn't make the problem worse when many callers hit it at once, telling retryable trouble apart from a request that was simply wrong, and — because a model will happily re-call a tool whose result looked ambiguous — making sure that a retried call is safe to run twice. Every example runs against `claude-opus-5`, and the same constraints apply to `claude-sonnet-5` and `claude-fable-5`.