Canonical update (2026-08-29): This article is a field note in the multi-agent journey. The consolidated through-line is The multi-agent journey.
I wanted Codex to stay focused on the hard parts of a job: understanding the request, making decisions, and checking the result. Long execution work made that difficult. It filled the model's context and used part of my subscription allowance.
So I split the job.
I kept Codex as the parent, or lead. The parent understands the request and judges the final work. I gave one small, clear slice to an OpenCode Go worker. A saved task record carries the scope, limits, expected files, and finish test. A scheduler starts the worker. A message channel carries short updates.
It is a small system with records that let me see what happened.
The main route is short. DeepSeek and Qwen are conditional routes, not equal defaults. Download the native draw.io source.
One task, from request to review
Suppose I ask for a report that needs research, file changes, and checks. Codex first turns that request into a plan. It writes a saved task record. The record names the task, allowed files, budget, finish test, and evidence path.
The scheduler then gives the task to one worker. In this setup, Beads is the durable task list. BVR is the small set of rules that checks task ownership and state. These names matter less than their function: they stop two workers from claiming the same job.
NTM starts and watches the worker. Agent Mail is the message channel. It carries an acknowledgement, progress, a blocker, or a completion note. It does not own the task. It does not carry credentials.
OpenCode Go reads the task record by path. It does the bounded slice. It writes the requested files and a result record. It must repeat the task ID and packet hash before work starts. That reply proves it received the right instructions.
The parent then reviews the result. It checks the files, evidence, scope, and finish test. It accepts the task only when the checks pass and the work answers the request.
If the worker stops, the saved record makes a safe restart possible. The replacement reads the last checkpoint, which is a saved restart position. It does not need to replay the whole chat. A lease is a short reservation that says who may work on a task or file. When the lease expires, a new worker can take over under the same rules.
Fresh tasks reset context; delegation changes the worker
When a Codex task grows too large, fresh-task rotation starts a new Codex task with a small handoff record. This changes the context. It does not change the provider. The new task is still Codex.
Delegation is different. Delegation changes who executes the bounded slice. The parent remains responsible for the plan and review. OpenCode Go performs the work. The result returns to the parent.
The distinction fixed a confusing part of my setup. A new configuration applies to fresh sessions. A running session keeps its original route. That is why old and new sessions can appear to disagree during a migration.
What the names mean
Beads and BVR keep durable task state. NTM schedules and watches workers. Agent Mail carries compact messages. OpenCode Go is the bounded execution worker. Telemetry is the record of events, routes, token counts, retries, and checks. A control plane is the part that owns task state and legal changes. These are functions first, product names second.
I keep fallback rules narrow. OpenCode Go with Luna is the default worker. DeepSeek is a text fallback only after a health check says Go is unavailable. Qwen is for image work. A failed health check closes the route. It does not silently pick another model.
What worked, and what failed
The useful part was the identity chain. One task could be joined to its Codex task, NTM worker, Bead, Agent Mail thread, OpenCode session, and usage record. That made the return auditable.
The weak part was recovery. One worker touched an unrelated coordination path. The controller rejected the result. That was the right outcome. The worker found useful information, but it did not complete the assigned task.
The system also needs a hard boundary around orchestration. A worker must not become a second parent. It must not create its own worker tree. It must not take a browser already reserved by another worker.
What the benchmark means
In one completed bounded task, the Codex parent used 4,997,110 tokens. The OpenCode Go worker used 11,967,667 tokens. The known total was 16,964,777 tokens. OpenCode Go therefore held 70.54% of the known total.
Those are measured counts. They show where work occurred in that task. They do not show how much work Codex would have done alone.
This was one delegation-heavy completed-task window, not a representative calendar day. It shows where measured work occurred, not what would have happened without delegation, and supports no causal savings claim.
The word token means a small unit of text used by a model. Different models can split the same sentence into different numbers of tokens. They can also use different amounts of reasoning. A provider is the service that supplies the model. Provider counts are useful evidence, but they are not a matched experiment.
What still needs proof
The next test should compare two runs of the same task. One run should keep all work with Codex. The other should delegate the same bounded slice to OpenCode Go. Both runs need the same inputs, tool rules, finish tests, retry policy, and measurement method.
I would compare total tokens, parent tokens, worker tokens, cost, elapsed time, steering calls, recovery time, and pass rate. I would also check that both runs produce the same required evidence.
The next matched pair is the evidence I need before I call this a saving.