Claude refusal fallback is sticky, and the second turn looks like nothing happened

Quick answer

As of September 26, 2026, a Claude refusal is not an error and retrying it is not a retry. It is an HTTP 200 carrying a stop_details object, and hanging off that object is a whole fallback subsystem with three implementations, a per-attempt billing record, and a routing memory.

The part that cost me an afternoon is the memory. Once a conversation has fallen back, later turns can be served straight by the fallback model with no fallback marker in the response at all. The signal you built your detection on is present on the turn where the handoff happened and absent on every turn after it.

Most writing about Claude refusals, including most of what currently ranks, stops at "it is a 200, check stop_reason". That part is true, well covered, and is about the first ten minutes of the problem. This is a field note about the rest of it.

The moment

I had a refusal counter on an internal dashboard. Two series: refusals, and refusals that fallback rescued. The gap between them was the number I actually cared about, because it is the number of users who got nothing.

For a week the second series read close to zero while the first one did not. I assumed fallback was misconfigured and went looking for the misconfiguration.

It was configured fine. My detector keyed on the fallback content block, which is the thing the API puts in content at the point where one model hands off to another. It was there on the first turn of a conversation and gone on turns two, three and four, even though the fallback model was still the one answering.

That is not a bug and it is not my configuration. It is sticky routing doing exactly what it says it does, and my detector was asking the wrong question.

Finding 1: The handoff is a content block, and it has to go back exactly where it was

When a fallback happens, the response content gains a block marking the seam:

{"type": "fallback", "from": {"model": "claude-fable-5"}, "to": {"model": "claude-opus-4-8"}}

The refusals and fallback documentation is blunt about what you do with it on the next turn.

On echoing the block back, verbatim: "Keep it exactly where it appeared. The API uses its position to validate the thinking blocks around it, so a request that echoes thinking blocks from both sides of the boundary is rejected if the block is omitted or moved."

So this is not a decorative marker you can strip while normalising history. It is load bearing, and the failure mode is a rejected request rather than a degraded one. If you have a sanitiser that drops block types it does not recognise, it will start rejecting conversations the first time one of them falls back, which is the worst possible moment for a new failure.

Two smaller facts from the same page that matter when you are writing that echo logic. from.model echoes the model string you sent when the declining hop is the requested model, so it is your string and not a resolved ID. to.model is always the resolved ID.

Finding 2: Streaming and non-streaming disagree about the declined model's output

This one surprised me more than the sticky routing did, because the two modes are the same request with one flag changed.

On a stream, a mid-output decline keeps what the first model already produced, and the seam arrives as an empty pair of events. From the streaming documentation, verbatim: "a fallback content block arrives at each model boundary as a content_block_start and content_block_stop pair with no deltas in between".

On a non-streaming request the same decline behaves differently. Verbatim: "the response omits the declined model's partial output, and the fallback model answers from scratch."

So the shape of content after a mid-output fallback depends on whether you streamed. If you have a test suite that exercises the non-streaming path and a production path that streams, the case your tests cover is the tidier of the two.

There is one exception worth knowing before you assume fallback always fires: a streaming decline that lands while a tool use block is still open on the stream is returned directly rather than retried. Completed tool work does not block fallback, but an open one does.

Finding 3: Sticky routing deletes the signal you detect fallback with

After a conversation falls back, the API remembers. Later requests for that conversation that include fallbacks go directly to the model that served it, skipping the model you asked for.

The properties, verbatim: "It is retained for approximately 1 hour and is scoped to your organization." It is stored as a content hash of the conversation prefix plus the serving model, the message content itself is not stored, and it is best effort, so the requested model can be tried again at any time.

Here is the part my dashboard got wrong, verbatim: "Such a turn carries no fallback content block, because no model declined that turn."

Which is obviously correct once you read it. No model declined, so there is no seam to mark. The documentation gives the three signals that do identify such a turn: a fallback_message entry in usage.iterations, the absence of a message entry for the requested model, and the response's model field.

I had been detecting the event and reporting it as the state. Those differ by exactly one turn, and then by every turn after that for about an hour.

On a streaming request the routing decision is made before the stream opens, so message_start already carries the fallback model's ID. That is the cheapest possible check if you stream.

Finding 4: The per-attempt record is usage.iterations, not the top-level usage

When fallback runs, more than one model did work. The response reports that in usage.iterations: a model that declined appears as an ordinary message entry, and the model that served the turn appears as a fallback_message entry. If every model in the chain declines, you get the last model's refusal plus a message entry for each earlier hop.

The top-level usage is narrower than it looks. Verbatim: "The top-level usage counts describe only the attempt that produced the returned message. Tokens from different models are never summed into one field."

That is a sensible design, because summing tokens across models would produce a number at no particular price. It also means a cost meter reading the top-level counts under-reports every request that fell back, and never reports the attempt that failed. Read the array.

Every attempt that runs, including one that declined, counts against its own model's rate limits.

Finding 5: Five refusal categories, and three of them bill you before any output (September 2026)

The stop_details.category field names the policy area that tripped the classifier. The full set on the Messages API reference is five values: cyber, bio, frontier_llm, reasoning_extraction and general_harms. Both category and explanation are null when the refusal does not map to a named category, and that null is described as a normal permanent value rather than a placeholder.

Of the third party write ups I read while checking this, the best one lists four of the five and explicitly punts to the docs for the rest, and another lists two. general_harms did not appear in any of them.

A refusal that arrives before any output is billed when the category is bio, frontier_llm or reasoning_extraction, and is not billed for cyber, for general_harms, or when the category is null. Mid-stream refusals bill the input and the output already streamed.

Treat that split as perishable rather than as an invariant. The documentation says so itself, verbatim: "The billed categories may change as Anthropic keeps measuring and refining its safeguards' false positive rates." So do not build a cost model whose correctness depends on which categories are on that list in September 2026. Build one that reads usage.iterations and does not care.

reasoning_extraction is the category most likely to surprise a developer, because it fires on asking the model to reproduce its internal reasoning in the response text, and the documented alternative is to ask for it in structured form instead.

Finding 6: fallbacks does not reach anything your tools call

From the pitfalls section, verbatim: "The fallbacks parameter does not propagate into model calls made from inside tool execution."

If you have an agent whose tools call the API again, those inner calls are unprotected unless you configure them separately. The same section makes the related point that you should budget retries per request rather than per turn or per session, because one turn can produce several refusals across an agent and its sub-agents.

The third pitfall in that list is the one I would put on a wall: make fallback a property of the request, not of ambient state. A shared flag or cached config can drift, and the requests most likely to need fallback are the ones coming from retry handlers and background workers, which are exactly the paths people forget to configure.

Finding 7: In Message Batches a refusal is a success, and fallback is not available there

A refused item in a batch comes back with a result.type of succeeded and a stop_reason of refusal. It carries the same detail object as a synchronous response.

On detecting it, verbatim: "Batch results carry the same stop_details object as synchronous responses, so you can detect refusals through either stop_reason or stop_details.type."

Server-side fallback is not available for batches at all. A batch item that includes fallbacks comes back as an errored result. The documented recovery is to collect the refused items, strip thinking blocks from any multi-turn histories, and resubmit them on a fallback model.

Finding 8: Three implementations, and two of them must never both be on

There are three ways to retry a refused request, and they are not interchangeable across platforms. Server-side fallback is a Claude API beta and is not available on Amazon Bedrock, Google Cloud or Microsoft Foundry. On those, the SDK middleware is the route. Writing the retry by hand is the third, and is the only one where you have to think about fallback credit yourself.

The trap is combining two of them, verbatim: "Configure one or the other, never both on the same request." If an application installs the middleware and you also want to send a server-side fallbacks request, the documented answer is a separate client instance without the middleware.

What this changed in my code

Three things, in order of how much they mattered.

The dashboard now counts a fallback-served turn from usage.iterations, not from the presence of a fallback content block. The gap between refusals and rescues immediately stopped lying.

The history normaliser now has an allow list that includes fallback rather than a deny list that happened not to include it. This is the same shape of bug as the Files API response field I could not see because my client was pinned to a shape without it: the code was correct about the shape it knew and silently wrong about the shape it got.

The cost meter reads usage.iterations. It was reading the top-level counts, which means for a week it was quietly reporting the price of the successful attempt and nothing else.

One thing I had already got right for an unrelated reason: refusals were already their own event rather than part of an error rate, because the Claude Code telemetry stream makes the same distinction with a dedicated api_refusal event. The pitfalls section makes the general version of the point, verbatim: "A refusal is an HTTP 200, so monitoring built on error rates or 5xx responses never sees it."

What I did not verify

• I did not trigger a real refusal to observe any of this live. Everything above is read from the current documentation on September 26, 2026, cross-checked between the refusals page, the Messages API reference and the streaming page. I have not seen a fallback content block arrive in my own logs.
• I did not test sticky routing's one hour retention, its organization scope, or its best-effort behaviour. Those are documented properties I am reporting, not measured ones.
• I did not measure the billing split. I am quoting the category table, and the documentation itself says the list can change.
• I did not exercise the SDK middleware, so I cannot say how it behaves when a fallback state object is shared across concurrent conversations.
• I did not check whether any of this differs on Amazon Bedrock, Google Cloud or Microsoft Foundry beyond the stated unavailability of the fallbacks parameter.

Postscript: the detector that broke was three weeks old and had never been wrong, which is exactly how long it takes for a conversation to fall back twice.