> One user, who asked not to be identified, said it has been impossible to advance his project since the usage limits came into effect.
Vibe limit reached. Gotta start doing some thinking.
Vibe limit reached. Gotta start doing some thinking.
Paid compilers and remotely acessible mainframes all over again - people apparently never learn.
I don't think this one is a good comparison.
Once you had the binary, the compiler worked forever[1]
The issue with them was around long term support for bugs and upgrade path as the language evolved.
---
[1] as long you had a machine capable of running/emulating the instruction set for the binary.
Clang is not being professionally used commonly in the embedded space.
IAR for example is simply a fantastic compiler. It produces more compact binaries that use less memory than GCC, with lots and lots of hardware support and noticeably better debugging. Many companies have systems-engineering deadlines which are much less amenable to beta quality software, fewer software engineering resources to deal with GCC or build-chain quirks (often, overworked EEs writing firmware), and also a strong desire due to BOM cost to use cheaper/less dense parts. And if there is a compiler bug or quirk, there is someone on the other end of the line who will actually pick up the phone when you call.
That said, some of those toolchain+IDE combos absolutely do suck in the embedded world, mostly the vendor-provided ones (makes sense, silicon manufacturers usually aren't very good at or care much about software, as it turns out).
That's true in general. With paid licenses and especially subscriptions, you're not just getting the service, you're also entering a relationship with the provider.
For companies, that often matters more than the service itself - especially when support is part of this relationship. That's one of many reasons companies like subscriptions.
For individuals, that sucks. They don't need or want another relationship with some random party, that they now need to keep track of. The relationship has so much power imbalance that it doesn't benefit the individual at all - in fact, for most businesses, such customer is nothing more than a row in an analytics database - or less, if GDPR applies.
(Also AVR/PIC compiler from Microchip had a dongle as recently as February this year, and it looks like it's still available for sale even though its license isn't in the new licensing model).
The destruction of spelling didn’t feel like doomsday to us. In fact, I think most people treated the utter annihilation of that skill as a joke. “No one knows how to spell anymore” - haha, funny, isn’t technology cute? Not really. We’ve gone up an order of magnitude, and not paying attention to how programming is on the chopping block is going to screw a lot of people out of that skill.
Zuckerberg recently said that those not using AI glasses will be cognitively disadvantaged in the future.
Imagine an AI-native from the future and one of the fancy espresso coffee machines that we have today. They will be able to know right away how to operate them from their AI assistants, but they won't be able to figure out how they work on their own.
That's the future that Zuckerberg wants. Naturally, fancy IT offices will likely be gone. The AI-native would have bought the coffee machine for nostalgia effect for a large sum, trying to combat existential dread and feeling of failure which are fueled by their behavior being even more directly coerced into consumption.
Sure, calculators are useful in professional life and in high school math and sciences. But you still had to do everyday math in all kinds of places and didn't always have a calculator at hand. The smartphone changed that
I feel that's relevant in two ways: just like with math, a little bit of manual coding is going to be a huge difference compared to no manual coding, and any study like the one you propose would be hugely complicated by everything else that happened around the time, both because of smart phones and the coinciding 2008 crash
For developers who read and understand the code being generated, the tool could go away and it would only slow you down, not block progress.
And even if you don’t, it really isn’t a hard dependency on a particular tool. There are multiple competing tools and models to choose from, so if you can’t make progress with one, switch to another. There isn’t much lock-in to any specific tool.
I think there is a lot of reticence to adopt AI for coding but I'm seeing it as a step change for coding the way powerful calculators/workstation computers were for traditional engineering disciplines. The volume of work they were limited to using a slide rule was much lower than now with a computer.
Recent research suggests it would in fact speed you up.
https://metr.org/blog/2025-07-10-early-2025-ai-experienced-o...
So even if it’s not an actual productivity booster on individual tasks, perhaps it still could reduce cognitive load and possibly burnout in the long term.
Either way, it’s a tool that devs should feel free to use or not use according to their preferences.
What's the cost between never using Claude, and using it and getting these lower limits? In the end, I'm left with no Claude in both situations, which leaves me better off for having used it (I wrote more code when Claude worked).
As for the cost, you are ignoring the situation where someone has depended on the tool so much that when it goes away they are atrophied and unable to continue as before. So no, in your scenario you’re not always left better off.
They don't, because ironically enough human meatbags all need to be trained from scratch, unlike LLMs which don't die every 80 years or so.
I doubt even 10% of the devs now were conscious when "paid compilers and remotely accessible mainframes" still existed.
For example, when playing around with claude code using a per token paid API key, it was going to cost ~$50aud a day with pretty general usage.
But their subscription plan is less than that per month. Them lowering their limits suggests that this wasn't proving profitable at the current limits.
----
In this case I'd imagine it's more of an assumption that almost all such subscriptions will have less than 33% utilization, and excepting few outliers, even the heaviest users won't exceed 60-70% utilization on average.
"33% or less" is, of course, people using a CC subscription only at work. Take an idealized case - using CC only during regular working hours, no overtime: then, even if you use it to the limit all the time, you only use it for 1⁄3 of the day (8h), and 5 days a week - the expected utilization in this scenario is 8/24 × 5/7 = 24%. So you're paying a $200 subscription, but actually getting at most $50 of usage out of it.
Now, throw in a rate limit that refreshes in periods of 5 hours - a value I believe was carefully chosen to achieve this very effect - and the maximum utilization possible (maxing out limit, waiting for refresh, and maxing out again, in under 8 hours wall-clock time), is still 10 hours equivalent, so 10/24 × 5/7 = 30%. If you just plan to use CC to the first limit and then take meetings for the rest of the day, your max utilization drops to 15%.
Of course people do overtime, use same subscription for personal stuff after work and on weekends, or just run a business, etc. -- but they also need to eat and sleep, so interactively, you'd still expect them to stay below 75% (83% if counting in 5-hour blocks) total utilization.
Sharing subscriptions doesn't affect these calculations much - two people maxing out a single subscription is, from the provider side, strictly not greater than two subscriptions with 50% utilization. The math will stop working once a significant fraction of users figure out non-interactive workflows, that run CC 24/7. We'll get there eventually, but we're not there yet. Until then, Anthropic is happy we're all paying $200/month but only getting $50 or less of service out of it.
I have a receipt of sale that says otherwise.
When you are totally hooked and they are fully out of money, that's when you'd realize the long con you've been dragged into. At this very moment, that they are tightening the usage limits they are not telling you, and you still think the peanuts you are paying them now would be enough in the future? It's called https://en.wikipedia.org/wiki/Enshittification and you better know that you are in it.
Like many of the companies that have gone before them, if / when the value proposition is gone, and I get less than 10x the amount I spend, I will be gone.
https://www.reddit.com/r/ClaudeCode/comments/1ma3wm6/weekly_...
> Like many of the companies that have gone before them, if / when the value proposition is gone, and I get less than 10x the amount I spend, I will be gone.
Seems you'd soon be going. Well it was fun while it lasted (all 3 months of it).
Hi there,
Next month, we're introducing new weekly rate limits for Claude subscribers, affecting less than 5% of users based on current usage patterns.
Claude Code, especially as part of our subscription bundle, has seen unprecedented growth. At the same time, we’ve identified policy violations like account sharing and reselling access—and advanced usage patterns like running Claude 24/7 in the background—that are impacting system capacity for all. Our new rate limits address these issues and provide a more equitable experience for all users.
What’s changing:
Starting August 28, we're introducing weekly usage limits alongside our existing 5-hour limits:
Current: Usage limit that resets every 5 hours (no change) New: Overall weekly limit that resets every 7 days New: Claude Opus 4 weekly limit that resets every 7 days As we learn more about how developers use Claude Code, we may adjust usage limits to better serve our community.
What this means for you:
Most users won't notice any difference. The weekly limits are designed to support typical daily use across your projects. Most Pro users can expect 40-80 hours of Sonnet 4 within their weekly rate limits. This will vary based on factors such as codebase size and user settings like auto-accept mode. Users running multiple Claude Code instances in parallel will hit their limits sooner. You can manage or cancel your subscription anytime in Settings. We take these decisions seriously. We're committed to supporting long-running use cases through other options in the future, but until then, weekly limits will help us maintain reliable service for everyone.
We also recognize that during this same period, users have encountered several reliability and performance issues. We've been working to fix these as quickly as possible, and will continue addressing any remaining issues over the coming days and weeks.
–The Anthropic Team
Seems tangential? Price entirely depends on what consumers/businesses willing to pay and the degree of competition
Based on my experience with Claude Code (which is relatively good TBH), I'd say good luck with that.
This is a price to get people hooked up, yes, but also to get them to explore all kinds of weird tricks and wacky workflows, especially ones that are prohibitively costly when billed per token. In some sense, this is crowdsourcing R&D - and then when Opus 7 or whatever comes along to take advantage of best practices people worked out, and that turns out to be good enough to replace your $150k/yr / $12.5k/mo employee - then they'll jack up prices to $10k/month or whatever.
The fact they declared their own project as “impossible to advance” given the situation reveals they are unwilling to go the thinking route right now.
I'm surprised, but know I shouldn't be, that we're at this point already.
Its not, but it does matter. LLMs, being next word guessers, perform differently with different inputs. Its not hard to imagine a feedback loop of bad code generating worse code and good code generating more good code.
My ability to get good responses from LLMs has been tied to me writing better code, docstrings, and using autoformatters.
The only thing standing between your LLM and bad code is the quality of the prompt (including context and the hiddem OEM prompt).
Don't feel sorry for me, I've used vibe coding to create many things, and I still know how to program, so I'll live if it goes away.
Its gotten so bad I'm actively trying to avoid talking about this in circles like Hacker News because people get so heavily and aggressively discredited and ridiculed as if they have no idea what they are doing or are a shill for big AI companies.
I know what I'm doing and actively try to help friends and co-workers use LLMs in a sustainable way, understanding their limitations and the dangers of letting them loose without staying in the loop. Its sad that I can't talk about this without fear of being attacked, especially in communities like Hacker News that I previously valued as being very professional and open, compared to other modern social media.
They have have either shitty codebase or can't narrow down the scope. Or both. Not the kind of folks you want on your team.
The whole value proposition of a Max subscription is that it lets you stop worrying about tokens (Claude Code literally tells you so if you type `/cost` while authenticated with a subscription). So I'd turn around and say, people who don't regularly hit usage limits aren't using Claude Code properly - they're not utilizing it in full.
--
Myself, I'm only using Claude Code for little R&D and some side projects, but I upgraded from Max x5 to Max x20 on the second day, as it's trivial to hit the Max x5 limit in a regular, single-instance chat. And that's without any smarts, just a more streamlined flavor of good ol' basic chat experience.
But then I look around, and see people experiment with more complex approaches. They run 4+ instances in parallel to work on more things at a time. They run multiple instances in parallel to get multiple solutions to the same task, and then mix them into a final one - possibly with help of yet another instance. They have the agent extensively research a thing before doing it, and then extensively validate it afterwards. And so on. Any single one of such tricks/strategies is going to make hitting limits on Max x20 a regular occurrence again.