---
title: When it takes too long
description: 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

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](/docs/troubleshooting/it-stopped-early). 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

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](/docs/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

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

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

**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](/docs/when-a-run-fails) says the same; better repeated than found on a
receipt.

## 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

- **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](/docs/checking-its-work).