One night I asked Rork to change a single line of text on a settings screen. The answer came back, and the text was right. Then I opened the list screen and the sort header was gone.
I asked for the header to be restored. The next answer brought it back, and the spacing on the settings screen had shifted. My stomach tightened a little before I typed a third request.
When every fix moves something else, the question worth asking first is not how to phrase the next fix. It is where to go back to. Rork gives you three ways back, and going back itself costs no credits.
Going back is free; I'd start there
Rork's documentation describes every answer from the agent as a saved version of the whole project. Your files and the chat history are committed together at the end of each turn, so the conversation and the code can't drift apart.
Undo and Revert both cost nothing. Only messages that do work spend credits.
Knowing just that changes how I hesitate. Before sending a third request, I can step back for free.
The three ways back
Here is how they differ. This table is my own reading of the behavior described in the official page, "Undo a change and go back a version."
| Way back | Where it lives | Where you land | What happens to the chat | Can you take it back? |
|---|---|---|---|---|
| Undo | Under the newest answer | The version just before it | That one exchange disappears | No dialog; you only lose the last step |
| Revert | Under every earlier answer | The project right after that answer | Everything after it is dropped | No. A confirmation dialog appears first |
| Edit message | Appears when you hover one of your earlier messages | The state before that message | Everything after it is dropped, and your new wording gets an answer | A revert and a retry in one step |
The detail that's easy to miss is that Revert is explicitly not reversible. If you only need the last change gone, Undo is the safer choice.
Three questions to pick one
Before going back, I ask myself these, in order.
First: was only the last answer bad? If so, Undo. In my settings-screen example, the second answer broke the spacing, so undoing just that one lands on the version where the header was already restored.
Second: was the answer reasonable and my request the problem? If so, edit my own message and send it again. The documentation calls this the cleanest way out of a conversation that went sideways. Rork resets the project to the state before that message, drops what followed, and answers the new wording.
Third: was an answer several steps back clearly better? If so, Revert. A confirmation dialog appears, and I use it as a pause. Everything after the target is lost, so I check once more whether one Undo would have been enough.
Going back is free; going forward costs credits. Step back first, then ask again. That is the order I try to keep in my own indie development work.
Look at what changed before you go back
If you can't decide where to land, open the "⋯" menu under an answer and choose "Review changes." It shows a full-screen diff of every file that answer touched, compared with the version before it.
The same menu shows which model ran, how many credits the message used, and how much context the agent carried. That is useful when you are judging whether an answer was worth keeping.
When something misbehaves without an error dialog, open the Logs panel under More → Code. It shows what your app printed in the preview, tagged [log], [warn], [error], and so on.
Three things going back cannot bring back
Please keep these in mind before you press Revert.
Published work stays published. Revert does not touch a live web app or a submitted build until you publish again.
Secrets are not part of a version. After a revert, open More → Secrets and confirm the values you need are still there.
Hand edits have no undo of their own. On a paid plan you can edit code directly, but once you save, the edit becomes part of the project. Asking in chat instead keeps the change as a version you can revert.
You also can't revert while the agent is working. Press the stop button instead. The partial work is saved, and a build that never finished isn't charged. If a long turn is heading the wrong way, stopping early is cheaper than letting it finish.
Ask again in a smaller, grounded way
Going back alone may land you in the same place if you send the same request. Rork's "How to get out of an error loop" page recommends grounding the model in real inputs, limiting the scope, and making it prove its fix.
I turn that into a short message like this:
I reverted to the previous state. I only want to change the text on
the settings screen. You may edit only the SettingsScreen file; do not
touch other screens or add libraries. After the change, quote the file
and the line you changed.
The first sentence says where we are, the second limits what may change, and the third asks for proof. I wrote it this way to avoid the "it says it's fixed, but nothing changed" situation.
When a runtime error dialog appears, "Fix with Rork" sends a fix request immediately by default. If you'd like to read the request first, turn off "Auto-send error fixes" under Account settings → Preferences.
For how credits are counted, see Two Balances, Not One: Reading Rork's Build Credits and Cloud Credits Apart. For which model to ask, there is Sonnet 5.5, GPT-6.1 Sol, or Opus 5.5? I Decide by the Kind of Fix Before I Pick the Model. If you're still on the free plan, the free-tier daily cap article may help too.
One thing to try next
Open the project you're working on, click "⋯" under the latest answer, and press "Review changes" once. Seeing that screen on a day when nothing is broken shortens the time you'll spend lost on a day when something is.
I tend to focus on getting the fix right and leave the way back for later. Deciding how to go back first is a rule I want to keep, even on tired nights.