Opus planned, Haiku audited, Codex executed. Total cost: one cent. That's the full ledger for a 12-file infrastructure refactor Tacavar ran through its own agent stack. It wasn't a promotional stunt or a benchmark with a favorable exchange rate. It was multi-model orchestration applied to an unglamorous engineering task: moving three MCP servers across two droplets and updating a dozen related service files. The result was a production-quality migration at a price that makes per-token pricing feel broken. ## The Refactor: 3 MCPs, 2 Droplets, 12 Files The task itself would be familiar to anyone who runs agent-heavy infrastructure. Tacavar needed to migrate three MCPs from one droplet to another and update every configuration, import, and runtime reference across twelve files. That's not novel work. It's exactly the kind of thing founders assume AI should automate, and exactly the kind of thing that usually goes sideways when one model is asked to handle the whole lifecycle. The first instinct is to paste the current state into a frontier model and say, "Plan this and do it." That's how a two-hour migration becomes a two-day debugging session. The model plans, writes, second-guesses, rewrites, and finally leaves a few stale references for the staging environment to discover. Tacavar's own control plane depends on these MCP connections, so we couldn't afford a sloppy cutover. We needed a plan, a check, and a flawless execution pass. So we split the work along the lines of what each model is actually good at. ## Why One Model Shouldn't Do Everything A single model asked to plan, audit, and execute has too many jobs in one context window. Planning requires compression: stare at the current state, decide what matters, and discard the rest. Auditing requires paranoia: look at the plan as if it were written by a stranger and find every logical gap. Execution requires endurance: touch 120,000 tokens of files without getting tired or improvising. Those are different cognitive modes, and frontier models are unevenly built for them. Claude Opus can reason through architecture tradeoffs that would make most engineers reach for a whiteboard. Haiku can read a plan and spot an inconsistency in milliseconds, for almost no money. Codex can perform large-scale file manipulation across an entire repo without developing opinions about your naming conventions. Using Opus to write file edits is like using an architect to lay bricks—it works, but you're paying a premium for a model doing something outside its edge. That's the core of LLM cost optimization: not choosing the cheapest model, but making sure each token is spent on the work that token is best at. The most expensive token is the one that produces output you have to throw away. In a single-model workflow, throwaway output is the default. In a delegation pattern, it's rare. ## The Delegation Triangle: Architect, Auditor, Executor Tacavar used three roles. First, the architect: a short, dense prompt to Claude Opus. The prompt contained the current topology, the target topology, and the non-negotiables. Opus produced a migration brief. It never touched a file. It didn't see the full contents of the twelve files, because it didn't need to. Its job was to make decisions: which MCP configs move, which health-check endpoints change, which order the cutover steps should follow. That brief cost less than a cent because it was short. The expensive model was used exactly where it creates the most leverage. Second, the auditor: a single Haiku call to review the plan against the actual file tree. This is the step most people skip, and it's the difference between a plan and a correct plan. Haiku found a stale reference to the old droplet's health-check URL, a missing environment variable for MCP auth, and a permission issue in the deployment script. All for $0.001. None of those errors were hard to fix, but catching them before execution instead of after saved real time and kept the rollout boring. Third, the executor: Codex. With the audited brief locked, Codex executed the migration across more than 120k tokens of implementation. It ran in an isolated workspace with --dangerously-bypass-approvals, which is only acceptable in a disposable environment. Because every architectural decision was already made, Codex didn't need to think hard. It just needed to move fast and stay consistent. That's what Codex execution is built for, and it is much better at that job than a reasoning model trying to do the same thing. This is the AI delegation pattern in its purest form: each model only does the work it has a comparative advantage at. ## Cost Breakdown: $0.01 vs a Single-Model Approach Let's put the numbers on the table. The Opus architecture brief was short enough to keep the total bill at roughly a penny. The Haiku audit was $0.001. Codex used the ChatGPT Pro subscription Tacavar already relies on for bulk execution work, so the marginal cost for the executor was zero. Total out-of-pocket: $0.01. Now imagine the single-model approach. One premium model gets the full context, plans, writes, aud—no, you won't get a separate audit. It just starts editing files. A 120k-token implementation run is not a single inference call. It's iteration after iteration of reading files, generating diffs, hitting errors, fixing them, and re-reading. That kind of workload on a flagship API can easily cost more than a dollar or two in a single session, and that's before you account for the human time spent reviewing the damage. The old approach is more expensive not because the tokens cost more, but because the model is doing work it's not specialized for. The cost lesson is not "use cheaper models." The lesson is that cost follows role. Architects should be used for architecture, auditors for auditing, and executors for execution. When you split the roles, the model that's expensive per token gets a small, high-value prompt, and the model that's great at volume gets the volume. ## The Hidden Quality Win of Model Specialization The quality argument is usually where people get skeptical. "Won't I lose context by splitting the work?" No. You lose context by mixing work. Tacavar's refactor ended up cleaner than previous single-model migrations because each phase had a different standard of review. Opus never wrote a line of code, so it never got attached to an implementation it would have to defend later. Haiku audited the plan from a clean perspective, and its cheapness made it possible to run the audit as a separate, serious step instead of a self-review that gets skipped. Codex executed without an architectural agenda. It didn't "helpfully" refactor unrelated services or introduce a new pattern at file nine. It followed the brief, because the brief was the only thing it had. That's the hidden quality win of model specialization. Multi-model orchestration isn't just a cost play. It's a quality play because fewer decisions per model means less drift per model. The output was a 12-file changeset that looked like one competent engineer prepared it, a second reviewed it, and a third typed it—without the usual multi-hour context gap between those steps. ## How to Replicate This Pattern in Your Own Pipeline You don't need custom infrastructure to start delegating. You need three disciplines. First, give the architect a compressed brief, not a file dump. Claude Opus does its best work when it's reasoning about constraints, not scrolling through code. If your architecture prompt is so long that the cost stops being negligible, you've turned the architect into a reader. Second, put an auditor between planning and execution. A cheap Haiku call over the plan and the current file tree will catch the logical gaps that an executor won't notice until runtime. Make the audit mandatory, not optional. At $0.001, the only reason to skip it is ego. Third, constrain the executor's freedom. Isolate the workspace, disable approvals only when the workspace is disposable, and make it clear that the executor is implementing a plan, not designing a new one. The more freedom you give an executor, the more decisions it will invent—and the more likely those decisions contradict the plan. Fourth, instrument the handoffs. Tacavar's routing layer records what each model produced, what changed between audit and execution, and what the final diff actually cost. That logged feedback is what turns a clever one-time hack into a repeatable pipeline. Next time, the pattern isn't a manual prompt chain; it's a template. Finally, stop treating multi-model orchestration as a clever workaround. Model routing is becoming the default operating model for serious AI work. The companies that learn it now will have a structural cost and quality advantage over the ones still forcing one model to wear every hat. Tacavar's agent routing makes delegation patterns like this turnkey. See tacavar.com/agents.