A frontier model coordinates, cheap models execute

Over four days, one frontier coordinator and a set of cheap executors closed six epics across two real projects: more than forty tasks, and a test suite that grew from roughly 1,100 tests to almost 2,000. The cost estimate shown by the executor ranged from $0.01 to $0.13 per task.

The architecture separates two responsibilities: Orca is the control plane; the pipeline is a policy adapter. Orca owns execution and its durable state. The custom layer decides what each agent may touch, what evidence it must produce, and when its work is safe to accept, retry, or close.

One incident shows why that boundary matters. Two subagents finished almost together. The coordinator handled the first, and the second appeared to vanish. No message had been lost. An older FIFO Delivery was still waiting for an ack, so Orca was correctly replaying that batch while later notifications waited behind it. The solution does not need another mailbox; it needs to honor the contract of the one already there.

1. The boundary that makes the pipeline useful

Orca already creates Runs, represents a DAG, dispatches a Task, keeps durable threads, supervises terminals, and manages worktrees. Reimplementing any of those means synchronizing two truths. Soon you are asking whether the real state lives in Orca’s Dispatch, a guard’s file, or a watcher’s PID.

The custom layer only earns its place where it adds a testable decision:

Orca, control plane	Pipeline, policy adapter
Run, DAG, Task, and Dispatch	project profile and effective concurrency limit
FIFO Delivery and durable threads	complete resolution before ack
terminal and transcript	safe agent command and startup proof
worktree lifecycle	setup, editable roots, and safe cleanup
worker outcome	gates, QA, and retry policy

That boundary removes a surprising amount of code. There is no daemon, broker, SQLite, NDJSON spool, or local queue. There is no wrapper for every Orca command either: if a wrapper cannot impose or verify a policy, it should not exist.

2. The decisions that hold the system together

Four decisions make the custom layer earn its place.

Real worktrees. Every worker gets its own checkout, branch, and terminal. Workers do not share an index, build caches, or a development server. Work also survives the session: if a provider fails, replace the process and keep the disk.

Complete specs. The Orca Task contains the whole contract: objective, scope, criteria, paths, cases, and gates. There is no copy in .pipeline/specs/ and no dispatch that merely points to an external file: those choices would create orphaned artifacts and specs that could disappear during recovery. The Task is the only copy, which also fits an important Orca property: a Task spec is immutable.

Default deny. OpenCode starts from a closed base, then receives a stack layer and a profile overlay. A web worker cannot touch Electron; a security worker can edit two directories; a QA worker only writes evidence. Secrets, keys, .git/**, and .pipeline/** cannot be reopened by a later layer.

Independent verification. The coordinator reruns gates and reviews the diff. A worker saying “all green” is not evidence. In Lawyer, a task that creates routes uses a profile that adds the production build and bundle verifier. In BIA, global style work adds computed CSS and Playwright: typecheck, lint, and unit tests passed twice while the application was visibly broken.

The gate comes from what the change can break, not from a ceremonial checklist.

3. The message was not lost; it was behind a Delivery

Orca’s public mailbox has a precise contract. check returns the oldest FIFO Delivery. That Delivery may contain many messages, and Orca replays it unchanged until the coordinator acknowledges the entire batch with its deliveryId.

The correct loop is small:

1. Get the oldest Delivery.
2. Process every message in it.
3. For each worker_done, validate Task, Dispatch, and outcome; then reuse, retain, or release the terminal.
4. Leave a question as needs_input in its thread; block the Task on escalation.
5. Send ack only after every decision is durable in Orca.
6. Check again without waiting until all currently available Deliveries are empty.

If the coordinator closes between steps 3 and 5, Orca returns the same batch after restart. Actions therefore have to be idempotent: worker-release is idempotent, blocking an already blocked Task is idempotent, and reuse checks whether the next Task already has a Dispatch.

The important semantic is this: worker_done does not mean the process died. It completes the Task and Dispatch, leaving the worker idle. Sending another message to the completed Dispatch does not create a second attempt. The coordinator must explicitly reuse the terminal with another Task, retain it for debugging, or release it.

4. Basic notification is not a reliable mailbox

Orca 1.4.182 includes the basic coordinator notice for worker_done (#12988). It does not include the retry that covers races, restarts, and stale waiters (#14332), merged after the 1.4.182 release.

The answer is not to build another mailbox. It is to treat this version as degraded: a profile may request three workers, but its effective limit is one. Parallelism requires an explicit per-Run override, and the override is visible in the receipt.

Nor is “any later version must be fixed” a valid capability check. The adapter keeps an exact compatibility table. The first release containing #14332 is added only after it has been verified and passes a real smoke test: two workers finish close together, the coordinator does not check while they work, and notification, Delivery replay, ack, and cleanup are all exercised.

One coordinator terminal supervises one Run. Concurrent Runs use separate coordinators, which prevents waiters from competing over one inbox.

5. The launch race is still a workaround

The convenient one-shot path—create a worktree, start an agent, inject the task—can dispatch before a new agent is ready. The race remains documented in #13488.

Until a verified release closes the race, the sequence is deliberately boring:

1. Create the worktree without an agent.
2. Run setup.
3. Write the OpenCode policy.
4. Start the agent.
5. Wait for tui-idle, then dispatch to that existing terminal.
6. Confirm a real transcript through worker-read.

Grepping the screen, measuring silence timestamps, or sending mailbox probes would confuse valid states with failures. The pipeline retries only for an observable reason: dispatch not started, failed outcome, provider error, or failed gate. Silence by itself is not an error.

6. OpenCode and Codex do not provide the same guarantee

OpenCode can prevent writes by path. Its policy composes as base + stack + overlay and is validated before startup. A replacement overlay may narrow the edit map, but it cannot erase non-negotiable denies.

Codex has different granularity. It starts with workspace-write, network disabled, and approvals disabled, following its official configuration. That contains the process within the workspace, but it is not equivalent to allowing only two directories inside the repository. The extra guarantee is detective: before accepting the result, the adapter compares the full diff—committed, staged, unstaged, and untracked—against the profile’s editable roots.

Calling both guarantees equivalent would be misleading. A preventive barrier and a detective gate can produce the same final rejection while exposing different risk.

7. Recovery without imaginary self-healing

“Self-heal on silence” sounds attractive: if a worker has emitted nothing for 210 seconds, read its screen, classify it, and relaunch. In practice, long model turns, wrapped TUI output, and a busy coordinator generate false positives.

The recovery policy starts from states Orca actually knows:

• a Dispatch never started;
• the outcome is failed or the provider returned an error;
• an independent gate failed;
• an escalation blocked the Task.

After repeated failures, the order is: split the Task, relaunch clean in the same worktree, and only then raise the model. A broken session does not require discarding the code. A more expensive model does not repair an oversized task.

Cleanup does not improvise either. First worker-release, which archives output and releases the exact terminal; then worktree rm. If the checkout has uncommitted changes, cleanup refuses. It neither hides Orca errors nor falls back to raw Git.

8. QA: structure, pixels, and evidence

An executor without vision can traverse the accessibility tree, assert text and structure, and produce screenshots. It cannot judge visual weight, contrast, or fidelity. That verdict belongs to whoever has eyes: the coordinator or the human.

The split works when the report also lists what it could not judge. In one batch, a worker correctly proved that a grid had five cells and escalated that it could not know whether the empty tracks looked painted. Visual review found exactly that defect.

Evidence itself must be verified. A screenshot can exist, weigh hundreds of kilobytes, and still be corrupt. After seeing PNGs whose signature started with efbfbd50 instead of 89504e47, the signature became a gate.

9. What it actually cost

Observed between August 8 and August 11, 2026—not a provider pricing table:

Metric	Observed
Epics closed	6
Tasks processed	~40
Tests	~1,100 → ~1,950, green
Executor estimate shown in the agent	$0.01–$0.13 per Task
Subscription paid at the time	$10/month; calls displayed $0.00
Time budget per Task	45 minutes

Executor tokens were never the expensive part. The expensive parts were an ambiguous spec, a gate that missed the surface, a Delivery acknowledged incorrectly, or twenty minutes spent watching the wrong indicator.

The pipeline stays small because it only keeps what Orca cannot know: what a Task may touch and what evidence makes it acceptable. Runs, messages, Tasks, and Dispatches still belong to Orca. The goal is not a pipeline that “heals itself,” but a system where every failure has one owner, one durable state, and a recovery path that does not invent another source of truth.