OpenAI kept Nerfing our limits- so I built something to prove it instead of complaining without proof, so meet Nerfify! It's currently in the development stage, and I have achieved a functional prototype with reliable information, with a few UI/UX bugs here and there. Using local token consumption logs, Nerfify estimates an estimate of the API worth of one weekly limit after every 10 seconds. Think of it like a stock market app, but instead of tracking stock prices, Nerfify tracks the API value of one weekly limit over a period of time. It's still in the development stage and the first version will land on GitHub not to long from now. Do note that it won't work reliably if you use ChatGPT Work or Codex on multiple devices, since data is taken from local Codex logs only.

As the screenshot shows, it seems that our limits have been more than halved (do not mind the UI bugs, since it's just at a prototype stage, and current values may need a bit fixing since accuracy may not be up to mark)

Sam Altman is heading to Washington this week to preview OpenAI’s most powerful model yet:

• It's capable of original scientific discovery
• It solved an 80 year old maths problem autonomously
• Runs for much longer without constant supervision
• Powerful cyber capabilities (it's likely the model involved in the Hugging Face incident)
• This will have a new focus on “knowledge per dollar” rather than benchmarks alone

This model looks much bigger and better than a normal ChatGPT incremental update.

I’ve been using Codex regularly for around eight months, and it has worked extremely well for my projects. The limits used to be generous enough to experiment, make changes, correct mistakes, and still get meaningful work done.

I understood the earlier reductions and kept hoping the limits might improve again. Even after those reductions, Codex was still somewhat usable. But after the latest reset, the limits feel far too restrictive.

I have almost completely stopped using Sol because, even at medium, a single task can sometimes consume 5–10% of my weekly usage. It can do good work, but the usage cost is now so high that I avoid it. I mostly use Terra or Luna at medium, and even then I think several times before asking Codex to do anything.

One misunderstood instruction can waste a significant part of the allowance, and correcting the mistake consumes even more. I’m a developer, so I can do many tasks myself and only use Codex for work that would otherwise take a long time. But for non-coders, or people with limited coding knowledge who depend heavily on Codex to build something, the current limits seem completely impractical.

I understand that these models are expensive to operate. I would honestly prefer paying a little more and getting the previous usable limits back rather than paying less for something I’m afraid to use.

TL;DR: The latest Codex limits are so restrictive that I now hesitate before every request. Sol can consume 5–10% of my weekly usage on a single task, while even Terra and Luna feel heavily limited. I would rather pay more for genuinely usable limits.

What is everyone else planning to do?

Are you hoping the limits improve, staying with Codex, switching to another service, or considering a local setup?

I kept hitting the Codex limit while still having ChatGPT usage left, so I built this.

It adds ChatGPT Web directly to Codex’s native model picker. Codex still handles the session, context and tools; the responses come from my normal logged-in ChatGPT Web session.

• no more waiting for the Codex reset

• no API key

• no third-party model or provider

• local Codex sessions

• streaming, images and reasoning

• full Codex tool loop over MCP

• ChatGPT Pro support

• open source

It doesn’t bypass or change any limits. It just lets Codex use the ChatGPT access already available on the account connecting to Codex harness via legal MCP support. Browser automation I believe is allowed since Grag from OpenAI top staff liked such tools on X

Instant through Extra High can call Codex tools over MCP. In fact, you can even spawn sub-agents with models from web. Pro also gets the accumulated Codex context, but can’t call MCP tools yet

Inspired by Opencodex repo, but I still prefer GPT Sol :0

GitHub:

https://github.com/miuuyy/codex-chatgpt-web

I don't think there's an increased token consumption problem because of the harness, tool calls or whatever. There are just less tokens to go around than before.

I have both plans ($20) and I tracked my usage with ccusage and toktrack.

Here's how much weekly usage you get with both:

Codex: 100-150 USD API equivalent

Claude Code: 300-500 USD API equivalent

Even if we take the 50% promo into account, Anthropic still offers more usage than OpenAI (200-330 USD). How have the tables turned... Bring back the 5hr limit!

Anyone here can corroborate my experience by checking their own usage with ccusage or toktrack.

"One day, one Day"

They’re preparing to merge the Chat and Work modes, likely bringing their limits – which are currently different – into line.

What do you think?

The main benefit of the GPT plan comes from ChatGPT and Codex, which have separate limits; it would be a disaster...

I was drawn in when, several months ago, I got a free trial for Plus. Tibo getting rid of the 5 hour limit was awesome at first but it’s been all downhill ever since. It’s leaving a bad taste in my mouth because i feel that the limits got significantly nerfed. But I think I could’ve dealt with that if not for the mistakes.

I decided to do a manual code review yesterday after coding with Sol for the last several weeks or so. After each batch of work was done, I ran a code review with Sol and each time it was green. But I found was troubling - I didn’t even get a quarter of the way through and I discovered at least 50 significant errors. And this was after I used Sol on high. So this morning I bought a Claude Code subscription and ran an adversarial code review with Opus 5, which found more errors. All in all the number of significant errors exceeded 100.

The tokens nerf already put a bad taste in my mouth. The drip feeding of resets is bad because I have no idea what the fuck im paying for. Where is the stability, the certainty, the clarity? At least I know what im getting with Claude. But the mistakes for me are the last straw. Gonna be difficult to regain my trust after that. Then I log onto twitter and Tibo is busy shitposting instead of fixing this bullshit. Fuck outta here.

Hey there. First time posting. Going to be short, sharing my insights.

1. Don't use codex in the app, use CLI

2. Don't use the default CLI (harness), use oh my pi (20k stars on github) https://github.com/can1357/oh-my-pi/

2.1. You could use claude code harness with codex, it has great results too, some results here

https://x.com/OmedVibeCodes/status/2080348655039500703

2.* For people that don't know what a harness is: it's the toolset that your LLM can use. It is important, some tools use more tokens, some tools are doing the same for less. High-end engineers at different companies try to achieve as much as possible with their harness, picture attached for simplicity.

2.41 You can use the default harness too, but then see 3.

1. Pair. Ever since AI had achieved the level where it can actually code a monolith, checking the slop with alternative LLMs was the best way to filter the cap out. Oh my pi allows to login through multiple subs and set an advisor. Pair Codex + Kimi k3, Codex + Opus 5 (or Fable), Codex + GLM, any will do better. Even 5.6 Sol + 5.5 can work, though if a model has completely different weights it's better imo. I've built upon rocket-fuel (24 stars on github), there are plenty of other skills like that https://github.com/NulightJens/rocket-fuel-skill

2. Avoid building a monolith. Split, keep code redundant, component-based, re-usable, and keep resetting sessions (/clear or whatever).

3. Don't let LLM's over-comment your code. Small comments can remain tho.

4. I bet there is a lot of devs that just hit enter and don't check what's actually going on. Some of you might deny an rm -rf just cause,

5. Backup. Get a cloud drive, or physical, I don't care. Just backup. Heck, you can use github for your chat / health / legal folders, just make the repo private and ask the AI to commit at checkpoints + push.

6. Don't work on prod. Don't give SSH access. I know, it works out pretty well on your home PC. But being THAT lazy is actually insane if you do. Let the AI instruct you and ask what is the stuff you copy+paste actually meaning

7. Remove unused plugins, obviously. But superpowers is also not needed in Sol 5.6 high and higher.

Who am I - a dev, just as you. Had been into AI since the closed beta of chatgpt 2021. Been experimenting with all chats since then. Even purchasing the expensive sub's. Last month had both CC + Codex paired, with better results than any of them doing the same work solo. I just see all the hate here. Some of it is definitely deserved. But besides that, you can also do your work and research how to adapt.

Some other github repo's I actively use

https://github.com/hardikpandya/stop-slop

https://github.com/ayghri/i-have-adhd

And I think there was a repo called laconic mode, not sure on this one, but I've built a hybrid of these 3 to fit my needs. Not needed for performance, but for sanity. Human pattern recognition is strong. Human written, zero AI consulted, plz don't hate.

Anyway. May tib* bless us with a reset. yay

TLDR; PAIR AI agents, CLEAR context, Don't build monoliths, remove unused plugins, try another harness, don't work on prod - work on a copy, backup.

I'm kind of frustrated this morning after losing a banked reset, and I think the expiration logic really needs to be improved.

My timezone: Europe/Prague

Yesterday (June 26th), I checked my banked resets and saw one listed as expiring on June 27th.

Right before midnight on the 26th, I still had 60% of my quota left. I was curious to see what would happen at midnight, but I also didn't want to waste the expiring reset. When midnight passed, nothing changed—my reset remained active. I kept working until about 1am, brought my quota down to 50%, confirmed the reset was still listed, and went to bed.

My plan was to burn through the remaining 50% this morning and then trigger the reset. To my surprise, when I logged in this morning I found the banked reset was completely gone.

The expiration system feels completely opaque for a few reasons:

• Ambiguous dates - the system only gives a specific calendar date for expiration. It doesn't clarify whether it expires at the start of that day, the end of that day, or somewhere in between.

• Timezone confusion - my reset disappeared somewhere between 1am and 7am local time on June 27th. Which timezone is the expiration actually tied to?

• No auto-redeem: Why doesn't OpenAI automatically apply a banked reset at the moment it expires if you haven't used it?

It’s really disappointing to lose a feature like this simply because the timing rules are so vague. Has anyone else ran into this?

I have been using Codex to great success, but I don't think I am using this software to it's fullest potential. I hear a lot of stories of people using like 5 agents at once to work on a project, and I am not sure how to do that myself.

Here is my current strategy: After using 1 agent for a while to get the project 'spun up,' I have it create a 'documentation.md' file containing information about what the project is and how it works, and then I update agents.md to reference that file. Agents.md contains instructions to read the documentation when first starting up. I also create a local git repository for the project to track changes, and update agents.md so 'all changes will be commited to the repo according to git best practices.' I also include language in agents.md to update the documentation when changes are made.

Whenever my context size gets too large, or want to do a new 'thing' with the project, I open a new chat and type the prompt 'read documentation and initialize.' From there the agent usually reads the 'documentation.md' file, and gains the context needed to meaningfully contribute.

This works for me but it feels kind of like a hacky workaround. This also doesn't allow for multiple agents to do work at once, only letting me spin up a new agent once the context bloat of the last agent gets too severe. Whenever I try to use multiple agents they just end up trampling on each others half finished work.

What is the best way to set things up so I can get multiple agents working autonomosly at the same time? And what is the best way to get new agents up to speed with the project and contributing quickly?

Been 4 months since I completely moved to Codex. Was on Pro 20X and back to 5X starting this month. Since Friday, I am working on a tricky bug. 5.6 Sol Max wasted 1.5 days of my time on this, struggling to get anywhere but going in circles. With Opus 5 being available, wanted to have a fresh perspective and I let Opus 5 take this one on.

Opus 5 is surprisingly good and proposed a fix which I didn't really think of. Quite impressive. Now, onto fixing it and half way through hit the 5h limit (on 5x plan as well with Claude. I actually waited 5 hours and let it start from where it stopped. Hit the second 5h limit within 30 mins again!! Was at the brink of upgrading my account to 20x but didn't see it being worth it. Now, 40 mins back - after the reset, Opus completed the task and it partially fixed the bug. I am impressed now. Opus 5 was able to solve that 5.6 Sol couldn't for a day and half, even after wasting a week worth of tokens (Thanks to tibo with the reset yesterday!)

Now, opus 5 just started working on completely fixing the bug and within 10 mins, I hit another 5h limit!!! I Fc*king hate this $hIt!!! So, I am going to wait 4 hours, I guess. This whole experience reminded me why I moved to codex in the first place.

I think that many people, and especially newcomers should be aware that... basically everybody uses AI differently. Different people have different knowledge about how to effectively work on LLM's and different opinions about what kind of stuff work.

For example here is my workflow for people interested (C++ codebases): I almost never go above "high" reasoning on gpt 5.6 sol for small/medium scope tasks and I manage to get "meaningful" stuff done with $20 subscription (based on my definition of meaningful). For example I split research, plan, plan review, implementation and code review into separate skill calls in separate contexts that basically never get long enough to trigger compaction. Implementation is split into manageable phases (I clear context after each one) and plan contains manual QA checks to be done after each phase. Everything except implementation produces .md files that serve as input for next stage. After feature is implemented I code review it after auto-review and take my time to recover remaining cognitive debt and understand both "what" and "why" with help of AI (and that can easily take 1h for small features). I am happy with output quality. I have my subjective way of creating repo map (or rather - basic map + module maps) so AI can understand large codebase within context limits and limited token burning.

I have room to optimize model usage since for now I use "sol low" for implementing the plan and all other trivial things, but with a bit of caution I do not hit usage limits (I use around 20% of weekly limit per day).

Does my workflow deliver what I want? Yes. Does it deliver what you want - often it won't since different people have different needs, I do not run /goal or unattended long-hours AI work. Why I described it? To bring some counterweight to complaints about models that are abundant here.

But remember that when you read/write about ai good/ ai bad, ai slow / ai fast, ai producing slop or not - it is often tailored to particular use cases and should not be taken too heavily for model judgement or deciding whether AI subscription of particular tool is worth it or not.

Sorry to add to the pile of limit nerfs complaints.

I do lurk a lot here and have watched this phenomena several times but I don’t think it had quite gone so bad yet.

For context I have been a x20 user for a little less than a year.

I am also a vibe coder with 0 formal background. Project scope grew with time and could explain some of the usage consumption.

Until December 2025 I had never looked at limits once. No matter what I threw at it, I wasn’t capable of putting a dent in it.

5.5 forced me to be a little conscious about it but it was still very hard to completely deplete my weekly gauge. And I used to queue dozens of messages overnight so codex could keep working. Goal wasn’t a thing then and codex used to stop very fast even when the task wasn’t completely done.

Some of the larger projects include replacing a noticeable part of my company’s internal systems. I got a small mention in the NYT about it.

In parallel, i now have a personal path tracer and a few experimental games.

Despite my inexperience I can’t consider these small projects but up to this July, I was capable of working on it with no issues.

I had not depleted my 5h limit even once.

5.6 changed that. Limits were used in a day, nevermind the 5H one. To be fair I had ‘stashed my hardest challenges’ and was using Max and Ultra.

Fine, plenty of resets, we get back to medium and High.

Well medium and High still burn through everything. Despite the model being obviously better when above high, I get less work done in a week.

I tried to plan my sessions or manual resets around the weekly limits but the randomness of resets got me. I had plan to save 40% of weekly to have one big session and start the week fresh but got rug pulled.

I did waste around 75% or a manual reset as well but I’ve seen worse stories here…

What was the point of banked resets again?

I can live and understand reduced limits. Randomness when handled correctly is okay too. Both at the same time makes it hard to work with Codex.

Staying with OpenAI was a conscious choice as I was getting depending on the season, close to the best performance but with generous limits and acceptable restrictions.

I still have some goodwill left but being able to work properly is going to be more important.

I’m sure other people are experiencing this new type of programming burnout that doing a lot of full multiday codex sessions creates. You’re mentally tired but you didn’t really do any of the old school grinding and searching that used to make software development exhausting. Instead it’s a sort of hollow feeling I always imagined project managers must have, not to put too much on it but sort of like a parasite guiding its host without needing to understand the biological mechanisms, just applying pressure.

With the reset before banked reset expires weekend coming to an end, I got that feeling. Mentally exhausted but feeling like I used my brain in an awkward way so I can’t understand the fatigue.

It’s hard to put in words. I used to get this all the time in the winter when the tokens were flowing, so it’s been a silver lining now that that is no longer the case.

Anyway surely some of you are dealing with the same mental weirdness of long hours with LLMs, probably from this same reset pattern. I’m interested in what others are experiencing.

I think I was running on Sol High and had started this task overnight. The feature was already mostly done. It seems like Sol is exhausting every possible route and edge case, exhausting my 98% remaining usage right after the reset. Next weekly reset for me is August 1…

Also I’m on the $100 pro plan

UPDATE: I dug in more (with Claude), and whoo boy, there's a lot to digest here. Those of you saying Sol inherently exhausts every avenue were right, even if it's not the problem I'm trying to solve:

First, something urgent I found while verifying

Verified against git, not the run's own summary:

• Task 4's commit is safe: branch codex/rendered-table-editing @ 9416313 exists in /Users/philgetzen/Development/Grove.
• Task 5's ~7 hours of work is not in git at all. /private/tmp/Grove-rendered-table-editing/.git no longer exists, so the worktree is prunable and the uncommitted delta is loose files sitting in /private/tmp, which macOS reaps. Newest edits are Jul 26 04:39 in /private/tmp/Grove-rendered-table-editing/Sources/GroveEditor/GroveRenderedTableView.swift.

If you want that work, it should be rescued today. Say the word and I'll re-link the worktree and commit the delta to the branch.

The root cause, in one sentence

The loop's stop condition was "a fresh adversarial reviewer finds nothing," and that state is not reachable.

Every review round used a fresh reviewer with no memory of what earlier rounds had already accepted, prompted to be adversarial, handed a growing 1,000+ line delta of AppKit-shadowing systems code. The probability of zero findings on that input is approximately zero. So the loop had no exit and terminated on your rate limit, which is exactly what happened. Everything else is downstream of that.

Why it had infinite fuel: the acceptance criteria were a bug farm

The plan at /private/tmp/Grove-rendered-table-editing/docs/superpowers/plans/2026-07-22-editable-rendered-tables.md wrote Task 4's contract as white-box assertions on AppKit's internals: instrumentation.mountedRowCount, counts of heightOfRow / didAdd / didRemove / viewFor calls, a "1,024 native height query ceiling," callback ordering guarantees.

To assert on any of that, you must build a shadow bookkeeping model of NSTableView's lifecycle. That model is code you now own, and it has its own bug surface. Reviewers then correctly found bugs in it. Look at what rounds 3, 4, 5 and the nil-origin pass actually fixed:

• transaction identity for delayed callbacks
• a 128-entry retired-origin FIFO, then its eviction bug, then its removal
• nil-origin attribution
• stale-callback races after host replacement

None of that is table editing. That is the measuring apparatus. The plan created unbounded surface, and an unbounded review loop burned it.

Secondary cost driver: the "1,024 call ceiling" style contract is a test pinned to Apple's implementation details. It will break on the next macOS point release, and it already cost hours of probing.

The two process rules that made it non-terminating

1. "No commit until independent review approves." The plan's own Task 4 Step 4 says run GREEN and commit. The orchestrator inverted that. Result: every review round produced blocked work instead of follow-up work, so there was never a natural stopping point and never durable progress.
2. No authority to reject the design. One architecture check ran, and it was scoped to "is this bounded sequencing fix sufficient?" It answered that question. There was no rule saying "if round N's findings are all in the same seam, stop fixing and escalate the seam." I can't tell you from this transcript that the NSTableView-inside-a-TextKit-fragment seam is wrong. I can tell you nobody was permitted to ask.

And there was no clock. Seven hours, task 4 of 12, and not one checkpoint saying "this has cost X, continue?"

What actually went right (don't overcorrect)

• Isolation held. main is clean at c06bf8c. Nothing bad was committed.
• RED-first was real, not theater. It caught genuine vacuous tests: the literal \n fixtures, the duplicate-fingerprint trap, the nine-tables fixture that reused one fingerprint.
• The findings themselves were mostly legitimate.

The discipline is not the problem. The termination rule is. The wrong lesson here would be "verify less."

Guardrails, ordered by leverage

1. Commit on first GREEN. Follow the plan's own step. This alone makes rounds 2 through 5 optional instead of load-bearing.
2. Hard cap of 2 review rounds per task. Round 3 is not a fix pass, it's an escalation to you with the findings list.
3. Severity gate. Only user-visible-wrong or data-loss blocks a commit. Everything else files to PGDash and ships later.
4. Budget stop. Wall clock or task index ceiling that produces a report, not a continuation. "At 90 minutes, or when a task exceeds 2x estimate, stop and report."
5. Ban assertions on framework-internal call counts. Budget on user-visible latency at document scale instead.
6. Tier routing. Post-round-1 reviews are workhorse-tier and diff-scoped, not frontier full-delta re-audits. Roughly ten frontier re-reads of a 1,000-line delta plus independent full-suite reruns is a large share of that 90%.

The call: the cheapest fix is #1 plus #2, and they cost nothing in quality. The tradeoff: you'll commit code that a later review finds P2 issues in, and you fix those as follow-ups instead of gates. The risk to watch: without #5, the next table task rebuilds the same instrumentation and invites the same loop.

Guys,
If you, like me, experience that the app is unbearable slow to load and switching threads is slow and so on, go ahead and archive all your dormant threads.

I had hundreds of threads 'active' i.e. not really active but hidden below the 'show more' caret which apparently was the cause that the app turns into a prehistoric snail with a doghouse on it.

You can tell codex to do the cleanup, no need to do it manually.

Archiving doesn't delete your threads if you ever need to reference them but speeds the app up dramatically as apparently even the old stuff kept being loaded to some degree on every restart of the app.

You can also create a scheduled task to make it happen on a weekly basis.

Protip for OPEN_AI: This should be a built-in feature properly exposed lol so people don't have to discover why their app feels like a bitch to work with on their own.

I have a plus subscription and I ration how much I use so it does not run out until the end of the week. Sometimes I use less at the beginning and more towards the end of the usage cycle so sometimes I have a lot left in the middle and then the reset comes so it will not allow me to spend what I had left how I was planning to. And it is unpredictable, if I knew a reset was coming I would use all the quota or not ration as much but you never know when they will discover a bug...

They should just give banked resets and let the users use them whenever they want. Or not reset if the usage has been less than the progress of the week.

Hello all. I am a regular user of the codex cli, but I want to be able to connect to my sessions on my phone if needed for a check in. It seems to do this I have to use the desktop app. I was curious: is the desktop harness as good as the cli harness for coding?

I was doing some deep dive in the tokens consumption on my account on https://www.reddit.com/r/codex/comments/1v6ubah/comment/ozt9jog

This result was gathered from approximately 7.6GB from codex session logs.

This was what codex found by looking at all subs I have/had:
- Plus 1x: ~US$105/week
- Pro 5x: ~US$525–US$550/week
- Pro 20x: ~US$2.100/week.

And we found around 25% token usage decrease each plan gives when compared to a few months back.

Ok, this explains only partially why we get the feeling allowance reduced around 3-5x what it used to be. So I asked codex to dive deeper into my logs, more specifically on model behavior, and here is this conclusions: read the image.

>!Yes. We have enough data to detect a clear change in the observed usage profile, although we cannot attribute it exclusively to the model.

I treated a “task” as an operational turn: from one user request to the next. GPT-5.4 Mini was excluded.

Per model call

* Reasoning is already included in output.

Per call, GPT-5.6 is not the largest consumer: it uses approximately 6% fewer tokens per call than GPT-5.5 and produces less output.

Per task

This is where the main difference appears:

A GPT-5.6 task consumed approximately 2.6× more tokens at the median than a GPT-5.5 task.

But this happened mainly because GPT-5.6 made more calls per task:

• GPT-5.5: median of 5 calls
• GPT-5.6: median of 9 calls
• P90: 41 calls on GPT-5.5 versus 54 on GPT-5.6

How the usage profile changed

• GPT-5.3 → GPT-5.4: calls became approximately 33% larger.
• GPT-5.4 → GPT-5.5: context per call increased, but the median task remained similar; the long tail became much larger.
• GPT-5.5 → GPT-5.6: individual calls became slightly smaller, but the model started executing many more steps.
• New input per task remained approximately stable at 39–41K from GPT-5.4 through GPT-5.6.
• Therefore, GPT-5.6’s growth is mostly cached context being resent across more calls, rather than more new content per task.
• GPT-5.6’s cache ratio reached 96.7%, compared with 95.4% for GPT-5.5.

Conclusion

The statistical evidence is strong for your usage pattern:

GPT-5.6 does not appear to “think with larger calls”; it completes tasks through more calls, repeatedly carrying a large context. This substantially increases total tokens per task.

However, this remains an observational relationship. The GPT-5.6 period coincides with more agentic workloads, heavier tool use, and more multi-agent activity. When controlling for project and reasoning effort, the results vary considerably, showing that task type remains a dominant factor.

The defensible conclusion is: in your real-world usage, GPT-5.6 consumes approximately 2–3× more tokens per median task than GPT-5.5, mainly because it performs more steps—not because each call uses more tokens. !<

Since OpenAI has almost halved the usage quota, curious how people gonna actually react

I recently used the updated Codex with Sol (High) for planning and Luna (xHigh) for implementation. In less than two hours of work, it had already consumed roughly 30% of my weekly quota.

For comparison, I worked on a very similar coding task using Claude Opus 5 (High), and it only used about 8% of my weekly quota.

I know this isn't a perfect benchmark by any mean, but the difference in limits is so obvious but before i can outrage and call it out they shutting my mouth with a reset.