Let Claude conduct, let Codex build

Claude workers were draining my weekly allowance ahead of schedule. I liked what they were building. I liked being stopped in the middle of a plan considerably less.

My Dynamic Workflows setup lets one Claude session divide a plan among several worker agents, review their changes, and report back. That's the conductor pattern. One agent coordinates while others do the work, keeping most of the file reads and tool output in their own sessions so the main conversation stays short.

But those workers still use Claude. Giving each one a tidy assignment doesn't give it a separate allowance.

So I kept Claude planning and reviewing, and moved implementation to Codex, OpenAI's coding agent. The Claude workflow calls it through codex exec, which runs a task without an interactive conversation. That became the Claude skill dynamic-workflows-codex.

Where the tokens went

As a worker reads files, writes code, runs a check, and fixes what failed, each new turn carries context from the earlier work, so several workers can use up your week while the main conversation looks beautifully economical. Mine did.

The workflow helps keep the conductor's context small by returning a compact task report. It doesn't remove the workers' context or the code they generate.

The split keeps Opus, a Claude model, decomposing the plan into groups of tasks that can run together. Codex implements each task in a Git worktree, a separate checkout where its edits won't collide with another worker's files. Sonnet, another Claude model, reviews the changes and prepares the report.

I still want Claude reviewing what comes back. A settled work order gives me a sensible place to try a different implementer, but writing code still involves decisions. The acceptance check has to catch the bad ones.

I compared the workflow logs from two two-task runs in the same repository. They implemented different features, so this is a look at where the tokens went, with no claim that either run did equivalent work.

The totals were close. I can't use them to claim that a Codex run costs a fraction as much, or that switching saved a particular percentage of my week.

What they do show is the implementation work leaving Claude's accounting. The sister post on hitting your limit describes how repeated context makes long sessions expensive: as an agent keeps working, earlier code and tool results keep coming along. Moving those implementation sessions to Codex moves that repeated context too.

That explains why I tried the split. It doesn't measure the weekly saving. Claude still spends tokens on planning and review, and a repair-heavy run can keep those agents busy. Codex has its own allowance to watch.

The original experiment used gpt-5.6-luna at xhigh reasoning effort, and my evidence for that choice amounted to one two-task pair passing review on the first attempt and another needing repairs on both tasks. I hadn't compared models on the same plan.

My installed Claude workflow now uses gpt-5.6-terra at medium effort and raises effort to high for repairs. That's the current configuration, not a benchmark result. A useful comparison would count tasks that pass first review and still pass the project's actual checks after integration, alongside the usage from both tools.

Give the worker enough to finish

A fresh Codex process doesn't inherit the Claude conversation. It can read the repository, but it needs a work order that explains the task without requiring the discussion that produced it.

The companion skill, dynamic-workflows-plan, adds that structure to ce-plan, my planning skill. Each task gets a Dispatch header naming its model and effort, the files it owns, the files it needs to read, and a gate: the check it must pass. The plan records prerequisites separately. The work order includes the acceptance criteria.

That gives the orchestrator enough information to schedule tasks without rereading every implementation detail. It also gives the worker something more useful than "do the next bit."

Separate files are a starting point. If task B needs code from task A, that code must be present in B's checkout before B starts. Putting A first in a list doesn't do that. The installed Claude bridge handles a task with one prerequisite by branching from that prerequisite's accepted commit. Tasks with several prerequisites still need attention during integration; their worktrees start from the original base.

Two skills now share the name

The version this experiment used lives under ~/.claude/, Claude Code's configuration directory. It's a bridge: Claude launches Codex, then reviews its output. Its procedure still requires a two-task pilot and a stop for my go-ahead before the full run.

The code-writing worker leaves its edits uncommitted. After review accepts a task, a separate workflow stage commits it on a dwc/<id> branch. The report lists the branches and suggests an integration order. Merging remains a separate step.

I also now have a native Codex skill called dynamic-workflows-codex, installed under ~/.agents/skills/. It uses Codex's own agents without the Claude bridge. It follows the configured model routing rather than prescribing a model in the skill.

The native version supports a bounded pilot when requested. For an authorized full run, it can start small and continue without another pilot-approval stop. By default, it leaves changes uncommitted in an isolated worktree. Commits and pull requests depend on the authority given for that run.

Its dependency handling is more explicit too. The primary agent accepts, integrates, and checks a prerequisite before releasing work that needs it. Unrelated tasks can continue. A required check that can't run leaves the affected task blocked.

These are different procedures with the same name. The two-run token comparison above belongs to the Claude bridge.

The checks that earned their place

The bridge's own incident notes record a worker writing code into the repository root instead of its assigned worktree. The task branch looked untouched, so the reviewer reported that the worker had done nothing. The implementation was sitting in the shared checkout.

That is why the post-run check includes the root's git status. Check where the edits landed before paying for another attempt, and preserve any unrelated work when recovering them.

Another task passed review with six TypeScript errors. The reviewer had inspected the diff, the record of changed lines, without a working typecheck. Those errors would have been caught by tsc --noEmit, which checks TypeScript without generating output files.

The pilot limits how much work reaches that failure state at once. One recorded pilot used roughly 410K workflow tokens and produced zero clean passes. The skill's notes recommend considering a direct repair when this happens, after checking for misplaced edits and misleading acceptance checks. Repeating the same dispatch is another paid attempt at the same problem.

Moving implementation to another subscription gives me more room to work. I still have to decide whether the result is worth keeping. The six TypeScript errors are a useful reminder of where that decision belongs.

Get the skills

The public skills repository contains both versions. The Claude bridge uses Terra/medium for implementation and high effort for repairs. The native Codex package includes dynamic-workflows-codex and session-orchestration.

Download the Claude bridge ZIP or the native Codex ZIP. Both were refreshed on September 8. Each includes install scripts; select claude or codex as the target. The README lists prerequisites and the small safety changes made for the public copies. Existing files are skipped unless you request an overwrite; the scripts leave your settings alone.

The bridge needs an authenticated Codex CLI and permission for Claude to invoke codex exec. Check that its model setting is available in your Codex installation before running it. In my current local workflow, WORKER_MODEL, WORKER_EFFORT, and REPAIR_EFFORT in the workflow script control the worker settings; they're passed into each task.

dynamic-workflows-plan can also be used on its own to prepare a plan. Start there if the work orders still need attention. Another worker won't fill in a missing decision for free.