When a run fails

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.

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 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 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 — what survives when you stop one yourself
• Reading a receipt — what you were charged, field by field
• Spending limits — where the limit you set is read, and where it is not