Three Models, One Refactor: Opus, Haiku, Codex
A recipe for splitting a multi-file refactor across three models: Claude Opus writes the brief, Haiku audits it, and Codex executes the audited plan.
This post describes a pattern for multi-file changes: split the work across three models by the kind of thinking each one is good at. One model writes a brief, a cheaper model audits that brief, and a third model executes the audited plan. It is a recipe, not a report of a measured run. We have not published measured cost, token or timing figures for it, and nothing here should be read as a benchmark.
Why split a multi-file change at all
A refactor that touches many files, such as service definitions, environment templates, deploy scripts, reverse-proxy config and runbooks, invites one failure mode: context sprawl. If a single prompt carries every file, every constraint and the full target state, the model tends to satisfy the first requirement and drift on the later ones. It is also an expensive way to do repetitive edits.
The alternative is to produce three separate artifacts: a brief, an audit and an execution pass. Each handoff has one artifact and one job, which makes the plan reviewable before anything is changed.
Step 1: a strong model writes the brief, and never touches files
Give your strongest reasoning model (Claude Opus in this recipe) a short prompt: the file paths, the current topology, the target topology and the constraints. Do not let it edit anything. Its job is to reason about dependencies, ordering, failure modes and rollback.
Ask for a markdown brief containing the step order, the intent for each file, required environment variables, validation commands and rollback triggers. Keeping the prompt to a file tree and the expected changes, rather than the full contents of every file, forces the brief to define intent and checks instead of reproducing implementation details.
Step 2: a cheap model audits the brief
A plan is not a plan until something adversarial reads it. Send the brief to a smaller, cheaper model (Haiku in this recipe) with one narrow instruction: you are reviewing a migration plan; list every missing dependency, ordering error and rollback gap; do not rewrite the plan; do not write code; return a numbered list.
Typical findings are a secret referenced in one place but not another, a reload order that could drop connections, a rollback step that assumes something that does not exist, or a documented environment variable that is never exported. Fold the valid findings back into the brief before any file is edited, and discard the ones that do not hold up. The auditor has no stake in defending the plan, which is the point.
Step 3: a coding agent executes the audited brief
Hand the audited brief to a coding agent (Codex in this recipe) as its source of truth. It applies the patches, runs the validation commands from the brief, checks the diff and iterates. The agent is the executor, not the strategist: if the brief is precise, execution is mostly mechanical.
Good hygiene for this step: pin the repository to a known commit, have the agent work on a separate branch, and review the resulting diff against the brief before merging. Some agent CLIs offer a flag that skips approval prompts. Use anything like that with great care: it removes the human checkpoint, so it belongs only in an isolated, disposable workspace and never on a machine or repository you cannot afford to damage.
The delegation triangle: brief, audit, execute
Opus produces the brief. Haiku audits the brief. Codex executes the audited brief. This is routing by cognitive shape rather than by price alone: architecture goes to the model that reasons best, gap-finding goes to a model that is cheap and adversarial, and bulk implementation goes to an agent built for large, mechanical edits.
The artifacts can be versioned alongside the code. The brief explains why, the audit explains what could break, and the execution produces the diff. Someone reading the repository later can follow the change without asking the original author.
Cost and quality: what to expect
The economic argument is directional, not measured. The most expensive model is used on a short prompt, the cheapest model is used at the point where a mistake is cheapest to catch, and the bulk of the token volume goes to whichever execution option has the lowest marginal cost for you, such as a flat-rate subscription. Costs depend on the models and plans you use and on the size of the change; we have not published measured figures for this pattern.
The quality argument is also a hypothesis you should test on your own work: a single model asked to architect and edit at once has to hold two modes at the same time, and separating them gives you an audit point before anything changes. The overhead is one extra call and one extra document. For small, single-file changes that overhead is not worth it; the pattern is aimed at changes that span several files or more than one deploy target.
When to use it
Use the triangle when a change crosses multiple files or services and a bad rollback would be costly. Skip it for trivial edits. In either case, treat the audit as a filter, not an oracle: a cheap model can raise false alarms, so a human should still read the brief and the final diff.