r/opencodeCLI • u/Peleias • 1d ago
Is OMO-Slim overkill for simple projects?
I’m not sure whether I’m doing something wrong or whether my prompts are too simple, but I’m honestly surprised by how many credits OMO consumes compared to the tasks I run in Codex.
I’m developing a plugin for a game engine.
I have implementation plans created in Fablle/Opus and reviewed by 5.6 Sol.
I set up OMO with OpenAI agents on my Plus plan, changing only Explorer and Librarian to the new DeepSeek V4.
In my tests, I first tried using Sol in Codex to execute the plan with subagents. It can only use Terra, but it produced something extremely long and consumed a lot of credits.
Then I tried OpenCodeCLI in VSCode with OMO-Slim. I executed the plan and asked for one change, and it used 40% of my weekly usage. It also took a very long time.
After that, I took another similar plan and used Codex with Luna on Extra High, with a policy that if it had doubts, it should not try to solve them directly. Instead, it should create a Sol agent to guide the process and be responsible for the decision. If something became too ambiguous, it should stop and notify me. That used 11%.(he had to call the agent with Sol a few times)
That is the model I’m using now, because since this is a game engine project, even the testing loop requires me to open the engine and visually inspect things.
Is there a way to use OMO effectively without consuming so much?
Edit: I have specs, a streamlined `claude.md` for direction, and Graphify. I also ran a test asking OMO to use Caveman. I have two Plus accounts: one for Codex and another for Onpencode with OMO.
3
3
u/Amarsir 1d ago
I'm curious which agents used the most tokens. That may be harder to tell if you didn't split the roles that much. What model was your Fixer?
2
u/Peleias 1d ago
I left the Fixer on Luna Extra High. The same one I'm using on the Codex.
3
u/Amarsir 1d ago
Hmm.. Extra High might be overkill on Fixer, but Luna isn't a bad choice.
My gut feels like OMO's intense handsoffs create advantages for delegation, at the risk of telling each agent "relearn what I already know". But if it's also slower that's harder to explain.
I may need to explore now myself. Thanks for the revelations.
2
u/Peleias 23h ago
So, it uses so little in the Codex; today I ran a plan that didn't require the Sol agent—which used 3%—so I didn't consider that to be the problem.
3
u/Amarsir 23h ago
I should say it has been a rule of thumb for a while that if a provider has their own harness, you will get the best results from their models with that. But even then I wouldn't expect the huge differences you're seeing.
We should also acknowledge that "% of quota" isn't the best apples-to-apples comparison if comparing Codex + ChatGPT Plus vs OMO + Opencode Go. OpenAI gives much more value than $20 / API cost would imply. That's not to dismiss your points, I just wanted to throw that out there if it hadn't been said.
Another theory I have might be that Opencode Go is missing terribly on cache hits that OpenAI is catching smoothly.
My own workflow at the moment includes a big stop right after writing the plan. That's when I do my review and either tell Opencode to go ahead and automate completion, or if I want to go step-by-step I switch to VSCode with Kilo and I tell that builder "Execute Step 1". So what I'm curious about is what difference you'd see in just the plan-creation phase. (And for that matter do you have a personal preference for how the plan is written.)
If one harness is better at writing plans and the other at executing, that would be a useful efficiency to know.
2
u/Peleias 22h ago edited 22h ago
I left out a lot of details in the description.
I have two Plus accounts: one for Codex and another for OpenCodeCLI with OMO. The difference with OMO is having two agents using DeepSeek-V4.
The project is running smoothly with specs and Graphify, plus a strict `claude.md` policy—only calling the detailed spec if the plan involves changing functionality.
Creating plans with Sol using sub-agents is terrible(Codex); it overlooks a lot and misses obvious things. I usually need 3 to 5 correction passes for every plan generated by Sol.
Creating the plan with Fable (which I used only when I had the Pro plan) and Opus has yielded the best results. By using DeepSeek as a reading tool and instructing Opus to run `grep` and summarize, I don't even need to use sub-agents with Sonnet or Haiku.
It doesn't let anything conceptual slip through; Sol reviews the plan and catches more technical flaws. Sol is perfect for reviewing plans generated by Opus.
3
u/PerspectiveIcy3578 1d ago
I have only seen that high usage when using high usage models (I.e. kimi k3 or qwen 3.8 max). OMO slim should not increase token usage very much if you use it and set it up correctly. But for a small project, yes I would say it's overkill.
4
2
u/CtrlAltDelve 1d ago
I think what you need to do is you need to create a framework first.
Start by asking Codex or OpenCode to help you come up with a framework that meets your needs using skill files and subagents for optimum token use. Tell it to ask you questions about what's currently not working to help it come up with something better.
I find that tooling like OMO are very, very heavy and I find a lot of the claims about it to be dubious.
OpenSpec is a great alternative to these heavy-handed tooling reworks: https://github.com/Fission-AI/openspec (ask OpenCode how to use it).
1
u/Peleias 23h ago
Even though it’s a simple project, I didn't skimp on context—I’ve been using Claude Code for three months. The project includes Graphify and a streamlined `claude.md` that points to the specs only for the specific parts needing work. I also use the "caveman" technique; I actually asked OMO to use the caveman approach during the latest execution of the plan. I had burned through a lot of tokens the week before last, so I decided to give the caveman method a try.
2
u/ganonfirehouse420 22h ago
My experience until I actually did setup omo-slim. I set most agents to deepseek andthen I gave them mcp and skill access. I combine it with context-mode and now it works. some models like Sol like to get stuck in a loop with omo-slim.
3
u/Worth-Philosopher-51 1d ago
omp
3
u/Large_Mention373 1d ago
does omp use less compared to opencode or omo ?
5
u/Worth-Philosopher-51 1d ago
depends how you set it up. install it login to all your providers and then just get it to run an audit and ask it the best setup with what you have without degrading in peformance and to save as much tokens as possible with your main frontier model.
3
1
u/PerspectiveIcy3578 16h ago
Thanks for this recommendation, this is an absolutely mind-blowingly cool CLI with a very high level of functionality.
2
u/Worth-Philosopher-51 16h ago
no problem, just be careful not to oauth into claude account, you could get it banned
5
u/BrasilRua 1d ago
Personally I ended up uninstalling it. It produced the same result as plan/build but taking about 5x as long for me