Understanding AI runs
A run is one AI execution. The chat shows what each run is doing, what it cost, and where it stopped — this page explains how to read that.
Every prompt you send is a run. So is every step of a plan, every design round, and every retry.
The life of a run
A run appears under your message with a status badge that changes as it moves:
| Badge | What it means |
|---|---|
| Queued | Accepted, waiting for a free build environment |
| Running | The AI is working; the activity list fills in below |
| Done | Finished, and the code was committed |
| Build issues | Finished, but a check found problems |
| Failed | Stopped on an error, shown in red under the message |
| Cancelled | You pressed Stop |
The line above the message shows the run's age and the model that handled it; a finished run adds its duration beside the cost chip.
When a run waits for you
Some runs pause and hand a decision back. The badge says which:
| Badge | What it wants | Expires after |
|---|---|---|
| Waiting for your answer | Ask first questions | 10 minutes |
| Awaiting approval | A plan to review | 30 minutes |
| Needs a decision | Planning did not finish: Try planning again or Run as one go | 30 minutes |
| Choose screens | Which design screens to draw | 60 minutes |
| Awaiting design review | Mockups to approve | 60 minutes |
Leave one past its expiry and the run is cancelled — send the prompt again. Answering, approving and choosing cost nothing.
Two more show up inside a plan: Planned on the parent row, and Pending on a step still waiting its turn.
Reading the activity list
While a run works, a list names each step — reading a file, writing one, searching the code, running a command — with its duration and a tick, a spinner, or a cross.
Only the five most recent steps stay visible. Click the fold above them (3 earlier steps) to see the rest.
If the AI goes quiet for more than 10 seconds while the run is still healthy, The AI is thinking… appears under the list. It disappears on the next step.
The list names the tool and the file it touched, never the body of a shell command. That is deliberate: a command line can carry secrets.
The cost chip
A chip under the message shows what the run cost.
- While the run is in flight it reads
≈1.00 cr…— a placeholder held against your balance, not a price. - When the run settles, the chip shows the real figure, for example
1.42 cr, metered from the tokens it used. - Beside it,
◇ 4,210 in / 890 outis the raw token count behind that figure.
No cost figure means the run was not charged. See how credits work for what drives the number.
When a run finishes with build issues
Build issues means the AI finished and its code was saved, but a check found the app is not working yet. An amber panel names what it found, with the file each one is in, up to eight at a time. Its first line tells you which kind of problem you have.
Most checks read the code and prove it will not compile — a route collision, a bad 'use server' export, a type error. The panel reads Build check failed — this code will not compile yet.
One check goes further and opens the app: after a run, the platform requests the pages that run touched plus the home page, and reports a server error as a finding, with the relevant server log attached. The panel then reads This page returned a server error when it was opened. The build is fine here — the page compiled, then failed the moment it was loaded. That failure used to pass as a clean success.
A second check of the same kind asks whether the images and fonts your code points at actually load. It is not the same question as "does the page work": a page can answer perfectly while every picture on it is missing. The panel then reads This page has an image or asset it cannot load, naming the path. The usual cause is login middleware — a rule that protects every page will, unless it is told otherwise, also block the files in your public/ folder. That breaks the image for signed-in visitors too, so it is easy to look straight at it and not see why.
One more check reads the code rather than opening it, and it is about a credential rather than a crash. If your project has AI enabled and the token ends up somewhere the browser can read — written into a file as a literal, or read inside a 'use client' component — the run is stopped and the panel names the file. Nothing is broken when this fires: the app compiles, the page renders, and the token works. That is exactly the problem, and it is why the heading here does not claim the code will not compile.
Both of the checks above only happen while the preview is running. When it is not, they are recorded as skipped rather than passed — so a clean run is not by itself proof that every page opens, or that every image on it appears.
Either way one automatic repair attempt is made before the run gives up, and a plan halts on the failing step rather than building on top of it. That attempt is part of the same run, so its tokens are in the cost chip — a run that had to be repaired reads higher than one that passed first time.
On an ordinary run there is no retry button here, on purpose: the work exists, so re-running the same prompt would only redo it. Recover with a follow-up prompt describing the fix. If the preview has crashed, you can also open it and use Resolve with AI, which sends the error text to the AI as a new run.
A step of a plan is the exception, because the steps behind it are waiting. There, Build issues do get a Retry, and a successful re-run lets the chain carry on — see plan mode.
Telling the AI something is broken
When a follow-up prompt says something is still not working — still broken, masih error, a 500, or a quoted error message — the platform attaches your project's own recent dev server output to that prompt, plus the bundler output when a mobile preview is running. You no longer have to copy the error text out yourself: saying what is broken is enough.
- It is reference material, not a task: the AI reads it for evidence and is told not to fix anything it finds there unless your message is about it.
- Only the most recent output goes in, capped in size and with secrets stripped first.
- If nothing has been running there is nothing to attach.
- Ordinary follow-ups only — a plan step and a Resolve with AI run already carry their own context.
Stopping and retrying
Stop appears on any run that is queued, running, or waiting on you. A running run is torn down as soon as the request reaches it, and is still charged for the tokens it burned first.
Retry appears on failed and cancelled runs, and on a plan step that stopped with Build issues. It is a new execution and is charged again — it suits a run that died on infrastructure, not a result you disagree with. Retrying a step of a plan re-runs that step in place, and the chain carries on from there.
When a run fails
The error text is shown under the message. Failures on our side — a build environment that died, an expired credential, a queue that could not place the run — settle at zero and show no cost chip.
Two cases are still charged: a run that hit its time limit spent the tokens, and one ending in Build issues produced code — just not code that works yet.
Limits & notes
- The activity list shows only the five most recent steps until you unfold it; the build panel shows at most eight findings.
- Opening the app is only checked while the preview is running. A run with no build issues does not prove every page loads.
- Build issues on an ordinary run cannot be retried — recover with a follow-up prompt. On a plan step they can, so the rest of the plan is not lost.
- Stopping a run does not refund it, and every retry is a fresh execution charged in full.
- A run started by a collaborator is billed to the project owner.
- Limits may change during alpha.