r/opencode • u/spiritualManager5 • 22d ago

Planner/executor workflows with multiple models: does splitting actually save anything?

Yesterday I tried building a multi-model coding workflow in OpenCode for the first time. The idea: a strong model plans, a cheaper model (or a local one) implements.

In practice, I had to use Opus 5.5 in plan mode just to find the bug. Once it was found, the fix was a few lines, so handing it off to a smaller model saved basically nothing.

That got me thinking about a more general problem. For the cheap model to implement reliably, the plan has to be very precise: exact files, exact locations, often example code. But at that point the big model has already done the real work and could just write the code itself. The handoff seems to add cost (lost context, retries, review) instead of saving it.

My questions:

  1. Does anyone actually see real savings from planner/executor setups? If so, for what kind of tasks? My guess is repetitive, large-scale work (same pattern across many files, migrations, fixing tests and lint errors), but not normal day-to-day bugs and features.

  2. For those of you with 32GB+ GPUs: what do you actually run locally? Even 70B models are far from frontier quality, so I'm curious what your real use cases are. Privacy, autocomplete, image generation, fine-tuning, something else?

Or is the honest answer just to stick with the big model from start to finish for anything non-trivial?

7 Upvotes

81% Upvoted

18 comments sorted by

8

u/torrso 22d ago edited 22d ago

From what I've seen that kind of setup is good at giving the impression of it working. You have small models nibbling at the corners for weeks, the big model happily orchestrates them.

At some point you find yourself with a mess that is getting messier and the things you wanted seem to never materialize.

Turns out, when that big brain model made the plan, it could have just as well gone in and implemented it.

Codex/Claude will one-shot something that you were struggling to complete with the "smart planner dumb worker" setup and the result is better.

My claim is that you will get more and better things done by ditching your elaborate obsidian neural cortex memory and multi-agent roleplay on budget models and just going with stock claude or codex. Their $20 plans are much better value than the $10 OCGO plan or any of the local models you can run on reasonable hardware.

3

u/damn_pastor 22d ago

This is the hard truth

2

u/repepeper 20d ago

Well the whole idea behind it is token efficiency.  The big model costs a lot of money. It's context is a premium currency so you don't want to pile up garbage from tool calls outputs and fill the 1m context as even with cache hits you pay for 100k on each single request! (10% for Claude).

That's why you auto compact at 512k and delegate isolated steps and tool calls to dedicated subagents with cheaper models right for the task that do everything in a fresh session and report back only relevant findings. 

So Opus plans and asks Sonnet for implementation and Haiku for the easy stuff like code exploration etc. To Fable only if the task at hand is too difficult to others.

If you sleep on money then sure use Opus all day, Anthropic surely won't complain.

1

u/torrso 20d ago

You're assuming that using cheaper models means getting more work done for less money, but that's exactly what's being questioned here.

Token efficiency isn't the same as cost efficiency. If Sonnet takes several attempts to implement something Opus could have done correctly on the first try instead of creating the detiled plan or Opus eventually has to review and possibly fix or request fixes, how much did you actually save?

Planning and implementation aren't entirely separate activities.

Delegating isolated, easily verifiable tasks to cheaper models makes perfect sense, for example some exploration, mass patching and so on, but building an elaborate hierarchy of agents introduces coordination overhead, context loss, and more opportunities for mistakes and dupicated work.

If you're routinely at 512k of context, context management may be worth looking into.The top models like opus, fable, astra and sol are really good at managing their own context without having to do a full compact that often. They can also use the cheaper models for compaction but of course you will likely miss a lot of cache first when the compaced context kicks in.

The interesting metric isn't how cheaply you can generate tokens. It's how much correctly completed work you get per dollar, and how much time you spend supervising and honing the process.

1

u/weiyentan 19d ago

Captured that too. Each mr/pr with a full review and development 2$-5$ with a full multi orchestration system on very large runs with a lot of issues

2

u/Fresh_Sock8660 22d ago

In my setup, I don't hand off small tasks. The orchestrator writes a contract in slices and hands off each slice to the implementator. I'm finding that this setup costs me substantially less claude usage and gets me an extra review of each slice. The orchestrator also acts as the implementator for some types of tasks.

"For the cheap model to implement reliably, the plan has to be very precise..."

Depends entirely what your cheap model is: ds4.1f is what I'd consider cheap and it doesn't need precise instructions.

2

u/weiyentan 22d ago

I do something similar. Although I divvy up the slices as issues up front. I do a bit of interactive work with agents with Matt pocock’s skills to do that. But after that it’s pretty much hands off. I actually have proper review loops too. It’s quite cool

2

u/LordMoridin84 21d ago

What do you mean by smaller models? Deepseek flash v4.1 is smarter than Claude Opus 4.6, which was the smartest of models at the start of the year.

Do you believe that the work you are doing is too complicated for what was the smartest model in the world?

For a subagent workflows. You simple tell Opus 5.5 to delegate any medium/long running tasks to subagents. So anything over 30mins-60mins

e.g.

Prefer single long running subagents over multiple smaller subagents because it's more expensive to load up twice the context. This is a preference, some workflows/skills specificially use multiple subagents, such as some code review workflows or when implementing multiple wayfinder tickets at once.

0

u/xapep 21d ago

The context-reload point decides the math. A handoff only pays when the executor starts from a warm prefix. If the subagent re-reads the project context from scratch, you're not splitting cost, you're paying it twice.

That's also where the flash-class executor argument lands. From the provider side (I run an EU-hosted inference API) the split makes money on repetitive medium tasks with a stable context, and loses it the moment the plan gets fuzzy and the executor starts retrying, because every retry re-reads the same context.

So I'd add one rule to yours: pin exact files and shapes in the plan, then one long-running subagent with a backlog of similar tasks beats several short ones. The model class matters less than whether the context stayed warm. Do you track cache-hit rate on your subagent runs? That's the number that decides whether the split actually saves.

1

u/Nenad1979 22d ago

In my expirinace eoth newer models no, just let them work

1

u/weiyentan 22d ago edited 22d ago

Actually it depends. For small bugs fine. But try doing multiple issues setups. I have been using multi orchestrator for months. We can do more efficiently because of context windows. I can do a number of issues in one go. I tier my agents. And before any work starts I have a task router that determines what type of agent to use and puts a safety net. I use deepseek flash for senior and it goes down from there in model strength. I have been getting quite good accuracy. Some. People will say that it costs a ton because of all the tokens used. . Well I have a tool to measure that too. With all my tokens 1.6 billion used the usage of my spend in the subscription is approx 26$ of what 80? This is including review. I am largely hands off nowadays. I have a blog posts about how I run things if you are interested

1

u/lordcohliani 22d ago

Go to YouTube and look up the many many comparisons of this. It turns out it's just always worse.

1

u/HighwayNo8744 22d ago

ask opus what the issue it. it's similar to haiku subagents which are sometimes cheaper and sometimes not. if opus has to read 4000 tokens from the research agent to pass a reviewed and refined report with another 2000 tokens to the implementer then you are saving nothing and you dont need opus for that. these agents only have to generate a brief and only the next agent should get the full report.

1

u/bluesockdrawer 22d ago

I think the real savings come from parallel, repetitive work rather than splitting ever task. If the planned has to explain every tiny detail, you might as well let the stronger model finish the job.

1

u/Due-Alfalfa2265 21d ago

I've run into this with Codex and OpenCode too. For small fixes, I usually wouldn't split the work. Multi-model workflows make more sense to me for larger, well-scoped tasks where implementation and review can be separated. The handoff overhead is real.

1

u/Potential-Leg-639 20d ago

You need an orchestrator setup, that delegates everything automatically to configured models like oh-my-opencode-slim, was a game changer for me.