> ## Documentation Index > Fetch the complete documentation index at: https://docs.mythos.new/llms.txt > Use this file to discover all available pages before exploring further. # Fixing a build that isn't right > When a Mythos build isn't what you wanted — how to phrase a correction prompt, revert to an earlier version, and when to open the code editor instead. Mythos is built to iterate: you correct it in chat, and each correction is a real change committed to your project. This page is about the three ways to fix a build — a correction prompt, a revert and retry, or a direct code edit — and when to reach for each. **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](/introduction/credits-and-usage). ## 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. Point at one thing per edit. "Make the hero background darker" lands cleanly; "redo the whole thing but better" makes the builder guess. Several small, specific edits beat one vague rewrite. Vague vs targeted, for the same fix: ```text theme={null} The hero looks off, fix it. ``` ```text theme={null} In the hero, make the background darker, increase the headline size, and move the CTA button below the subheading. ``` More corrections that work because they name the section and the change: ```text theme={null} Change the palette from blue to a warm terracotta and cream. ``` ```text theme={null} Add an FAQ section above the footer with four questions about pricing and delivery. ``` ```text theme={null} The testimonials section has three cards — make it a single centered quote instead. ``` ```text theme={null} Replace the stock hero photo with a solid dark gradient. ``` If something looks broken rather than just wrong, describe **what you see**: ```text theme={null} The pricing section overlaps the footer on mobile — fix the spacing. ``` ```text theme={null} The contact form shows an error when I submit it — make it submit cleanly. ``` ## 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. In the workspace, open the **History** panel — each build and edit is a listed checkpoint you can go back to. Click an earlier checkpoint to view the project as it was at that point. 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. With the good version restored, prompt your next change. You're iterating from a clean base instead of fighting a bad edit. **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 an edit fails outright (it errors or runs out of room), you're **refunded** and the project is left as it was — nothing half-applied. Just re-prompt; you weren't charged. ## 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. Switch to the code view in the workspace and click the file you want to change. Type your change. The editor keeps per-file undo history, so undo/redo stays scoped to the file you're in. Press **Ctrl+S** (or **Cmd+S**), or wait — the editor auto-saves a short moment after you stop typing. Saving formats the file and commits it to your project, then pushes it to the live preview so you see the change right away. **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. Reach for the editor when: * 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. Stay in chat when the change is conceptual ("make this feel more premium," "add a pricing section") — describing intent is what the builder is good at. ## 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. Use whichever matches how well you can describe the change. ## 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](#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](/prompting/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 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." 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. No. Reverting and editing code in the workspace are free. Only builds and chat edits spend credits — and a failed one is refunded. 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. No. A failed edit is refunded in full and leaves the project as it was. Re-prompt at no cost. ## Related * [Writing good prompts](/prompting/writing-good-prompts) — get the first build closer so you correct less. * [Plan mode](/features/plan-mode) — shape the look before building to avoid corrections. * [Credits & pricing](/introduction/credits-and-usage) — what edits cost and how refunds work. * [Quick start](/introduction/getting-started) — the full build-and-iterate flow.