What an interrupted response costs once you've resumed it

Providers do fail, and under load Anthropic documents returning an overloaded error inside the event stream itself, corresponding to an HTTP 529 in a non-streaming context. What matters for cost is what happens next. The tokens generated before the interruption were produced and billed, and you have no usable answer. The documented recovery is to capture the partial response and construct a continuation request that includes it, so the model can carry on from where it stopped. That continuation is a fresh call, and the partial output you already paid to generate now arrives as input tokens on it. The double charge is small per event and structural, which is the awkward combination: it never shows up as a spike, it just makes every interrupted request quietly cost more than a clean one, and interruptions cluster exactly when the provider is busiest and your traffic is highest.

• Costs run above your model during periods when the provider was degraded.
• Retries and resumes aren't recorded as their own calls.
• Nobody knows what share of your requests get interrupted.
• A resumed request is logged as one call rather than two.
• Your error rate is monitored and your error cost isn't.

1. Find what share of your requests ended without a complete response last month.
2. Check whether your logs record the tokens generated before an interruption.
3. See whether a resumed request appears once or twice in your cost data.
4. Compare cost per completed answer against cost per call and size the gap.

Illustrative example

A modelled 2,000-token prompt producing a 4,000-token answer on Claude Sonnet 5 at its real introductory rates of $2.00 and $10.00 per million from the price book effective 2026-07-02. The stream is interrupted at 80% of the output, and recovery follows Anthropic's documented approach of re-sending the partial response as context so the model can continue. Token counts and the interruption point are modelled, the rates and the recovery method are published.

Nearly a quarter more for the same answer, and the resume was the cheap option. Retrying from scratch would have regenerated all 4,000 output tokens at output rates instead of carrying 3,200 forward at input rates. The overhead is small per request and it lands hardest when the provider is under load, which is when your traffic is highest.

Whether a request completed, and what it took to get an answer out of it, is knowledge that lives in your request path. A provider invoice records the tokens and can't record that two of its calls were one user question, and a tool watching from outside sees two unrelated requests. Culpa prices every call and carries whatever identifiers you attach, so a resumed request links to the attempt it continues and cost per completed answer becomes a query rather than an estimate. That number is the one worth watching, because it absorbs interruptions, retries and abandoned attempts automatically, and it moves when your provider has a bad week whether or not anyone noticed.

• Unattributed LLM Spend: The Bucket That Quietly Grows
• LLM A/B Test Cost: You Shipped the Winner and Not the Bill
• LLM Cost Accrual: Closing the Month Before the Invoice Arrives
• LLM Cost Anomaly Detection: The Aggregate Has a Noise Floor