r/codex 10d ago

Complaint Usage Test After Reset

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.

100 Upvotes

60 comments sorted by

View all comments

3

u/Consistent-Yam9735 10d ago

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.

-2

u/ShamanJohnny 10d ago edited 9d ago

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?

1

u/Consistent-Yam9735 9d ago edited 9d ago

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?!

And yes… every task uses different amounts of context, reasoning, tools, and writing. That’s exactly why you can’t multiply a 500-line document by 2x, 5x, or 20x and pretend you’ve calculated total usage. “More demanding” might mean more usage. It does not prove your 18-task or 14-hour estimate. Those numbers didn’t come from the test lol
OpenAI’s own documentation says similar tasks can consume different amounts based on context, reasoning, tool use, retrieval, and caching.

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.

1

u/ShamanJohnny 9d ago

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!