Same here, tested on both the old & the latest Codex apps.
I think they could easily deploy the old models and reinstate the old service.. nobody wants that. Really. They got new models, new offer. The old plan is discontinued. And it was never said, that it will exist forever. Do the legal path.. they will be annoyed for 20 seconds… but they might as well laugh a little
So here is a practical thing you may do:
start a new chat for every task. I know it is inconvenient but it helps to bring down the other wise average of approximately tokens per request from ~170-180k down to 15-20k. Which means you should - in theory get 10 times what you get now.
If you dream about letting the model do stuff on full auto mode then you should at least be able to build it without a model. Otherwise you should see it as a very well payed employee.
OpenAI gives programmers a cheap programming tool and people who are not programmers an employee that is expensive like a real developer.
I really appreciate this from OpenAI!
Also this may help to reduce cost (which should in theory give you more usage of codex - anyone would like to try that).
You have to keep in mind that the old plan is discontinued, yes, however, only for new users, not for existing users. In other words, my 200 USD plan is still active, is being renewed and I am still paying for it every month. Also, the purpose of taking legal action is not to annoy them, but to set an important precedent for others.
@jochenschultz Also, I just saw this:
Edit:
Sorry @Olufsen, I replied under your message by mistake.
Has effective Codex usage on Plus changed substantially? My session data suggests it has.
I use Codex in the VS Code extension for sustained work on the same software project. Recently, I have reached the usage limit after roughly an hour, including when using Sol 6 Light. Previously, I could often work for several hours. I cannot justify moving from a roughly €20/month plan to a roughly €100/month plan simply to regain workable sessions.
I compared my recorded sessions:
| Period | Sessions | Average tokens/session | Average active work/session |
|---|---|---|---|
| March | 3 | 133.0M | Unavailable |
| April | 3 | 265.6M | 363 min* |
| May | 9 | 86.6M | 304 min |
| June | 6 | 99.1M | 340 min |
| July | 8 | 110.7M | 272 min |
| August | 3 | 81.7M | 229 min |
| Spring | 15 | 131.7M | 315 min* |
| Summer | 17 | 101.5M | 288 min |
| Recent three | 3 | 13.2M | 27+ min |
Active-work telemetry is unavailable for March and one April session. Spring’s duration estimate uses the 11 sessions with recorded task durations. One of the recent sessions was still active when I compiled the table.
This is a small personal sample, and session length alone cannot establish which limit or accounting change caused the difference. But the change in effective working capacity is large enough to warrant an explanation.
Could the Codex team clarify whether Plus allowances, model quota weights, context or tool-use accounting, or the way limits are applied have changed? Is there a regression affecting VS Code extension users? Per-task usage and remaining-capacity data would make it much easier to understand what is happening and plan work.
For a tool used in long development sessions, the practical question is how much work a subscriber can complete before hitting a limit. I would appreciate clear communication about any change to that capacity.
That’s the context window filling up. On long runs the older turns get summarized or dropped. What’s helped me: keep an AGENTS.md with the decisions and constraints that must survive, and ask Codex to update a short progress note every so often (what’s done, what was tried, what’s still open). When it starts drifting, open a fresh session and point it at that note. It also goes easier on rate limits, since you’re not dragging the whole history along.
Well well well. Who could’ve possibly have known that that was the goal all along. But of course what we get instead is that all of us who have been reporting that token burning is “we’re all delusional.”
$200 Plans. Ya, that sounds more like it.
Share it with other OpenAI defenders here, let’s see how they are going to spin that one and what kind of shoe polish they have to lick this time.
Following to jevgrep I was testing to implement Laya - a local decission model - instead of jev…
With disappointing results!
I am still posting it here so you don’t have to test it.
But, with the new decission model of openai I will test it again.
There are ways to reduce token usage with it! Maybe give it the error messages and let it decide which one is important atm to a friction of the price and much faster…
Let’s solve this stuff! I am sure we can get coding affordable for everyone. If anyone is interested we can make that an open project and go through it step by step.
I’ll be brief. There’s no possible reading of the recent changes to usage limits that could be viewed as benefiting developers. We’re getting half the benefit for all of the same price. All I’m going to say here is that Open AI has burned a lot of goodwill with the developer community in doing so.
So, this 5 hours thing is trying my temper!!
ONE prompt for a simple update on a function, it took 70% of it.
so i thought this next one a tiny fix as it broke the code…
as it was fixing the code, RAN OUT OF CREDIT now i’ve got half finished project! i cannot compile it, missing commands, it literally just left my project corrupted !!
codex has become un-usable now.
i can’t afford more than the plus! my coding skills are slow, Codex speeds things up, but now, it feels like i could write the code at the same rate now. almost pointless using the codex at this point now.
AT LEAST let us FINISH the last prompt and leave the code compilable, even if its the wrong result!! its something to work with!
so frustrated!
Well, what I found so far is the following:
GPT 6.1-sol < the sol stands for solid! Because it is a solid model.
It just does what you tell it to do - although you have to keep an eye on the implementation of LLM - because: the models in general tend to use too many tokens.
Let me give an example.
I have build a logo generator as part of my SaaS builder system and I wanted it to get me a text logo with an icon.
First it implemented a flow where it first made the logo, then used that as an example for a second llm call to generate the icon that I want when a sidebar is minimized.
As you can tell the icon wasn’t really good.
So I asked it to prompt the model to use a specified area for the icon and the text beside that. Which lead to a control flow where the model decided to check if the icon overlaps the area.
Which then went into a loop because it happened pretty much every time.
I solved it by explaining the model that I want it to OCR the text and remove it and then cut out the icon. Which is not only faster than a new image generation but also more reliable.
And then I told it to write a script that inverts the colors so I got 4 images (two text + icon and two icons for darkmode and lightmode).
I havn’t tried by telling it to do it as determnistic as possible and it is only allowed to use one llm call. But at this point I doubt it would have solved it without serious api cost.
But then on the other hand when I asked it to build some modules it was even following i18n and theme compatibelity without me mentioning it. And the other models never did that, not weven astra did that reliable.
And anotehr thing that I found is: I had a couple files opened - huge files - and i didn’t remove the option where the model should use opened files for the context.
I think that was really expensive.
And another thing: you should not let the model run on auto approve when you are on a budget. You are on a budget that means you have to work more than people who are not. That is how the world works (at least for now.. who knows maybe we will live long enough to experience a change - maybe after the next large scale world war - but I doubt it).
Are you being paid by deepseek or anthropic? That’s the question.
The limits have changed. But they are not going to tell you that. What they’ll tell you is “in order for you to be able to do what you did before you need to pay us 5 times as much. And if you want to go beyond that understandable limit, you will need to pay us 10 times as much.”
Codex’s allocated usage time for paid subscribers is so short that it’s becoming almost useless for serious work.
When I started using Codex, I was getting around 40 minutes of continuous work, compared with roughly three times that on Claude. But over the past couple of days, Codex has dropped to around 20 minutes of continuous work.
Twenty minutes is simply not enough for any substantial coding task. You barely get into the flow before hitting the limit. And if the solution is to pay even more just to get a reasonable amount of working time, that makes the paid subscription less appealing. Because of this, as a programmer, I now use it almost exclusively for finding bugs that can be fixed quickly.
Just noticed this: The ‘Pro’ plan is now called “Standard usage”.
I mean…if they’re going to try to be clever at gaslighting people, they could’ve at least tried to do a better job. Absolute B.S.
Until a very competitive alternative comes along, nothing will change. Except it will get worse from here on out.
I am pretty positive that we are just a few months away from outcome based creation anyways. You explain the bot what you want and it will tell you an aproximated price. Tokens is just for the experimentation phase .. that’s what I think.
It is not that far.
Let the model split the task in doable issues per turn.. and it comes out at ~1 million tokens per issue. That’s easy to calculate actually.
Posting here because it could be relevant to the workflows of some of you, and also because other than the questionably useful support bot, I don’t have a way to relay this to anyone.
A single scheduled task has nuked my weekly Plus usage, nothing else was running to my knowledge since I wasn’t working this week.
I don’t really care about the usage since I can just use a reset. What concerns me is that the only reason it stopped was that it found a match, otherwise at the rate it was going it would’ve not only blow through my entire weekly usage, but likely consume the ~$80 in credits I currently have on my account. I don’t even want to imagine the nightmare that would’ve been to attempt to recover.
I know there was an update around June of this year to give scheduled tasks more abilities through Work, but over the summer i didn’t notice any significant usage consumption, but looking into it i do see blips that would account for some trivial usage.
I asked it to monitor eBay for the arrival of a product released in Asia that would make its way over to North America. The task was set up automatically by the model (normal conversation via 5.6 over web) after i clicked the button to accept it. This is the prompt the model used:
Check current online marketplace listings for the exact (name of the item previously discussed in the thread). Notify me only when you find a listing that offers direct international shipping to (where I live) without requiring a forwarding/proxy service. Include the marketplace, seller, item price, shipping cost if shown, total before tax if calculable, and a direct link. If no qualifying listing is available, do not notify me.
Text in (parenthesis) my edit. In the context of the conversation that led to the creation of the task, “marketplace” had a very define range of sites to use (eBay, Etsy, Mercari). I suspect that the model running from the task didn’t have the benefit of the context of the original thread, so it had to guess what “marketplace” meant, and probably ran around the entire internet doing so.
Where my previous scheduled tasks ran with gpt-5.6-sol, this one apparently ran as a fully clouded environment using gpt-5.6-sol-vm.
This task:
My last run of another similar scheduled task:
No idea why this task incurred the use of the massively more expensive gpt-5.6-vm model and cloud environment, previously similar tasks were perfectly happy to run in something more appropriate.
Meanwhile, my expectations when accepting the task was that the model would simply query eBay, check if the listings returned were greater than 0, and ping me when it did.
Worse still, the task was scheduled hourly for some unexplained reason, where all of my previous tasks ran daily or weekly, unless otherwise specified.
Finally, I have no idea where `If no qualifying listing is available, do not notify me.` came from. I had entirely forgotten about this task by the time it resolved, and this task would’ve probably kept consuming my account until the end of time.
tl;dr:
Suspected failure: Model failed to provide the proper context when writing the prompt for a scheduled task, leading it to silently consume disproportionate amounts of compute.
Impact: Near complete weekly quota usage on a single task. Strong risk of consumption of Codex credits, which would’ve been a near certainty if I was actually using Codex that week.
Suggested improvements: Allow the users to block the usage of cloud compute for scheduled tasks (allowing the model to fail gracefully if the task really required such resources. Allow the user to block the consumption of credits by type of task (such as scheduled tasks) unless they either authorize the task (as Codex CLI does I believe) or opt into it account wide. Improve the Codex usage dashboard so it’s more clear what the origin of the usage actually is, it’s insane that that dashboard still doesn’t offer any granularity.
I strongly suggest everyone takes a look at what their scheduled tasks have been doing in the last couple weeks, I suspect I’m not the only one affected by this reading the thread.
If it gets to, as you say, to be “Pay-per-task”, I will cancel my subscription altogether and will never look back. That sounds like a terrible idea.
What they need is a middle tier between Plus and Pro for people who want more than Plus but less than Pro.
I don’t think anyone needs a subscription anymore when Pay per task is implemented.. because what are the devs needed for then?
Everyone can just tell their dot to make what they need without the middlemens