You start a refactor at four in the afternoon and close the laptop at six. The next morning the run has finished, or it is still going, or it stopped at 9:40pm to ask a question nobody was there to answer. Three very different situations, and from the outside they looked identical all night.
Anthropic says Claude Opus 5.5 stays on task for 18 or more hours. Take that literally. A run started at the end of one working day is not over when the next one starts. It has been making decisions for eleven hours without you, and the only thing between it and a bad one is whatever you wrote down before you left.
A run that fits inside your day gets supervised. A run that outlives your day gets returned to. Those are different systems, and most teams are still running the first one.
TL;DR
A long-running agent run is one that continues past the point where a person is present, so every decision it cannot make has to wait as recorded state instead of as a prompt in a terminal nobody is reading. Three things have to be true before that is safe: a stop condition the agent applies without you, a waiting-for-human state visibly different from working and from failed, and an inbox one named person opens in the morning. Agents research, execute, test, and report. People set direction, grant authority, and accept the result. Sharkly holds all three on the Task.
What changed on 2026-09-22
Two labs shipped on the same day, and between them they moved both the duration and the price of a run.
| Claude Opus 5.5 | GPT-6 Sol | GPT-6 Luna | |
|---|---|---|---|
| API id | claude-opus-5-5 |
gpt-6-sol |
gpt-6-luna |
| Input / output per million tokens | $4 / $20 | $2 / $10 | $0.10 / $0.50 |
| Cached input | $0.20 read, $5 write | 90% off reads | 90% off reads |
| Context | 1M | 872k | 1M |
Anthropic states Opus 5.5 costs 40% less to run than Opus 5, produces output about 30% faster, has a 128k maximum output, and stays on task 18 or more hours. OpenAI states Sol and Luna are each 50% cheaper than GPT-5.6 promotional pricing; “promotional” is OpenAI’s own word, so that compares against a discounted rate, not a list one. OpenAI also reports a 90% discount on cached input reads for GPT-6 and says changing reasoning effort or tool availability no longer invalidates the cache, which matters most to exactly the runs that last all night.
So a run can now be long and cheap at once. The working day did not extend to match, and neither did anyone’s capacity to read results.
Review inverts
When you watch a run, you are its error handler. You see it open the wrong file and you interrupt. That correction never reaches any log, because it never had to.
Overnight, none of that exists. Every correction you would have made is either a rule the agent already has or a stop. There is no third option. A long-running agent is not an unattended agent that finished. It is an agent that will reach a decision you have to make while you are asleep. Design for the stop, not for the finish.
Anthropic also reports 85% fewer successful boundary-circumvention attempts on Opus 5.5. Lower odds are not a stop condition. A model that is harder to talk out of its instructions still needs somewhere to put a question at 2am.
Three things that have to be true
1. A stop condition the agent can apply without you
Two halves: a hard ceiling the platform enforces, and written conditions the agent applies itself.
The ceiling is configuration. A Sharkly Agent carries a maximum number of parallel running Tasks and a per-Task timeout, set on the Agent rather than per run. Put the timeout above the longest run you want and below the longest run you are willing to pay for. It is a circuit breaker, not a schedule.
The written conditions are the half teams skip. An agent that never stops is not diligent, it is unsupervised.
Stop and wait for a human when:
- a change would touch a file outside the paths named in the Task;
- a check that passed at the start of the run still fails after two attempts;
- the Task description and the code disagree about intended behavior;
- you are about to run a command that writes outside the working directory.
When you stop, leave one comment: what you did, what you need, and the single
question that unblocks you. One question per stop.
Use a long timeout when the Task is a bounded change with tests that can tell the agent whether it is done. Keep it to an hour or two when the Task is exploratory, when the acceptance criteria are still a sentence someone will argue with, or when the run can touch things you would not want changed unreviewed. Approval gates cover where an agent stops even when it is confident.
2. A waiting state that is not the same as working
In Sharkly, Task lifecycle status and Agent working state are separate records. A Task can sit In Progress while the Agent is Working, Waiting for human reply, Waiting for human review, or Error. The run underneath has states of its own: Queued, Dispatched, Waiting for local directory, Running, Completed, Failed, Canceled.
That sounds like bookkeeping until you have eight overnight runs. Without it, a board at 9am shows In Progress for an agent mid-edit and for an agent that stopped eleven hours ago waiting on one answer. You open all eight to find out which is which.
| What you see | What it means | What ignoring it costs |
|---|---|---|
| Working | The Runtime is actively on the Task | Nothing yet |
| Waiting for human reply | The agent stopped and asked | Every minute is idle capacity |
| Waiting for human review | Work is finished and unaccepted | The change is not shipped |
| Error / Failed | The run ended badly | A retry you have not started |
The execution log makes a stop legible the next morning: why a run was queued, when it started and ended, the tool calls and Runtime events, the trigger source, and the failure or cancellation details. That is what you read cold, with no memory of what you asked. See status, logs, and failure signals for what to capture if you build this yourself.
3. An inbox one person opens
A waiting state with no owner waits forever. Overnight runs fail quietly in a way daytime runs do not, because nobody is there to notice the silence.
Sharkly’s Inbox is a personal queue of task activity, and Primary holds the signals that need a person: waiting for your reply, waiting for your review, failed or blocked work, direct mentions, and assignment to you. Run failures and blocked signals go to the assigned person rather than every subscriber, so a failed 3am run lands with someone instead of with everyone, which is the same as nobody.
Two saved Views carry the morning: tasks waiting for review, and tasks assigned to Agents and currently blocked. Name the person who opens them. “The team” does not open an inbox.
The morning pass
Order matters, and it is not the order the board offers.
- Waiting for human reply first. Answering restarts a stopped agent; reviewing starts nothing. If SH-312 has been waiting since 9:40pm, the fastest thing you can do all day is answer in a comment, which enqueues a follow-up run on the same Task.
- Failed and blocked second. Read the execution log title and the technical details before retrying. A single HTTP status is a clue, not a diagnosis.
- Waiting for review third. This is the real queue, and it is the one that grows when runs get cheaper.
- Still running last. Let it continue or cancel it. A canceled run does not resume in place, but the Task and its history stay, so cancel without ceremony when the direction is wrong. Read the log first.
What this does not fix
Longer runs do not reduce review. They concentrate it. An 18-hour run returns one result carrying a night of decisions, and a person still has to read it, judge it, and accept it. OpenAI’s own researchers show where that ends: a median researcher runs more than $600 a day of inference at API prices and the 90th percentile is over $7,000 a day, while the number of people available to read the output stayed the same. We did the arithmetic when OpenAI published it, and nothing in this launch changes the denominator.
Cheaper, longer runs buy more parallel attempts, not fewer decisions. Human review is the bottleneck, and a price cut makes it worse before it makes it better. Automation stops where team judgment is required, and returns a delivery with complete context and inspectable evidence when it does.
FAQ
How long should a per-Task timeout be for an 18-hour model? Longer than the run you want, shorter than the run you would regret. Start at a few hours for ordinary work and raise it per Agent for Tasks that genuinely need a night. The timeout ends a run that is looping; it does not decide how long good work takes.
What happens to a question the agent asks at 2am? It should become a waiting-for-human-reply state and an Inbox item for the assigned person, not a line in a scrollback buffer. If your setup would lose it, close that gap before you extend any timeouts.
Where this leaves you
No vendor ships the part that matters here, because what matters is where the stop lands and who owns the morning. The question is identical on Claude Code, Codex, and everything else, which is why ownership belongs at the task level rather than inside one vendor’s session.
If you already run agents overnight, the test is simple. Open your board at 9am and see whether it distinguishes an agent that is thinking from an agent that has been waiting since last night. If it does not, that is the first thing to fix, and it is the layer Sharkly sits at: the Task holds the goal, the run state, the blocker, the result, and the human decision, from request to release.
