What a build run is
Checked against the Orcyx source tree at 1df386e74 on 2026-10-10 (release 0.2.16). That is a later read than the rest of this documentation set, which is stamped at c339cf993 on 2026-09-14 - this page was written after it. Where this page describes something the build does not do yet, it says so in place rather than describing the intention.
Open Space, choose Build end to end, describe an outcome, optionally add files or links, and press Build it. Orcyx plans the work, sets up the project, implements it, runs the checks itself and puts the result in front of a reviewer that did not do the work, all inside the Build end to end panel. No terminal interaction is needed and local steps are not put to you for approval. Build it authorises local setup, file changes and checks for that build only; it does not change what other agents may do.
Each run gets its own isolated Git worktree where one is possible. A folder that is not a Git repository is still buildable, and the run discloses the missing isolation in place rather than proceeding as though it had it.
Using a website as a reference
Include the website address in your request. Before planning, Build reads the pages it can reach through the site's links and sitemap, saves them for the builder to read, and records the fonts and colours used by its stylesheets. The capture lists pages it could not read and explains why. A failed capture is reported and retried when the build resumes.
With Edge or Chrome installed, Build also reads pages that depend on scripts, takes desktop and phone screenshots of the main pages with their measured layout, and downloads images, icons and fonts. With Codex, the model sees the named page's first screen at both sizes. Without a supported browser, Build reads HTML and reports the limitation in its log.
For a site behind a sign-in, open Build settings, Sites behind a sign-in, and sign in using Build's separate browser before starting. Later builds can use that session. Build does not use your everyday browser profile. Anything the capture cannot reach remains an explicit assumption for the builder.
The five stages
1. Plan
The planner inspects files and proposes requirements, assumptions, verification commands and approximate effort. File reads include up to 200,000 characters per file. When inspection reaches its allowance or the builder lacks information, Build it continues with stated assumptions and sensible defaults. The plan, its assumptions and its checks stay readable under Accepted scope & verification.
2. Build
The implementation provider reads, writes only against the content it read, and runs commands through Orcyx’s own command runner, including installing the project's locked dependencies. Pause and stop cancel active work; output already written stays on disk.
3. Verify
Orcyx executes the planned checks itself rather than believing a report about them, and keeps the command, its exit code, its output, a timestamp and the scope revision it ran against. A failed check returns to implementation.
4. Review
A fresh review context must accept that evidence before a run can complete.
5. Deliver
In a Git project a reviewed Build it run is merged into your project by itself, through the same merge as Put all of it in my project: unrelated uncommitted edits are kept, and staged changes or edits the build would touch stop the merge with your project unchanged and the reason on the finish card. Pick what goes in stays available. A folder that is not a Git repository was built in place, so the result is already there.
What completion does not mean
Completion means the planned checks passed and an independent review accepted the result. It does not imply a deployment or an app-store publication. By default, Build it skips steps that would publish, send, pay or change an outside service, continues the local work, and lists the skipped steps in the report for you to complete separately.
Required platform checks have to be among the planned checks, or they did not happen. Missing credentials, an unavailable platform and signing that could not be performed must be reported as unfinished work, never counted as a pass.
A Build it run has no Orcyx token, time or round limit, because a complete app routinely needs millions of tokens and hours. Only the spending cap in the Build settings applies, and a run that reaches it offers one click to allow the same amount again and continue. Time and round limits for every build in a project live under Settings, Automation, Build end to end, Advanced project limits.
Restart recovery is deliberately paused rather than automatic. An interrupted command may have changed files partially, and replaying it as though it had succeeded would be a silent corruption. You decide what to do with it.
Choosing who does the work
Connection mode is set in the Build settings. One connection can cover every stage, or planner, builder and reviewer can each have their own.
- Current subscription or CLI login - Claude, Codex, Gemini, Grok, OpenCode, Copilot, Cursor or Droid. Needs an installed, signed-in CLI; Copilot, Cursor and Droid need a saved key or token in Provider accounts. OpenCode's free models refuse requests from outside OpenCode, so they cannot run builds. There is no automatic switch to API billing.
- API key - OpenAI, Anthropic, Google, Groq or OpenRouter, from a workspace or global key, a saved API account, or a keychain profile.
- Local model - Ollama, using its discovered models.
- Custom endpoint - any OpenAI-compatible chat-completions endpoint. It needs its exact model ID, because arbitrary endpoints share no discovery contract.
Empty model IDs are filled in automatically where they can be: a configured task model for the provider first, then that provider's discovered text models. Discovery sources and discovery failures are both shown, and an explicit saved model ID is never overwritten.
Subscription CLIs run hidden, with their native tools disabled or restricted inside a temporary inference directory; Orcyx executes the validated actions against the build workspace itself. Unsupported flags, missing logins and invalid actions fail visibly in the run log. The same action protocol and the same verification gates apply to every transport.
Editing and re-running
Select a run in Build history and choose Edit build. The editor prefills the outcome, references and the planner, builder and reviewer connections; you can change providers, models, modes, accounts or budgets. Save changes validates and stores them together as a new paused revision - including for runs that already completed or stopped.
A save keeps the existing worktree, its files and the cumulative usage, and resets the plan and the verification. It does not call a model and does not change your global defaults. Resume replans from there; Cancel edit discards the draft. Pause an active build before editing it.
The new-build form stays usable while other builds run. Each run snapshots its own connection settings and gets its own worktree. Two concurrent runs in the same non-isolated directory are refused explicitly rather than allowed to interleave.
Dictating the outcome
Both outcome fields support Record voice, then Stop and insert. Dictation uses the engine and microphone from Settings > Voice > Quick Dictation, with shared hardware in Audio - independently of whichever provider the build itself is routed to. The final transcript is appended to what is already there for you to read; it never submits on its own, and planning or saving waits for dictation to finish or be cancelled.
Cancel recording, closing the panel or leaving the editor discards unfinished dictation and releases the microphone. Engine identity, live partials where the engine provides them, redactions and any recording or transcription failure are all shown. Reference paths stay typed, because file names are exactly what dictation gets wrong.