[pcbeingused333]

handleMessageMetadata in the Anthropic streaming instrumentation only took output_tokens from message_delta, while the input and cache counts stayed at their message_start values. The message_delta usage is cumulative and these counts can be larger there, for example with server tools such as web search, where message_delta reports more input and cache-creation tokens than message_start. Spans for those streams under-reported gen_ai.usage.input_tokens and the cache attributes.

Input, cache creation and cache read counts from message_delta now overwrite the stored ones when they are numbers, and the prompt token total is recomputed from them. A null or missing count keeps the message_start value, so streams that don't resend them are unchanged. The message_delta usage type gains the optional input and cache fields.

This change was made with Claude Code.

Fixes #25621

[RulaKhaled]

bugbot run

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 4ac20c7. Configure here.}

[RulaKhaled]

Thanks for working on this! logic looks right and matches what the SDK's own MessageStream accumulator does with message_delta usage. one small comment, nothing blocking

CI failures look unrelated

[RulaKhaled]

l-m: could you add a case where message_start has input_tokens: 0 and the real count only shows up in message_delta?

[pcbeingused333]

Added in dfd9154: a case where message_start reports input_tokens: 0 and the real count (1500) only arrives in message_delta. Runs for both the async iterable and the message stream, and expects input 1500 and total 1540.