1. Separate reusable input from new work
A cached token is an input token that a provider can reuse from a previously processed prompt segment. Its practical value is the difference between the normal input charge and the cache-read charge, minus any extra costs required to create and maintain that cache.
Start with a real request. Mark the instructions, reference documents, tool definitions, and other material that stay unchanged between calls. Then mark the user question and any fresh context. That split tells you where caching might help.
Repeated text is a caching opportunity, not proof of a cache hit. Eligibility depends on the model, provider rules, minimum prompt length, retention window, and sometimes explicit cache settings.
2. Put a price on one warm request
Use hypothetical rates first so the arithmetic is easy to inspect. These figures are an illustration, not SwiftRelay pricing or a quote for any model.
- Normal input: $2 per million tokens.
- Cached input reads: $0.20 per million tokens.
- Output: $8 per million tokens.
- Request: 20,000 reusable input tokens, 2,000 fresh input tokens, and 1,000 output tokens.
Without caching, input costs $0.044 and output costs $0.008, for a total of $0.052.
If all 20,000 reusable tokens qualify for the illustrated cache-read rate, their cost falls to $0.004. Fresh input still costs $0.004, and output still costs $0.008. The warm request totals $0.016, saving $0.036, or about 69% of the original request cost.
Notice the boundary: cached input became 90% cheaper in this example, but the whole request did not. Output and fresh input still count.
3. Check the rules before counting savings
Before testing a model such as Claude Sonnet 5.5, check its current caching support and the rules for the route you will actually use. Do not assume another model uses the same thresholds, retention behavior, or billing categories.
Some implementations apply caching automatically to eligible prefixes. Others require explicit cache controls. Cache creation can also carry a different charge from ordinary input. A request that populates a cache may therefore cost more than a later cache-reading request.
Your useful equation is: net savings equals avoided normal input charges minus cache-read charges and extra cache-creation charges. Include repeated creation after expiration when estimating a longer workload.
4. Keep the reusable prefix genuinely stable
Place stable instructions and reference material before changing request content wherever the provider's caching design supports that structure. Keep timestamps, random identifiers, and user-specific details out of the reusable prefix.
A changed prefix can prevent reuse beyond the change. Even harmless edits to document ordering or tool definitions may affect eligibility. Keep the test prompt identical except for the final question, and avoid padding prompts merely to reach a caching threshold: extra tokens still have a cost.
5. Run a small test through your real client
SwiftRelay is a practical place to measure this in your existing workflow because billing is per token. Sign up for SwiftRelay, use the small gift credit available to new accounts, and begin with a tightly bounded experiment.
Use https://api.fastapirelay.com as the bare host for Claude Code and Gemini CLI; OpenAI-compatible SDKs use https://api.fastapirelay.com/v1. Check the selected route's caching requirements rather than assuming that changing the host enables caching.
Send one initial request, then several requests with the same reusable prefix. Record ordinary input, cache reads, cache writes where reported, output, and billed cost. Usage field names differ across APIs, so inspect their meaning rather than guessing from a single total.
6. Judge the full run, not the best hit
Compare the measured run with a no-cache baseline using equivalent input and output volumes. Include the initial request, cache creation, missed hits, and expiration. If output lengths vary, account for that before attributing the bill difference to caching.
A cached token is worth the charge it actually avoids. Keep caching when repeated, stable context produces lower total spend across your real request pattern. A large reusable document can be valuable; a frequently rewritten prompt may offer little benefit.