Orchestrator-Worker Agents: The Sidekick Paradigm

The sidekick paradigm is an orchestrator-worker pattern for AI coding: a strong, expensive model (Fable 5) plans, decides, and reviews, while a cheaper model (Sonnet 5) does the hands-on execution as a persistent subagent. Because the executor costs about 20% of the frontier model but the plan is already fully specced, you cut the cost of the actual work by roughly 80% with no drop in quality. This guide is the why, the cost math, and the copy-paste setup - in Claude Code and across any other agent you use.

Watch the full walkthrough, including the live cross-harness demos:

Why Does Claude Code Burn Your Quota So Fast?

You open Claude Code in the morning, give Fable 5 one real task, and by lunch you have hit the limit. Most people read that as "the quota is too small." I read it the opposite way: you are paying frontier prices for a model to do work a cheaper model would do just as well.

The newest, strongest models - Fable 5, GPT-5.6, Opus, Codex, Grok - are extremely capable, but they are also slow and expensive to run at scale. Point one at every step of a build and it burns out your quota in minutes. The fix is not a weaker model. It is using the strong model for the right role.

Here is the shift in one line: as the frontier gets stronger, the frontier model stops being the thing that writes your code and becomes the thing that decides what code gets written.

What Is the Sidekick Paradigm (Advisor-Executor Model Relay)?

The sidekick paradigm splits one job into two roles:

• Coordinator - a strong, expensive model that plans, decides, architects, and reviews.
• Executor (the sidekick) - a cheaper, smaller model that does the hands-on implementation.

The canonical setup is a Fable 5 orchestrator plus a Sonnet 5 worker. The coordinator produces a clear, unambiguous spec, and the executor turns that spec into code. This is now the officially recommended practice in Claude Code, not a hack.

The key word is role-based, not capability-based. You are not swapping in a worse model and hoping. You are handing the strong model the job it is uniquely good at - design, decision, review, spec - and handing the already-specced execution to a model that is cheap and plenty capable for a now-unambiguous task.

The Cost Math: Why the Executor Is ~20% the Price

The whole economic argument rests on one number.

Sonnet 5 costs about a fifth of Fable 5, yet performs close to what was the strongest model on the market a few months back. So when you move execution off the frontier model, you are not downgrading. You are paying 2026 prices for what was state of the art in spring. You pay frontier prices only for the thinking, not the typing.

Advisor vs Orchestrator: Which Pattern Wins?

Claude Code ships two ways to run this split, and the choice matters more than it looks:

1. Advisor-as-tool-call - the cheap model (Sonnet 5) is the main executor and calls up to the strong model (Fable 5) as an advisor to review its plan.
2. Orchestrator-spins-up-worker - the strong model (Fable 5) is the main orchestrator: it plans, writes a frozen spec, and spins up a smaller-model worker to execute.

The orchestrator method wins, and Devin actually ran both to prove it. The reason is token accounting, not intelligence. An advisor has to read the main agent's full conversation history to say anything useful - expensive fresh input tokens, every single time. A worker only receives a task, and it runs on cached context. Cached tokens cost roughly 10% of new input tokens.

Put bluntly: the advisor pattern quietly charges you frontier rates for re-reading your own transcript, over and over. Delegating down (orchestrator to worker) is both cheaper and cleaner than escalating up (executor to advisor).

This is also exactly what Devin Fusion is under the branding. It is a harness that claims frontier-level-or-better performance at about 35% lower cost by routing different task types to different models. Strip away the name and it is Claude Code's Fable 5 orchestrator plus Sonnet 5 workers. Useful as outside validation that the relay is a real, repeatable win.

What Makes a "Sidekick" Different From a Normal Subagent?

A traditional subagent spins up fresh, returns one message, and dies. The moment the main agent wants a revision, it calls the task tool again and spawns a brand-new subagent with zero context - which re-reads the same files, re-derives the same understanding, and burns the same tokens a second time.

A sidekick is a persistent, resumable session. When the main agent has feedback, it sends a follow-up message to the same worker, which still has everything it learned. And all of that context is now cached, so the follow-up is nearly free. Persistence is the whole trick: it is what turns "delegate" from a token tax into a token saving.

If you use Claude Code, you already have this. It is what Agent Teams is:

• Prompt Claude Code to use an agent team instead of a one-shot subagent.
• The SendMessage tool lets the main agent message an existing session.
• A finished teammate stays resumable until it gets a shutdown request.
• When you start a team session, you set the model per agent - strong lead, cheap workers.

So Fable 5 as coordinator and Sonnet 5 as executor, persistent and cache-warm, is available to you today with no infrastructure.

How to Set It Up in Claude Code (Delegation Rules)

The whole workflow is a delegation-rules section you add to your CLAUDE.md. It spells out three things: what to delegate, what to keep, and a road check so the subagent knows it is a subagent.

Delegation rules

You are the COORDINATOR. Your job is to design, decide, and review. Delegate hands-on execution to executor subagents running Sonnet 5.

DELEGATE to a Sonnet 5 executor:

• Feature implementation
• Refactors
• Writing tests
• Anything mechanical once the plan is clear

KEEP in the coordinator (do it yourself):

• Design and architecture decisions
• Planning and speccing
• Tiny one-line edits (delegating costs more than doing it)

For any non-trivial task, first write a FROZEN SPEC into /tasks so the executor has zero ambiguity, then spin up the executor.

ROLE CHECK: if you are an executor subagent, you do NOT spawn further subagents. Read the spec, do the work yourself, report back.

That last line - the role check - matters more than it looks. Without it, subagents recursively spawn their own nested agents and you get a fan-out you never asked for.

In practice: I start a session, ask it to design and build a to-do app. It asks clarifying questions, plans, and for anything non-trivial writes a frozen spec into a task folder. Then it spins up a Sonnet 5 subagent whose prompt is basically "your role is executor, read the spec first, do the work yourself, do not spawn subagents." Because the executor is Sonnet 5, it is much faster than building the whole thing with Fable 5, and it costs a fraction.

The delegation rules and the skill below are in the [AI Builder Club skills repo](https://github.com/AI-Builder-Club/skills/blob/main/skills/open-agent-teams/references/CLAUDE.delegation-template.md), so you can copy them straight into your own `CLAUDE.md`.

## Delegating Across Harnesses (Codex, Gemini CLI, and Anything Else)

In reality you probably run more than one agent. Codex on GPT-5.6 for some things, Gemini CLI for frontend, Kimi K3, whatever. The ideal is to keep the best model and harness as your coordinator, but let the executor be *any* agent you prefer.

Two bridges make that work.

**The Codex plugin for Claude Code.** The Codex team shipped a Claude Code plugin that delegates to a Codex agent. Install it, add OpenAI Codex, reload plugins, and you can tell Claude Code to hand a task to Codex. Its command set:

| Command | What it does |
|---|---|
| `codex rescue` | Treat Codex as a subagent for the task |
| `codex review` | Have Codex review the git diff |
| `codex result` | Fetch output from a specific Codex session |
| `codex resume` | Send a follow-up to an existing Codex session |
| `codex transfer` | Fork the conversation history over to the Codex side |

**The tmux hack for everything else.** tmux is a terminal multiplexer - it runs multiple persistent terminal sessions you can read and control. That means you can drive any CLI agent like a human:

```bash
# Start a second agent in a pane on the right and send it a message
tmux split-window -h "claude 'build a hello world page'"

# Send a follow-up to that pane (.1 targets the second pane)
tmux send-keys -t .1 "tell me a joke" Enter

# Read back whatever is on that pane's screen
tmux capture-pane -p -t .1

The one hard part is the notify-back: how does the worker tell the main agent it is done? tmux has a signal mechanism for that - the worker runs tmux wait-for -S <name> when it finishes, and the coordinator blocks on tmux wait-for <name> until it fires. Wire that up and you have real agent teams across any harness.

I packaged all of this into a skill called Open Agent Teams. It wraps the tmux plumbing behind clean commands - start a session, send a message, wait for a result, read the result - with adapters for Claude Code, Codex, Grok, Pi, and OpenCode. One prompt like "ask Codex to write a joke, then have Pi review it and Haiku check grammar in parallel, then you do the final review" runs end to end. It is open and free in the AI Builder Club skills repo: github.com/AI-Builder-Club/skills. The copy-paste delegation rules from the section above live right next to it at references/CLAUDE.delegation-template.md.

Want a Packaged Experience? Orca and Herd

If you would rather not hand-roll tmux, there are tools with this built in. I tested most of the options, and Orca gives the best experience. It is open source and free, ships an orchestration skill and CLI out of the box, and pairs it with a UI: a hierarchy view of subsessions, a Kanban board, token tracking, even a mobile experience. New sessions pop up as panes you can jump into and continue, and finished workers report back to the main agent automatically. It has been my daily driver for the past few weeks. Herd is a comparable option worth a look.

When Should You NOT Delegate?

Delegation is not free, so the coordinator should keep some work:

• Tiny one-line edits. Spinning up a worker and passing context costs more than just making the change.
• Design, planning, and architecture. This is the exact thinking you are paying the frontier model for. Do not hand it down.
• Ambiguous tasks. If the spec is not clear, delegating just moves the confusion. Write the frozen spec first, then delegate.

The rule of thumb: delegate execution, keep judgment.

Related Content

• Claude Code Agent Teams: Run an AI Project Group That Actually Coordinates - The full setup for the persistent multi-instance teams this pattern runs on.
• SubAgent: Context Isolation - Why one-shot subagents exist, and the context-saving job they do best.
• Dynamic Workflows: Orchestrate Subagents at Scale - Move the loop into a script and run up to 1,000 subagents without flooding context.
• AI Agent Reliability and Cost Control - Spend caps, halt conditions, and keeping a delegated fleet from burning money.
• Loop Engineering: The Complete Guide - The discipline of building systems that run agents, not prompting agents by hand.

Start Here

Add the delegation rules to your CLAUDE.md this week and run one real build through it. Let Fable 5 plan and spec, let Sonnet 5 execute, and watch your quota last the whole day instead of the whole morning.

Grab the delegation rules and the Open Agent Teams skill from the AI Builder Club skills repo, drop them in, and you are running the orchestrator-worker pattern in about five minutes. For the step-by-step workflows and the weekly live workshops - including the one-hour deep dive we did with the Orca founder on shipping hundreds of commits through orchestrated agents - come build with us.

Join AI Builder Club