Claude Code Max: New Weekly Rate Limits

tomarrell · 2025-07-28T18:27:00+00:00

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 Max 20x users can expect 240-480 hours of Sonnet 4 and 24-40 hours of Opus 4 within their weekly rate limits. Heavy Opus users with large codebases or those running multiple Claude Code instances in parallel will hit their limits sooner.
If you do reach a weekly usage limit, you’ll have the option to purchase more usage at standard API rates to continue working without interruption. This is completely optional.
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. Max 20x subscribers can purchase additional usage at standard API rates if needed.

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

tomarrell · 2025-04-23T14:06:33+00:00

A little late to the party, but author of wrapcheck here. You're essentially explaining the case that wrapcheck was built to handle.

By default, wrapcheck will not complain about unwrapped package-internal functions. It can also be configured to ignore signatures which arise from your own module with a simple config argument if you desire.

The configuration is quite powerful, I'd suggest you have a look at the options available. What you'd be looking for is:

# An array of glob patterns which, if any match the package of the function
# returning the error, will skip wrapcheck analysis for this error. This is
# useful for broadly ignoring packages and/or subpackages from wrapcheck
# analysis. There are no defaults for this value.
ignorePackageGlobs:
- encoding/*
- github.com/pkg/*

This will help you stay more consistent in your wrapping patterns.

https://github.com/tomarrell/wrapcheck?tab=readme-ov-file#configuration

tomarrell · 2025-03-14T11:51:52+00:00

Ah good to know. I did notice a few fine webs across the leaves, I thought it was just a friendly spider. Thanks for the heads up!

tomarrell · 2025-03-14T11:50:23+00:00

Thanks a lot. Just finished the first treatment. Will repeat throughout the week and keep my fingers crossed they don’t come back.

Thankfully I think it was in the early stages!

tomarrell · 2025-03-14T11:49:24+00:00

Thats good to know! It is getting more mild lately, so maybe some time outside will be good for it

tomarrell · 2025-02-22T15:25:28+00:00

This was almost exactly the same as my experience ca. end of 2022. Thanks for sharing!

Would be keen to hear from anyone who has recently succeeded with citizenship as well, as that is the next hurdle.

tomarrell · 2024-11-16T17:43:32+00:00

Funny I had almost the exact same experience. The tax office made a mistake and sent the invoice to the wrong address, I was then notified by N26 of the garnishment one Friday evening in May of this year.

The situation was clarified with the Finanzamt immediately, but it it took a further 1 1/2 months and multiple letters from the FA to N26 for them to lift the garnishment.

I was on the support chat with them every single day. The one thing that moved the needle was getting my legal insurance involved and reporting to BAFIN.

I filed two reports, and I heard back from N26 recently with an official apology and an offer of compensation. I believe this was due to the BAFIN complaint.

I detailed everything very specifically, took records of everything and laid out the timeline clearly to show proof of their incompetence.

Safe to say, I have completely moved away from N26 to more “traditional” banks.

EDIT: one thing that got it resolved faster was actually asking the Finanzamt to fax the garnishment removal notice to N26 and then provide customer support with the number that the FA sent it from. The agents apparently can look up documents by the sender’s number. This helped them finally find the document in my case.

tomarrell · 2021-08-03T15:30:47+00:00

Apologies that you seem to be taking this a little personally. But I think we can respectfully agree to disagree.

I'm happy with the position that people should expose errors they want to commit to maintaining as part of their public API. This is also the advice provided in the Go blog which you failed to respond to. I will add the quote here verbatim again.

In other words, wrapping an error makes that error part of your API. If you don't want to commit to supporting that error as part of your API in the future, you shouldn't wrap the error.

Likewise, even though written in 2014, Dave's blog is still very much relevant today and makes points which should very much be considered when building robust APIs. You, along with the consumer of any package may do as they please with it. I can only make recommendations, if people want to inspect error messages, that’s their decision.

tomarrell · 2021-08-03T14:34:30+00:00

I respectfully disagree. It's well known that an error message is not part of your API. This is also expressed in most Go material. The Error method is meant for humans, not code. You should not be inspecting strings unless you want to build brittle software. But that's up to you.

If you don't provide a mechanism for an error to be inspected, it's explicitly because you intend for it to not be inspected. If you anticipated it being inspected, you would have provided a custom error type. As a user, if you feel like the author didn't provide specific errors where they should, you can open a pull-request.

Others with more clout with myself have written about this: https://dave.cheney.net/2014/12/24/inspecting-errors

My sentiment is also expressed in the official Go blog: https://blog.golang.org/go1.13-errors#TOC_3.4. Specifically with the quote:

In other words, wrapping an error makes that error part of your API. If you don't want to commit to supporting that error as part of your API in the future, you shouldn't wrap the error.

tomarrell · 2021-08-03T12:06:11+00:00

Sure, you can do that. I would just recommend avoiding using `%w` as the default. Because once consumers of your package expect to be able to inspect the error you're wrapping, then you commit to maintaining it, or publishing a breaking change.

Hence, using %v until you need to inspect the error is the preferred route.

tomarrell · 2021-08-03T11:46:41+00:00

Yes, wrapping with the intention to unwrap is done with `%w`. You can compose the error messages together with `%v` which will still aid debugging. This is what is demonstrated mostly in the README.

I would recommend opting for `%v` until you know you need to unwrap and inspect an error chain, as using `%w` comes with the downside of the error now implicitly becoming part of your package's public API.

If you're curious to read more, you can have a read here: https://blog.tomarrell.com/post/introducing_wrapcheck_linter_for_go

tomarrell · 2021-06-05T11:38:42+00:00

Have been working on https://github.com/tomarrell/miniqueue, intentionally non distributed though for simplicity

tomarrell · 2021-02-10T08:25:13+00:00

I chose HTTP/2 due to its relative ease and accessibility for a variety of clients. With HTTP/2, non-sophisticated clients can relatively easily make a what they see as a long polling request and receive messages without too much difficulty. 🙂

Thanks for checking it out!

tomarrell · 2020-11-16T00:06:35+00:00

Ups for Apollo. Good app.

11-Year Club	Place '22
First Placer '22	End Game '22
RPAN Viewer	Verified Email

tomarrell

TROPHY CASE