How Long to Let an AI Coding Agent Run Unattended

Ask how long to let an AI coding agent run unattended and you will get numbers back: twenty minutes, an hour, until the tests pass. All of them are guesses dressed as policy, because time is not the variable that determines whether an unattended run hurts you.

The variable is how much damage the agent can do before you look, and how cheaply you can undo it. Get those two right and a two-hour run is fine. Get them wrong and four minutes is enough to lose an afternoon.

Why the clock is the wrong unit

Two runs of identical duration are not comparable. An agent refactoring test fixtures in a scratch branch for forty minutes is doing something almost entirely safe. An agent with database credentials and deploy access doing "the same forty minutes" is a different category of event.

Duration only becomes a useful proxy when everything else is held constant, and in practice nothing is. What changes between runs is scope: what the agent can touch, what happens automatically when it finishes, and whether you can get back to where you started.

So set an unattended budget from those three, and let the duration fall out.

The three questions that set the budget

1. What can it write to?

List the destinations, not the intentions. An agent's stated task is irrelevant to what it is able to do.

• Working tree only, uncommitted: safest tier. Recovery is git checkout .

• Its own branch, committed: still cheap. Recovery is deleting a branch.

• Shared branch or main: expensive. Recovery involves other people.

• Anything outside the repo, meaning databases, deploys, third-party APIs, cloud config: this is the tier where unattended stops being reasonable without hard scoping.

Most teams never enumerate tier four, and it is usually reachable by accident through a script the agent found in the repo. The general shape of that risk is covered in giving an AI coding agent access to your terminal.

2. What happens on its own when the run ends?

An agent that stops with a diff waiting for you is fundamentally different from one whose commit triggers a pipeline that deploys.

If any automation fires after the agent finishes, the unattended window does not end when the agent stops. It ends when the last automated consequence lands. That is the window you actually have to reason about.

3. How long does undo take?

Time the recovery, not the failure. Reverting a branch is seconds. Restoring a database is a process with a runbook, a restore window, and a conversation with whoever depends on it. If your undo path takes longer than the run itself, you were not supervising, you were gambling. There is a fuller version of this in rolling back a bad AI coding agent change.

A practical budget

Here is the mapping I use, with duration as an output rather than an input.

The rows that say "do not leave it" are not about trust in the model. They are about the recovery cost being borne by people who did not choose to run the agent.

Checkpoints beat timers

A timer that stops an agent at 30 minutes stops it at an arbitrary point, often mid-refactor, which leaves a codebase in a state that is worse than either finishing or never starting.

Checkpoints are better because they create resumable states. Practically:

• Have the agent commit at each completed sub-task, with a message describing what changed. A commit per logical step turns a long run into a list of revertible units.

• Ask for a written plan before execution and read it. Two minutes reading a plan removes most of the failure modes that produce a long wrong run, which is the argument in reviewing an AI agent plan before it runs.

• Define a stop condition in the task itself: what "done" is, and what to do when blocked. "Stop and report" is a valid instruction, and agents follow it more reliably than they follow "do not guess".

• Give it a budget it can observe, such as a maximum number of files to touch, and ask it to stop and summarise on exceeding it.

What actually goes wrong on long runs

Three failure modes account for nearly everything.

The loop. The agent tries a fix, the test still fails, it tries a variation, and it circles. Long unattended windows are where this burns the most, since nothing interrupts it. The tells and the exits are in an AI coding agent stuck in a loop.

Scope drift. It fixes the bug at minute six and spends the next fifty minutes improving things nobody asked about. The diff arrives correct and unreviewable, which in practice means unmergeable.

Confidently wrong groundwork. An early incorrect assumption gets built on for an hour. Everything after it is internally consistent and wrong, and this is the one that costs the most to unpick because the code looks fine.

All three are cheap to catch at minute five and expensive at minute fifty. That asymmetry is the real argument for checkpoints, and it is worth noting against the backdrop of Linear's published data showing agent-connected teams opening around 65 pull requests a week: the volume is already high, and unreviewable long runs make it higher without making it better.

A workable default

For most people on most days: own branch, commits at each step, no deploy automation, and a look every 15 to 20 minutes for the first few runs on a new codebase until you have a feel for where that particular agent goes wrong.

Then extend. The number that matters is not how long you can leave it. It is how quickly you can tell that leaving it was a mistake.

FAQ

Can I let an agent run overnight?

Only in the top row of that table: a scratch branch, no automation downstream, and no external writes. The problem with overnight is not the model, it is that the feedback loop is eight hours long, so a wrong turn at minute three costs you the whole night.

Should the agent be allowed to commit on its own?

Yes, on its own branch. Commits are what make a long run recoverable in pieces. What it should not do unsupervised is merge, push to a shared branch, or trigger anything that deploys.

Does a bigger context window let it run longer safely?

No. Context capacity affects how much it can hold, not how correct it stays or how reversible its output is. Those are the constraints that set the budget.

How do I know if my unattended runs are working?

Track how often you throw the output away. A high discard rate on long runs means your scoping is wrong, not that the agent is bad. Shorten the leash, tighten the task, and the discard rate usually drops sharply.