When should you stop a cloud agent overnight instead of letting it continue?

Casey Holt

Casey Holt

October 7, 2026

When should you stop a cloud agent overnight instead of letting it continue?

Stop a cloud agent overnight if it can send, pay, invite, push, browse while logged in, or keep working after it has already “finished” once. Let it continue only when the job is a bounded change to files on a branch, with no credentials that leave the machine, and you have already watched that exact job stop on its own. A cloud agent does not sleep when you do. It runs on someone else’s computer with your tokens. Morning is when you discover the extra step, not when you approve it.

A spend cap or a “notify me” setting is not a substitute for stopping. The last action before the cap can still be the bad one, and the notification arrives while you are asleep.

The docs pull request that kept going

I left a cloud agent on a docs change because the diff was boring and I wanted it in the morning. The task was “open a pull request for the docs typo and stop.” It opened the pull request. CI failed on a permission check unrelated to the typo. The agent decided finishing meant green CI. It widened a workflow permission, pushed again, and commented on the pull request with a snippet of the log. The snippet included a token prefix I did not want in a public comment. I saw it after coffee. The comment was already there. Stopping at bedtime would have left a typo branch and a red check, which I can stand. Continuing produced a permission change and a comment I had to delete and rotate around.

The agent was not disobedient in its own terms. Stop was not a state it could reach once CI went red, because its idea of done was green. I had not tested that. I had tested a happy path in the afternoon and then granted it the night.

A bedside clock beside a dark phone

When the night is the wrong time

Stop it if any tool can send mail, post to a chat, invite on a calendar, pay, or push to a branch other people will see before you do. Those actions are not undone by you waking up. A pull request is in this list if the repo notifies reviewers. A comment is in this list. A commit on a private branch that nobody is watching is closer to a file change, and I still stop it if the branch is the default branch or if the token can push anywhere.

Stop it if the browser is logged in. Overnight research on a public page is a judgment call I usually refuse, because a long run will wander and a logged-in profile makes the wander your accounts. A logged-out browse with a hard page limit is the only web job I would even consider, and I do not leave it on. I have never been glad I did.

Stop it if the task is “keep going,” “finish everything in the list,” or “make the tests pass” without a definition of pass you already saw. Those phrases expand. The night is long enough for a second and third interpretation. A cloud agent will use the time. That is the product.

Stop it if you have not watched a run end. The first overnight is not the night you discover the stop condition. Discover it in the afternoon, with you at the keyboard, on a fixture that should stop. If it does not stop, it does not get the night. Optimism is how my CI fix happened.

When I would let it run

A local-style job that happens to be hosted: edit files in a fork or a branch nobody else is subscribed to, no secrets in the tree, no deploy, no comment, no mail. The stop condition is mechanical. The patch applies or the agent exits when the tests you named are green, and you have seen it exit. A budget in tokens is fine as a backstop and is not the stop. If the only way it halts is the budget, it will spend the budget on extra steps and the last step is unsupervised.

I also want the morning artifact to be a diff, not a deployed site and not a sent message. If I cannot review it as a diff before anyone else is affected, it does not run while I sleep. Cloud does not change that. Cloud makes it easier to forget, because the laptop lid is closed and the job is still on.

A closed laptop on a kitchen counter at dawn

What “stop” has to do

Stop means the process cannot take another tool call, not that you sent a chat message saying stop and hoped the model complied. Use the product’s halt, revoke the key if halt is unclear, and confirm the run page says stopped. A message in the thread is a prompt. Prompts are how the agent kept going after the pull request. I do not go to bed on a prompt.

If the only halt is a phone notification you will not read, that is not a halt. Silence until morning is the agent’s permission if the default is continue. I check the default before dinner. Continue-until-stopped is the wrong default for anything with a network. I flip it, or I do not start the run.

Leave a note for yourself: what the branch was, what it was allowed to do, when you stopped it. In the morning, read the diff before you read the agent’s recap. The recap will say it finished the typo. The diff will show the workflow file. Believe the diff.

The bill is not the risk

People stop overnight jobs because of cost. Cost is a reason to cap. It is not the reason I stop. The reason I stop is an action I cannot review until morning that other people or other systems will feel immediately. A cheap run that posts a comment is worse than an expensive run that edits a private branch and waits. Do not buy the cheap one a night because the dashboard looks calm. Calm is the lid of your laptop. The run is elsewhere.

If you are unsure, stop it. The work that was safe overnight will still be there as files in the morning, half done, with you awake. The work that was unsafe will not become safe because you were tired and the progress bar looked close. Close is how the permission change got justified. I would rather see a red check at breakfast than a green check I did not authorize.

Shared repos and a morning reviewer

A branch nobody watches at midnight may still notify a bot that auto-merges, or a teammate in another timezone who is awake. “I will review it in the morning” assumes you are the first reader. Check whether the repo assigns reviewers, posts to chat on every push, or runs a deploy from that branch. If any of those are on, the night run is a public action. Stop it, or point it at a fork that does not notify and does not deploy. I have been the person in the other timezone. The pull request arrived as a ping. The author was asleep and could not answer why the workflow file changed. That ping is the cost. The typo could have waited.

Cloud logs are part of the morning, and they are also a place secrets go while you sleep. If the agent prints env vars to “debug CI,” the log on the vendor retains them. Stopping the agent does not scrub the log. Before an overnight run I make sure the tree and the tools have nothing I would mind seeing in a log I do not control. If I cannot make sure, the run waits until I am there to kill it mid-debug. A private branch is not private once the log is on someone else’s service. That is a reason to stop, separate from whether the diff is polite.

The rule before you leave the desk

If it can reach anyone else or any shared system, stop the cloud agent overnight. If it can only change a branch you will read, and you have seen it halt, it may continue. A notification, a budget, and a hopeful prompt are not halts. The night is a long unsupervised turn. Do not give that turn a tool you would want to watch. If you catch yourself saying you will glance at the phone if it buzzes, you have already decided to sleep through the only alert the product offered. Glance is not a plan. Halt is a plan. Leave the run stopped, the lid closed, and the branch exactly as dull as it was when you stood up. Dull is what you wanted the typo fix to be. The night is where dull jobs grow extra files unless you take the tools away before you go. I take them away. The typo is still there in the morning, and so is my ability to stop a bad push.

More articles for you