Cost: each edit costs 2 credits, charged when the change is delivered and refunded if
the edit fails. Reverting to an earlier version and editing code in the workspace do not cost
credits. See Credits & pricing.
Three ways to fix a build
| You want to… | Use | Cost |
|---|---|---|
| Change what’s on the page (copy, layout, a section, colours) | A correction prompt in chat | 2 credits |
| Throw away a bad change and go back to a version you liked | Revert to an earlier commit | Free |
| Tweak exact code yourself (a class, a string, a value) | The workspace code editor | Free |
Phrasing a correction
A correction is just another prompt — but a targeted one. Name the thing you want changed and what you want instead. The builder applies the change as an edit on top of the current version, so you don’t need to re-describe the whole site. Vague vs targeted, for the same fix:Revert and retry
Sometimes an edit makes things worse, or you preferred the version from two changes ago. Every build and every edit is a commit in your project’s history, so you can go back.Open the History panel
In the workspace, open the History panel — each build and edit is a listed checkpoint you can go back to.
Click Restore
While viewing that version, press Restore. The restore is applied as a new commit — it doesn’t erase the later versions, it just brings back the earlier state on top.
Reverting never destroys history. A revert is a new commit that restores an earlier state —
your later versions stay in the history, so you can always move forward or back again.
When to use the code editor
Chat is best for describing what you want. When you know exactly what to change — a specific Tailwind class, a piece of copy, a number — it’s often faster to edit the code yourself than to describe it. The workspace has a built-in editor for that.Edit it directly
Type your change. The editor keeps per-file undo history, so undo/redo stays scoped to the file you’re in.
Editing code is free and doesn’t spend credits — it’s a direct save to your project, not a
builder run. Use it for precise tweaks; use chat for anything you’d rather describe than write.
- You know the exact value to change (a colour hex in the theme, a headline string, a padding number).
- A chat edit keeps not landing the precise thing you mean — sometimes typing it is the shortest path.
- You want to read the generated code to understand how the page is put together.
Build mode vs the code editor
- Chat (Build mode) edits by describing a change; the builder writes the code and commits it for 2 credits.
- The code editor edits by typing the code yourself; it saves and commits for free.
Good to know
- Edits build on the current version. Each correction is applied on top of where the project is now — it can’t merge two earlier versions together. To go back to an earlier state, restore it first (see Revert and retry), then edit from there.
- Every build ends with a result or a refund. A correction either lands as a committed change or fails cleanly with a plain message — and a failed edit is refunded in full, leaving the project exactly as it was. You’re never charged for a change you didn’t get, and a stuck run is never left half-applied.
- A few files are protected in the code editor. Scaffold plumbing (
package.json, lockfiles,tsconfig,src/main.tsx,app/layout.tsx, …) can’t be hand-edited from the workspace — saving one returns “This file is protected.” Change those through chat instead.
Troubleshooting
| Problem | Fix |
|---|---|
| An edit changed the wrong thing | Be more specific — name the exact section and what to do. Or revert and re-prompt. |
| Several edits drifted away from what you wanted | Revert to a version you liked and iterate from there. |
| A form doesn’t save data | Forms don’t store anything until you connect your own Supabase under Services → Cloud, then ask for the data to be saved. See Writing good prompts. |
| An edit errored out | You’re refunded automatically and the project is untouched — just re-prompt. |
| You know the exact code change | Skip chat — edit the file in the workspace editor and save. |
FAQ
How do I phrase a correction so it lands?
How do I phrase a correction so it lands?
Name one thing and the change you want: the section, and what to do to it. Targeted single-change prompts land far more reliably than “fix the whole thing.”
Can I undo an edit I didn't like?
Can I undo an edit I didn't like?
Yes. Revert to any earlier version from the project history. The revert is a new commit, so nothing is lost and you can move back and forth freely. It doesn’t cost credits.
Does reverting cost credits?
Does reverting cost credits?
No. Reverting and editing code in the workspace are free. Only builds and chat edits spend credits — and a failed one is refunded.
When should I edit the code instead of prompting?
When should I edit the code instead of prompting?
When you know the precise change — a class, a string, a number. Editing is free and instant. Use chat for changes you’d rather describe than write.
My edit failed — was I charged?
My edit failed — was I charged?
No. A failed edit is refunded in full and leaves the project as it was. Re-prompt at no cost.
Related
- Writing good prompts — get the first build closer so you correct less.
- Plan mode — shape the look before building to avoid corrections.
- Credits & pricing — what edits cost and how refunds work.
- Quick start — the full build-and-iterate flow.