Most people use coding agents the same way: one model, one chat, you watch it type. If the model is good, it's expensive. If it's cheap, you end up babysitting it.
I stopped doing that. Right now I run several projects at the same time, and the most expensive model in the setup doesn't write a single line of code.
Maybe this is new to you. Maybe you've been doing it for a year. If you have, I'd like to hear how you do it differently (see the end).
Three roles, one job each
Strategist. One Claude Code session per project, at high reasoning effort. Every 5 minutes (/loop 5m) it looks at what the orchestrator is doing: what it picked, what it shipped, what's stuck. It doesn't write code. It decides whether the work is going in the right direction.
Orchestrator (Orchestro Minimal). Holds the backlog, picks the next item, hands it to an executor, and records what happened.
Executor (Muse). A cheaper coding agent on a flat subscription. It does the actual work: branch → change → tests → PR → merge only if verification is green → check that the change is live.
Strategist (project) Strategist (framework)
Claude, every 5 min maintains the orchestrator
│ framework problem ──────────▲
│ │
project ▼ │
problem → backlog ──► Orchestro ──► Muse (cheap executor)
picks code → test → PR → merge → verify
The rule that makes it work: two kinds of problems
When the Strategist finds something wrong, the first question is whose problem is it?
- A project problem (a bug, a wrong priority, a missing item in the backlog): the Strategist fixes the backlog directly. The executor picks it up on the next round.
- A framework problem (the orchestrator picks the wrong item, gets stuck, never closes work): the Strategist doesn't patch around it. It reports it to another session whose only job is maintaining the orchestrator. That session fixes the core and ships the new version to every project.
A real one, from 14 October: the Strategist watching my blog's content pipeline noticed that since we switched to the lighter orchestrator, nothing had been verified for a day. Work was shipping, but the orchestrator only recorded "delivered", never "verified", so the verifier never saw it. That's not a blog problem, it's a framework problem. It went to the framework session, not into a local workaround.
Every project ends up testing the framework, and every fix to the framework helps every project. I don't plan improvements to the orchestrator in advance. Real projects find them.
Why mix models: cost and recovery
The orchestrator doesn't care which model executes. A project declares its executor (Claude, Codex, Grok or Muse are supported). That gives me two things:
- Cost. Thinking is expensive, typing is cheap. The expensive model reads state every 5 minutes; the cheap one does the long runs. All of them run as CLI subscriptions, not pay-per-token API calls, so a new fix costs nothing extra. My full cost is just [X €/month in subscriptions] ÷ verified fixes per month.
- Recovery. When one provider runs out of quota (this week it was Codex), work doesn't stop. The item stays in the backlog with its evidence, and another executor can pick it up.
Numbers so far, including the bad ones
- Blog content pipeline, 3–14 October: the independent verifier issued 95 verdicts: 87 passed, 7 failed, 1 inconclusive.
- The orchestrator's own repo, same period: 63 merges and 0 passed independent verification (8 failed, 13 inconclusive).
- After switching to the lighter orchestrator on 13 October: 0 verification records on the blog for the first day, until the Strategist caught it (the bug above).
The lesson I keep relearning: merged is not verified. A setup that only counts merges will look great and lie to you.
What still doesn't work
- Executors still say "done" when they haven't done it. That's why the Strategist reads state, not messages.
- A Strategist checking every 5 minutes is mostly checking quiet systems. [Number of checks per verified fix, once measured.]
- Two heavy builds on the same machine fight each other. Today a shared lock serializes them; that's a workaround, not a design.
I know this isn't entirely new
Planner/executor splits, supervisor agents and model cascades exist. What I haven't seen elsewhere is the combination: a cheap supervisor on a fixed clock, problems routed by owner (project vs. framework), and a separate session that improves the orchestrator from what real projects break.
If you already work like this, or you solved the same problem in a different way, tell me how. Especially:
- How often does your supervisor check, and what does it actually look at?
- How do you decide what's a project problem and what's a tooling problem?
- What's your real cost per verified change, not per merge?
I'll update this post with the best answers.
The orchestrator is Orchestro. It's in a very small private beta, mostly used on my own projects. If you want to try it on yours: orchestro.org.
Top comments (0)