---
title: When a run fails
description: You are charged for work that actually ran, even when nothing useful came back. There is no refund. Here is exactly what you keep and what you pay.
---

**You are charged for work that actually ran — including when the run failed and
produced nothing you can use — and there is no refund.** That is the whole answer, and
it belongs in the first line rather than the last section.

What softens it is narrower and real: a run that consumed nothing costs nothing, partial
work is kept rather than thrown away, and you always get the receipt.

## Why a failed run still costs something

A run is not one purchase. It is a sequence of steps, and each step that actually ran was
work that was actually done. By the time a run fails, the earlier steps have already
happened. Charging for them and telling you so is the honest arrangement; the alternative
would be to hide the cost somewhere else.

So a task that ends in **Couldn't finish** can still carry a real charge, and that charge
is itemized on its receipt exactly like a successful one.

## When you are not charged

**A run that consumed nothing.** If no work was billed, there is no charge and **no
receipt at all** — you will not see a `$0.00` line. No receipt means nothing happened.

**A run stopped by a limit, at the point of stopping.** When a run is cut short by a
spending ceiling or a time limit, the work already done is billed and the stopping itself
adds nothing.

**A cancelled checkout.** Backing out of a top-up charges nothing at all — see
[Topping up](/docs/topping-up).

## What you keep

Failure is not erasure. When a run stops early, whether it hit a limit, failed, or you
stopped it yourself:

- **Files it already finished are kept.** They stay under the run's outputs and remain
  downloadable.
- **The partial work is still there.** A run that got most of the way through a document
  hands you the part it wrote.
- **You get the receipt.** What was charged, how long it took, and which engine choice
  was in force.
- **You can often continue.** A run stopped at a spending ceiling can be resumed from
  where it got to, rather than started over.

A real run that reached its limit said exactly this:

> I stopped here because this turn reached its spending limit for a single turn. You were
> only charged for the work that actually ran. Ask me to continue and I'll pick up from
> what's already done.

That is the behaviour to expect: it stops, it tells you why, it keeps what it made, and
it offers to go on.

## Runs that report their own shortcomings

A run can also succeed and still tell you what it could not do. A completed research task
closed with *"Two things to flag honestly…"* and then listed what it had failed to
achieve, including work it had been unable to finish because of spend limits.

Read that section when it appears. A run that hands you a result *and* a list of caveats
is more useful than one that quietly presents partial work as complete — but it does mean
the caveats are where the important information often is.

## Refunds

There is no refund path, and we are not going to imply one.

- Money spent on work that ran is not refunded, whether or not you found the result
  useful.
- Unused balance cannot currently be withdrawn.
- There is no goodwill-credit mechanism inside the product.

We would rather write this down than let a "contact us for a refund" hint set an
expectation the product cannot meet.

## How to keep a failure cheap

The controls that actually help are all set before you send:

- **Set the spend limit low on anything exploratory you hand off.** Handed-off work is
  the path where the number you set is actually read, so a low limit is the cheapest
  place to change your mind — it stops between steps rather than preventing an overrun,
  and it says nothing about a job that finishes in one push. **In a chat, setting it low
  does nothing at all**; a chat is bounded by a fixed per-turn ceiling you cannot change.
  [Spending limits](/docs/spending-limits) is precise about both.
- **Try the work as a chat first.** A short exchange tells you whether the request is
  understood before you hand off a long unattended run.
- **Say what "done" looks like.** Most expensive failures are runs that worked hard on the
  wrong thing — [Writing a good request](/docs/writing-a-good-request) is about exactly that.
- **Check the first receipt.** One real run on your kind of work tells you more about cost
  than any estimate.

## Where to look next

- [Stopping a run](/docs/stopping-a-run) — what survives when you stop one yourself
- [Reading a receipt](/docs/reading-a-receipt) — what you were charged, field by field
- [Spending limits](/docs/spending-limits) — where the limit you set is read, and where it is not