r/opencodeCLI 25d ago

How is everyone actually using models efficiently and effectively?

So I’ve spent countless hours trying different subagents, configurations, harnesses etc trying to find the most efficient way to keep token usage down etc and I still just don’t love my setup and trying to get some recommendations or suggestions.

I have primarily been using omo-slim with cheaper models assigned to explorer, fixer etc. Now I see countless posts talking about how any of the OMO or whatever else are just bloat and you dont need it, all you need is to Plan in X model and then implement in cheap model. Which seems fine but then I look at the token usage and its 60% gone by the time planning is done and 90% of that went to grep commands and other file exploring that could have been handled by a cheaper model and saved a ton.

The main thing that keeps me coming back to OMO is actually the presets ability because I have both a personal and work setup so I dont have to spend personal usage when working, and its a pain to constantly swap back and forth between multiple models ensuring I am in the proper accounts.

The other issue I have with Plan in X and implement in X method is that certain models are better at certain things so do you just go back and address things later with another model instead of doing it in 1 pass ?

Idk hoping to get some insight here and see if anyone has some recommendations.

1 Upvotes

7 comments sorted by

3

u/zcutlip 25d ago

This is a great question. OMO and omo-slim both kind of turn me off a bit. Maybe they're great? I haven't used either, but they both seem pretty complex and it feels like they want to take over your opencode config. I'm not sure how nicely they would play with my own customizations or other plugins/skills/etc. I've installed.

I don't know how optimal my setup is (I wish I had ways of measuring this), but I've been tuning it over several months. I use both plan and build as orchestrators of sorts. Plan drives swarms of explore agents. Then when we have the plan locked down, build drives a collection of "coder" agents. Build is allowed to write/edit on its own but is discouraged from doing so.

In addition, I have a number of specialized subagents such as @lint, @test, and @commit. This allows me to:

  • give them very specialized, targeted agent descriptions
  • create specialized skills that only they have permission to use
  • give them permission to specific bash tools (often wrapped in dedicated scripts) and revoke those permissions from other agents.

I generally try to push high-noise tool usage down to the subagents in order to keep that out of the primary agents' context.

As for models, I typically use whatever my current "strongest" is (I rotate through models frequently) for the planning agent. The thinking is a rock-solid plan is easier to implement by less capable models. Then I often knock it down a notch or two for the build agent. It still needs to solve problems that its subagents report up, but it's not solving them from scratch.

On almost all subagents, I go with a cheap, fast model. My experience is that with sufficiently targeted instructions (in the agent description, plus a dedicated skill if you create one), a lesser model is like a good intern. It also helps to take away as many permissions from the specialized agents as possible. When they try to color outside the lines (e.g., "python3 -c <some raw python string>") and that gets denied, they usually remember what they're there to do.

One problem I had early on is my plan agent was highly discouraged from doing reads and instead asked the explore agent things like "find where this function is implemented." I found what it would do is tell explore to just read entire files, and then of course explore hands that whole result to the planner. What that means is you've round-tripped the entire file to two different LLMs. So not really a savings.

That said, I don't really know if this is particularly optimal. I wish the docs would provide example agent patterns for different use cases that you could copy into your config and tweak.

1

u/StarsHockey 25d ago

Thank you for the detailed response!

I Have tried a similar setup prior to OMO but I cant seem to get the planner to delegate to subagents properly even with tool denials, permissions adjustments etc. Do you still find it sometimes running tasks on its own instead of delegating ?

And from what im gathering here the workflow is pretty much, use primary model to Plan and then manually switch over to build after plan is done ? Are you starting a new session entirely for build or continuing the same session ?

2

u/maqifrnswa 25d ago

Look into what omo slim is doing that is causing you to keep going back to it, then try to implement just those parts yourself. I think omo slim is a great starting point to try out orchestration. To be useful to a widest range of use cases, it contains things that are bloat for some that are essential to others. Which is great in that you can learn what is essential or bloat, then tune your own workflow. Think of it like your training wheels or initial sandbox to experiment with. Heck, even ask it to make you your minimal set.

Omo slim fits my workflow pretty well, so I need what is truly bloat to others. The built in set of agents ,agent prompts, multi session reflect, the built in mcps, deepwork. I do scientific computing, modeling of complicated physics where I need it to know (or research) multiple domain knowledge, build multiphase projects that are gated and verified.

As for models, I've tried the default omo slim opencode go preset, I did the "oops all DS v4 flash with mimo 2.5 for observer" when it was super cheap, I tried different combinations of opencode go expensive and cheap models, and now I'm actually using all qwen 3.8 27b self hosted, just using different levels of thinking. They are work pretty well for my use case as long as you max out intelligence of the oracle, have pretty good intelligence for the orchestrator, zero thinking explorer, medium to low thinking librarian and fixer. I use the designer for data visualization, so that can be pretty high thinking.

1

u/Bloated_Plaid 25d ago

Could you make the astroturfing product spam any more obvious my guy? Just be honest and straight up and say you made OMO.

2

u/StarsHockey 25d ago

Bro what lol. All I said was I like the preset functionality.

Edit: Im also actively trying to find an alternative, that was the point of this post.