Running coding agents overnight: what must be true before you sleep

The idea is obvious once you have it. You go to sleep at eleven, the agents work until seven, and in the morning there is a stack of finished, reviewed changes waiting for you. Eight hours a night is more than most teams get from a contractor in a day.

Most first attempts go differently. The agent stops after twenty minutes to ask a question nobody is awake to answer. Or it spends the night retrying the same failing test. Or it finishes something that looks done and isn’t, and the morning goes on figuring out what it actually did. Running agents overnight is not a prompt problem. It is a set of conditions that have to be true before you close the laptop.

Why overnight agent runs fail

An unattended run removes the one thing that quietly holds an interactive session together: you. In a normal session you answer questions, approve commands, notice when the agent is going in circles and say “that’s enough”. At night, every one of those moments becomes either a stall or a mistake.

So the failures sort into three groups. The agent waits for something that never comes (a question, a permission). The agent keeps going when it should stop (loops, runaway cost, a wrong plan pursued for hours). Or the agent stops when it shouldn’t, declaring a task done that isn’t. Each group has a fix, and none of the fixes is “use a smarter model”.

How long can an agent work without help

The honest answer comes from METR, which measures how long a task, in human working time, a model can complete with a given probability. The headline number has grown fast. The number that matters for a night shift is the second line on this chart.

How long a task the best model can finish

Human working time, at 50% and 80% success, log scale

• 50% success
• 80% success

Data as a table

	50% success	80% success
GPT-4, 2023	4 min	0.9 min
Sonnet 3.5, 2024	20.5 min	2.6 min
Sonnet 3.7, 2025	60.4 min	12.1 min
o3, 2025	119.7 min	30 min
GPT-5, 2025	203 min	38.3 min
Opus 4.5, 2025	293 min	49.4 min
Opus 4.6, 2026	718.8 min	69.9 min

At 50% success, the best model on that list handles tasks of about twelve hours. At 80% it is a little over an hour. METR also warns that its current task suite can’t measure reliably above sixteen hours, so the newest models’ top numbers are less certain.

For overnight work that gap is the whole story. One eight-hour task handed over at 11 p.m. is roughly a coin toss. Eight one-hour tasks, each checked and committed before the next starts, give you a high chance that most of them land, and the ones that fail fail early and on their own. The night is not one job. It is a queue.

What has to be true before you go to sleep

Here is the checklist I use. If any item is missing, I’d rather not start the run.

1. The work is a queue of small tasks. Each one fits in about an hour of human-equivalent work and can be merged on its own. Big tickets get split during the day, while you are around to split them well.
2. Every task has criteria the system can check. A command that exits 0 only when the task is done. See acceptance criteria an agent can’t talk its way around.
3. Stopping is gated. The agent can’t end a task until the checks pass. In Claude Code a Stop hook does this, as I describe in why agents stop halfway.
4. Nobody needs to answer anything. Questions and permission prompts are handled up front, or the run is configured so that they are denied rather than waited on.
5. A reviewer that isn’t the writer. A second model, or a fresh context, reads each diff and the check output before it counts as done.
6. The blast radius is small. A sandbox or container, a branch per task, no production credentials, no ability to push to main or deploy.
7. Hard limits. Maximum rounds per task, wall-clock time per task, money per night, and a rule that two rounds without progress parks the task with a note.
8. A morning report. Per task: done, parked, or failed, with the diff, the commands and their exit codes, and the cost.

Most of this is the same discipline you’d apply to any production agent. The night just removes your chance to compensate for missing pieces.

How to run Claude Code unattended

Claude Code’s non-interactive mode is the building block. claude -p "<prompt>" runs a single task and exits with code 0 on success and non-zero on failure, so a script can branch on the result. A few options matter for a night run:

• --permission-mode auto has a classifier review actions instead of you. dontAsk is stricter: anything that would prompt is denied, and only what your allow rules cover runs.
• --permission-prompts none is meant for exactly this situation, when nobody is available. Anything that would wait for a person is denied, Claude is told not to retry it, and tools like AskUserQuestion are removed so the agent can’t stall on a question.
• --allowedTools with permission rules such as Bash(npm test *) lets you allow specific commands rather than the whole shell.
• --max-budget-usd puts a ceiling on spend for the run.
• --output-format json returns the result with the session ID and total_cost_usd, which is most of what a morning report needs.
• --bare skips loading hooks, plugins and CLAUDE.md from the machine. That is good for reproducible CI, but if your Stop hook is the thing keeping the agent honest, don’t use bare mode, because hooks won’t run in it.

Two details from the docs are worth knowing before you write the wrapper. If you stop a run with SIGTERM, Claude Code exits with code 143 and records no result for the interrupted turn. And Stop hooks have a cap of eight consecutive continuations, after which Claude Code ends the turn anyway, so a hook alone is not your loop limit. Your wrapper should count rounds and time per task itself.

Anthropic’s own write-up on harnesses for long-running agents adds a pattern that suits nights well: each session starts by reading a progress file and the git log, checks that the app still runs, works on one feature, commits, and leaves the environment clean for the next session. A night of that is a night of small, recoverable steps.

One task in an overnight queue

• Agent
• Automated check
• Person

Steps as text

Step	What happens
1. Take next task	Step — from a queue written in the day
2. Agent works	Agent — headless, sandboxed, own branch
3. Checks	Automated check — criteria commands run by the system
4. Reviewer	Agent — different model reads the diff
5. Commit or park	Step — limits decide
6. Morning report	Person — diffs, exit codes, cost
Loop	findings go back: back from step 4 to step 2
Loop	next task: back from step 5 to step 1

Bad and good ways to run agents overnight

Some setups look like overnight automation and aren’t.

The worst is one big prompt with “keep working until it’s done” and full permissions. It produces exactly one of three outcomes: an early stop, a long loop or a large diff nobody can review. The second worst is a cron job that runs an agent with no checks, so every morning starts with reading transcripts to find out what happened, which costs more time than the night saved.

The setup that works is boring. A queue prepared during the day. One task per agent run. Checks the system runs. A reviewer. Branches, not main. Limits that park rather than retry. And a short report, so the morning takes ten minutes, not two hours. Security deserves its own line here: OWASP lists prompt injection and excessive agency among the top risks for LLM applications, and an agent reading issue text at 3 a.m. with nobody watching is exactly where both matter. Keep the night shift away from secrets and production, and see guardrails for AI coding agents for the layers.

What a day looks like when agents work at night

Here is a model of one developer’s 24 hours with and without a night queue. The hours are illustrative, not measured, and they assume the queue is prepared during the day and the agents’ work is reviewed by a second model before a person sees it.

A developer's day with and without a night queue

Hours of work happening on the product, illustrative

• Person working
• Agents working
• Nothing happening

Data as a table

	Person working	Agents working	Nothing happening
Person only	8 h	0 h	16 h
Agents in working hours	8 h	6 h	10 h
Agents day and night	8 h	14 h	2 h

The interesting change is not the agent hours. It is what the person’s eight hours become. Less implementation, more writing the next day’s queue: specs, criteria, splitting work into pieces an agent can finish reliably, and settling the questions the night parked. That is a different job, and I think it is a better one. A small team working this way gets most of a second shift without hiring one, and the limiting factor becomes how well they can say what they want.

Questions

Can I leave Claude Code running overnight?

Yes, with claude -p in a script, a permission mode such as auto or dontAsk, --permission-prompts none so nothing waits for an answer, a budget cap, and a Stop hook that blocks until your checks pass. Run it in a sandbox on a separate branch.

How long can an AI coding agent work on its own?

METR’s data shows the best current models complete about an hour of human work with 80% success and around twelve hours with 50% success. For unattended runs, plan around the 80% figure and split longer work into a queue.

How do I stop an overnight agent from running up a big bill?

Set a spend cap such as --max-budget-usd, limit rounds and wall-clock time per task in your wrapper, and park any task that makes no progress for two rounds instead of retrying it.

What should an overnight agent not be allowed to do?

It should not hold production credentials, push to main, deploy, or run destructive commands. Give it its own branch, a sandbox and only the tools each task needs.