The chat says done. The bill says more.

A coding agent ends a task with a short message. It doesn't tell you how many model calls it made, how much context it carried into each one, which tools it loaded and ignored, or whether the second half of the session was spent undoing the first.

Those details decide the cost. Token Meter reads the session logs that agents already write to your disk and prices each request at public list prices, so you can see them. The findings below come from a few months of that data on one machine. Your numbers will differ. The patterns are worth checking for yourself.

Why small token shares cost the most

Not every token costs the same. A request to a model is billed in four parts, and the prices differ by up to a hundred times. These are the list prices for Claude Opus 5.5:

Claude Opus 5.5 list price per million tokens
Token typeWhat it isPricevs. cache read
Cache readContext the provider already stored and serves again$0.201×
Fresh inputNew input that isn't cached$420×
Cache writeInput stored in the prompt cache for reuse$5–825–40×
OutputText, code, and reasoning the model writes$20100×

Over 30 days on Opus 5.5, about $1,423 at list price, the split looked like this:

Cache reads did their job: almost all the tokens, a third of the money. The surprise was cache writes. At 25 times the price of a read, 6% of the tokens took more than half the bill.

Cache writes pile up in long sessions whose context keeps shifting. When anything early in the prompt changes, everything after it has to be written to the cache again. Caching makes repeated input cheap. It doesn't make irrelevant input useful.

The five levers

Each lever below has one number from the same laptop, one thing to try this week, and the place in Token Meter where the change shows up.

Lever 01

Model and reasoning

Which model runs the task, and how much reasoning effort it spends. Reasoning tokens are billed as output, the most expensive kind.

The number: xhigh reasoning effort went from 70% of spend in July to 22% in September. In a side-by-side run of the same prompt, Opus cost 5.1 times as much as Haiku, and $0.21 of the $0.33 gap was cache writes.

What to do Monday: Send routine work, such as renames, small fixes, and test runs, to a cheaper model at medium effort. Keep the top model and high effort for tasks where the path is unclear or a mistake is expensive. If you switch models partway through a task, start a fresh session with a short handoff note. The new model can't reuse the old model's cache, so carrying the whole history over means writing all of it again.

Where to see it: Models groups each model by reasoning effort. Sessions → Compare puts up to four runs side by side, with model, effort, and cost split by token type.

Lever 02

Task context

Everything loaded before the agent starts working: instructions, tool and MCP definitions, skills, files, and earlier turns. You pay for it on every call.

The number: 83,907 tokens of tool definitions were loaded into prompts and never called. Separately, subagent cost per run fell from $6.04 in August to $0.96 in September, as runs became shorter and more narrowly scoped.

What to do Monday: Turn off MCP servers and skill packs a project doesn't use. Give each subagent one specific job and only the files it needs. When most of a session's context is history the current step no longer needs, compact it or start fresh.

Where to see it: Tools lists definitions that were loaded and not called. Treat “no use observed” as a prompt to review, not proof that a tool is useless. Efficiency tracks context load, and Subagents shows cost per run for each role.

Lever 03

Prompt caching

Providers store a repeated prompt prefix so later calls can read it cheaply. Writing to the cache costs more than plain input, so a cache only pays off when the prefix stays the same long enough to be read many times.

The number: cache writes were 55% of the Opus 5.5 bill.

What to do Monday: Keep the start of the prompt stable. Avoid editing instruction files or changing the tool list in the middle of a session. Put material that changes often near the end. Cache entries also expire after a few idle minutes (five by default on Anthropic's API), and the next call writes them again, so a session left idle and resumed many times pays for repeated writes.

Where to see it: each session shows cache writes beside cache reads. Efficiency tracks the cache hit ratio over time.

Lever 04

Outcome-focused prompts

Telling the agent what finished looks like, instead of describing activity.

The number: 15% of 1,964 follow-up messages were pushback: corrections, redirections, and requests to redo work.

What to do Monday: Name the outcome, limit the scope, and say how to test it. For example:

Fix the failing date test in tests/test_dates.py.
Change only the date parser module.
Done means the test suite passes with no other test changes.

Where to see it: run the same task once with your usual prompt and once with an outcome-focused one, then open both in Sessions → Compare. Executions, active time, and cost sit next to each other.

Lever 05

Avoid rework

Rework is the expensive part of a session. Each correction in a long session re-reads the whole context before the agent writes a word.

The number: sessions that recovered after pushback cost $33 on average. Sessions accepted without pushback cost $6.

What to do Monday: If a session goes off track twice, stop pushing. Start a new one with a short handoff: the goal, what was tried, what failed, and the next step. For larger changes, review the agent's plan before it writes code.

Where to see it: sort Sessions → All sessions by cost and open the most expensive runs to see executions and peak context. Token Meter doesn't decide whether a session succeeded. That call is yours.

Change one thing, then measure

Pick two or three tasks you repeat often. They become your personal benchmark. Change one lever, run a task again, and compare the runs on four measures:

  1. Cost per successful result. Cost per session misleads if half the sessions fail.
  2. Quality. Did the result pass review and tests without changes?
  3. Elapsed time. A cheaper model that takes twice as long may not be a saving.
  4. Correction effort. How many times you had to step in.

Keep a change only if it holds up on all four.

The same laptop shows why one change at a time matters. From June to September, output per dollar rose 73% after three changes: dropping Opus 4.8, cutting xhigh effort from 70% to 22% of spend, and moving routine work to a cheaper model at medium effort. In October, 98% of spend moved to Opus 5.5. Context load rose, cache writes reached 55% of the bill, and output per dollar fell 30%. A model that is cheaper per token cost more per result for this workload. The drop showed up as a number first, and the number pointed to the lever to check.

Can I trust these numbers?

Use them to compare, not to reconcile an invoice.

  • Costs are estimates at public list prices. Contract discounts, subscription plans, and gateway rates aren't visible to Token Meter.
  • Only sessions stored on this machine count. Web chat, CI runs, and other laptops are not included.
  • When a model has no known price, or a runtime doesn't report a value, it is shown as unavailable rather than counted as zero.
  • The figures in this article come from one engineer's laptop, estimated at public list prices, between June and October 2026. A different workload will produce a different split.

For the amount you actually owe, use your provider's console. For deciding what to change next, compare sessions, models, and trends on your own machine.

Measure your own

Token Meter runs locally, needs no API keys, and works on the history your agents have already written. On macOS or Linux:

git clone https://github.com/splunk/token-meter.git
./token-meter/scripts/install

Then open http://127.0.0.1:8722. Windows (beta) instructions are on the install page.

Get Token Meter on GitHub