What I Actually Teach About Token Spend
Ask most people how to cut their Claude token spend and they tell you to write shorter prompts. Not wrong. Just not where the money is.
The money is in caching. Turn it on, verify it is actually reading, and cutting your effective spend by half is a realistic outcome on any workload that reuses context. That is arithmetic, not a marketing number.
The agenda I actually run
I built real training curriculum around this, not a deck of generalities. The session I teach from opens in this exact order:
- Enable Prompt Caching, enable Context Pruning
- Restart the gateway
- Set up session management
- Set spending targets against the Anthropic billing dashboard
- Set hard limits
Look at what is first. Not "review your prompts." Not "pick a cheaper model." Caching and pruning go first because they are the two levers that bend your cost curve without taking anything away from what the agent can do.
Everything after that is guardrail. Gateway restart, session management, spending targets, hard limits. That layer is what makes sure the savings land on the bill instead of getting eaten by one runaway session nobody was watching.
The mechanics, not the marketing
Here is what I actually track, because "enable caching" means nothing until you know the numbers under it.
There is a 1-hour TTL option and it costs 2x the normal write. Under a per-model token floor a prompt will not cache at all: 512 tokens for Fable and Mythos 5, 1,024 tokens for Opus 4.8 and Sonnet 5, up to 4,096 tokens for Haiku 4.5. If your system prompt or tool schema is smaller than that floor, caching it does nothing. you are paying the write premium on a cache that never gets read.
And I do not assume a hit happened just because I flipped a switch. I check the cache_read_input_tokens field in the usage response. That field is the ONLY honest signal that a request read from cache instead of writing a fresh one.
Zero on a request that should have hit? Something upstream moved. A session boundary, a prompt that changed by one token, a TTL that expired. "On" and "working" were never the same thing, right?
That is the gap most people miss. Turning a feature on and confirming it saves you money are two separate steps, and only the second one shows up on the invoice.
Why the caching skill exists as its own thing
I built and installed a dedicated skill for this, gemini-api-caching. Its own description is exact about the job: implement context caching to reduce costs on repeated context, by caching large prompts with TTL management, covering cache creation, cache listing, TTL configuration, and the cost-savings math for repeated context.
It lives as its own piece of the toolkit because caching is not a one-line flag. It is a lifecycle. You create a cache. You track its TTL. You list what is active. Then you do the math on whether it is actually paying back the write premium you took on to create it.
Where "cut in half" comes from, honestly
The half-off number is not a case study I am claiming off one specific run. It is what the mechanic itself implies once the floors are respected and the reads are verified. A cache read costs a fraction of a fresh write, and on any workload where the same system prompt, tool schema or long context gets reused across a pile of calls, that fraction compounds fast.
The write premium is real. 2x on a 1-hour TTL. So caching a prompt you will only use once actually costs you MORE, not less. The savings live specifically on repeated context, which is most agent fleets, most of the time.
So the real advice is narrower than "enable caching and save money." Know your model's token floor. Verify the read field instead of trusting the toggle. Only cache what you are genuinely going to reuse.
Do those three and the arithmetic takes care of itself.