When it takes too long
The limits that stop a run that is going on too long, what a stalled task looks like, what you can do about it, and what any of it costs.
Runs are bounded, but not in the same way. A single turn in a chat is stopped by time, cost or size — whichever it reaches first. A handed-off task has no time limit at all; what brings it to a halt is the limit you set on it, checked between steps. That distinction is the whole page.
A single turn in a chat is capped
Section titled “A single turn in a chat is capped”A chat turn cannot run indefinitely: it stops on the first of a wall-clock limit, a fixed cost ceiling, a size ceiling, and a cap on how many steps it may take. So a chat that feels slow is bounded — it will end on its own, with a note saying which limit it hit and an invitation to continue.
The four ceilings, how to tell which one you hit, and what to do about each are on It stopped before it finished. The rest of this page is about the case that page does not cover: handed-off work, which is not capped by time at all.
A handed-off task has no time limit
Section titled “A handed-off task has no time limit”There is no deadline on a task. It keeps working as long as it has work to do — the result page even tells you it “keeps running if you close this tab.”
What stops it is that run’s spend limit: when the total is found over the limit between steps, the task moves to Needs you and waits. Two qualifications, both real: the check looks at money already spent, so it cannot prevent an overrun, and a run that finishes on its own is never limit-checked at all. Each individual turn inside the task is still bounded by the same fixed per-turn ceilings, not by your number. Read Spending limits for the detail.
So a long-running task is usually not stuck. Check the spend against its limit first.
When it is genuinely stuck
Section titled “When it is genuinely stuck”A task whose connection stalls is retried automatically a couple of times. If it still does not recover it goes to paused — not failed — and tells you why:
The model’s connection stalled while working on this task and didn’t recover after a couple of automatic retries. This is a temporary upstream issue — resume to try again.
Paused with a message means something broke and the work is intact; Resume is the right action. A task that dropped out mid-handover is also revisited automatically, so one that looks frozen for a minute is often picked back up on its own.
What you can actually do
Section titled “What you can actually do”Everything here is a real, shipped control:
- Stop a chat run. While a run is in flight the send button is replaced by Stop. Finished work is kept, files already produced are named for you, and it says plainly that it stopped before writing a summary rather than passing a truncated answer off as the result.
- Pause and resume a task, both on the result page. Resume on a stalled task clears its retry count and starts it ticking again.
- Answer a Needs you task. It waits indefinitely, charging nothing, and resumes where it stopped.
- Turn a task back into a chat when it is on the wrong track rather than merely slow. The trade: what was spent stays spent, and the work so far is discarded.
Two things you cannot do, so you do not go looking:
- You cannot send a follow-up mid-run. There is no send button to press — Stop first.
- There is no “re-run this task” button. For a stalled task, Resume is the retry. For one that finished wrong, the move is a follow-up in chat — a fresh run with its own cost that does not bring the old result or files with it.
What it costs
Section titled “What it costs”You are charged for the work that ran — for a run cut short by a limit and for one that failed alike. Billing happens step by step, so anything that finished is already paid for. A turn that consumed nothing costs nothing.
There is no refund — not for a timeout, a stall, or a result you cannot use. A paused or failed run’s receipt still shows what happened, and the work it did stays charged. When a run fails says the same; better repeated than found on a receipt.
Don’t wait for an email
Section titled “Don’t wait for an email”Settings has a switch called “Email me when a task finishes.” It does not send an email. The preference is stored and nothing sends anything. Until that switch works or goes, the task list is the only place a finished task announces itself.
Deciding whether to wait
Section titled “Deciding whether to wait”- Long, spend well under the limit — it is working. Leave it.
- Long, spend near the limit — expect Needs you shortly. Decide in advance whether to raise the limit or take what it has.
- Paused with a message — resume it.
- Needs you — waiting on you, costing nothing while it waits.
- Same step for a long time with nothing accruing — the stalled shape. Resume; if it stalls again, turn it into a chat where you can see each step.
If the run finished but you are unsure whether the result holds up, that is a different question — see Checking its work.