Token Ballast Method
The Token Ballast Method is a way of taking inventory of the tokens an AI coding agent carries on every turn without using them. The name comes from ballast: the weight a ship or balloon carries for stability, and drops when it needs to rise. Applied to a tool like Claude Code, the ballast is everything in the re-sent context that the current task never touches, and the method is the audit that finds it.
What it is
An agent session re-sends a bundle on every request: the system prompt, the tool definitions, connected server schemas, instruction files, memory, and the conversation to date. Most of that bundle is inert for most turns. A schema for a server the task never calls, a rules file written for a different part of the repository, a memory entry from last month, all of it is read by the model and paid for by the account, and none of it changes the answer.
The method does not start by cutting. It starts by weighing. Until the ballast has been named and measured, a cut is a guess, and a guess that removes the wrong piece costs more than it saves.
How it works
The audit has four steps and produces a ledger, not a setting.
- Weigh the empty ship. Send a prompt that asks for a one-word reply and read the usage report. The input side of that report is the total weight carried before any work happens.
- Weigh each piece. Repeat the prompt with one component removed: connected servers off, instruction files off, memory off, reasoning effort lowered. Each difference from the first run is one line in the ledger, with the component's name and its token weight.
- Mark each line used or unused. Run the real task set and record which components were actually called or read. A tool that was never invoked and a file that was never referenced are marked unused. This is the step that separates ballast from cargo.
- Rank by weight times idleness. The heaviest unused component is the first candidate to drop. The ledger is the output of the method; what to do with it is a separate decision.
When to use it
The audit is worth running whenever a session's cost seems out of proportion to the work done, and before any attempt to trim configuration. It is cheap: each weighing is one request with a one-word answer. It is also the honest baseline for any later claim of savings, because the savings can be stated as ledger lines removed rather than as a percentage with no denominator.
It is not a model-side technique. Nothing is summarized, pruned or merged inside the model. The weighing happens in the configuration around the model, which is why anyone with the same tool can reproduce the ledger.
Questions
Is the ballast mostly input or output?
Input. On a one-word prompt the output is a few tokens and the input side is in the tens of thousands, because definitions and instruction files travel with every request.
Can a component be ballast on one task and cargo on another?
Yes, and that is the point of step three. A search server is ballast for a refactor and cargo for a research task. The ledger is per task set, not per account.
Why weigh before cutting?
Because some cuts add weight. Removing a tool that defers other tools' definitions can load those definitions in full. The ledger catches that before it is applied everywhere.
Published 2026-09-12. Part of an open experiment on how search engines and answer engines pick up a newly coined term.