800 to 1

Most of our development now runs through an AI coding agent. On a flat-rate subscription the dollar cost is fixed, but tokens are not free — they are rate-limit headroom. Burn through them and you hit a mid-task cutoff four hours into a refactor. So we wanted to spend fewer tokens per unit of work.

The advice that circulates is simple: tell the model to answer tersely — drop the filler, speak in fragments — and you cut your token usage by "up to 75%." It is a satisfying idea. We decided to measure whether it was true for us before believing it.

Output is a rounding error

Over several weeks of heavy real usage we sent tens of billions of input tokens and received about forty million output tokens back. That is a ratio near 800 to 1. Every turn re-sends the entire growing context — system prompt, tool definitions, file contents, command output, conversation history — to get back a few hundred tokens of reply.

And it is not an average hiding a lucky week. Bucket the same logs by week and the shape never moves — output stays pinned to the baseline against input, every single week.

The terse-talking trick compresses only the model’s prose, and it leaves code, tool calls, and structured output alone. That prose is 0.12% of our token volume. Even weighting for the fact that output tokens are priced several times higher than input, the absolute ceiling on what "make the AI talk less" could ever save us is around 1% of the bill. We were about to optimize a rounding error.

The token-saving trick that goes viral optimizes the thing you can see — the model’s words — not the thing you can’t: the context you re-send every single turn.

Where the tokens actually live

So we pointed the analyzer at the logs the agent already writes and measured the composition of everything that flows into context. It was not the model’s prose. It was not even close.

We did not eyeball this, and we did not draw that chart by hand — tokenops rendered it. The tool reads the JSONL logs the agent already writes and reports the split directly, no daemon, no setup:

$ tokenops fmt analyze --top 6

Context composition — 768 sessions, 78539 tool results
  SOURCE                 ~TOKENS    SHARE
  Read                     14.3M    46.5%
  Bash                      8.2M    26.6%
  (assistant prose)         3.5M    11.4%
  (user prose)              1.1M     3.7%
  Agent                     861k     2.8%
  Edit                      723k     2.3%

And that split is not a one-off snapshot either. Bucket the same logs by week and the mix holds: file reads and command output dominate the context every week, not just on average.

Command output: real, but not where we assumed

Command output looked promising, so we built a deterministic compressor for it — 46 per-command formatters that strip the noise from tool output (progress bars, up-to-date chatter, passing-test scaffolding) while guaranteeing that no error, failure, or changed-state line is ever dropped. On a benchmark corpus it removes 57–68% of the volume.

Then we ran it against our actual command history — and it reclaimed 1–4%. The formatters are excellent at compressing noisy builds and verbose test runs. Our commands, it turned out, are mostly grep, cat, echo, and small git calls — already terse, nothing to strip. The catalog was not wrong; our usage simply does not lean on the commands it shines at. Honest measurement beat the demo number.

The real lever: reading the same file twice

The biggest slice was file reads. Within it we looked for waste: the same file read more than once, and byte-identical content re-sent. About 16% of reads were repeats and 24% was duplicate content — reclaimable in principle. But more than half of all our reads already used ranged reads (offset/limit), and when we isolated the genuinely wasteful case — the same file read in full, unchanged, twice in a session — it came out to a handful of reads and a few thousand tokens across several sessions.

$ tokenops read-guard stats

read-guard — 112 reads seen across 3 sessions
  repeat reads (same file again in a session): 53
    ├─ reclaimable (unchanged full re-read): 4 · ~5354 tokens
    ├─ post-edit (file changed — not waste):  2
    └─ ranged (intentional partial re-read):  47

In other words: we were already reading efficiently. The lever existed, but for us it was nearly empty. The tool proved that rather than assuming it.

The biggest win was not a compression trick. It was measuring — which killed three plausible optimizations before we shipped snake oil to ourselves.

What we shipped

The through-line of all of this is the same: you cannot optimize what you have not measured, and the AI-token economy is full of confident advice measured against the wrong denominator. So the useful artifact was never a single compression knob — it was the measurement itself.

We built and open-sourced tokenops: a local-first CLI and MCP server. It reads the logs your agent already writes and tells you where your tokens actually go — no daemon, no account, no telemetry leaving your machine. It ships the deterministic command-output formatters, and a hook that reclaims genuinely redundant file re-reads at the source. Every number and chart in this post came out of it, pointed at our own usage.

$ brew install felixgeelhaar/tap/tokenops

# where do my AI-coding tokens actually go?
$ tokenops fmt analyze

# what would the command-output formatters save on my traffic?
$ tokenops fmt learn

Point it at your own usage

Setup is not installing another optimizer — it is aiming the measurement at your own situation. Everything below reads the logs your agent already writes; the only question is how much you want wired in. Four common starting points, in order of commitment.

If you only want to check your own denominator before trusting anyone’s percentage: install, run one command, read the split. No daemon, no account, nothing left running. This is where every number in this post came from.

$ brew install felixgeelhaar/tap/tokenops

# context composition from the logs already on disk — no daemon, no account
$ tokenops fmt analyze

If you are the person in this post — coding all day against a Claude Max or ChatGPT plan and tired of mid-task cutoffs — bind your plan so tokenops can predict the window, and wire the read-guard hook so genuinely redundant full re-reads never spend tokens. It starts in observe mode; you flip it to active once you have seen what it would block.

$ tokenops init --detect                      # sniff installed AI clients
$ tokenops plan set anthropic claude-max-20x  # predict the rate-limit window
$ tokenops read-guard hook                    # prints the Claude Code settings.json block

If you are building your own agent or MCP workflow, the deterministic formatters are the reusable part. Wrap a noisy command so its output is compressed — losslessly for errors and changed state — before it ever reaches context, or run the whole thing as an MCP server your agent calls directly.

$ tokenops fmt -- go test ./...            # compress this command's output in place
$ eval "$(tokenops fmt hook --shell zsh)"  # then: export TOKENOPS_FMT=1 to activate
$ tokenops serve                           # MCP server over stdio — tools your agent calls

And if you run a team, the daemon adds per-project and per-session attribution: which project burns the most, and where a specific session went wide. The coach turns that into ranked, dollar- and hour-denominated recommendations — measured against your traffic, not a benchmark corpus.

$ tokenops start            # daemon: proxy + analytics + dashboard
$ tokenops spend --by agent  # which project burns the most
$ tokenops coach prompts     # per-session waste, ranked by tokens / $ / hours

The lesson

For us the honest answer was: you are already lean, and the fashionable optimizations would have bought almost nothing. That is not a disappointing result — it is the correct one, and a tool that can prove it is worth more than one that manufactures a saving. Measure your own usage. The denominator is almost never where the internet says it is.