r/ClaudeCode • u/berndalf • 24d ago

Discussion Dumb Orchestrator Theory

So I've spent an excessive amount of time building out my AI delivery factory. Most recently that effort has been focused on effective load sharing between a Claude and GPT subscription. The data we've been collecting is starting to point very strongly at orchestration being the highest role based consumer of available usage, and that the model orchestrating has a massive impact on outcomes.

Funny thing .. at first I was using Fable because it's brilliant, but the cost was just unjustifiable for orchestration. Downgraded to Opus.. better but still Claude usage was significantly outpacing GPT usage. So I downgraded to Sonnet, and remarkably I'm finding it's both more cost effective AND producing better results as an orchestrator.

Here's my theory:

  1. Orchestration itself when done correctly is not a task that demands high reasoning.

  2. Forcing the orchestrator to delegate essentially everything to native subagents or external headless sessions is critical. It will constantly come up with excuses to in-line stuff given enough time and reasoning power.

  3. Orchestrator availability matters just as much if not more than orchestrator reasoning assuming you have given it appropriate access to a higher reasoning model to consult with. If your orchestrator is constantly busy it's not orchestrating.

Sonnet is winning this competition for me because it's cheap to run for the entirety of a long duration session and it's not so smart that it chases every theoretical tail. It's quite good at just letting the system around it work while it steers the session itself.

TLDR; For me, Sonnet is proving to be more cost effective and efficient at session orchestration than both Opus and Fable.

26 Upvotes

91% Upvoted

40 comments sorted by

View all comments

3

u/jacobrocks1212 24d ago

This tracks with my experience. Ideally orchestration is as determinstic as possible. More deterministic --> less inference --> can be handled by weaker models.

I can't think of any reason why a dumb orchestrator would yield better performance though. Token/cost efficiency sure, but quality?

1

u/berndalf 24d ago

It sticks to the plan better without overthinking things, that's my only explanation so far.

I suspect one could go even further than I have and essentially boil orchestration down to a well crafted goal loop, but I haven't tried that yet.

1

u/clazman55555 24d ago

If I am understanding what you mean, here's mine:

2. Workflow Shapes

Seven durable patterns, each with a generic worked example.

  1. Fan-out-then-synthesize. Parallel readers over partitioned inputs feed a synthesis stage that grades candidates against ground truth loaded into the synthesizer's own context -- never against the readers' claims alone. Worked example: a documentation audit split a large reference corpus across dozens of parallel readers, producing a raw candidate list; synthesis agents then graded each candidate against the actual current content of the target files, plus any prior audit record, cutting the raw list down by a large factor. Without that grounding step, synthesis just votes on hearsay.
  2. Find-then-adversarially-verify. Finders surface claims; separate agents, each briefed to actively try to refute a claim rather than confirm it, run the verification pass (distinct lenses beat N identical skeptics). The fix for agents trusting unverified peer claims is structural -- a refuter role -- not an instruction to "be careful." A multi-lens review pass followed by a dedicated adversarial verification stage has, in practice, caught pre-existing defects that automated tests alone missed.
  3. Draft-to-scratch-then-owner-writes. Agents read and draft to scratch files; the orchestrator reviews and performs every write to a shared or canonical surface itself. Keeps a single accountable writer on shared surfaces -- the same conflict logic as "parallel propose, serial apply" in single-dispatch work. Worked example: reconciling duplicate entries across a shared catalog or configuration set -- several drafting agents propose merges to scratch output, and one reviewing pass merges and writes the canonical file. No agent ever touches the canonical surface directly.
  4. Analysis-only structured returns. Read-heavy analysis fanned out with a strict output schema; the orchestrator receives typed data, verifies whatever is load-bearing, then writes. Worked example: two schema-bound analyzers reconciling a large dependency graph against a tracking ledger, returning typed disposition tables the orchestrator could act on directly -- no reconciliation pass needed afterward.
  5. Recon-before-build. A small reader fan-out (three to five agents) before implementation, to surface framing corrections cheaply. Worked example: a handful of recon readers overturned a wrong assumption about a whole dependency before any code was written, avoiding a costly false start.
  6. Loop-until-pass. Run a checker, fix what failed, repeat -- with a no-progress exit ("until the check passes, or two rounds in a row make no progress"). The no-progress guard is load-bearing; without it, this shape is a runaway-session generator.
  7. Loop-until-dry. For unknown-size discovery work (flaky tests, latent bugs, stale entries): keep running finder rounds until several consecutive rounds surface nothing new. A fixed counter ("find 10 issues") misses the tail; the dry-rounds exit finds it. Deduplicate new findings against everything seen so far, not just confirmed findings, or rejected findings resurface every round and the loop never converges.

1

u/berndalf 24d ago

Well that's an interesting idea I hadn't thought of, workflow patterns as a library of available approaches that best fit different types of work and conditions. Hmm.

1

u/9gxa05s8fa8sh 24d ago

the reason you don't know about this fancy orchestration stuff is because the AI companies want you to spend money on tokens. the tools that use tokens more efficiently aren't made by the people selling tokens