Usage accounting reads cache writes split by 5-minute and 1-hour lifetime

What

When Claude Code sends a request, it can store part of the conversation in a prompt cache so later requests are faster and cheaper. Cached entries last either 5 minutes or 1 hour. The API's usage report can now say how many cached tokens were written at each lifetime, and Claude Code reads that.

• The usage format now accepts a cache_creation object holding ephemeral_5m_input_tokens and ephemeral_1h_input_tokens.
• The cache fields and server_tool_use may now be missing or empty without causing a problem.
• When usage from several responses is combined, cache_creation is kept, and cache_creation_input_tokens is worked out from it.
• A new check reports whether the cache lifetime was 1h or 5m from these counts.
• The fallback that picks the cache lifetime for the main conversation now calls a function. Before, it chose 1h for the main thread and 5m otherwise.
• Each usage record now carries cache_creation_5m_input_tokens and cache_creation_1h_input_tokens, each 0 when not reported.

Why

The cache lifetime is now taken from what the API reported rather than assumed. That feeds Claude Code's decisions about cache misses and keeping the cache alive, and it lets the cost of cache writes be split by lifetime.