← Blog
·4 min read

The $1,800 cron job: when “run it overnight” goes wrong

Stories of overnight agent runs racking up four-figure bills. The fix isn’t fear — it’s a bounded, reviewed queue instead of an open-ended loop with no off switch.

“Just run it overnight” is the most natural idea in the world once you have an agent that can code. Point Claude Code or Codex at your backlog, go to sleep, wake up to finished work. The dream is real — and so is the failure mode that comes with it, which usually shows up as a billing alert.

The cautionary tales have piled up. One widely-shared roundup of overnight-agent incidents reports a developer who burned roughly $1,800 over two nights by scheduling runs in a way that bypassed their subscription and billed the API directly; another whose agent got stuck in a loop and made about 14,000 redundant tool calls; and a “convergence system” that confidently spent its budget generating dozens of copies of the message “you’ve hit your limit” and two actual fixes. Treat the exact figures as reported rather than audited — but the shape of the problem is very real.

The footgun isn’t the agent. It’s the loop with no edges.

Notice what all of these have in common: an open-ended loop, running unattended, with no natural stopping point and no spending ceiling. The agent wasn’t malicious or even especially wrong — it just had no edge to stop at, so it kept going. A loop that runs until something external interrupts it will, on a bad night, run until your card does.

The usual quick fix people reach for — --dangerously-skip-permissions so it doesn’t pause for approval — makes it worse. You’ve removed the one checkpoint that would have caught the runaway. Speed and safety got traded the wrong way.

Bound the work, not just the budget

Budget caps help, but the deeper fix is to give the agent a bounded queue instead of an open-ended goal. The difference:

  • “Keep improving the codebase” is unbounded — there’s always more, so it never stops.
  • “Do the tasks currently assigned to you, then idle” is bounded — when the queue is empty, the work is done.

A finite list of explicitly-assigned tasks is its own stop condition. The agent pulls the next assigned item, does it, marks it for review, and when there’s nothing left, it waits. No convergence math, no “are we there yet” spiral — just an empty queue.

How Lume’s shape avoids it

This is exactly why running agents against a real task list beats pointing them at an open goal. In Lume, an overnight loop pulls only the tasks you assigned to an agent, works each one, and sets it to “ready for review.” The number of tasks is finite and chosen by you, so the run is naturally capped — it can’t wander into a 14,000-call spiral because there are only so many things to do.

And because agents stop at “ready for review” rather than acting further, the morning after is a review queue, not a cleanup. The overnight dream is achievable. It just needs edges — a bounded queue and a review gate — so the only thing that runs out overnight is the task list.

Want a list your agents can pull from?

Lume gives every task an API, an MCP server, and an assignee. Free to start.