How Revix Works
After this page you will understand what happens between pressing send and seeing your game change — and why Revix asks questions, shows a checklist, and sometimes tells you it could not check something.
What has to be true first
Revix has no cloud copy of your game. It works live inside the place you have open in Studio. A build request is refused if any of these is missing:
| Requirement | Why |
|---|---|
| You are signed in to Revix | Work is billed to your account |
| Your Roblox account is linked | It is how Studio and your account are matched up |
| Studio is open and the plugin is connected | This is the only way changes reach your place |
| You have at least 0.1 credits | Enough to start a run |
| No other build is running in this chat | One job per chat at a time |
What happens after you press send
- Revix works out what you are asking for — something to build in your place, a picture, or a mesh file. You see a Deciding next move… pill while it does.
- It looks at your place. It can search every script you have, list what is inside any container, read properties, and measure the real size and position of parts.
- It decides on an approach and starts. There is no plan document to approve and no "shall I proceed?" step.
- It works in small steps. Each step creates, edits or reads something back, and waits for Studio to confirm before moving on — which is why its idea of your game and the real tree stay in step.
- It checks its own work before it says it is finished.
- It writes you a summary of what it made and where. See Reading What It Built.
It works differently depending on the job
Revix does not treat every request the same way. Laying out a screen and fixing a save system are different crafts, and it switches between them:
| When you ask for | It behaves like |
|---|---|
| A menu, shop or HUD | A UI designer — it commits to a look first, then builds the screen and the script that makes it work |
| A building, road, tower or map | A builder — volumes first, then surfaces, then detail, measuring as it goes |
| A system, a fix, a refactor | A programmer — it reads the existing code before changing a line and changes only what is responsible |
| "Does this actually work?" | A tester — it writes and runs a check rather than claiming a pass |
| "It's broken" or an error message | A debugger — it reads your Output window, names the cause in a sentence, then makes the smallest fix |
| Movement on a character or model | An animator — it gets the model ready, then saves a clip onto it |
You do not choose this and there is no setting for it. A follow-up in the same chat carries on in the same shape of work, which is part of why replies to a build are quicker than the build was.
Why it sometimes asks a question first
Revix asks only when the answer genuinely changes what gets built — a fork it cannot guess its way out of, like "round tower or square?". Anything it could answer with a sensible default, it answers itself, and small surgical requests never trigger a question at all.
When it does ask, a card pins above the message box with 1 to 4 questions, each either a set of options or a box to type in. Answering does not send a new message — it resumes the same job from where it paused, and the pause costs you nothing. There is a Skip — use your best judgement link under the card if you would rather it just picked.
Why long jobs show a checklist
A build with ten moving parts needs somewhere for you to see the shape of the work, so Revix writes a checklist at the start and keeps it honest — items move from waiting, to in progress, to done, as they actually land. Alongside it you get a step-by-step timeline and a step counter. That is covered properly in Long Tasks and Checklists.
Nothing is silently destructive
- Every change Revix makes is a normal Studio undo step, named after what it did.
Ctrl+Zin Studio walks back through the build exactly as it would through your own edits. - You can just ask. "Undo that" or "revert the last change" steps Studio back for you, up to 20 steps at once.
- Nothing is saved or published for you. Everything lands in the open place. You still choose when to save and when to publish.
- Revix cannot read or change anything inside ServerStorage. It is off limits to every operation.
Two honest caveats:
- A big operation — dozens of parts placed in one go, or a whole generated world — lands as one undo step, not one per part. A single
Ctrl+Zcan remove a lot. - Generating a map clears the existing terrain first. Generate the world before you build on top of it, not after.
What it genuinely cannot do
Revix cannot see your screen. It has no screenshots and no view of the viewport — it checks its work by measuring and by reading things back, never by looking. That is the single most useful thing to know about it.
- It cannot press Play. It will ask you to, then read the Output window once you have.
- Anything that only exists while the game is running — players, their screens, the character in a live session — is invisible from edit mode. Code that only runs for a player is checked by reading it back against what was built, so press Play to confirm behaviour.
- It does not browse the web. It works from its own built-in reference for Roblox classes and members, which is why it rarely invents an API that does not exist.