What Orcyx does, and does not, do here
Checked against the Orcyx source tree at c339cf993 on 2026-09-14. Everything factual on this page restates the seats, swarm and agents pages; the one working pattern is labelled as a pattern. Where this page describes something the build does not do yet, it says so in place rather than describing the intention.
Orcyx, an agentic development environment, does not run models. It runs the coding CLIs you already pay for, each in its own pane, on your own account. Claude Code and Codex are both on the swarm-seat list and both support session resume, so nothing about a pane is specific to one vendor: you open one of each, or seat one of each in a swarm, and they share the same split grid, the same review gate and the same way of getting work back onto the main branch.
| CLI | Swarm seat | Session resume | Provider accounts (credential kinds) | Plan-usage window |
|---|---|---|---|---|
| Claude Code | ✓ | ✓ | api_key · oauth_token · config_root | ✓ read per account |
| Codex | ✓ | ✓ | api_key · config_root | ✓ read per account |
Give each CLI its own checkout
Two agents editing one checkout will read each other's half-finished files, and a type check run by one will fail on the other's in-flight edit. Mixing vendors does not change that. In Orcyx each pane gets its own git worktree on its own branch, so a Claude Code pane and a Codex pane cannot overwrite one another. A worktree shares the object database with the main checkout, so it costs a working tree rather than a clone.
In a swarm run the same rule applies per role: each role that changes code gets its own git worktree for the run. The mechanics - branch naming, linked dependency directories, hook shims - are on the seats and worktrees page.
Two ways to use both
- Side by side, driven by you. Open a pane for each CLI and give them separate tasks, or the same task to compare. You decide what each one does and when its branch is merged.
- Seated in a swarm. A run is a coordinator that holds the plan and routes work, builders that change code, scouts that investigate and reviewers that check, with a CLI chosen per seat. See the swarm and its review gate.
A split that works in practice is to let one CLI build and have the other review the result. That is a pattern for you to set up, not a claim about which model is better and not something Orcyx enforces; it runs whichever CLI you seat.
Accounts and rate limits
Each CLI can hold several credentials, each bound to a pane, with secrets in the OS keychain and only a reference on disk. A pane that hits a rate limit fails over to another account of the same CLI and names the switch in the pane. It does not fail over from Claude Code to Codex: those are different tools with different behaviour, so switching between them is your decision.
Plan usage is read per account for both CLIs - the five-hour and seven-day utilisation the subscription reports - so you can see which account is close to its limit before a pane stalls. Where a provider publishes no such endpoint, the app says so rather than drawing an empty bar. The full table is on the agent integrations page.
What the review gate does and does not stop
When a builder, scout or reviewer reports it is done, the run lists the files that role changed and scans them for committed secrets, unsafe code patterns and content-security-policy problems, graded high, medium or low. That applies the same way whether the role is a Claude Code seat or a Codex seat. A clean result is shown explicitly, and a scan that throws is reported as an error rather than a pass.
The gate is advisory. It fires after routing is decided and does not block, and the decision to merge is yours. Shell panes are not agent seats, so the gate does not scan them.
Getting the work back
A pane's work reaches the main branch by merging its branch from the main checkout, not by copying files across. If the branch is behind, rebase in the pane's checkout first. First merge wins; a later one that conflicts rebases and retries.