Stop Burning Tokens.

Every model has three prices, not one:

• Input — text you send (your prompt, the conversation history, file contents).
• Output — text the model generates (code, explanations, tool calls).
• Cached input — input the provider has already seen and stored.

Output is roughly 4–5× more expensive than fresh input. Cached input is roughly 10% the price of fresh input. So a one-shot "rewrite this file" can cost more than a full hour of careful patches — because rewriting forces the model to generate every line as output, while patching has it generate a tiny diff.

Mental model: token cost ≈ diff size × output-multiplier  +  context size × cache-discounted-input-rate. Optimize for small diffs and cache-warm context, not "the smallest possible model."

Prices per million tokens. Verify against the provider's page before you optimize anything serious — vendors adjust these often. The calculator below uses these defaults.

The Sonnet rule: if you can't articulate why Opus is needed for the next task, you don't need Opus. Sonnet does ~80% of real coding work for ~20% of the cost. Reserve Opus for: ambiguous architecture decisions, refactors across >10 files, debugging that's taken you longer than an hour.

Anthropic, OpenAI, and Google all cache prefix-matching input. If turn 1 sends "system prompt + project rules + file A + question 1" and turn 2 sends "system prompt + project rules + file A + question 2", the prefix is reused. You pay 10% of the input rate for the cached chunk.

This sounds like free magic. It is, but it requires shaping your prompts so the long, static parts come first and the short, varying parts come last. Reverse the order and you cache nothing.

In Claude Code, Cursor, and Codex CLI this happens automatically as long as you don't keep re-loading different files mid-conversation. The way to ruin caching: every turn, the agent reads a new file with cat and dumps it inline. Now the prefix changes every turn and your cache hit rate is zero.

Tactic: at the start of a session, ask the agent to read the files it needs once, summarize what it learned, and proceed. Re-load only on demand.

"/compact" is the most overused command in Claude Code. People run it because the UI shows context filling up — but the question is never "how full is the context", it's "does any of this old context still help with the next thing?"

The rule of thumb: compacting always loses signal. If you're already losing signal because the agent is confused, compact will help. If you're not losing signal, compact will hurt and you'll re-load the same files anyway.

Sub-agents look like a free productivity boost — until you do the math. Spawning a sub-agent means duplicating the system prompt and tool definitions, then carrying the return message in your main context. Net cost is real.

The math works out when:

• Research collapses into a summary. Sub-agent reads 50k tokens of docs, returns 500 tokens of answer. You spend 50k in the sub-agent's context, 500 in yours. Win.
• Tasks parallelize cleanly. Four sub-agents on four independent files in 5 minutes vs four sequential turns in 20 minutes. Wall-clock win, often a cost win because each sub-agent's context is smaller than your shared one would be.
• You want to throw away the working notes. The sub-agent's whole context dies when it returns. You keep only the answer.

The math fails when:

• The work is sequential. Three steps where each depends on the last. A sub-agent buys you nothing.
• The sub-agent needs your context to do its job. If you have to brief it for 5 minutes, you've already lost.

Pick a model, drag the sliders to match what your day actually looks like. Numbers update live. All math runs in your browser — nothing leaves the page.

Things to try: bump cache from 70% to 0% (see why it matters). Switch from Sonnet to Opus on the same workload (4–5× jump). Drop output from 1.5k to 0.5k by asking for diffs not rewrites.