$200 Pro exhausted in 2 days — these limits are unviable for higher tiers

Codex
21

ADDITIONAL EVIDENCE: Even with 80% Spark quota remaining, server throws “Selected model is at capacity” errors inside Project Workspaces.

The system is completely unviable for production development right now. Not only am I locked out of my General Limits, but switching to the specialized GPT-5.3-Codex-Spark model throws a hard “at capacity” error on basic code executions like ‘import os test’.

I am paying CA$250/month for a Pro tier precisely to avoid server capacity queues. The platform is actively blocking paid quotas during critical client delivery hours.

22

I’m facing the same issue, even on the Pro plan.

I don’t want to upgrade again, especially when I can already see people on the $200 plan reporting similar problems. OpenAI seriously needs to rethink how these usage limits and pricing tiers are structured.

I can hit the limit in a single day and then be told to wait almost a full week before I can properly use Codex again. For a paid professional plan, that makes very little sense and makes it difficult to rely on the product for real development work.

With Claude, the limits are much more transparent. You can clearly see the session limit, weekly limit, and other usage limits, so you know exactly where you stand. With OpenAI, it feels much less clear.

This will probably be my last month if the situation doesn’t improve. I’ve also created topics asking for clarification, but so far I haven’t received a clear answer.

The main issue for me is not just the existence of limits. It’s the lack of transparency and the fact that the available usage does not feel reasonable for the price of the plan.

23

I’m seeing something very similar, but in my case it was even more extreme.

I’m on the $200 ChatGPT Pro plan, and while using GPT-5.6 Sol with Ultra reasoning in Codex, I managed to exhaust my included weekly usage within a single day. OpenAI Support has since confirmed that my weekly Codex window is at 100% and won’t reset for roughly another 6 days.

What happened afterwards is even more concerning.

Once the included Pro usage was exhausted, Codex started consuming my purchased credits. I initially had automatic credit top-up enabled, and the balance was being depleted so quickly that one top-up after another was triggered.

I noticed what was happening and disabled automatic top-up, but the credit consumption continued at an extraordinarily high rate. I then made one final manual credit purchase, and those credits were again consumed extremely quickly.

In roughly 30–40 minutes, the resulting credit purchases/top-ups amounted to around $491.

To be clear, I’m not claiming that the purchases themselves were unauthorized. The issue is the underlying rate of credit consumption that caused those purchases. I was doing normal software-development work with Codex and did not intentionally start a workload that I would reasonably expect to burn through hundreds of dollars in credits within such a short period.

I have opened a support case and asked OpenAI to investigate the server-side usage logs, including token consumption, individual agent/sub-agent runs, retries, duplicated executions, model invocations, and the credits charged per operation.

For me, there are therefore two separate problems:

  1. $200 Pro / 20x usage was exhausted in less than one day with GPT-5.6 Sol Ultra.
  2. Once falling back to purchased credits, the consumption rate became financially extreme - hundreds of dollars within well under an hour.

At that point this is no longer just about “higher limits would be nice.” For serious agentic software-development workloads, it becomes very difficult to predict or control the actual cost.

I’d be very interested to know whether others using GPT-5.6 Sol Ultra with Codex are seeing similarly extreme credit consumption after hitting the Pro limits.

24

Thanks for the responses. After reading the examples here, I think the core problem is not simply token cost—it is the inability to predict and control the cost of an agent workflow before it consumes the available allowance.

I’m building a proof of concept called AI Broker: a “PowerBroker for agents” that sits outside the agents being governed. The goal is to provide:

  • an estimated budget before a run begins;

  • per-task and per-agent spending limits;

  • approval before expensive models, high reasoning levels, or additional subagents are used;

  • automatic routing of routine work to less expensive models;

  • live burn-rate monitoring and a circuit breaker for runaway loops; and

  • an audit trail explaining what was approved, downgraded, blocked, or stopped.

For API-based agents, this can enforce actual token and dollar limits. For subscription-based Codex usage, where the quota calculation is less transparent, the initial goal would be to estimate consumption and control the workflow factors we can observe: model choice, reasoning level, context growth, delegation, iterations, and runtime.

I have a private working proof of concept. If anyone here has experienced unexpected usage—especially from multi-agent or long-running workflows—I would be interested in learning which controls would have prevented it. Please send me a direct message if you would like to test it or compare requirements.

25

I think the biggest issue isn’t only the number of messages—it’s the unpredictability.

When you’re building production workflows or iterating on complex architectures, it’s difficult to plan your work if you don’t know when you’ll hit the limit.

I’d personally prefer a more transparent usage model: clear remaining capacity, estimated reset time, and perhaps an option to purchase temporary additional capacity when needed.

That would make the platform much easier to rely on for professional engineering work.

26

I only tried it once… it ate 80% of the response, generated 180 agents, 70GB of meaningless data, didn’t do what it was supposed to do, and generated turbo-corrupt code.

I really don’t understand ULTRA - Unless you’re saying it’s ULTRA resource-intensive, it’s definitely not ULTRA efficient.

Since the release of 5.6, everything breaks, it’s expensive, and not very effeciency - it’s bad… really bad.

27

I agree, but as for today… I have feeling that it’s consuming less!
Anyone notice that? or it’s just make fake sensation :sweat_smile:

29

Yup same here, went back and forth with customer support and they basically told me to go … myself lol (/s but not really /s)

30

Yesterday i had jumps in the quota from 50 to 90%, made me think if the weekly day had changed.

but then it came back after some 12 hours.this cant hapen.

Regarding the token usage maybe is the new subagent feature that is causing all this no?

it add flexibility and more potencial but uses much more tokens.

I will study today a bit more about it, its hard to find gaps to have time to study more things. :expressionless_face::expressionless_face:

i need serius holidays, but if i came back in 60days maybe now llms are using quantum conputing. :rofl::money_bag:

31

It’s true. It doesn’t feel like the Pro 20X like it used to be

32

This is ridiculous! How do I lose 20% of usage by doing nothing!? When I went to bed, I had 81% left. After waking up today, I have 63%!!! This is on the 20x plan and I didn’t have anything running! The same thing happened last week as well.

Four weeks ago I could run Sol ultra for an entire day and lose only 20%! All of this, the usage percentages, the reasoning labels, all of it is complete arbitrary bullshit.

33

The max and ultra levels are imho wasteful.

This is clear in the Introducing Codexometer: keep track of remaining quota, session telemetry & model benchmarks! - #24 by merefield benchmarks too.

Ultra is especially carefree with your quota.

Try to use medium or high. Those are more than capable of solving problems and building great projects.

This morning I was working on two serious projects simultaneously and unable to keep up the pace to burn more tokens than would be required to use up the quota before next reset.

34

I’ve noticed I am hitting the usage limit in 4 days instead of 2 now.

38

Same issue. I’m running the same tasks for a few weeks and now these have started burning tokens at a rate my credit card can hardly keep up with.

I’ve noticed that the monitoring it does on longer running tasks results in very large context that it keeps sending with each monitoring update. So either token caching is not working (as most of the context remains the same) or something else is off.

My workaround (or probably something I should have done before) is not let some default rule/skill decide how to monitor but use a dedicated runbook for monitoring that just notifies the agent when the task is complete or failed while giving period (operator-only) console updates.

39

Maybe something is running in the cloud on a /goal or a loop/schedule. I am on $200 plan. I hit the limit usually in 4-5 days on Sol High. I do code every day, to not hit the limit simpler tasks are done with Terra.

Claude is eating limits much faster in my experience. Grok might indeed be a cheaper version - not sure about the performance though. I like the Codex Desktop App. Have not tried Cursor for a while - I believe they make lots of progress. That should work very well with Grok.

And for @OpenAI_Support Please give more transparency on the usage during thinking. On chat level or even query level would be great. Just put a number after the timer or timestamp (when the query is done). Claude shows token count while thinking, which is helpful to see if things go crazy or not…

40

Okay but you need to pronounce it codek-SOM-meter.

Just like how on that website Rotten Tomatoes, the tomatometer is pronounced tomeh-TOM-meter.

Okay I’m done here.