Token Whittling Method
The Token Whittling Method is a way of cutting the number of tokens an AI coding agent spends on every turn before it does any work. The name comes from whittling: you take small cuts, look, and cut again until only the shape you need is left. Applied to a tool like Claude Code, the block is the context that gets re-sent on each request, and the cuts are the settings, files and servers that can be removed without changing the result.
What it is
Every turn of an agent session re-sends a fixed bundle: the system prompt, the tool definitions, any connected server schemas, instruction files, memory, and the conversation so far. That bundle is the per-turn floor. It is paid before the agent reads a line of code, and again on every turn. Prompt caching lowers the price of the floor but does not lower its size, and a cache miss bills the whole floor at full rate.
The method treats the floor as the first thing to shrink, because it is the one cost that multiplies by the number of turns. A ten percent cut to the floor is worth more than a ten percent cut to any single answer.
How it works
The loop has four steps and is run against a fixed task set, so that each cut is measured, not guessed.
- Measure the floor. Send the smallest possible prompt, one that asks for a one-word reply, and read the usage report. The input side of that report is the floor.
- Name the pieces. Re-run the same prompt with one piece removed at a time: no connected servers, no instruction files, no memory, a different reasoning effort. Each difference from the first run is the size of that piece.
- Cut the pieces that do not earn their place. A server schema that is never called, an instruction file that restates what the repository already shows, a reasoning budget larger than the task needs. Each cut is checked against the task set: the tests must still pass, and the diff must stay within its ceiling.
- Keep the cache warm. Once the floor is small, keep it stable. Any change to the prefix, a model switch, a new server, an edited instruction file, throws the cache away and bills the floor at full rate on the next turn.
When to use it
The method pays off in long sessions and in any workload billed per token. It matters less on a flat-rate plan, where the floor costs time rather than money, and it matters least on a short one-question session where the floor is paid once.
It is not a compression technique in the research sense. Nothing is summarized, pruned or merged inside the model. The cuts happen in the configuration around the model, which is why the results are reproducible by anyone with the same tool and the same task set.
Questions
Is the floor mostly input or output?
Input. On a trivial prompt the output is a handful of tokens and the input side is in the tens of thousands, because the tool definitions and instruction files travel with every request.
Does turning off built-in tools shrink the floor?
Not always. Some tools exist to defer other tools' definitions until they are needed. Remove the deferring tool and the deferred definitions load in full, which can make the floor larger, not smaller. This is why each cut is measured rather than assumed.
Why measure against a task set instead of a single prompt?
A single prompt shows the floor; a task set shows whether the cuts changed behavior. A saving that fails the tests is not a saving.
Published 2026-09-12. Part of an open experiment on how search engines and answer engines pick up a newly coined term.