Which response fields tell you whether caching is working?
Why B is the answer
cache_creation_input_tokens and cache_read_input_tokens
These fields show tokens written to and read from the cache, while input_tokens counts tokens after the last breakpoint. Track the read share over time.
In detail
- These fields show tokens written to and read from the cache.
- input_tokens counts only the tokens after the last breakpoint.
- Track the read share over time.
- Chart the read share over time.
Use case
An illustrative scenario, not a real incident.
After a release, costs rise. Usage shows cache_creation_input_tokens up and cache_read_input_tokens down, so the prefix changed. The team finds a new line at the top of the prompt.
See it in different ways
stateDiagram-v2 [*] --> Written: first request Written --> Read: same prefix within the lifetime Read --> Read: reused again Read --> Expired: idle past the lifetime Written --> Expired: idle past the lifetime Expired --> Written: next request
mindmap
root(("Usage"))
n1["cache_creation_input_tokens"]
n2["Written to the cache"]
n3["cache_read_input_tokens"]
n4["Read from the cache"]
n5["input_tokens"]
n6["After the last breakpoint"]Key point: Usage fields show whether caching is working.
Why the other options are wrong
- A. id and model
- These identify the response and model.
- C. role and content
- These hold the reply and say nothing about caching.
- D. stop_reason and stop_sequence
- These describe why generation stopped.