@cheesealloverme@thsottiaux Using quota just because it might suddenly disappear isn’t a (strategy). That’s exactly the problem. A weekly allowance should be usable when needed during the week, not rushed through because an unexpected reset might wipe the remainder..
You’re talking about total usage over a month, which is a different point. Extra resets may have let you use more than 400%, but that doesn’t change the fact that this reset wiped remaining quota and restarted the weekly clock. More resets overall does not mean nobody lost usage in this specific reset..
You’re mixing hypothetical future resets with the quota many of us actually had. Many users still had remaining usage and a scheduled reset only a few days away. After the forced reset, that remaining quota disappeared and the next weekly reset was pushed back. If those extra resets aren’t guaranteed, they don’t belong in the calculation.
You’re averaging two different time windows and treating a weekly quota like it accrues daily. It doesn’t..
By day 7, my old schedule gave me access to 45% + 100% = 145%. After the forced reset, I have only 100% until day 7. The timing of access is the whole point, not an invented “14.3% per day” average..
That math assumes the weekly quota accrues evenly at 14.3% per day. It doesn’t. It’s a 100% bucket, not a daily allowance.
I had 45% left that I could use in those 3 days, then a fresh 100% on my scheduled reset. After the forced reset, I only have 100% until day 7. So the 45% wasn’t “2.1% lost” just because you divided the week by seven..
@GillenGuo@thsottiaux Exactly, I noticed the same thing. My usage is draining noticeably faster after the reset, which makes pushing the next weekly reset back even more frustrating..
@JeBrilleO@thsottiaux That’s exactly the problem. “They’ll reset in 3-4 days” is not guaranteed. We already saw reset issues after Sept 12, where users had to wait for their scheduled weekly reset. The weekly reset date is the only thing I can actually rely on, so pushing it back matters..
@Asserali@thsottiaux@codex_resets That actually proves my point. Everyone paying for the plan intends to use their quota, but people should not have to rush and burn 40% just because a surprise reset is coming. Unused paid quota should not become a (use itnow or lose it) situation..
You’re changing the comparison window to make the reset look better than it actually was for my situation.
Before this forced reset, I still had 45% of my current weekly limit left, and my normal weekly reset was only 3 days away. That means I could use that remaining 45% first, then receive a fresh 100% on my normal reset date... That is up to 145% of usable quota across that period.
After the forced reset, I was put back to 100%, but my weekly reset date was pushed all the way to 7 days from now.. So the 45% I still had was effectively wiped out, and the next 100% was delayed.
Your 200% over 10 days only works because you extend the time window until after the new reset happens. That does not change what happened to the quota I already had available under my original schedule.
And “maybe there will be another reset” cannot be used as part of the argument. That is hypothetical. You cannot count an unannounced future reset as if it is guaranteed compensation..
My point is simple: I had 45% remaining plus a scheduled reset in 3 days. After the compensation reset, I had 100% but had to wait 7 days for the next scheduled reset. For someone in my position, that reset reduced the amount available under the original schedule instead of adding to it..
Yeah, I get why you’re frustrated. For me the main issue is just the reset date getting pushed back. Some of us were only 2 or 3 days away from a full reset, so this ended up making the situation worse instead of better. I don’t think anyone needed to be blamed personally, but the way this reset was handled definitely needs another look..
That’s not really the point though. Even if they reset again on Tuesday, this reset still pushed everyone’s weekly reset date back and wiped the benefit of the quota people had saved. Some of us were only 2 or 3 days away from our normal reset. We shouldn’t have to depend on another possible reset just to get back what we were already due to receive.
@Clear_up_KM@thsottiaux Yeah that’s actually worse. You purposely saved that 60% because you knew you had a lot of work coming up, and your reset was only 2 days away. So you were about to have 160% available, but now it’s just 100% and another 7 day wait.
@WkfChristopher@thsottiaux Exactly. Making it optional would’ve been much better. You still had 80% left and only 3 days to wait, so getting just 20% extra now and then being pushed back to another 7 days makes no sense. That’s the part they need to fix..
@automadynamics@thsottiaux lol yeah, pretty much 😅 I was supposed to get something extra from this, not lose the 45% I already had before my next reset. Resetting the usage is fine, pushing the reset date back is what messed it up.
The Biggest Trap in AI Right Now: The Collapse of “Cost Per Finished Project”
I’ve been building with AI since the early ChatGPT and Codex days.
Back then, AI felt like an accelerator. You gave it a task, it understood what you wanted, wrote relatively clean code, made the change, and stopped. You could move fast and actually finish projects.
Fast-forward to today’s FRONTIER models, and my experience has flipped.
Benchmarks keep rising and agents can work for hours, yet finishing a project feels slower, more expensive, and more exhausting.
The metric that matters most is being ignored:
Cost Per Finished Project.
Not tokens per second. Not SWE-bench. How much money, time, and human supervision did it take to get from an idea to a finished project?
Today’s workflow increasingly looks like this:
Understand project → ask for a change → AI explores half the codebase → invents an unnecessary abstraction → modifies adjacent systems → introduces a bug → starts debugging → forgets an earlier constraint → another regression appears → usage keeps burning → you hit the limit.
A small change becomes a session. A project that should have taken weeks starts dragging into months.
Much of that extra work is complexity introduced by the AI: more abstractions, files, rewrites, tool calls, and more chances to break something it previously got right.
The loop becomes:
AI adds complexity → more context → more reasoning → more usage → more bugs → more debugging → even more usage.
Meanwhile, the project still isn’t finished.
I’ve personally felt the difference across the pricing eras.
The $20 era: serious coding was practical. The model answered the task and usually stopped.
The early $200 era: the larger allowance made heavy AI development genuinely powerful. You could work aggressively and still finish substantial projects.
The $200 era today: agentic models can burn huge amounts of the allowance exploring, looping, testing, reconsidering decisions, and repairing problems they introduced themselves.
So even if the subscription price looks unchanged, the amount of finished work you get from it can be dramatically lower.
That is the hidden inflation nobody talks about.
The real price is:
Money spent ÷ finished work produced.
From my experience, that number has gotten much worse.
And this doesn’t seem isolated. Developer communities are full of people describing agents overthinking basic tasks, burning through limits, creating correction loops, ignoring simple instructions, and turning straightforward changes into architectural projects.
Then comes the part that makes this especially frustrating.
While heavy users complain about exhausted limits, reports appear about even higher subscription tiers, including a possible “Pro Max” tier aimed at heavier Work and Codex usage.
From a paying developer’s perspective, the progression is hard to ignore:
More agentic workflows → more work per task → limits become easier to hit → the same project needs more sessions → more usage becomes something you can buy → an even more expensive tier appears.
So the obvious question is:
Are these models actually making us more productive, or are we just paying for more AI activity?
Those are not the same thing.
If a model spends 30 minutes reading 40 files and calling 20 tools when a simpler model could correctly change two files in five minutes, all that extra intelligence produced negative value.
I care whether the project got finished.
That’s the benchmark I want:
Give the same real-world project to every model generation. Measure money spent, time, human interventions, regressions, code churn, and how often the model fixes its own mistakes.
And most importantly:
Did it finish the project?
Then calculate Cost Per Finished Project.
AI coding was supposed to eliminate development friction.
Increasingly, it feels like we’re paying the AI to create friction and then paying it again to remove the friction it created.