How to cut Claude Code token usage (without a proxy)

July 10, 2026 · Tokeasy

If you run Claude Code all day, you have felt it: the "usage limit reached" wall, or an API bill that looks nothing like the amount of code you actually shipped. The instinct is to blame the model for being chatty. That's rarely where the tokens go.

We spent a while reading raw agent transcripts — not the pretty final diff, the full sequence of tool calls — and the pattern is consistent. The model's own reasoning and code generation is a minority of the token spend. The majority is plumbing: the mechanical work of finding files, reading them, and editing them. And almost none of that plumbing is as efficient as it looks.

Where the tokens actually go

Four patterns account for most of the waste in a typical session:

1. Full-file reads for one function

The agent needs to see renderInvoice. The default read tool hands it the entire 2,400-line file. Those 2,400 lines get written into the context window, then re-read on every subsequent request in the session. You didn't need the file; you needed forty lines and the signatures around them. You paid for the whole thing, repeatedly.

2. Grep → read → read → read chains

Finding where something lives is a multi-step ritual: glob for candidate files, grep for the symbol, then read each hit in full to get context. Four or five round-trips, each one a full request with the entire accumulated transcript attached, to answer a question a single ranked search could have answered once.

3. Failed exact-match edits

String-replacement edit tools demand an exact match on the surrounding text. A single trailing space, a smart quote, a tab-vs-spaces difference, and the edit fails. The agent's recovery is to re-read the file to re-anchor, then retry the edit — sometimes twice. Every failed edit is a wasted call plus the re-read it triggers.

4. Log and test-output floods

The agent runs the test suite. A hundred kilobytes of pytest output — mostly passing-test noise and repeated stack frames — gets dumped straight into context. The one failure that matters is in there somewhere, now surrounded by 98KB of tokens you're paying to carry for the rest of the session.

Why token-stripping proxies make it worse

The popular fix is a proxy that sits between the agent and the model and compresses or strips tool results — truncating file reads, dropping "unimportant" lines, summarizing logs. On paper each call gets smaller. In practice, the cost per completed task often goes up.

The reason is simple: the agent is a closed loop reacting to what it sees. Strip information out of a tool result and the agent notices something is missing — a function body it needs, a line of a stack trace, a config value — and it does the rational thing. It calls the tool again to get the part you removed. You've now paid for the original call, the stripping, and the re-fetch. Multiply that across a task and the round-trips you added dwarf the tokens you saved on any single message.

Tokens-per-call is the wrong metric. It rewards exactly the tools that cause the most re-fetching. Cost-per-task is the only number that reflects what you actually pay.

What actually works: fewer round-trips

The durable win isn't smaller messages, it's fewer of them. You attack the four patterns at the source:

• Ranked search with context, in one call. Instead of glob + grep + N reads, a single search that returns ranked matches, the surrounding context lines, and which files import the match. The agent gets its answer in one round-trip instead of five.
• Structure-aware reads. Return the file's shape — imports, types, signatures — with long function bodies stubbed out, and let the agent ask for a specific body only when it needs it. It sees a 2,400-line file's architecture in a couple hundred tokens.
• Edits that tolerate drift and validate themselves. Fuzzy-matched edits that survive whitespace and quote differences, batched across files, with a syntax check after applying. No failed-edit-then-reread loop, because the edit lands the first time and never ships something broken.
• Bounded log digests. Read test and build output as a digest that keeps every failure verbatim and crushes the repeating noise — with a receipt of what was elided and a way to pull any of it back exactly. A 100KB run becomes ~2KB the agent can use.

A checklist you can apply today (buys you nothing to try)

None of this requires a product. If you're driving an agent by hand or writing your own tools:

1. Prefer targeted reads. Ask for a symbol or a line range, not the whole file. Re-reading the same big file is the single most common waste.
2. Search before you read. One good search beats a chain of speculative reads.
3. Batch your edits and normalize whitespace before matching, so a stray space doesn't cost you a retry.
4. Never pipe raw test output into the model. Filter to failures first.
5. Start fresh sessions for unrelated tasks. A stale transcript is re-read, in full, on every call — old context is a recurring tax, not a one-time cost.

Where Tokeasy fits

Tokeasy is that checklist packaged as ten drop-in tools — ranked code_search, AST-stubbed code_read, batched validated code_edit, bounded log_read, one-call git_context, and more — for Claude Code, Codex, Cursor, Windsurf (via MCP) and OpenClaw. It runs entirely on your machine; there's no proxy between you and the model and your code never leaves the box.

On our benchmark suite — five real repository tasks, each run to completion — it cut total cost 19.8% versus stock Claude Code, and it was the only configuration that came in cheaper than the baseline on all five tasks. The token-stripping tools we tested lost to the plain baseline on cost per task, for exactly the re-fetch reason above. Those numbers are from our suite and depend on your workload; the point that generalizes is the mechanism, not the percentage.

claude mcp add tokeasy -e TOKEASY_LICENSE_KEY=*** -- npx -y tokeasy