Stop an Overnight AI Agent Burning Your Budget

How do you stop an overnight AI agent from running up your bill?

You stop an overnight agent from burning your budget by capping the tokens per turn and cutting the context it re-reads on every loop, not by trusting a wall-clock timeout. The trap people fall into is mental: they picture an agent like a cron job that costs a fixed amount per hour. It isn't. An agent bills by the token, and an unattended loop that keeps reading files, re-reading its own transcript, and dumping command output back into the context window can compound a small per-turn cost into a genuinely alarming morning surprise. I build token tooling for a living, and the "I left it running and woke up to a $300 bill" message is one I get often enough that I stopped being surprised by it. The numbers are almost never explained by the agent doing a lot of work. They're explained by the agent re-reading the same bloated context across dozens of turns, because that's how an agentic coding loop is built: every step sees the whole transcript again. So the question isn't "how long did it run." It's "how big was each turn, and how many times did it re-pay for the same junk." Get those two numbers down and overnight runs become boring instead of frightening.

Why does an unattended agent cost more than you expect?

It costs more than you expect because the bill grows with the square of a sloppy session, not linearly with time. Here's the mechanism, because the mechanism is the whole story. On every step of an agent loop, the model re-reads the entire conversation so far. A 6,000-token file the agent read on turn 2 isn't billed once — it's billed again on turns 3, 4, 5, and so on, for as long as it sits in the window. A 40-turn overnight session that accumulates junk early pays for that junk forty times. This is the same re-read multiplier I dig into in reduce AI coding agent token usage; overnight runs just make it dramatic because nobody's there to reset the context. Put rough numbers on it with published rates. Per million tokens (MTok):

Model	Input / MTok	Output / MTok
Claude Opus 4.8	$5	$25
Claude Sonnet 4.6	$3	$15
Claude Haiku 4.5	$1	$5

GPT-5.5 sits at $5 input / $30 output per MTok for comparison — the wider table lives in LLM API token pricing. Now picture an Opus session that lets its context drift up to 120,000 tokens and then runs 40 more turns at roughly that size. That's about 4.8M input tokens re-read across the night — around $24 in input alone, before a single output token, and most of it paying to re-read context the agent didn't need a second time, let alone a fortieth. Prompt caching softens this: cached input reads bill at roughly 10% of the normal rate, so the stable prefix of your context gets a 90% discount. But caching only helps the part that doesn't churn. An overnight agent that keeps appending fresh file dumps and command logs keeps invalidating the cacheable tail — so the discount applies to less and less of the window exactly as the window grows. Caching is a real lever, but it won't save a session that's busy poisoning its own cache.

What actually drives the overnight spend?

Three things drive it, and none of them is "the agent worked too hard." They're all context bloat that gets re-read on every loop. Eager whole-file reads. Left alone, an agent reads whole files to use one function. A 500-line source file is roughly 5,000–7,000 tokens, and an unattended loop will happily read a dozen before it does anything. Each read then rides along in the window for the rest of the night. Raw command output. A failing test run can dump 15,000 tokens of stack traces into the transcript. The agent needed the failing assertion — maybe 50 tokens. The other 14,950 get re-read on every subsequent turn. This is the single biggest overnight surprise multiplier I see, because a flaky test in a loop can re-dump that wall of output again and again. Output filtering is the direct counter. The MCP manifest. Every connected MCP server re-advertises its full tool schema on every turn, used or not. Overnight, that's a fixed per-turn tax multiplied by however many turns the loop runs. Lazy-loading the schemas — sending them only when a tool is actually called — removes the tax entirely. The pattern across all three: the cost isn't the answer the agent produced. It's the noise it carried, re-billed turn after turn after turn.

How to cap an overnight run today

Cap it in two layers: hard guardrails on the account, then token discipline on the context. The guardrails stop catastrophe; the discipline stops slow bleed.

Set a hard spend limit at the provider. Both Anthropic and OpenAI let you set monthly usage limits and billing alerts on the API account — do this first, because it's the only thing that can't be defeated by a runaway loop. The Anthropic API limits and OpenAI usage limits controls are the floor under everything else. A wall-clock timeout is not a budget cap; an agent can spend a lot in a short time.
Reset the context between tasks. If your overnight job is several independent tasks, don't let one giant transcript drag across all of them. Start each fresh so the re-read pool stays small. This single habit removes most of the quadratic blow-up.
Make it search, not read. Replace "read the auth module" with "find the function that validates the JWT." Semantic code search pulls the three relevant chunks instead of every file in the directory — typically a 5–10x cut on retrieval, the biggest line item in most sessions. The trade-offs are in context engineering.
Filter command output before it lands. Prefer git status --porcelain over bare git status, pipe type-checks through a grep for errors, use terse test flags. On a failure-heavy overnight run this alone can be an order-of-magnitude cut.
Prune MCP to what the job needs. Disconnect servers the overnight task won't touch, or lazy-load their schemas so the per-turn manifest tax disappears.

Do steps 1 and 2 even if you do nothing else. They're the difference between "a bad night cost me a few dollars more than usual" and "I'm emailing support about a refund."

Where does Tokenade fit?

Tokenade automates the context-discipline half of that list so an unattended agent stays lean without you babysitting it. It installs into Claude Code (and Cursor, Codex, Copilot, Windsurf and the rest) and sits between the agent and your tools: it serves semantic code search instead of whole-file reads, filters noisy command output down to the lines that matter, compresses large files to skeletons, and lazy-loads MCP tool schemas so the manifest tax goes away. A savings dashboard shows the tokens and dollars it actually saved overnight — so the next morning you see proof, not a faith-based claim. It's source-available under MIT, which matters for something that sits in your context pipeline and runs while you're asleep — you can audit exactly what it sends. Free up to about 10M tokens/month; Pro is $19.90/mo excluding tax in the US (€19.90/mo TTC in France) with unlimited machines. If you're comparing options, best Claude Code token optimizers puts the field side by side. It does not replace the provider spend cap. Set that anyway. Tokenade keeps the bleed slow; the account limit is your hard stop.

What goes wrong (anti-patterns)

The biggest mistake is treating time as the budget dial. It isn't — tokens are. Watch for these:

"I set a 6-hour timeout, so I'm safe." A timeout caps duration, not spend. An agent stuck in a tight error-retry loop can burn through a lot of money inside that window. Cap tokens and set a provider spend limit; treat the timeout as a backstop, not the control.
Letting one transcript span the whole night. A session that wanders across five tasks builds a window that costs more to re-read than the work was worth. Reset between tasks.
Ignoring the failure loop. The classic overnight disaster is an agent that keeps re-running a failing command and re-dumping its full output. Filter the output and add a retry ceiling, or that one flaky test funds your provider's quarter.
Assuming caching covers you. Caching only discounts stable context. An agent that keeps appending fresh dumps invalidates its own cache as fast as it builds it. Clean the context first; the cache discount compounds after.

See also: