Made my Codex limits last almost ~3x longer with one change

[u/Busy-Instance-6973]

Plus users are basically being forced to give up Sol and just use Luna to get any usable amount of work done. That's a huge downgrade basically using a deepseek flash model level which you can get for free in opencode anyway.

I started tracking where Sol's spent most of its tokens and most of it was searching around your repo looking for what to edit. Search took 30-60% of the total cost.

so I tried to come up with a solution that both lowers search cost and at the same time keep the same output quality from sol.

Then I found this Microsoft research paper that I based this on called FastContext. The concept doesn't work directly in Codex so I built my own implementation as an MCP Rust tool with a custom router I tuned and improved over weeks and weeks of benchmarking. Sol still does all the actual coding just that the search goes to luna*(Much cheaper).

The first attempt was simple putting custom instructions in agents.md and.. it was a disaster. Sol either ignores it or at one point it literally opened a web search for "how to start a subagent" (wish I was making that up lol). Even when it works you end up paying more for a much slower response because Luna sends back garbage half the time and Sol has to redo the search anyway.

the benchmarks I ran are DeepSWE, MAH-SWE, and bugs from repos I actually work on,with Luna's cost counted with Sol. limits lasted almost 3x longer, with no quality regression and most of the time faster responses!

one command in 3 seconds, it uses your existing Codex sub.

 https://github.com/repotracer/repotracer

[u/AutoModerator]

Sorry, your post has been held for manual review due to account karma.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Valieo]

In your testing and benchmarks, is this your only use of subagents? What guidance if any did you include in your agents file to teach it how to use it?

[u/Busy-Instance-6973 → u/Valieo]

This is not a subagent but an MCP server for sol to call with instructions baked in fine tuned for search with luna (Via codex app server using your sub) and as a result it's much cheaper with no regressions,
it's optimized and built for search only.

[u/sugarfreecaffeine]

Cool! But can’t you just say to sol “spin up a sub agent using Luna as the model and do x y z” I’ve done this before and it works

[u/Thog78 → u/sugarfreecaffeine]

Did you do that in codex or another harness?

[u/sugarfreecaffeine → u/Thog78]

Codex and other harnesses like oh my pi

[u/Busy-Instance-6973 → u/sugarfreecaffeine]

Will you remember to do this everytime? Do it in the best senario where luna makes sense? can you confirm that luna delegation at that time actually saved you cost not made sol waste time waiting for a bad answer?
And with a big caveat of subagents inheriting the entire context of their parent. you can configure it to not do that changing some config file tedious and unpractical because sometimes you do want subagents with full context and sometimes you don't.
Hopefully this makes the value clear :).

[u/Poildek → u/Busy-Instance-6973]

Honestly no. And agents doesnt inherit the context if you spawn a cli for this. If you are afraid to forget you create a skill with 5 sentances in it and that's it.

I use it all the time for this and peer ai reviews across claude vodex ang antigravity.

[u/ManRowing]

30-60% of cost on search alone matches what we've seen elsewhere - orientation, not generation, is where most of the spend goes on these agents. The router idea is neat. Have you noticed the split holding steady across repo sizes, or does search cost grow faster on bigger repos where there's more to look through?

[u/RevolutionaryHole69]

I'm using cursor these days, and I told cursor I would like the higher thinking model to be made aware of the exact lower thinking model we were going to prescribe for the build job (usually composer), to remove thinking from the builder model during execution, and to have the higher level model doing the planning do all of the thinking, so building is purely execution.

Doubles my efficiency this way. I've run comparisons side by side and the output quality is like 90% of what I would get if I built using the higher model and didn't alter the way it wrote the plan.

My workflow results in increased token use during planning and since composer is basically free, the build part doesn't really cost me anything.

[u/dvduval]

I just don’t see how you can have a high level of reasoning working many hours a day and expect to pay $20 a month. You either need less time or a model that thinks less.

[u/Busy-Instance-6973 → u/dvduval]

Or you can also optimize your workflow and harness and get most work possible out of the 20$ plan without sacrificing quality by switching to a worse model ;)
But in anycase this works for all wether pro or plus.

[u/dvduval → u/Busy-Instance-6973]

I’m working with codex and the way I look at it they have a huge team optimizing my harness all the time. They’re making updates to codex often multiple times per day.

And I easily make $200 more than I did before so the $200 is not a big deal to me. But I have to admit early on I was not ready to subscribe to the higher price point.

[u/RevolutionaryHole69 → u/dvduval]

The updates they're making aren't to get you more token efficiency, it's to make more money off you. No company is good by heart, it's good to remember that. Not a single one of these companies is profitable at the moment.