Same gap on the native AnthropicLlm path (Vertex Anthropic / AsyncAnthropicVertex), not only LiteLLM+Bedrock.

Still true on released google-adk==2.6.3 (2026-08-07). message_to_generate_content_response maps:

input_tokens → prompt_token_count
output_tokens → candidates_token_count
cache_read_input_tokens → cached_content_token_count (since b15c8a0 / v2.3.0)

and drops cache_creation_input_tokens. Anthropic bills that bucket at 125% of input, disjoint from input_tokens — so cost pipelines that only see usage_metadata under-count cache-priming turns (large cached system prefix across subagents). We see this in BigQueryAgentAnalyticsPlugin rows: attributes.usage_metadata never has a cache-write field, and the plugin has no cache_creation_* view column.

GenerateContentResponseUsageMetadata also has no dedicated cache-write scalar (only cached_content_token_count for reads). #5395 suggested cache_tokens_details; that issue was closed without a mapping.

Unreleased main (a95b008, 2026-08-05) folds cache_creation_input_tokens into prompt_token_count. That stops the total from going missing, but still prices writes at 100% of input instead of 125%, and still leaves observability tools (Arize / BQ / Looker) unable to split read vs write.

Ask: expose cache-write as a first-class field on usage_metadata (or a documented extra on the dumped JSON) for Anthropic and LiteLLM, then have tracing + BigQueryAgentAnalyticsPlugin persist it. Happy to send a PR if that shape is acceptable.

Uh oh!

Cache read write token counts #5835

Description

Activity

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions