Token optimization: the money is in not paying for the same tokens twice

Output tokens are the expensive ones. On every current Claude model, output is priced at five times input: Anthropic's published rates as of September 2026 are five dollars per million input tokens and twenty-five per million output on Opus 5, two and ten on Sonnet 5, and one and five on Haiku 4.5.

That single ratio reorders most people's instincts. Shaving a hundred words off a prompt saves input. A model that restates the question before answering it spends output, at five times the rate, on every call.

The other thing to settle before touching anything is the unit. Measure cost per completed task, not per request. A cheaper request that needs an extra turn or a retry to finish the job is not cheaper, and a per-request dashboard will tell you it is.

Almost every AI feature sends the same large block on every call: the system instructions, the tool definitions, the schema, the reference material. Prompt caching lets you pay for that block properly once and cheaply afterwards.

Anthropic's published multipliers make the economics simple. A cache read costs about a tenth of the base input price. Writing to the cache costs a quarter more than a normal request with the default five-minute lifetime, or double for the one-hour option. Every read also resets the timer at no extra cost.

So with the five-minute cache, two requests sharing a prefix already come out ahead. Ten requests pay 2.15 times the base price for that prefix instead of ten times: one write at 1.25, then nine reads at 0.1 each. That is arithmetic on published rates rather than an estimate, and it is why caching comes first. It is the one lever that cuts cost substantially without touching quality at all.

The effect is stronger at the top of the range. On Claude Fable 5.1 a cache read is a fortieth of the input price rather than a tenth, which makes a cache miss comparatively expensive and keeping the cache warm the main cost decision for long sessions.

Here is the failure that catches almost everyone who turns caching on: it quietly does nothing.

The cache works by matching the start of the request exactly, byte for byte. Change anything, and everything after that point is a miss. The most common culprit is a timestamp or today's date near the top of the system prompt, put there with good intentions, which makes every request's prefix unique. Others are JSON with keys in a different order each time, and a tool list that varies from one request to the next.

The rule is stable content first, volatile content last. Instructions, tools and reference material go at the front; the user's question, the current time and anything per-request go after the last cache breakpoint.

And check rather than assume. Every response reports how many input tokens were read from the cache. If that number stays at zero across repeated requests, something at the front is changing, and the saving you think you have is not happening.

Before any of the tuning above, ask whether the call needed to happen.

Our own feedback coach is a small example. Piko, the assistant that helps someone improve a written note, reads a field only when the writer leaves it, never while they are typing. A field that is left without a change costs nothing, and punctuation or whitespace edits do not count as a change. It reads one field rather than the whole form. And each note has a rewrite budget the company sets; when it is spent, the calls stop.

Worth being honest about why it was built that way: the reason at the time was quality, not cost. Re-reading the whole form kept re-opening fields the writer had already settled. The saving came along with the better behaviour, which is common. The best token optimizations tend to be product decisions about when a model is actually needed, rather than techniques applied to the calls you already make.

Since output costs five times input, what you ask the model to produce is where most of the remaining money sits. Ask for the answer rather than the answer plus a restatement of the question. Ask for structured output when a program is reading the result rather than a person. Do not ask for an explanation nobody will read.

The tempting shortcut is to set a low maximum on output tokens. It is a false economy. The cap is not something the model plans around; it simply cuts the response off mid-thought. A truncated answer is usually useless, so it gets retried, and you pay for both. Shape the output with what you ask for, and leave the ceiling where it cannot interrupt a correct answer.

Anything that does not need an answer within seconds can go through the batch interface at half price. Nightly summaries, bulk classification, re-scoring an archive, evaluating a prompt change against a test set.

It is the plainest saving on this list and one of the least used, mostly because work gets built as live calls by default and nobody goes back to ask whether it had to be.

Only now reach for the levers that trade quality for cost: lower effort settings, and cheaper models. They are real and often worth it. They are also where most teams start, which is exactly backwards, because they are the only levers on this list that can make the product worse.

Two cautions. Test on a sample of real requests before changing a default, and judge the result per completed task. And be careful with cascades that route between several models: caches belong to one model, so switching models throws away the cached prefix, and a cheaper model paying full input price can cost more than a better one reading from its cache.

Watch for cliffs in other providers' pricing too. Grok 4.6 and GPT-6 Astra both reprice an entire request once the prompt passes a threshold, 200,000 tokens and 272,000 tokens respectively, and it is the long-running agents that accumulate context by working well that drift across them.

Measure per task. Cache what repeats, and check the cache is actually hitting. Remove calls that did not need to happen. Ask for less output instead of cutting it off. Batch what can wait. Only then trade quality, and measure when you do.

The first five cost nothing in quality. The last one can. Teams that begin by switching to a cheaper model usually save less than they would have by moving one timestamp to the end of a prompt, and they take on the risk while doing it.