My AI coding setup: Claude Code as an orchestrator, not a writer

Let me start with the honest constraint, because it shaped everything: I don’t have $200 for a top-tier AI plan, and I don’t have $100 either. What I have is a $20 Claude Code account and about $20 I invested myself. That’s the budget. And I’m genuinely happy with what it gets me.

The trick is a change in role: Claude Code doesn’t write my code — it orchestrates other agents that do.

The idea

If you’ve used Claude in headless mode (claude -p), you know you can run agents non-interactively and drive them from a script. I lean on that hard. My setup is usually three agents, sometimes four depending on the task:

• Claude Code (Opus) as the orchestrator. It plans, decomposes the work, and hands out small instructions — but it does not write the actual code. (I used to reach for Fable too; that’s gone now, so Opus is the brain.)
• Cheap worker agents that do the writing. These run open-source models in headless mode and take the small, well-scoped tasks the orchestrator hands them.

The orchestrator’s job is to think and delegate; the workers’ job is to type.

Why Claude Code for the orchestration

People ask why Claude Code is the orchestrator and not Cursor or Codex. The real reason is Claude Code’s background shell. When I launch a worker in a background shell, Claude Code doesn’t sit there polling it — it isn’t waking up every 5 or 60 minutes to check if the worker is done. It just stops and gets out of the way.

When the worker exits — exit code 0 or an error — Claude Code is notified, picks back up, reads the worker’s output from a file, and verifies the result. That’s the whole loop.

This matters a lot when a worker takes 30 to 60 minutes. There’s no wasted polling and no orchestrator tokens burned while it waits — the orchestration is event-driven on the worker finishing, which is exactly the shape this workflow needs. That single feature is why the orchestrator lives in Claude Code.

The economics (why this is worth it)

This is the part I’m oddly proud of. The workers run on very cheap CLIs:

• cmd — a worker CLI whose subscription is about $1/month, and that $1 gives you around $10 of inference on open-source models. Run a strong open-source model like DeepSeek V4 Pro and it effectively stretches to roughly $40 of inference. Forty dollars of model output for a dollar is a lot.
• Cursor — my other worker.

So the whole thing runs on about $20 of Claude Code plus ~$20 I invested myself — and for that I get an orchestrator brain plus a small fleet of workers to fan tasks out to.

The workflow

I wrote two skills for this — orchestrate and build-features-autonomously — and a Python orchestrator that dispatches and manages the worker agents (pluggable adapters, run directories, per-task logs, and resumable sessions). The orchestrator is its own tool now, orca, open and pipx-installable at github.com/mokbhai/orca.

orchestrate breaks a task into small chunks and delegates each to a worker (cmd, or another CLI). The instruction Claude hands down is tiny — usually something like “take this section, trim it, and add it to this file” — a few hundred tokens, often under 300. Claude never writes the whole function; the worker does.

Where it actually paid off

The clearest example: I had to modularize around 14,000 lines of code spread across a few files. A single Claude Code session can’t really do that — it would hit its limit in half an hour to an hour, because 14k lines is a huge number of tokens and having one instance rewrite all of it into new files is the wrong tool for the job.

So instead of letting Claude write the code, I had it delegate: for each chunk, Opus writes a short instruction, a worker does the actual rewrite into the target file, and the orchestrator waits for it to finish before moving on.

The token math is the whole point. If a function is ~1,000 tokens to write, and Claude only writes an under-300-token instruction to a worker instead, I’m saving roughly 70% of the expensive orchestrator tokens on every chunk. Across 14k lines, that difference is enormous — and it kept the whole job inside one Claude budget instead of blowing past it.

The honest tradeoff

It’s not free lunch. The worker agents are slower, because each one has to rebuild its context before it can work. There’s a resume feature and a fork feature to carry context forward, but I found that for open-source models like DeepSeek, keeping the context window clean actually gave better results than dragging a long history along. So I traded some wall-clock speed for lower cost and more reliable output — a trade I’ll happily take when the alternative is not being able to do the task at all.

And honestly, the extra time costs me nothing. I usually kick these runs off at night: I leave the laptop on, give Claude Code one prompt, and it just loops — orchestrating, delegating, verifying, on and on. I get a good night’s sleep while the work gets done, and I wake up to a finished job. Slow workers don’t sting much when you’re asleep for the slow part.

Why I like it

This setup is the closest thing I have to a personal philosophy about AI coding: spend the expensive model on thinking, spend the cheap models on typing. It’s also just fun to build — I used this exact orchestrator to audit eleven repositories in parallel while putting together my own portfolio. On a ~$40 total budget, that feels like a good deal.

The orchestrator is open as its own tool — orca — at github.com/mokbhai/orca, installable with pipx. I only wired up a handful of worker adapters myself, and the whole point is that you should be able to plug in your own agents; if you use a CLI I haven’t added, that’s exactly the kind of contribution I’d love. (The skills that drive it live at github.com/mokbhai/claude.)