The Five Ways AI Agents Burn Your Token Budget

A practitioner’s confession, with the log files to back it up. Pull up July 10 in my logs: 52 agent sessions across six projects. 7.3 million tokens of output. 117 million tokens read fresh into context, 1.4 billion if you count cache hits. That’s one day. A heavy one, but not the record. I’m not confessing the total. The total is what a small AI engineering team costs to run, and that’s exactly what my setup is: leads, builders, researchers, critics, some working while I sleep. The confession is in the line items. Because when I go through those 52 sessions, they split cleanly into two piles: tokens I’d spend again tomorrow, and tokens I still regret. Here’s the distinction almost every token-cost conversation misses. People count tokens the way dieters count calories, as if fewer is automatically better. But my healthiest engineering days are often my heaviest. What separates a good token from a bad one isn’t the price. Burned tokens are spent by your failures. Productive tokens are spent by design. After months of reading my own logs, I know my regrets by their shapes. There are five. Burn Pattern 1: The Failure Loop The symptom: The agent proposes version A. It breaks. It proposes version B. That breaks differently. It proposes A again, with complete confidence, as if for the first time. My worst one is on the record: an activity-detection API whose dependencies my agent upgraded and downgraded in an oscillating loop, burning an astronomical number of tokens while converging on nothing. I wrote about it last year. I’d like to tell you it was the last loop I paid for. My logs say otherwise. The cause: No memory of failed attempts, no bound on retries, no external check forcing the loop to terminate. The model isn’t stupid. It’s stateless. Without structure, every retry is a fresh guess dressed up as a strategy. The fix: A retry bound the agent doesn’t control. My global config carries a rule I paid dearly to learn: Two-Strikes: if the first fix attempt fails, STOP. Research conventional solutions. Present options ranked by simplicity. Never retry blind: the loop doesn't get to vote on its own continuation. Burn Pattern 2: The Haystack Tax The symptom: You ask how authentication works. The agent greps, gets 40 matches, and starts reading entire files. Thousands of tokens later it answers, having ingested your codebase’s greatest hits to locate two functions. I watched my agents do this daily until the frustration turned into a side project: I built and open-sourced a semantic code-search tool specifically because grep noise was eating my context windows. Returning the ten relevant functions instead of forty files measured out to roughly 10x less context per question. The cause: Retrieval that returns containers instead of the thing you asked about. Agents pay per token to read, and naive search makes them read the haystack. The fix: Make the needle findable. Index the code semantically if you can. Even without tooling: scope the question, point at the directory, pass file paths instead of file dumps. Burn Pattern 3: Frontier Models on Grep Duty The symptom: Your best, most expensive model is renaming variables, reformatting JSON, and searching logs. It does this perfectly. So would a model a tenth the price. This one embarrassed me personally. Yesterday I audited the configuration of 50-plus skills and agents in my own setup, mine, the ones I wrote, checking which model each was assigned. Frontier-model defaults were everywhere, sitting on jobs a small fast model handles identically. The wrong-tier assignment wasn’t the exception. It was the default I’d never questioned. The cause: “Best model” feels like the safe choice, and nothing in the workflow ever surfaces the waste. Mechanical work can’t tell the difference between genius and competence. The fix: Assign by seat, in writing: frontier models for judgment calls, mid-tier for building against a spec, small models for retrieval and mechanical transforms. Then audit, because your defaults drift. Burn Pattern 4: Groundhog-Day Sessions The symptom: Every session opens with the same expensive ritual: re-explaining the project, re-discovering the architecture, re-reading the same files, re-litigating decisions that were settled last Tuesday. This differs from the failure loop: nothing is broken. Every individual read is reasonable. You’re just paying, again, for context you already bought yesterday. The cause: Treating the context window as long-term memory. It’s RAM. It evaporates. If a decision lives only in a conversation, you will pay to re-derive it, every session, forever. The fix: State on disk. In my setup, this eventually became automation: a hook that writes a checkpoint file (phase, last completed step, next action, open questions) before context gets compacted, and reads it back on resume. I built that hook after one too many mornings spent interviewing my own agents about my own project. Burn Pattern 5: The Beautiful Diff Nobody Asked For The symptom: You asked for a bug fix. You received the bug fix, a refactored module, a new abstraction layer “for flexibility,” and three features nobody requested. All beautifully implemented. All destined for deletion. The cause: Agents are completion machines. Unconstrained, they generate the most impressive-looking diff, not the smallest correct one. Every unrequested line costs three times: once to generate, once to review, once to remove. The fix: Scope is part of the spec. My config says it bluntly: “no features beyond the ask, no speculative flexibility, no single-use abstractions.” That sentence exists because I paid for its absence, repeatedly. Pair it with a review gate that treats unrequested changes as defects, not bonuses. Where I Deliberately Spend More Here’s the part the calorie-counters get wrong. Fixing the five burns didn’t shrink my token bill. It freed budget for the spending that actually buys something, and this is the pile I’d defend line by line. Independent critics. Every substantial piece of work in my pipeline gets reviewed by a fresh agent that has no idea how the work was made, and for anything important, more than one, each looking from a different angle. The drafts of this very article went through four of them. From a calorie-counting view that’s pure overhead; the work was already “done.” It’s also the highest-return spend in my entire setup. A critic that stops one bad merge pays its own token bill many times over. Planning before code. Tokens spent producing a written plan (options, trade-offs, locked versions and constraints) before any implementation. I learned this on a real project: skipping the plan doesn’t skip the cost, it moves the cost downstream and multiplies it. My standing rule is that no code gets written until a plan is on the table, and the tokens that plan consumes are the cheapest correctness I ever buy. The plan is the cheapest place to be wrong. Parallel attempts under uncertainty. When the right approach is genuinely unclear, I don’t iterate one agent through three sequential guesses. I spawn several on different approaches at once and judge the results, five research agents on five angles, or three implementations of the same risky function. Triple the generation cost, a fraction of the wall-clock. The comparison itself is information no single attempt produces. All three have the same signature: tokens spent on purpose, at a chosen time, with a defined payoff. Nobody chooses a failure loop. That’s the whole taxonomy. Burned tokens happen to you. Productive tokens are a decision. The Bottom Line Stop asking how many tokens you spent. Ask who decided to spend them. If the answer is “my process, by design” (a critic, a plan, a parallel probe), that’s not burn. That’s the product. If the answer is “nobody, it just happened” (a loop, a haystack, a Groundhog-Day morning), that’s the regret pile, and it doesn’t shrink by spending less. It shrinks by fixing the process that spends without asking. Get the five burns under control. Then spend more than ever, on purpose.