Reviewing what comes back

Check three things, in this order: the state it ended in, the deliverable itself, and the receipt. Reading only the summary paragraph is how people accept work that was never finished.

The state it ended in

A handed-off task carries one of these, and they mean exactly what they say:

State	What it means
Making a plan	It has the job and is working out the steps
Working on it	Running
Needs you	Stopped and waiting on you — a question, an approval, or a limit reached
Done	It finished
Couldn’t finish	It ran and failed. This is a real outcome, not a glitch
Turned into a chat	You pulled it back into a chat

Needs you is the one people misread as failure. It isn’t. It waits indefinitely, and while it waits nothing runs and nothing is charged. It resumes where it stopped once you answer.

In a live chat you get the same information as it happens: the stage it’s currently in — planning the run, working in a secure browser, working in the secure workspace, verifying the result — shown according to what the job actually needed, so a short job shows fewer stages than a long one.

A run can also end having produced no answer. That is a genuine ending, and it is shown as one rather than dressed up as a partial success.

The deliverable

Results arrive in five shapes, and which you get depends on what you asked for:

1. The written answer, in the result itself — the finished task shows the result first, not the log.
2. Files it produced, listed with their sizes and downloadable individually.
3. A preview for the common kinds — web pages, CSV, Markdown, source code, images, PDFs and plain text — so you can look before downloading.
4. A page it captured, as a screenshot or as a PDF of the page.
5. A share link, read-only, for showing someone the run. Note that produced files are yours only: they are stripped out of the shared view, so a shared link shows the run and not the downloads.

A website it built is a downloadable set of files you open locally. There is no hosted address to hand around.

Judging it done is mostly mechanical: the artefact you asked for exists, it opens, the numbers in it trace back to something, and web research carries the sources it was read from. If you asked for three of something and got two, that should be stated in the answer — the honest short answer is the intended behaviour, and a padded list is the bug.

The receipt

Every finished task shows a receipt: the total, the spend limit for that run and how much of it was used, and the line behind the total. In a chat, each reply carries a small receipt of its own — what it cost, how long it took, and the engine choice you sent it with, whether that was Auto, Fast, Smart, Max or an exact engine.

A reply that consumed nothing produces no receipt at all rather than a cosmetic zero.

It flags its own failures

When part of a job didn’t work, it says so in the result — which step failed, what it could not save, what it was stopped from doing. Read those lines before the conclusion. They are the most reliable part of the report, and they are why a Done task can still be missing something you wanted.

When it came back wrong

In a chat — just reply. Say what’s wrong specifically (“the second column is using list price, not net”) rather than asking for another attempt; it keeps the material and the context you already gave it.

To stop something mid-flight, use Stop. Work that already finished is kept — files it had already produced are named for you — and it tells you plainly that it stopped before writing a summary rather than presenting a truncated answer as the result.

To pull a handed-off task back, turn it into a chat: it stops the task and asks the same question in a chat instead. Be clear on the trade: what was already spent stays spent, and the work so far is discarded. Do it when the task is on the wrong track, not when it’s merely slow.

When it couldn’t finish, the receipt still shows what happened, and work already performed is already charged — ending badly doesn’t undo it. A run that never got as far as doing anything costs nothing. Before re-sending the same request, change something: give the missing background, name the constraint it tripped over, or ask for less in one go.

Getting a second attempt

Replying is the cheapest fix and usually the right one, because it keeps everything you already gave it. When you want an actual re-run rather than a correction, these are the mechanisms that exist — and it matters which surface you’re on, because a chat can be re-run and a handed-off task mostly cannot.

In a chat, on the newest reply. The reply’s More actions menu offers Retry, which re-runs that same turn — optionally on a different engine tier, chosen from the submenu. Use it when the answer looks like a reasoning miss rather than a missing-context miss. It is a second run, so it is a second charge, and picking a tier there also leaves the chat on that tier — see Switching engines.

In a chat, on any reply. The same menu offers Branch in new chat, which forks a fresh chat carrying the history up to that reply and leaves the original untouched. This is the tool for “go back to where it was still on track and try a different direction” — and it’s better than replying when the chat has already gone somewhere you don’t want it carrying forward. It also gives you the cheaper chat back: a branch taken early carries less history, and history is what makes later turns expensive (Why it cost that much).

When a turn stopped at a limit. It says so and invites you to continue — “Ask me to continue and I’ll pick up from what’s already done.” Take that literally: replying with continue resumes from the partial work rather than starting over. This is the one case where the work you already paid for is genuinely reused.

On a finished task. The result page offers Run this prompt again in chat, and it tells you exactly what that is: “Starts a new chat with your original prompt — a fresh run that may add its own cost, and won’t bring this task’s result or files into the new chat.” So it is a re-do from scratch, not an iteration on what came back. If you want to build on the result, download the file and attach it to a new chat.

On a task that couldn’t finish — nothing. This is the honest gap on this page. A failed task’s result page has no retry, no resume, and not even the Run this prompt again in chat button that a finished one gets. Its outputs, steps and receipt stay readable, but the only way to try again is to start the work over from the Tasks composer. So when a task fails, copy anything useful out of it first, then re-send a changed request rather than the same one.

On a task still going. From More you can Pause and Resume it, and while it is running, paused, or in Needs you you can turn it back into a quick answer — which stops the task and asks the same question in a chat. That last one discards the work so far and the money already spent stays spent, so it’s for a task on the wrong track, not a slow one.