# What an interrupted response costs once you've resumed it > Resuming an interrupted response re-sends what you already generated as input. A modelled interruption at 80% costs 23.6% more than a clean run. URL: https://getculpa.com/stream-interruption-cost Last reviewed: 2026-08-05 Rates effective: 2026-07-02 ## Answer An interrupted stream still bills for everything generated before it stopped, and the documented way to resume re-sends that partial output as input. So you pay to generate it once and to read it back again. Culpa, a local-first LLM cost, margin, and forecast ledger, prices both halves as the two separate calls they really are. ## Why this happens 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. ## What this usually looks like - 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. ## Common mistakes - Treating an interrupted request as costing nothing. Why it hurts: Everything generated before the interruption was billed, and you got no answer for it. Do instead: Record the partial usage as its own call, so the waste is visible. - Logging a resumed request as one call. Why it hurts: It's two calls, and the second one carries the first one's output as input. Do instead: Record both, linked, so cost per completed answer includes the retries it took. - Retrying from the start after an interruption. Why it hurts: You pay to regenerate everything, rather than paying input rates to carry it forward. Do instead: Resume from the partial response where the model supports it, which is cheaper on output. - Monitoring error rate without error cost. Why it hurts: A rate tells you it happened and not what it took to recover from. Do instead: Report cost per completed answer, which absorbs interruptions automatically. ## Self-check - Find what share of your requests ended without a complete response last month. - Check whether your logs record the tokens generated before an interruption. - See whether a resumed request appears once or twice in your cost data. - Compare cost per completed answer against cost per call and size the gap. ## One answer, two calls (illustrative) 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. clean run: 2,000 x $2.00/M + 4,000 x $10.00/M = $0.004000 + $0.040000 = $0.044000 interrupted attempt: 2,000 in + 3,200 out = $0.004000 + $0.032000 = $0.036000, no usable answer resume: (2,000 + 3,200) in + 800 out = $0.010400 + $0.008000 = $0.018400 total paid: $0.036000 + $0.018400 = $0.054400 against $0.044000 clean, an overhead of $0.010400, or 23.6% more 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. ## Cost figures Every figure carries its confidence and its source. No figure on this page is provider-reported. - 23.6%, modelled overhead of one interruption plus resume against a clean run [calculated] Source: A modelled 2,000-token prompt and 4,000-token answer on Claude Sonnet 5 at real rates of $2.00 and $10.00 per million from the price book effective 2026-07-02 costs $0.044000 clean. An interruption at 80% of output costs $0.036000 with no answer, and a resume carrying the 3,200 partial tokens forward as input costs $0.010400 + $0.008000 = $0.018400, totalling $0.054400, which is $0.010400 more or 23.6%. Rates and the documented recovery method are published, the token counts and interruption point are modelled. ## FAQ Q: Do I pay for a response that was interrupted? A: Yes, for everything generated before it stopped. The tokens were produced and billed even though you have no usable answer. That partial usage is worth recording as its own call, otherwise the waste is invisible. Q: Is resuming cheaper than retrying? A: Usually. Resuming re-sends the partial output as input, which bills at input rates, while retrying regenerates it at output rates. Output costs several times input on most models, so carrying the partial forward is the cheaper recovery even though it isn't free. Q: How much does an interruption actually add? A: In the modelled example, 23.6%. A clean 2,000-in, 4,000-out request on Sonnet 5 costs $0.044000, while an interruption at 80% plus a resume costs $0.054400. The overhead is the partial output being paid for twice, once as output and once as input. Q: What should I measure? A: Cost per completed answer rather than cost per call. It absorbs interruptions, retries and abandoned attempts without anyone having to model them, and it moves when your provider degrades, which is exactly when a cost-per-call figure looks reassuringly flat. ## Sources - Anthropic, streaming messages: https://platform.claude.com/docs/en/build-with-claude/streaming - Anthropic pricing: https://platform.claude.com/docs/en/docs/about-claude/pricing Run the free Cost Leak Scan: https://app.getculpa.com/scan?source=pseo&slug=stream-interruption-cost&cluster=problem Machine-readable index of every guide: https://getculpa.com/api/pages Human-readable index of every guide: https://getculpa.com/guides Site overview: https://app.getculpa.com/llms.txt Privacy: Culpa runs on your infrastructure. Your prompts and responses never leave it. Culpa counts calls to run your plan, and it fails open, so if it ever breaks your app keeps running.