In packages/ai/src/providers/anthropic.ts, the cache-write per-token rate is computed once from the cache_creation TTL breakdown in message_start (~550-556) and captured in a closure. The message_delta handler (~682-711) re-reads the latest token counts but keeps passing the stale rate into calculateCost.
When message_delta carries different cache-creation numbers than message_start, reported cost.cacheWrite and cost.total drift from actual billing. This happens behind proxies like LiteLLM that re-aggregate usage, and the 1h vs 5m rate gap under cacheRetention: "long" amplifies the error. The SDK's MessageDeltaUsage type does not declare the cache_creation breakdown (only the scalar), so the current code never reads it from message_delta at all, but proxies do include it at runtime.
Fix: reprice inside the message_delta handler from the latest event.usage.cache_creation breakdown when present, and fall back to the message_start rate otherwise.
In
packages/ai/src/providers/anthropic.ts, the cache-write per-token rate is computed once from thecache_creationTTL breakdown inmessage_start(~550-556) and captured in a closure. Themessage_deltahandler (~682-711) re-reads the latest token counts but keeps passing the stale rate intocalculateCost.When
message_deltacarries different cache-creation numbers thanmessage_start, reportedcost.cacheWriteandcost.totaldrift from actual billing. This happens behind proxies like LiteLLM that re-aggregate usage, and the 1h vs 5m rate gap undercacheRetention: "long"amplifies the error. The SDK'sMessageDeltaUsagetype does not declare thecache_creationbreakdown (only the scalar), so the current code never reads it frommessage_deltaat all, but proxies do include it at runtime.Fix: reprice inside the
message_deltahandler from the latestevent.usage.cache_creationbreakdown when present, and fall back to themessage_startrate otherwise.