Claude API Refusal Billing Rules and Retry Audit Guide

With the Claude API, you may be charged even when the model refuses to answer. On September 24, Anthropic resumed billing for certain refusal responses. For refusals before output begins, only three categories are billed. Refusals that stop during output have always been billable. The source is the official refusal billing rules.

Teams running automated reports should check this. Your deliverable may look fine while your cost records are inaccurate. If the first model refuses and the second model answers, both attempts may appear on the bill.

What changed

The announcement appeared in the September 24 release notes. It does not state the exact effective time.

Two details matter: whether output began, and the refusal category.

Refusal point	Category	Billing
Before output	bio, frontier_llm, reasoning_extraction	Standard rate for the model that ran
Before output	Other categories, null	None
During output	Refusal after a partial answer	Input and output already generated

The official billing rules apply across all platforms. This includes Claude API, Amazon Bedrock, Claude Platform on AWS, Google Cloud, and Microsoft Foundry. The billable-category list is current as of September 2026. It may change, so check again before operating.

Free refusals still leave traces. A refusal before output has an empty body. Yet usage (the token usage field) still records token counts. It also counts toward rate limits. Do not assume a charge occurred based on token counts alone. See the usage and rate-limit explanation for unbilled refusals.

What happens to the first request charge after a retry

Consider a hypothetical automated advertising report. The first model refuses the request. The second model completes the report. The file is delivered successfully. If you record only the final response, the first refusal disappears from your logs.

Sending a refused request to another model is called fallback (a retry with an alternative model). If the first attempt was billable, that charge remains. This is true even if the next attempt succeeds. Fallback is an optional feature enabled by the operator. Switching models does not guarantee an answer either.

With server-side fallback, there is one HTTP request. But multiple models may run. Usage for each attempt is stored in usage.iterations (the per-attempt usage list). The top-level usage in the response shows only the attempt that produced the final response. Do not combine these two values when reconciling costs. Details appear in the official usage and billing explanation.

fallback credit (an alternative-retry credit) is a separate mechanism. It only offsets duplicate costs from caching the same conversation again. It does not make the entire retry free. Server-side fallback and SDK middleware apply it automatically. If you wrote your own retry code, review how to pass credit tokens and headers.

HTTP 200 does not mean success

A refusal may not arrive as an error code. It can return with HTTP 200. In the official response example, the status code is normal. Only the stop reason is stop_reason: "refusal".

Review other stop reasons as well. max_tokens means the answer was cut off by the output limit. Even with end_turn, content may be empty. Move on to numeric and format validation only when a real answer is present. See the official stop-reason guide.

MCPY checked this distinction with four synthetic responses from a local server. All four returned HTTP 200. Reading their bodies separated them into a refusal, a truncated response, an empty response, and one for validation. These were not real Claude calls or billing experiments. You cannot calculate refusal rates or savings from these results.

What to do today: inspect just one job

You do not need to clean up all logs. One recently completed job is enough. The sequence below is not an official rule. It is an inspection method proposed by MCPY.

1. Link the deliverable to execution records. Find which models ran and how many times. For server-side fallback, review usage.iterations as well.
2. Check the refusal point and category. Separate before-output refusals from during-output refusals. Review stop_details.category. Do not relabel null as a billable category.
3. Reconcile usage with billing records. If an amount cannot be verified, mark it as unverified rather than 0 KRW.

Your tracking sheet needs only these fields: task ID / request ID / model / stop reason / refusal type / output timing / usage / retry link / cost check status. If billing records show only daily, model, and workspace totals, group logs at the same level. You do not need to copy customer information or full prompts.

To retrieve billing records through an API, you need the Usage & Cost Admin API. Organization administrator credentials are required. Individual accounts without an organization cannot use it. A workspace-only key is also insufficient. Claude Platform on AWS does not yet provide this API. Use the Usage and Cost screens in Console instead. Requirements are in the official Usage & Cost API documentation.

Frequently asked questions

Are all refusals billed now?
No. Only three categories of before-output refusals are billed. Other categories and null remain free. During-output refusals are billed for input and output already generated, as before.

Did our team's costs increase too?
You cannot tell from the announcement alone. Match refusal categories and retry records against billing data. This is why usage and actual costs should be recorded separately.

If you also use the Naver Search API, review NAVER API HUB pricing, call limits, and retry conditions (in Korean). NAVER is Korea's largest search engine. Rules differ by service. Do not apply Claude rules directly to another API.

Official policy checked: September 28, 2026. The images are generated illustrations explaining billing conditions and processing flows. They are not actual product screens or billing evidence.