Prompt caching changes the cost of repeated context
Measure cache reads, writes, and misses before deciding whether a long prompt is wasteful.
Two requests can carry similarly large contexts and have very different costs. One may reuse a provider cache while the other processes new input. Looking only at total input tokens can hide that difference and lead a team to optimize the wrong part of a workflow.
The useful question is how the provider classified the input and how often the workload actually reused it.
Keep the token categories intact
Anthropic documents separate cache-creation and cache-read usage, along with conditions governing cache reuse. Its documentation is the source for the current behavior and pricing. Do not assume another provider has the same fields, lifetimes, or rates.
Retain the categories the vendor reports and avoid counting cached input twice when a total input field already includes it. A reporting adapter should explain how it maps provider fields into its own totals. The number of tokens and their valuation are related but separate transformations.
Reference: Anthropic: prompt caching
Test a stable-prefix workload
Use an illustrative task with a stable repository summary and a changing question. Send the same setup twice through the supported configuration, then inspect the returned usage categories. Change the part of the prompt expected to affect reuse and inspect again.
This experiment gives the team evidence about its actual route and request shape. It is more useful than assuming a theoretical cache discount will apply to every call. Include the first request's setup cost when comparing the complete task, rather than reporting only a favorable later cache hit.
Avoid turning cache optimization into stale context
Stable input is helpful only while it remains correct. A cached repository summary that omits a newly changed constraint can cause expensive mistakes. Keep the context relevant, version the information that changes, and check whether the agent has the facts needed for the current task.
Account handoffs also deserve attention. In FlockTab's documented subscription pool behavior, provider cache state does not carry to the next login. A switch that creates more account headroom may therefore alter the next request's context-processing cost. Evaluate the completed run rather than assuming every handoff is free.
Report the realized effect
Compare equivalent tasks using total observed usage, duration, and accepted outcomes. Show cache coverage and the period measured. A high cache-read percentage is an operational signal; it is not proof of a particular dollar saving without the corresponding rates and baseline.
FlockTab records cache-read information where the supported proxy and provider supply it. Older or incomplete records can lack that measurement. Exclude missing values from claims that require them, and tell the reader what population remains. A useful cache report explains observed reuse without manufacturing precision from absent data.
Sources checked 23 September 2026. Numerical scenarios are illustrative unless explicitly identified as provider data. Vendor limits and interfaces can change; consult the linked documentation for current details.