Capturing token usage from a streaming response

A non-streaming call hands you one response body with one usage object, and capture is a solved problem. Server-sent events break that in two ways, both documented and both easy to get wrong. First, usage arrives split: an opening event carries an input count and a running output count, and a closing event carries the totals. Anthropic's docs warn in as many words that the counts on the closing events are cumulative, so code that adds them up across events reports more output than the model produced. Second, and worse because it looks like nothing is wrong, the opening figure can be stale by the end. Server-side tool use adds context mid-request, so the input count that arrived first no longer describes the request that ran. Both failures are silent. The stream completes, the user gets their answer, your ledger writes a number, and nothing anywhere reports an error. You find out at the invoice, which is the one place that disagreeing with you costs a month.

• Your captured spend is lower than the provider invoice and nothing explains the gap.
• Streaming endpoints report costs that the same prompt won't when run without streaming.
• Your capture reads the first usage event it sees.
• You add up usage across events rather than taking the last one.
• Calls that used server-side tools look suspiciously cheap.

1. Find where your code reads usage from a stream and check which event it takes.
2. Check whether it sums across events or takes the last value.
3. Run one prompt streaming and non-streaming, and compare the cost you recorded.
4. Compare a month of captured spend against the invoice and size the gap.

Anthropic's streaming documentation, read 2026-08-05, includes a worked web-search response on claude-opus-5. Its message_start event reports input_tokens of 2,679. Its final message_delta event, on the same request, reports input_tokens of 10,682 and output_tokens of 510, because server-side tool use added context while the stream ran. Both token counts are published by Anthropic. The pricing is the price book's real claude-opus-5 rate of $5.00 and $25.00 per million, effective 2026-08-01.

None of this is a modelled edge case. It's the example Anthropic publishes to show what a stream looks like, and the two input counts in it differ by a factor of four. Any capture that reads the opening event and stops will under-report that call by 60%, quietly, forever.

Nothing here is hidden by a provider, since Anthropic documents all of it plainly. The pivot is where the capture runs. Anything reading usage from a stream has to sit inside your request path, handling your SSE events, in your code, which is exactly where a tool watching from outside can't reach. Culpa captures at the call site, takes the final usage rather than the first or the sum, prices each call from a versioned price book in exact decimal, and keeps the ledger on infrastructure you control. It also fails open, so a capture problem never becomes an availability problem. The check that proves it stays the boring one worth doing anyway: reconcile a month of captured spend against the invoice and see whether the two agree.

• Annual AI Budget: the Number You Commit To Crosses a Price Change
• Multi-Agent Cost Tracking: You Pay for the Context Every Hop
• Selling AI Credits: One Price, Ten Times the Cost
• Tool Definition Token Cost: You Pay for Every Unused Tool