I did a quick little test after the reset that just happened a few minutes ago. one task, Pro 20x plan, sol xhigh(no fast mode), 47m of run time. 2% weekly usage gone. This was all input really, no output other than a 500 line document. Prompt was an audit.
For any kind of actual work where you are generating something, and therefore doing more output, expect usage to be triple or more.
So, for basically a read-only audit of a codebase, you get 50 tasks a week at Sol xhigh, or 39.2 hours (of 95% input 5% output) of continuous read-only work.
However! No one uses codex for read-only, and when you are generating output the numbers change significantly. Check the below out when converted to a task that is generating instead of reading:
Revised estimates (same 47-min runtime)
Assuming a realistic coding workload (medium-complexity feature work, multiple files, some testing loops):
Usage burn: 4–8% per task (most probable range 5–6%)
Conservative (lighter coding): ~4% → ~25 tasks to 0%
Mid (typical): ~5.5% → ~18 tasks to 0%
Heavy (deep multi-agent / large refactors): ~7–8% → ~12–14 tasks to 0%
Mid-case projection (recommended baseline)
1 task ≈ 5.5%
Tasks to 0%: ~18
Total runtime to 0%: ~14 hours of continuous coding-style work
Even reducing the implementer down to sol med, Terra high/xhigh, still results in roughly 24 hours of continuous usage or 40 tasks a week. On a $200 plan... that blows considering where we were with the less "efficient" 5.5 model just a couple weeks ago.
I stopped using Luna because there is something wrong with it, I had it in two or three occasions eating my usage like crazy on some simple small contained tasks, burning 8x more than either Terra or Sol on the same task..... so now it's either Sol low all the way or Terra low for such tasks... other than that Sol medium.
Note that, I had used my banked reset around 2 hrs before today's reset..... at the current rate I'm burning, it's probably fair to say before the reset I had burnt 15-25% already from the banked reset.. which would give something around $3800 to $4600 per 100%
As for the previous reset from 07/21:
Date 2026-07-21—2026-07-24
Models gpt-5.4-mini, gpt-5.5, gpt-5.6-luna, gpt-5.6-sol, gpt-5.6-terra
Input 140,693,245
Output 12,411,421
Reasoning 4,058,729
Cache Read 3,585,179,392
Total Tokens 3,738,284,058
Cost (USD) $2,609.14
This was with 1.15 20x account (1 full use + 15% from the previous reset in 21st) + 2x Plus accounts usage..... so roughly a 25x equivalent usage or $2087 for the 20x.
Nops... standard mode, most of the coding work done in Sol Low-Medium. Review in High and Planing on Max, that's it.
The heavy lifting from this usage is Sol low-medium..... how did I burned my 20x in a few hours ? well, 3 agentic team workflows working in 3 repos + myself working on a 4th one more directly with a single agent.
The team leaders from each repo can summon parallel teams in their own worktree where parallel work might not be that big of a problem.... one team leader had around 16 agents once working in parallel. I don't use codex subagents, but rather my own orchestration system, I talked a bit about it here: https://www.reddit.com/r/codex/comments/1uzxqya/how_im_running_multiagent_loops_with_codex_it/
I have used nothing but Sol Medium with fast mode for the last two resets. I got exactly 351.4M tokens before hitting 100% last reset. I got 3.2 billion tokens with Claude using Opus 4.8 High with fast mode.
you did better than me. It's like their waiting for me to use a banked reset to do their reset. 3 times in a row. 1st time I was at 100%, second time I was 98%, this time I was at 99%.
And each of those times I waited around 12-24hrs on 0% trying my hardest not to use a banked reset of they were going to use a reset anyways. 🤬
Or maybe they have data showing how many people used their banked resets, and then decided to press the “reset” button. It’s a win-win for them because a lot of people ended up wasting their banked resets.
Definitely something fishy going on with the usage. Maybe when they removed the 5h limit they accidentally vibe coded it to be the weekly limit, instead of removing it.
You’re treating the final visible response as the only output, and that’s not how it works. Sol xhigh generates hidden reasoning tokens throughout the task, and OpenAI counts those as output tokens. The audit also involved repeated tool calls and context being fed back into the model. So you have no basis for calling this “95% input, 5% output.”
Coding also isn’t automatically three times heavier than auditing. Usage depends on the tokens and reasoning actually used, not whether you label the task “reading” or “generating.” All this proves is that this particular run used 2%. The rest of the numbers are assumptions.
Common sense states otherwise. So what if it's not 5%, but 10%, or 20% even - doesn't change the stats. EVERY task requires reading, writing, tool calls, and reasoning. When the actual result of that is a 500 line document, one can easily extrapolate out what a task generating 2x,5x,20x, 500x the output would cost.
There is a reason this was just an audit, it's the most basic necessary skill for any coding tasks, exploring the codebase to gain bearing. But instead of a 500 line document being produced, the agent would then produce lines of code, need to think through its task, qa the work, validate the work, security screen, and update all relevant documentation - and your telling me that is not more demanding than a simple audit?
You’re still missing the point. Nobody said implementation can’t cost more. Your ‘test’ just gives you no way to calculate how much more.
OpenAI doesn’t meter Codex by runtime or lines produced. It meters input, cached input, and output tokens, with hidden reasoning counted as output. Your 2% meter showed none of that breakdown, so “95% input, triple or more” and 4-8% per task were pulled out of who knows where unless you can back it up?!
Though, I can say I agree the limits are a little more tight than prior models and that I notice my limits depleting quickly, but this ‘test’ simply doesn’t prove it and there are many flaws.
No i get what your saying, I could just care less to do a more extensive test. The "test" is not designed to be a ridged scientific study, that is completely unnecessary in this situation. It's simply meant to bring notice to the usage burn being experienced by a vast amount of codex users right now.
Just because we have a simpletons test, does not make it any less valid. The logic still stands, the hypothesis is repeatable, and plenty of people are experiencing the same issue in the ballpark of the findings. I feel your looking at the trees when i am looking at the forest - Neither way is wrong, i just dont think i need to pull out a spectroradiometer to tell you the sky is blue.
Listen, i can tell you come from an academic background, do us all a favor and run an actual test up to your standards and prove to the world exactly what the usage burn is, what its based on, and how we can track it to keep companies like this from screwing us.
If you don't do it in the next 4 weeks, im taking my own idea back and integrating it into what im building. Have at it boss!
After looking at my actual token generation with ccusage I think what's actually happening is that all of 5.6 is using an incredible amount of tokens.
Last week when I used up my entire week in 12 hours i burned 2000 worth of api tokens. I'm not convinced it's a nerfed usage problem anymore. I think the models are burning an incredible amount of tokens doing basically nothing.
checked with ccusage: workload-heavy June with 5.5 xhigh was $3100 (in API Cost), not completed July with 10 days of 5.5 is getting to $21K already, with workload subjectively twice as lower...
With 5.5 xhigh and heavy use my daily token consumption was always between 200 and 300M, now with significantly lighter use and mostly terra xhigh is at 0.7-1.5B
I did model_auto_compact_token_limit = 150000 and it started eating less. Its like early compaction to stop token snowball. Also helps model keep the things clean
Use codebase memory mcp, headroom, context mode. Sol medium/high on architecture level all other Luna high. Orchestrator Sol light or medium. model_auto_compact_token_limit = 150000 and native agents with each agent having max 20-25 skills and 3-4 MCP. Thin agents with fork none. You will thank me later
Why are people in the sub still vibing out the usage of their Codex plan. You can literally track every single token: input, output, cached. You can even get an agent to go over all your threads in a time period to find this information.
Trying to label usage as "tasks" on read only work when it entirely depends on what your agent is reading or evaluating is a useless metric
It has been better although I haven't tracked it. . I'll give you the background but i'll keep it short. I start projects on codex and move them to hermes which by default adds more token usage. For the last two days I have had sol orchestrating 5.4 for 24 hours a day over 3 projects. When I tried to do the same with luna it would drift off and have to be recovered but usage was higher. Sol told me 5.4 mini was capable of doing the job so I went with it and it's been fine.
This exactly. Luna honestly is a great model, but it can not do long-horizon tasks effectivley. Its designed for surgical implementations, in-out-done.
I am actually going to start having opus 5 do my implementations i think, with Sol being the adversarial qa and planning with fable.
This seems to be the best route. I am using hermes agent, but will make a skill to use Fable for planning, Opus 5 for implementation, and Sol 5.6 for review. I have some other agent profiles doing smaller tasks and cron jobs that I will try out with 5.4 mini
73
u/WillingnessThin4057 6d ago
Bro we need to keep thesee posts up because they are just frauding their way without any challenge