Doubling the five-hour rate limits is merely a marketing stunt if the weekly rates are not also doubled. It simply means that you can reach the weekly limits in three days instead of five.

▲

swalsh 3 hours ago | parent | next [-]

I have never come close to my weekly limit, but have hit my hourly limit frequently.

▲

mirzap 3 hours ago | parent | next [-]

For me it's the opposite. I almost never hit hourly limit, but I hit weekly limit in about 5 days.

▲

nickthegreek 2 hours ago | parent | next [-]

Would be more meaningful if everyone said what plan they are on, as there are 3 different ones that users could be discussing.

	▲	replygirl 2 hours ago \| parent \| next [-]
		last week with claude i saturated a team premium seat at day 6 of its cycle, and a max 20x seat at day 4, plus ~$150 extra usage spend, with a 60hr work week where i am not even primarily an IC, as well as a codex 20x plan at day 3 with a personal project
	▲	mirzap 2 hours ago \| parent \| prev [-]
		I'm on $200 Max plan

▲

extr 2 hours ago | parent | prev [-]

What does your usage look like day to day? Are you using a low level amount all day long? I'm with the others here, I've never hit the weekly limit ever, only the hourly, and I consider myself a heavy user.

▲

mirzap 2 hours ago | parent [-]

I dedicate a significant amount of time to defining the precise actions that agents should perform (PRD/ADR). I break down the feature sets into Milestones and slices (tasks). These tasks are small, well-defined, and scoped. I have a prompt template that the “architect” agent prepares whenever I want to initiate a new feature. This ensures that the prompt structure remains consistent and standardized over time. The generated prompt is then pasted to the “orchestrator,” which performs context discovery (using Repoprompt) and finalizes the plan then proceeds to launch subagents to do the work.

Based on the size and complexity of the task, as well as any inter-task dependencies, the orchestrator deploys one or more subagents (sometimes 5 or 6 subagents) to work on these mini tasks. Once all tasks are completed, the orchestrator initiates verification and launches a review workflow. This workflow uses the original prompt, acceptance criteria, repository internal guidelines, and relevant skills to conduct a thorough review of the agents’ work.

Typically, there are one or two review iterations, during which the review agent identifies any issues. Sometimes, I may also notice issues and have to "steer" the orchestrator. The time required for a slice to complete ranges from 30 minutes to 4 or 5 hours, depending on its size, complexity, and the number of subtasks it contains.

Only if I run about 3 such orchestration in parallel I can reach hourly limit.

▲

calgoo 2 hours ago | parent [-]

I have found that it uses a lot more tokens if I give it a very detailed todo and loop over every task 1 by 1. I now keep it to phases with detailed tasks underneath and use /loop over the phases and it uses a lot less. I also manage the context windows and tend to clear it often to keep it under around 200k (or less depending on project size)

	▲	mirzap an hour ago \| parent [-]
		Yeah, I do that too. Essentially, the system I described begins working on a task that is small enough and clearly defined. Each “slice” in a milestone usually have 5-10 subtasks (for instance, Slice E1 has P1...P6 subtasks). The orchestrator then receives the prompt to implement E1-P1.

▲

codazoda 2 hours ago | parent | prev | next [-]

Same. I hit limits after 45 minutes. I'm on a measly Pro plan. I'm usually building small, open source projects, often from scratch. I only work on these projects in a 2-hour window in the morning. This is my "free time" development. I hope this change helps, because I was days away from switching back to Codex, though I like Claude Code a bit better these days.

I also hope that the fact I had OpenClaw in my sandbox once is not why I hit these limits so damn fast. I don't use it anymore and I've tried to rid my sandbox of anything "openclaw" but it is in my git history in various places on various projects. Claude doesn't seem to be transparent about this limitation.

▲

piyh 2 hours ago | parent [-]

Are you using haiku for most tasks? I'm in the Google ecosystem so I'm curious how it is on the other side.

	▲	codazoda an hour ago \| parent [-]
		Nope, I use Opus 4.7, mostly. Sometimes Sonnet 4.6 if I’m trying to use less tokens.

▲

vidarh 2 hours ago | parent | prev | next [-]

I hit my weekly limit in 3 days this week. Irregularly do in 5. With the top MAX sub.

▲

headcanon 2 hours ago | parent | prev [-]

same, I struggle to use more than half of my weekly, even if I max out my 5-hour windows regularly during the day.

▲

druskacik 2 hours ago | parent | prev | next [-]

For me personally, I have the basic Claude Code subscription that I use to rewind on some evenings or on weekend, to code a bit for 1-2 hours. I have like 3-5 session with it every week.

The 5h windows are frustrating because I can go through them quickly if I have a more complex task. I haven't yet met the weekly limit. I'd say there are many cases similar to mine.

▲

9wzYQbTYsAIc 2 hours ago | parent | prev | next [-]

Exactly, the weekly limits are the real limiting factor. If you really push it, you can easily hit the weekly $200/mo Max limit in a day.

▲

sidrag22 2 hours ago | parent | prev | next [-]

I've found with opus 4.6 which im still stubbornly using i can burn about 10% of the weekly within a 5 hour window with my workflow.

Mentally i think about the weekly usage in terms of usage per day so about 14% per day which results in me not using that much early in the week so i can kinda "burn freely" later on. which leads me to a spot where usually on the final two days im sorta thinking about how can i expend that usage ive "saved".

the 5 hour windows make this harder, sometimes the final day of the week im trying to get that 10% in every 5 hour window of my waking hours and i HATE that, i wanna work when i am most productive, not around some ridiculous window of time, i dont wanna think "I am gonna be utilizing claude the most around 11am so i should send a dumb message to haiku to get my 5 hour window started at 7:30am so i can have it roll over at 12:30."

So im happy about this change sure. But it is 100% them creating a problem and pretending having some relief from that problem is them doing their users a favor. I understand they are doing it to lower peak hours usage and all that, I still despise it.

▲

alxsuv 2 hours ago | parent | prev | next [-]

[dead]

▲

varispeed 2 hours ago | parent | prev [-]

Who cares about rate limits if they serve your prompt using dumbed down model.