Updated 13 September 2026: this article now presents a general method. Examples are illustrative, not customer results.
A cache setting written in a configuration file does not prove that the application accepted it or that the provider reused the input. I check both before claiming a reduction in API cost.
This article describes a general debugging method. Provider features, retention periods and prices depend on the current model and API; no private workload or bill is used as evidence.
The fix that wasn't
A fictional configuration illustrates the risk: a developer writes cacheTTL, but the application's schema expects cacheTtl. The file looks plausible. Depending on the validator, the unknown key may be rejected, retained or discarded.
Those identifiers are illustrative, not instructions for a particular product. Find the supported field in the installed version's documentation or schema, then inspect the effective setting and outgoing request.
Silent-strip validation is a cost bug factory
Discarding an unknown field without a useful diagnostic can hide a misspelling. Accepting an arbitrary field does not establish that a downstream component uses it either.
Test how the configuration layer behaves with an intentionally invalid field in an isolated setup. Prefer an explicit failure or clear diagnostic over a silent fallback.
Verify from the meter, not the mirror
Use synthetic inputs and inspect the provider's reported cache-read and cache-write usage. Check whether repeated requests share the prefix required by the provider and whether the relevant retention conditions were met.
A cache miss can have several causes: a changed prefix, expired retention, an unsupported request shape or a different processing route. Token usage helps investigate; a repeated request alone does not prove that caching should have occurred.
Compare the actual billed cost, including any write premium and additional calls. A higher hit rate does not by itself establish a lower total cost.
The checklist
- Check the installed version's supported setting and exact spelling.
- Verify how unknown fields are handled.
- Inspect the effective request using synthetic data.
- Compare provider usage and charges before claiming a benefit.
- Record the tested configuration and its limits.
The same distinction between configuration and behaviour applies to context limits and router health checks.
Questions people ask about prompt caching and config drift
Why can a setting have no effect?
It may be unsupported, misspelled, overridden or ignored by the request path. Verify each boundary.
How do I verify caching?
Use controlled requests and the provider's actual usage fields, then compare the billed cost.
Does a longer cache lifetime always save money?
No. It depends on request timing, prefix reuse, provider pricing and the work needed to maintain the setup.