Because the goal is to extract more money from the people who have significant usage. These users are the actual targets of the product. The idea that it’s a few bad actors is misdirection of blame to distract “power users”.

They undercharged for this product to collect usage data to build better coding agents in the future. It was a ploy for data.

Anecdotally, I use Claude Code with the $20/mo subscription. I just use it for personal projects, so I figured $20 was my limit on what I’d be willing to spend to play around with it. I historically hit my limits just a few times, after ~4hrs of usage (resets every 5hrs). They recently updated the system and I hit my limits consistently within an hour or two. I’m guessing this weekly limit will affect me.

I found a CLI tool (which I found in this thread today) that estimates I’m using ~$150/mo in usage if I paid through the API. Obviously this is very different from my payments. If this was a professional tool, maybe I’d pay, but not as a hobbyist.

What was the name of that CLI tool?

It’s called “ccusage”. Search for other comments on this story for more details.

> why not figure out how to special case them without affecting everyone else

I’m guessing that they did, and that that’s what this policy is.

If you’re talking about detecting account sharing/reselling, I’m guessing they have some heuristics, but they really don’t want the bad press from falsely accusing people of that stuff.

fair enough - DS probably ran through data and came up with 5% and some weekly cutoff as a good starting point until they have better measures in place

my point is that 5% still a large cohort and they happen to be your most excited/creative cohort. they might not all want to pay a surchage yet while everyone is discovering the use cases / patterns / etc

having said that, entirely possible burn rate math and urgency requires this approach

They did have several outages last week, it would be good to find better plans for those huge users but I can also see them wanting to just stop the bleeding.

I've noticed the frequent perf issues and I'm on the 20x plan myself - good point that you'd want to stop the bleeding or bad actors to make sure the majority have a better experience

> why not figure out how to special case them without affecting everyone else is the primary question I would ask myself if I worked on this

The announcement says that using historical data less than 5% of users would even be impacted.

That seems kind of clear: The majority of users will never notice.

5% of a large number is a large number - this why it's both a significant problem for them and why I'm thinking out loud about the downsides of discouraging good actors who happen to be power users.

that 5% is probably the most creative and excited cohort. obviously it's critical to not make the experience terrible for the 95% core, but i'd hate to lose even a minority of the power users who want to build incredible things on the platform

having said that, the team is elite, sure they are thinking about all angles of this issue

5% seems like a huge number of previously ecstatic customers who may suddenly be angry. Especially when it is trivial to identify the top 0.1% of users who are doing something insane.

What do you think they should have done instead?

At a bare minimum there needs to be some way to understand how close you are to these limits. People shouldn’t be wondering if this is going to impact them or not.

It’s tricky without seeing the actual data. 5% of a massive user base can still be a huge number so I get that it’s hard to be surgical.

But those power users are often your most creative, most productive, and most likely to generate standout use cases or case studies. Unless they’re outright abusing the system, I’d lean toward designing for them, not against them.

if the concern is genuine abuse, that feels like something you handle with escalation protocols: flag unusual usage, notify users, and apply adaptive caps if needed. Blanket restrictions risk penalizing your most valuable contributors before you’ve even discovered what they might build

5% of a massive user base could also be huge if 50% of users are on an enterprise plan and barely using it.

in other words, these limits will help introduce Enterprise (premium) plans?

> if it affects only a minority of accounts, why not figure out how to special case them without affecting everyone else

that's exactly what they have done - the minority of accounts that consume many standard deviations above the mean of resources will be limited, everyone else will be unaffected.

"You're absolutely right!" i misread the announcement - thought everyone moved to primarily a weekly window but seems like 5hr window still in place and they're putting in place another granularity level control that DS teams will adjust to cutoff mostly bad actors.

correct me if I'm wrong, it's not like we have visibility into the token limit logic, even on the 5hr window?