How to Choose a Token Optimization Tool

Four things drive an agent's token bill and each needs a different class of tool. Find which one is yours before comparing products, or you will buy the wrong category.

Profile photo of Paul Irolla

By Paul Irolla

Founder · AI & developer tools · Tokenade

Ph.D. in AI · builds token-optimization tooling for AI coding agents

View author page
6 min read
Cite this page
Part of the reduce AI coding agent token usage pillar. This page is the category entry: what kind of tool you need, before which brand.

Which token optimization tool should you choose?

The one that addresses the driver your bill actually has. There are four, they need different mechanisms, and no single product covers all four well — so the first task is diagnosis, not comparison. Most people arrive at this decision from the wrong end: they read a roundup, pick the tool with the biggest published percentage, install it, and see the invoice barely move. That is not because the tool was bad. It is because a tool that filters command output does nothing for a bill dominated by whole-file reads, and its percentage was measured on the part it touches. Diagnose first. It takes twenty minutes and it decides everything after.

What are you actually trying to fix?

One of four things, and you can tell which within a week of measuring.
DriverWhat it looks likeWhat it is
RetrievalThe agent opens eight files to answer one questionWhole-file reads where a fraction would do
Output noiseA test run or build log arrives in fullUnfiltered command and tool output
Standing loadCost per turn is high even on trivial turnsTool manifests, memory files, system prompt
HistoryCost climbs steadily through a long sessionEvery prior turn re-sent on the next
Input dominates output by roughly an order of magnitude on agent traffic, so all four of these are inbound problems. That already tells you something useful: optimising what the model writes is the small side of the bill. To find yours, log the usage object per call, or use whatever your agent gives you — opencode stats --tools, Aider's /tokens, Claude Code's /usage. How to measure agent token usage covers doing it properly.

Which class of tool fixes which driver?

Four classes, and they are not substitutes for one another. Code indexes (semantic or call-graph) fix retrieval. They build a symbol index so the agent queries instead of reading. They do nothing for command output, nothing for history, and they add standing load of their own in the shape of a tool manifest. tokensave alternatives and codegraph alternatives compare this class. Output filters fix noise. They sit at the shell or tool boundary and fold verbose output before it enters context. They do nothing about which files get read. Filtering command output explains the mechanism. Context trimmers and compactors fix history. They summarise, prune or expire old turns. Most agents now ship some version of this natively, so check what you already have before adding anything. Meters fix nothing. They tell you which of the four you have, which is exactly what you need first and exactly why they are not optional. ccusage alternatives covers this class. The standing-load driver is the one with the fewest dedicated tools, and the awkward part is that installing tools from the other three classes usually increases it.

How should you read the savings percentages?

As a claim about the slice the tool touches, not about your invoice — and ask for the denominator before you apply the number to anything. This is the single most useful habit in this category, so here is the pattern in full. A tool intercepts, say, 12% of your traffic. On that slice it saves 80%. The headline says 80%. Every clause is true. The effect on your bill is under 10%, and the reader who did the arithmetic in their head got it wrong by an order of magnitude. Nobody is lying. The measurement is real and the generalisation is where it breaks. So three questions to ask of any published figure, including ours:
  1. What was measured? Retrieval against whole-file reads is not the same as session cost against a control.
  2. On whose repository? A self-benchmark on the vendor's own codebase with a query set they chose is a different claim from an independent one.
  3. Against what? A comparison against a hypothetical worst case is arithmetic. A comparison against the same agent doing the same task without the tool is an experiment.
Tools that ship a command so you can re-run their benchmark on your own repository deserve credit for that — it is about reproducibility, not about the size of the number.

What does measured evidence look like?

A control arm, real sessions, and a published method you can check. I run an open benchmark of token optimizers on long agent sessions, comparing against running no tool at all. It is public, including the runs that make my own product look ordinary, and the result worth knowing before you buy anything in this category is this one: of the twelve tools tested, most show no measurable session-cost saving. Several are indistinguishable from running nothing; one finished more expensive than the control. That is not an argument against the category. It is an argument for asking what a percentage covered, because the tools that publish the largest numbers and the tools that move a session bill are not the same set. Disclosure, plainly: I run that benchmark and I sell one of the tools in it. Which is why the method and the raw results are published rather than summarised.

How to choose today

  1. Measure for a week before buying anything. You are looking for which of the four drivers dominates, not for a total.
  2. Match the class to the driver. An index for retrieval, a filter for output noise, a compactor for history. Buying across categories is how people end up with three tools and an unchanged invoice.
  3. Count the standing load you are adding. A tool manifest is billed on every turn, including the turns that never use the tool.
  4. Ask for the denominator on every percentage you are shown, ours included.
  5. Re-measure after. If you cannot see the change in the same instrument you used in step one, the tool did not do what you bought it for.

What goes wrong (anti-patterns)

Buying the biggest percentage. It is usually the narrowest measurement. The number is not fake; the scope is not what you assumed. Installing across categories at once. Three tools installed together means you cannot attribute the change to any of them, and one of them is probably adding more standing load than it removes. Skipping the meter because it does not save anything. It is the only class that tells you which of the other three you need. Buying without it is guessing with a credit card. Assuming your agent has none of this built in. Most now ship context compaction, and some ship output limits. Check before paying for a second copy. Treating a subscription as a reason not to care. A plan absorbs the cost in money and charges you in rate limits instead. You still hit the ceiling sooner; you just do not see a line item.
See also:

Cut your AI coding agent's token bill.

Ranked #1 on the Token-Harness Optimizer Leaderboard. Zero config.

Tokenade is the simplest way to cut what your coding agent sends to the model — set it up once and save on every prompt.