Claude API streaming usage should be recorded once per request, using the provider’s cumulative counters rather than adding every progress update. Streaming changes how an answer arrives; it does not turn each chunk into a separate model call. Keep the request identity, the latest reported usage and the completion state together so an interrupted connection does not become a false success or a zero-cost record.
The counter is a running total
Anthropic’s streaming documentation says that usage in message_delta is cumulative. The stream ends with message_stop, and it can also carry error events.
That makes the accounting rule straightforward: replace the previous reading for the same counter and request. Do not add successive readings as though they were independent purchases.
Consider an illustrative sequence, invented solely to show the arithmetic:
| Update observed | Cumulative output tokens |
|---|---|
| First | 45 |
| Second | 82 |
| Final | 120 |
Adding the column produces 247. The final reported output count is 120. Nothing in this example establishes a model price, typical response size or latency.
A dashboard that makes the first mistake could report rising costs even when neither the workload nor the provider’s rates changed. Before optimizing prompts, check whether your accounting is measuring the same work repeatedly.
Give an attempt its own identity
Keep your business job separate from the API attempt. A support-summary job might involve an initial request, a retry and a later review call. Those belong to one business outcome but remain separate accounting records.
A suggested local record includes:
- Your job ID and a unique attempt ID.
- The provider’s message or request identifier, where received.
- Requested model and the model reported in the response.
- The most recent usage fields, preserving their names.
- Whether completion was observed, an error occurred or the connection ended unexpectedly.
- The application’s acceptance decision.
These are proposed application controls, not additional required Claude API parameters. They help answer two different questions: what did the provider report for this attempt, and did the business receive a usable result?
Do not deduplicate attempts solely because their prompts are identical. A retry is still another attempt. Conversely, processing the same stored event twice should not create a second copy of the same accounting record.
An interrupted stream needs an incomplete state
Suppose the connection closes after the second illustrative reading. Store the observed 82 and mark the attempt incomplete. Do not silently promote that observation to a verified final total, and do not replace it with zero because the final message is missing.
The distinction matters when comparing application logs with the provider’s account records. Label what was observed, what was completed and what remains unreconciled. The connection’s failure is evidence about delivery, not a complete invoice.
Anthropic documents recovery by constructing a new request from retained partial text, with different continuation patterns for older and newer model generations. Treat recovery as its own attempt in your application, rather than overwriting the first attempt’s history. Use the current SDK and model-specific instructions rather than assuming one continuation recipe fits every version.
Keep rendering separate from acceptance
Displaying a fragment is useful for responsiveness. It should not be the sole trigger for completing a business action.
For example, a proposed document-summary workflow could show partial text immediately but save the final approved summary only after the application has checked the complete result. An interrupted draft stays recoverable without being labeled a finished deliverable.
Apply an even clearer boundary when a response proposes an external action. A visible sentence is not a receipt showing that a payment, upload or other tool operation succeeded. Confirm those outcomes through the relevant system.
Our AI task-cost guide explains why accepted results, retries and review effort belong beside model usage. Idempotency keys address a different problem: preventing an uncertain mutation retry from creating a second operation.
Test accounting before interpreting the chart
Use a small synthetic event fixture with known expected results:
- Feed the 45, 82 and 120 readings into the same attempt. Expect 120.
- Replay one update. Expect no additional attempt or duplicated charge estimate.
- End a fixture before completion. Expect an incomplete record.
- Create a retry under a different attempt ID. Expect both attempts to remain visible.
- Reject a completed answer in your quality check. Keep its usage while marking the business result unaccepted.
This is a proposed test plan, not a claim that Webtamine ran a production integration. Its purpose is to make accounting assumptions inspectable before they drive a cost decision.
Source
Anthropic: Streaming messages, checked October 24, 2026. The arithmetic fixture and application-control recommendations above are original illustrative examples. This guide does not quote current token prices.
