How builds work

One message, one turn

Every message you send is a build turn. opix reads your project, decides what to change, and writes scoped edits into a live cloud sandbox that runs your app's dev server. The activity feed shows exactly what's happening — which file is being written, which command is running — and the preview hot-reloads as changes land.

Power modes

By default opix runs on Auto: each request is classified and routed to the right power tier — quick copy tweaks stay cheap, complex multi-file work gets the heavy tier. The power picker next to the composer lets you pin a tier for a turn:

• Auto — opix picks the right power per task.
• Low — fast, for everyday edits and small tweaks (1× cost).
• Medium — balanced power for real builds (~3×).
• High — deep reasoning for complex work (~4×).
• Max — absolute maximum power and care (~5×).

Your choice persists per project. Costs are always metered from real usage — the multipliers are guidance, not a meter.

The quality gates

After every generation, your build passes through gates before it reaches you:

1. Type check — the whole project is compiled. If there are errors, an automatic repair loop fixes them (up to three passes). This never costs you credits.
2. Runtime check — the running app is probed for crashes and obvious runtime errors.
3. Visual check — opix screenshots the running preview and scans it for gross visual defects (broken layout, unreadable text, dead images). Critical findings get one automatic fix round. This gate never blocks a build.

The trust footer

Every finished turn ends with a footer you can audit: type-error status, how long the turn took, which power tier ran, exactly how many credits it cost, and your remaining balance. Failed turns show up too — at a cost of zero, because failures are always free.

Versions

Every completed build commits a version with its diff stats (files changed, insertions, deletions). You can restore any version or even publish an old one directly — see Unpublish & rollback.