What an Overnight Agent Actually Costs
The expensive part is not the code an agent writes. It is the context it re-reads — so cost grows with turns, not with lines changed.
"Let it run overnight" is one of the more appealing ideas in AI-assisted development. Hand an agent a well-scoped task at the end of the day, review a pull request in the morning.
It is a real workflow. It also has a cost profile that surprises people the first time they look at a bill, because the expensive part is usually not the part they were thinking about.
Where the money actually goes
For a long-running coding agent, the dominant cost is almost never the code it writes. It is the context it re-reads.
A coding agent works by holding a conversation. Each turn sends the accumulated history — the task, the files it has opened, the command output it has seen, its own prior reasoning — back to the model. Every turn re-transmits most of what came before.
This produces a shape worth understanding: cost grows with the number of turns, not the number of lines changed. A task that takes forty exchanges to get right costs far more than one that takes eight, even if the final diffs are identical in size. An agent that reads a large file, gets confused, reads it again, and tries a third approach is billing you for that file three times.
That is why a six-hour session can cost many times a thirty-minute one while producing a similar change. The wandering is the expense.
Four things that make long runs expensive
Vague scope. "Fix the flaky tests" invites exploration across an entire suite. "The checkout.spec.ts timeout at line 240 is flaky under parallel execution; make it deterministic without changing the public API" gives the agent a place to stop. Scope is the single biggest lever, and it costs nothing.
Large files read repeatedly. Agents re-open files as their understanding shifts. A 3,000-line module read five times across a session is five times the tokens. Pointing the agent at the specific module, or splitting genuinely enormous files, has a measurable effect.
Failure loops. An agent that cannot get a test passing will try variations indefinitely. Each attempt costs a full turn with full history. A stop condition — "if the targeted suite still fails after two repair attempts, stop and report" — converts an open-ended spend into a bounded one.
Unbounded autonomy on ambiguous work. Investigations are where budgets disappear. An agent asked to find the cause of a latency spike, with no checkpoint, can spend hours confirming things you already knew. Ask for an initial hypothesis with evidence before it starts implementing.
Practical controls that do not slow you down
Set a stop condition, always. Not a time limit — a completion or failure condition. "Open a draft PR once the targeted tests pass, or stop and report what is blocking you." An agent that stops when it should is the cheapest kind.
Split investigation from implementation. Two bounded tasks with a human decision between them consistently cost less than one long autonomous run, and the output is more reviewable. The decision point is also where you catch a wrong hypothesis before it becomes a wrong diff.
Prefer several small tasks over one large one. Each starts with a clean context. A single session that accumulates four unrelated problems is paying to re-read all four on every turn.
Check in at the point of ambiguity, not on a timer. The costly moments are decisions, not durations. An agent that pauses to ask "should this be handled in the service layer or with a database constraint?" saves more than any scheduled interruption.
Match the model to the task. Not every step needs the most capable model. Reading a file, running a test, or applying a mechanical rename does not. Reserve the expensive reasoning for the parts that need reasoning.
The measurement that matters
Most teams track cost per month. That number tells you almost nothing actionable.
Track cost per completed task, and split it by outcome. What did a merged pull request cost? What did an abandoned session cost? The second number is usually the shocking one, and it is the one you can act on: abandoned work is pure loss, and the reason for abandonment — bad scope, missing context, an ambiguity nobody resolved — is almost always fixable with a better task definition.
Also track how much of your spend happened while nobody was available to intervene. An agent that ran for three hours after hitting a decision it could not make is the single most preventable line item in the bill. That is not a cost problem. It is a supervision problem wearing a cost problem's clothes.
The trade-off, stated honestly
Overnight agent work is worth it when the task is well-scoped, the tests are meaningful, and someone can act on the result in the morning. It is a poor deal when the task is ambiguous, because ambiguity is exactly what an unattended agent handles worst — and it will spend your budget discovering that.
The teams who get good value from long runs are not the ones with the biggest budgets. They are the ones who write tighter tasks, set explicit stop conditions, and stay reachable for the two or three moments where a human decision changes the outcome. Everything else the agent can genuinely handle alone.