Server-side fallback is a resilience feature of the Claude API: instead of failing a request when the requested model can't serve it, the service can switch to a fallback model and keep generating. For teams that would otherwise build client-side retry ladders, it moves the failover inside a single request. But it raises an auditing question — if a different model wrote part of the answer, how do you know? In streaming responses, the answer is the fallback content block.
The normal streaming grammar, briefly
A streamed response is a sequence of server-sent events (SSE): message_start, then for each content block a content_block_start, one or more content_block_delta events carrying the actual text or tool JSON, and a content_block_stop; then message_delta updates and a final message_stop. Every block carries an index matching its position in the final content array. Deltas are where the payload lives — a text block without deltas would be empty.
What fallback looks like on the wire
That empty-block shape is precisely the signal. During server-side fallback, a fallback content block arrives at each model boundary as a content_block_start / content_block_stop pair with no deltas between them. It carries no text; its existence and position are the message. Everything at lower indices was produced before the switch; blocks after it were produced by the fallback model. If the stream shows no fallback block, one model handled the whole response.
event: content_block_start
data: {"type":"content_block_start","index":2,
"content_block":{"type":"fallback", ...}}
event: content_block_stop
data: {"type":"content_block_stop","index":2}Two implementation notes. First, write your stream consumer to tolerate unknown block types generically — a parser that assumes every block produces text deltas will mishandle an empty start/stop pair. Second, if your product surfaces "answered by model X" metadata for compliance or evaluation purposes, treat the fallback block as the boundary marker and record both models, not just the one you requested.
Platform availability: mostly a first-party feature
This is one of the features where the four platforms genuinely differ. Anthropic's platform documentation lists server-side fallback (the fallbacks parameter) as not supported on Amazon Bedrock, Google Vertex AI, and Microsoft Foundry — on all three, the documented alternative is client-side fallback, meaning your own code catches errors like 429s and 529s and reissues the request against another model or region. Claude Platform on AWS, which tracks the first-party API surface with same-day parity in most areas, is the 3P route where first-party API behaviors like this are expected to appear; check the current docs for your platform before designing around the block.
That split has an architectural consequence. If you run the same workload on both the Claude API and Bedrock or Vertex, you need both mechanisms: parse the fallback block where server-side fallback exists, and keep a client-side failover path where it doesn't. Teams sometimes standardize on client-side fallback everywhere for uniformity — a legitimate choice, at the cost of giving up the within-request seamlessness on platforms that offer it.
Handling it in code
The robust pattern is a small state machine over block types: accumulate text from text_delta events, accumulate tool input from input_json_delta events, and on a fallback block record a boundary annotation with the current index and timestamp. Since the block produces no deltas, no buffering logic changes — only your metadata does. Remember, too, that mid-stream error events remain possible after the HTTP 200; fallback reduces some failures but does not eliminate the need for in-stream error handling.
Where to go next
For the full event grammar, read streaming event types and how SSE works. For building your own failover on platforms without server-side fallback, Bedrock's common errors is a good starting inventory of what to catch.