Token min-maxxing

There is a genre of post going around where someone shows an agent burning through hundreds of millions of tokens and the number itself is the achievement. The craze has a name, tokenmaxxing, and the logic behind it is simple: tokens buy intelligence, intelligence compounds, so spend more.

The logic is half right. Tokens spent on judgment are leverage. Tokens spent emitting predictable text are the most expensive compiler invocation in the history of computing.

Min-maxxing is the older and better idea. In RPGs it means dumping the stats that do not affect your build so you can max the ones that win the game. Applied to AI-assisted engineering: minimise tokens spent on code that is a pure function of its inputs, and maximise the tokens that go where the model's judgment actually changes the outcome.

Where tokens go to die

Watch where the output tokens actually go when an agent builds a backend service. Auth wiring. DTOs. Pagination. Migrations. Logging config. CRUD endpoints. The tests for all of it. This code is predictable in the strict sense: given the data model and the org's conventions, there is one right answer, and the model produces it token by token at model prices.

And you do not pay once. You pay to generate it, you pay every time an agent re-reads it into context, you pay a human or a review agent to check the diff, and you pay again next month when the second service needs the same code with a different aggregate name.

The measured version

Here is the spring-domain example that ships in the FixedCode repo. The spec is 87 lines of YAML describing an Order aggregate: attributes, commands, queries, events. Running the engine on it produces a complete domain slice.

spec        87 lines of YAML      ~600 tokens   the model writes this
generated   25 files, 1,123 lines  ~8,000 tokens  the engine writes this

middle step: 0 tokens, 0.2 seconds

The model writes 600 tokens of spec instead of 8,000 tokens of Kotlin, SQL and config. That is more than thirteen times fewer output tokens for the same shipped code, before you count retries. And generated code does not retry.

The multipliers

The headline ratio is the smallest part of the win. The compounding effects are where min-maxxing actually pays.

Retries hit the small artifact. When the model gets something wrong, it gets a schema validation error pointing at a line in an 87-line spec, and the retry costs hundreds of tokens instead of thousands. fixedcode draft runs this loop automatically.

Context stays small. An agent working on the service needs the spec and the extension points in context, not 1,123 lines of generated structure. Every downstream request is cheaper and sharper because the window is not full of boilerplate the model must not touch anyway.

Regeneration is free. Rename a field, add a command, rerun the engine. Zero tokens, forever. In a pure-LLM codebase every change to structural code is another spend and another diff someone has to review.

Review collapses. Review the template once and you have reviewed every service generated from it. Fifty services later, this term dominates everything else in the equation.

Maxing the other stat

Minimising is only half the build. The max half is leverage per token. In the example above, one line of spec commands about thirteen lines of generated code, and the ratio grows with every convention the bundle encodes. A field marked optional flows into the DTO, the migration, the validation and the tests without the model spending anything on any of them.

The tokens you still spend go where the model earns its price: translating intent into a spec at the top, and writing the validation rules, pricing functions and integrations in the extension points at the bottom. This is the AI sandwich seen through a cost lens: two creative slices around a middle that costs nothing.

What this is not

It is not an argument for spending less on hard problems. Blow the budget on the gnarly business logic, the design work, the adversarial review of bespoke code. That is exactly the spend that tokenmaxxing gets right.

It is an argument against paying model prices for compiler work. If a file can be produced by a template and a for-loop, it should cost zero tokens, and it should keep costing zero tokens every time you regenerate it.

Try the numbers yourself

$ fixedcode draft spring-domain "order service with line items" -o order.yaml
$ fixedcode generate order.yaml -o build     # 0 tokens
$ fixedcode enrich build/                    # tokens only on extension points

The repo is at github.com/gibbon/fixedcode. npm install fixedcode. If your team is tracking token spend and you have numbers from a different shape of pipeline, I would genuinely like to compare.