What a build run is
Checked against the Orcyx source tree at 8f1c56df3 on 2026-09-21. 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 and optionally point at workspace-relative documents. From there Orcyx plans the work, asks you to accept a scope, implements it, runs the verification commands itself, and puts the result in front of a reviewer that did not do the work. No terminal interaction is required during a run.
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.
The five stages
1. Plan
The planner inspects files and proposes requirements, assumptions, verification commands and approximate effort. Planning uses paged file lists, batched reads and bounded previews, and inspection is bounded: past a point the planner is asked to propose scope or report a blocker, and one that keeps getting nowhere pauses the run rather than grinding at it.
2. Accept scope
You read the proposed commands and accept them. Acceptance authorises exactly those verification commands and nothing else — implementation writes and other commands are each approved individually unless you explicitly enable automatic execution.
3. Build
The implementation provider reads, writes only against the content it read, and runs commands through Orcyx’s own command runner. Pause and stop cancel active work; output already written stays on disk.
4. Verify
Orcyx executes the accepted 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.
5. Review delivery
A fresh review context must accept that evidence before a run can complete. Then you copy the worktree path or export the report.
What completion does not mean
Completion means the accepted checks passed and an independent review accepted the result. It does not imply a merge, a deployment or an app-store publication, and Orcyx does not perform any of those as part of a run.
The practical consequence is that required platform checks have to be inside the scope you accept, or they did not happen. Credentials you have not supplied, a macOS runner you do not have and signing you cannot perform are reported as blockers — not quietly skipped and not counted as a pass.
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 directly above Plan this build, or in Build settings. One connection can cover every stage, or planner, builder and reviewer can each have their own.
- Current subscription or CLI login — OpenAI through Codex, Anthropic through Claude, Google through Gemini. Needs an installed, signed-in CLI. 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, 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.