if it affects only a minority of accounts, 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 principle: let's protect against outliers without rocking the behavior of the majority, not at this stage of PMF and market discovery

i'd also project out just how much the compute would cost for the outlier cohort - are we talking $5M, $100M, $1B per year? And then what behaviors will simply be missed by putting these caps in now - is it worth missing out on success stories coming from elite and creative users?

I'm sure this debate was held internally but still...

▲

vineyardmike 5 days ago | parent | next [-]

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.

▲

benoittravers 4 days ago | parent [-]

What was the name of that CLI tool?

	▲	vineyardmike 4 days ago \| parent [-]
		It’s called “ccusage”. Search for other comments on this story for more details.

▲

Uehreka 5 days ago | parent | prev | next [-]

> 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.

	▲	arach 5 days ago \| parent [-]
		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

▲

data-ottawa 5 days ago | parent | prev | next [-]

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.

	▲	arach 5 days ago \| parent [-]
		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

▲

Aurornis 5 days ago | parent | prev | next [-]

> 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.

▲

arach 5 days ago | parent [-]

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

	▲	0cf8612b2e1e 5 days ago \| parent [-]
		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.

▲

bananapub 5 days ago | parent | prev | next [-]

> 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.

	▲	arach 5 days ago \| parent [-]
		"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?

▲

nharada 5 days ago | parent | prev [-]

What do you think they should have done instead?

▲

actsasbuffoon 5 days ago | parent | next [-]

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.

▲

arach 5 days ago | parent | prev [-]

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

▲

smileysteve 5 days ago | parent [-]

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

	▲	arach 4 days ago \| parent [-]
		in other words, these limits will help introduce Enterprise (premium) plans?