One Orchestrator, Three CLIs: Can Delegating to Codex and Gemini Really Save Your Claude Tokens?

Like a lot of developers in 2026, I've ended up with three AI coding CLIs installed on the same machine, and each one earned its place for a different reason:

• Claude Code — the orchestrator-grade agent. Best at multi-step reasoning, architecture, debugging, and working across a large codebase. Also the one whose tokens I care most about.
• OpenAI Codex CLI — a capable coding agent that's excellent when you hand it a well-scoped, self-contained task with a precise spec.
• Google Gemini CLI — the multimodal workhorse. Image generation, audio and TTS, transcription, and high-quality translation, especially for regional languages.

At some point the obvious question arrives: the smartest of the three is also the most expensive to run all day. So can I make it the manager? Give Claude a task, have it split the work, hand pieces to Codex and Gemini, and let them report back with a markdown file when they're done — while Claude only spends tokens on the hard parts and the final review?

I've now run this pattern for weeks of real work — a full marketing-site redesign, a fleet of AI-generated hero images, translations into eight languages, utility scripts, bulk content work. This post is the complete playbook: how the pattern works, the exact prompt shapes I use, the report contract that keeps it honest, where the savings are real, and the two hidden costs that decide whether the whole thing is worth it.

The short answer: yes, the pattern works, and the savings are real — but only if you engineer the handoffs properly. The long answer is everything below.

First, understand what you're actually paying for

Before any strategy makes sense, you need a clear picture of where tokens go in an agentic CLI session. Roughly four buckets:

1. Input tokens — everything the model reads: your prompt, file contents, tool outputs, prior conversation. In a long coding session this dwarfs everything else, because the agent re-reads context on every turn.
2. Output tokens — everything the model writes: code, prose, tool calls. Usually billed at a higher rate than input.
3. Re-reads — the silent killer. Every time an agent opens a 1,000-line file "just to check something," you pay for those 1,000 lines again as input.
4. Rework — the compounding killer. A misunderstood task costs you the first attempt, the review that catches it, and the second attempt.

Delegation attacks buckets 1 and 2: the sub-agent's generation happens on its bill (a different subscription, a cheaper model, or a free tier), and the orchestrator only reads a compact summary. But delegation done badly inflates buckets 3 and 4 — and that's the whole tension of this article.

The orchestrator pattern, properly defined

Here's the architecture in its simplest form:

            ┌─────────────────────────┐
            │   YOU (one instruction)  │
            └───────────┬─────────────┘
                        ▼
            ┌─────────────────────────┐
            │  CLAUDE (orchestrator)   │
            │  plans · splits · specs  │
            │  reviews · integrates    │
            └─────┬──────────────┬────┘
        spec + exact output path │
              ▼                  ▼
   ┌─────────────────┐  ┌─────────────────┐
   │  CODEX (coder)   │  │ GEMINI (media)   │
   │ scoped modules,  │  │ images, audio,   │
   │ tests, boiler-   │  │ translation      │
   │ plate, scripts   │  │                  │
   └────────┬────────┘  └────────┬────────┘
            │  artifacts → disk   │
            │  report.md (≤40 ln) │
            ▼                     ▼
            ┌─────────────────────────┐
            │  CLAUDE reads reports,   │
            │  verifies, fixes/retries │
            │  or integrates & ships   │
            └─────────────────────────┘

The orchestrator owns four things and only four things: the plan, the specs, the review, and the integration. Everything bulky and mechanical gets pushed down, with two non-negotiable rules:

Rule 1 — artifacts go to disk at an exact path. The sub-agent never pastes its output into the conversation. It writes files. The orchestrator's context stays clean.

Rule 2 — the reply is almost nothing. Ideally a single word plus a short markdown report. The report is the only thing the orchestrator is guaranteed to read.

If you remember nothing else from this article: the delegation prompt and the report are the only two places the orchestrator spends tokens on a delegated task. Everything else is someone else's bill. Your entire optimization surface is those two documents.

Walkthrough #1: delegating image generation to Gemini

This is the highest-value delegation I run, because the orchestrator literally cannot do it — Claude Code has no image model behind it. Here's the actual shape of the prompt Claude writes and fires at the Gemini CLI:

Generate a single photorealistic editorial corporate portrait.
Concept: <detailed art direction — subject, pose, wardrobe,
lighting, background, composition>.

CRITICAL: the entire subject must be fully inside the frame with
generous margin on all sides — do not crop arms or held objects.
Plain seamless light-grey studio background for easy cutout.
No text, no watermark, no logos, no props.

Save the image to /tmp/work/hero-cyber.png (overwrite if it exists).
Then reply only DONE.

Notice the engineering in this prompt:

• The output path is exact. No "save it somewhere" — the orchestrator knows precisely where to look, so there's zero back-and-forth.
• "Reply only DONE." The Gemini CLI would happily narrate its creative process for 400 tokens. We don't want it. One word.
• Constraints are spelled out mechanically ("fully inside the frame," "no watermark") because every constraint you don't write is a rework roulette spin. I learned each of those lines from a failure — more on that below.

Then the orchestrator runs a quality gate before ever looking at the image — a cheap, mechanical check:

# does the file exist and is it non-trivial?
test -s /tmp/work/hero-cyber.png || echo "FAILED: missing/empty"

# entropy gate: catches blank/placeholder images without
# spending any model tokens at all
python3 -c "
from PIL import Image; import sys
img = Image.open('/tmp/work/hero-cyber.png')
# a flat placeholder has near-zero entropy; a real photo is > 4
print(img.entropy())
"

Only after the gate passes does the orchestrator actually view the image once — a single vision call — to check the things a script can't: composition, artifacts, brand-safety. That's the entire token cost on the orchestrator's side: one short prompt out, one word back, one image view.

Run these in the background. Image jobs take one to five minutes. A blocking wait means your orchestrator sits idle holding its whole context in memory. Fire the job, continue with other work, come back when the file lands. Every serious agent CLI supports backgrounding now; use it.

Walkthrough #2: delegating a coding task to Codex

Coding delegation is trickier, because the failure mode isn't a bad image you can see at a glance — it's plausible-looking code that doesn't fit your codebase. The fix is a spec so tight that "done" is machine-checkable:

TASK: Write a standalone Node script at scripts/import-legacy.mjs

SPEC:
- Reads ./data/legacy-export.csv (papaparse is already a dependency)
- Maps columns per the table below … (exact mapping)
- Writes ./data/import-ready.json, an array of objects
- Node 22, ESM, no new dependencies
- Handle: missing fields → skip row + count; duplicate IDs → last wins

ACCEPTANCE (all must pass):
- node scripts/import-legacy.mjs runs clean on the sample file
- node --test tests/import-legacy.test.mjs passes (write these tests)
- npx eslint scripts/import-legacy.mjs → zero errors

REPORT: write REPORT-import.md (max 40 lines) with status, files
created, how to verify, and up to 5 gotchas. Do not paste file
contents into the report.

Three properties make this delegable where most coding tasks aren't:

1. Self-contained — one new file, no edits to existing modules, no architectural decisions.
2. Machine-checkable acceptance — the orchestrator verifies with three commands, not by reading the code line-by-line.
3. Bounded interface — input file, output file, done. The sub-agent can't wander into the rest of the codebase.

When the report lands, the orchestrator runs the acceptance commands (cheap), skims the gotchas (cheap), and only opens the actual code if something fails or smells wrong. On a clean pass, the orchestrator never reads the 300 lines it would otherwise have written — that's the saving.

Where the savings are real — with rough math

1. Bulk generation. Say a task produces 2,000 lines of output (~25k tokens). Done directly, the orchestrator pays ~25k output tokens plus all the context-reading around it. Delegated, the orchestrator pays: a ~300-token spec, a ~400-token report read, and a few hundred tokens of verification commands. Call it ~1k tokens against ~30k — a 95%+ reduction on that task, with the generation itself billed to the sub-agent's quota.

2. Work the orchestrator can't do anyway. Every image, every audio file, every one of the eight-language translation batches I've shipped lately was generated by the Gemini CLI from a spec the orchestrator wrote. There is no Claude-native alternative to compare against — this is pure capability gain, and the token cost is just spec + report.

3. Long mechanical output with a precise spec. Test scaffolding, data migrations, boilerplate modules, format conversions, doc drafts from an outline. The common thread: low judgment, high volume. Volume is exactly what output tokens price; judgment is exactly what the cheap agent lacks. Delegate volume, keep judgment.

Where the savings evaporate — the two taxes and one overhead

The verification tax

This is the cost nobody prices in, so let me give you the receipts from my own project — a batch of AI-generated hero portraits for a website:

• One image came back with a competitor-recognizable laptop logo baked into the shot. Legally and brand-wise unshippable. Regenerate — no wait, actually patch it out with an image tool, then re-verify.
• Another set had corners that claimed to be transparent but weren't — an opaque near-white that only showed against a tinted background. Caught late, fixed with a flood-fill pass, re-verified.
• A third had the product tablet generated half out of frame — the model cropped the very object the image existed to show. Full regeneration with a new "everything fully inside the frame" constraint line.

Every one of those images passed the cheap mechanical gates. Every one still needed the orchestrator to actually look, judge, and route a fix. The delegation didn't remove the review step — it moved the generation cost elsewhere and left the review cost exactly where it was.

And when a delegated task fails review, you pay three times: the delegation, the review that caught it, and the redo. Two failed delegations of the same task usually cost more than the orchestrator doing it directly the first time. That's why every constraint line in my image prompts reads like a scar — each one is one.

Budget rule: assume 20–30% of delegated creative tasks need a fix cycle, and price that into your decision. If the task is cheap to verify (run the tests, check the file), delegation wins even with rework. If verification means "read everything carefully," the savings were an illusion.

The integration tax

If the task touches many files, must match your codebase's conventions, or depends on context that lives in the orchestrator's head — architecture decisions, a cross-module refactor, a race-condition debug — handing it off is a false economy. The sub-agent doesn't have your context; the orchestrator ends up re-reading everything the sub-agent touched just to integrate it safely. You've paid twice for the same understanding: once for the sub-agent to build its own partial picture, once for the orchestrator to rebuild the full one.

The tell is simple: if writing the spec requires explaining your architecture, don't delegate the task. The spec-writing alone costs more than the savings, and the misunderstanding risk is enormous.

The overhead floor

A good delegation prompt costs 200–400 tokens to write. Reading a report costs 300–500. Verification, another few hundred. So there's a floor: if the task's direct cost is under roughly 1,000–2,000 tokens (~50–100 lines of output), delegating it loses money every time. Just do it.

The markdown report contract — where the savings live or die

The idea that makes this pattern click for most people is the report file: each sub-agent finishes and drops a markdown summary for the orchestrator. It's the right instinct — and it's also exactly where the whole scheme quietly fails. If Codex writes a 500-line report and Claude reads all of it, you paid anyway — just in reading instead of writing.

Here's a bad report (this is what agents produce if you don't constrain them):

A 340-line essay: restates the task, narrates every decision chronologically, pastes in the full contents of two files it created "for reference," includes the complete test output, and closes with three paragraphs of caveats and suggestions for future improvements.

Reading that costs more than writing the code did. Here's the contract I enforce instead:

# Task: import-legacy script
Status: DONE
Files created:
  - scripts/import-legacy.mjs
  - tests/import-legacy.test.mjs
How to verify:
  - node --test tests/import-legacy.test.mjs
  - node scripts/import-legacy.mjs && head data/import-ready.json
Gotchas:
  - 14 rows in the sample CSV had no email; skipped, count logged
  - CSV dates are DD/MM/YYYY, not ISO — parser handles both

And the four rules that keep every report this shape:

1. Hard cap: 40 lines. State it in the delegation prompt. Status, paths, verify commands, gotchas — nothing else.
2. Paths, never contents. Artifacts live on disk; the report points at them. The orchestrator opens a file only when verification demands it — reading twice becomes a choice, not a default.
3. "Reply only DONE" for pure generation. When the artifact speaks for itself (an image, an audio file), even a report is too much. File lands, one word comes back, gates run.
4. Machine-checkable acceptance criteria in every spec. "Make it nice" produces rework. "All tests pass, zero lint errors, output is a 1200×630 JPEG under 200 KB" produces a pass/fail the orchestrator verifies in one command. The quality of your acceptance criteria is the quality of your delegation.

Division of labor: who gets what, and why

Task	Give it to	Why
Images, audio/TTS, transcription	Gemini CLI — always	Orchestrator can't do these at all; pure gain
Translation (esp. regional languages)	Gemini CLI	Strong quality, high volume, trivially verifiable by sampling
Self-contained script/module with a tight spec	Codex CLI	High volume, low judgment, machine-checkable
Test scaffolding, migrations, boilerplate	Codex CLI	Mechanical output; acceptance = the tests themselves
Architecture & design decisions	Claude — never delegate	Pure judgment; spec would cost more than the task
Multi-file refactors, integration work	Claude	Integration tax makes delegation a false economy
Debugging	Claude	Requires accumulated context; sub-agent starts from zero
Final review of everything delegated	Claude	This is literally the job you're paying the premium model for

One nuance worth stating: this isn't "Claude good, others bad." It's volume versus judgment. Codex writes excellent self-contained code; Gemini's image and translation quality carries real production work. The split is about what each seat costs and what each task needs.

The operational playbook

A handful of habits that compound the savings:

Background everything slow. Generation jobs run one to five minutes. Fire them detached, keep the orchestrator working on something else, process results when files land. Never let the expensive agent block-wait.

Batch aggressively. Six images as six conversations is six rounds of prompt+report overhead. One prompt that produces six files with a naming convention (hero-01.png … hero-06.png), one report, one review pass. Same for translations: all eight languages in one delegation.

Gate mechanically before reviewing intelligently. File exists → size sane → entropy/lint/tests pass → then spend orchestrator tokens on judgment. Every failure the gate catches is a model-review you didn't pay for.

Fail fast, escalate once. If a delegation comes back wrong, the orchestrator gets one corrective retry with a sharpened constraint ("the previous attempt cropped the tablet — the ENTIRE tablet must be visible"). If the retry also fails, stop delegating that task; the orchestrator does it directly or routes around it. Endless retry loops are how delegation becomes the most expensive way to do anything.

Keep the orchestrator's session clean. Long-running orchestrator sessions accumulate context, and context is input-token rent you pay every turn. Delegation helps precisely because artifacts stay on disk instead of in the conversation — don't undo that by cat-ing files into the chat "to have a look."

Write the constraints you learned into the templates. Every rework teaches you a prompt line ("no watermark," "fully inside frame," "no new dependencies"). Templates are how you stop paying for the same lesson twice.

What a week of this actually looks like

Qualitatively, after running the pattern across a real project week: the orchestrator's context stayed small and its turns stayed fast, because bulk output never entered the conversation. The visible token spend shifted almost entirely to specs, reports, and review — which is exactly where you want the premium model spending its attention. The sub-agents burned their own quotas on volume. And the failures were real but boundable: a fix cycle on roughly a quarter of the creative generations, near-zero rework on tightly-specced code tasks, and one task (a cross-cutting refactor) that I correctly kept with the orchestrator after the spec draft started turning into an architecture document.

The pattern didn't make the expensive model cheaper. It made me stop using it as a typist.

The verdict, and a checklist

Is the strategy right? Mostly, yes. The savings are real and large for generation-heavy work — that's delegation of output, and output is what you pay for. The savings are an illusion for judgment-heavy work — that's delegation of understanding, and understanding always lands back on the orchestrator's bill, usually with interest.

Treat the expensive CLI as a picky tech lead with a great, cheap team: it writes specs, reviews small reports, and only opens the hood when something smells wrong.

Before you delegate a task, run the checklist:

• Is the output big (>100 lines / >2k tokens) or something the orchestrator can't produce at all?
• Can I write the spec without explaining my architecture?
• Is "done" machine-checkable (tests, lint, file properties) rather than "read it all carefully"?
• Is the output path exact, and the reply constrained to DONE + a ≤40-line report?
• Have I budgeted one fix cycle — and decided what happens if it fails twice?

Five yeses: delegate it, background it, gate it, and enjoy the math. Any no: the premium model does it directly — because the most expensive tokens you'll ever spend are the ones spent twice.