Contents
Since June 2, a Claude API request that gets refused before the model produces any output has cost nothing. You get back a normal HTTP 200, stop_reason: "refusal", usage.output_tokens: 0, and no line item. On September 24, Anthropic carved three specific exceptions into that rule, documented in one paragraph on its release notes page: refusals whose stop_details.category is "bio", "frontier_llm", or "reasoning_extraction" are now billed like any other request, at the full rate of the model that ran, even though it wrote zero tokens.[1] If you have retry logic, an evaluation harness, or Anthropic’s own server-side fallback pointed at Claude, this is a real cost change on traffic that looks identical to what it looked like a week ago.
What a refusal actually is
Claude’s safety classifiers can decline a request without returning an error. The response is a normal message with stop_reason: "refusal" and a stop_details object naming the policy area:
{
"stop_reason": "refusal",
"stop_details": {
"type": "refusal",
"category": "cyber",
"explanation": "This request was declined because it could enable cyber harm."
},
"usage": { "input_tokens": 412, "output_tokens": 0 }
}
That particular example is cyber, one of the two categories still free before output. The category is what decides billing, not the shape of the response.
Anthropic’s docs list five named categories, and as of September 24 only three of them are billed when the decline happens before any output:[2]
category | What triggers it | Billed before output |
|---|---|---|
cyber | Could enable cyber harm (malware, exploits) | No |
bio | Could enable biological harm | Yes |
frontier_llm | Could assist a competing AI model’s development, restricted under Anthropic’s commercial terms | Yes |
reasoning_extraction | Asks Claude to reproduce its internal reasoning as response text | Yes |
general_harms | Anything else under the usage policy | No |
content is empty either way, and the request always counts against your rate limits regardless of billing. What changed is purely whether the zero-output attempt shows up on your invoice.
Why these three and not the other two
Anthropic states the reasoning directly: these are “the categories where Anthropic measures low volumes of false positives, as of September 2026."[3] Read against the category descriptions, that’s a meaningful filter. cyber and general_harms both carry the caveat that “benign work can also trigger this category,” meaning a security researcher or an ordinary support bot can trip them by accident, so Anthropic keeps those free. bio, frontier_llm, and reasoning_extraction carry no such caveat for two of the three, and the third, frontier_llm, points at a specific contractual restriction rather than an ambiguous harm judgment. In plain terms: the three billed categories are the ones where a decline is rarely an accident, which makes them the categories where someone iterating past the classifier at volume is the dominant traffic pattern, not the exception.
reasoning_extraction is worth sitting with. It fires specifically when a request asks the model to write its own reasoning into the visible response rather than use structured thinking output. That is functionally the same move as chain-of-thought distillation: capture a frontier model’s reasoning trace and replay it as training signal for a cheaper model. Making the zero-output version of that probe cost full price, rather than free retries until one gets through, changes the arithmetic for anyone running it at scale, independent of whether any single attempt is flagged as abuse.
The fallback double-charge
The sharper edge is in how this interacts with Anthropic’s server-side fallback feature, where a declined request automatically retries on another model in the same API call. The billing rule: “the refusal that triggered [fallback] is billed, in addition to the fallback request, when it arrived mid-stream or is in one of the billed categories."[3]
Before September 24, a bio, frontier_llm, or reasoning_extraction refusal with fallbacks: "default" set cost you exactly one billed attempt: whatever the fallback model charged to actually answer. The declined attempt was free, because it produced no output and wasn’t yet in a billed category. After September 24, the same request bills twice: full rate for the model that declined with zero tokens, plus full rate for the fallback model that answered. Nothing about your code or your traffic changed. The invoice did.
This is easy to miss because a refusal is a 200, not a 4xx or 5xx. Anthropic’s own docs list “instrument refusals as their own signal” as a common pitfall, precisely because error-rate dashboards never see a decline.[3] That advice was already true for reliability monitoring. It’s now also true for cost monitoring: a spend spike from hitting these three categories more often won’t show up as a spike in error rate, timeouts, or anything else a typical on-call dashboard watches.
What to actually do
Three concrete changes, if you have automated traffic touching Claude in these areas:
- Stop treating pre-output refusals as free signal in eval or red-team harnesses. If you iterate over prompt variants to find where a
bioorreasoning_extractionboundary sits, each declined variant now costs the same as a completed request at that model’s rate. Budget it as inference spend, not as a free classifier probe. - Re-check any
fallbacks: "default"or named-fallback configuration that regularly hits these three categories. You are now paying for both hops, where three months ago you paid for one. If the fallback model reliably answers, this is a real, multiplying cost increase on the same traffic pattern. - Add a refusal counter split by
stop_details.category, not just a refusal counter. The five categories now split into two different cost regimes, and a single aggregate refusal metric can’t tell you which one moved.
None of this requires new code beyond reading a field you likely already have in the response. It does require treating a documented pricing change as a production event, since nothing about the API’s error surface will flag it for you.
Sources
[1] https://platform.claude.com/docs/en/release-notes/api: Claude Platform API release notes, September 24, 2026 entry, “Refusal Billing Expansion,” and June 2, 2026 entry establishing the pre-output-refusals-are-free baseline
[2] https://platform.claude.com/docs/en/build-with-claude/refusals-and-fallback#refusal-response: refusal category table and category descriptions
[3] https://platform.claude.com/docs/en/build-with-claude/refusals-and-fallback#how-refusals-are-billed: “How refusals are billed” and “Common pitfalls” sections