What to Do When You Hit a Claude Code Rate Limit Mid-Client-Build
- Claude Code enforces two usage limits, not one: a 5-hour rolling window for a session and a separate weekly cap. A long agentic session on a big client codebase can trip either one, and both reset on a timer, not on demand.
- The failure mode that actually costs you the client is going quiet. Message them the moment you see the limit coming, give a specific resume time from Settings > Usage, and hand them something concrete to review while you wait.
- Build the buffer into the estimate, not into an excuse after the fact. Commit and checkpoint often, add slack before a deadline session, and keep a non-Claude-Code task ready so a locked session never means a dead afternoon.
What a Claude Code Rate Limit Actually Is
A Claude Code rate limit is not a punishment or a sign you did something wrong - it is a usage cap tied to your plan. There are two separate limits to know about: a 5-hour rolling window that tracks the tokens you consume in a session and resets automatically once that window passes, and a separate weekly cap that resets on a fixed schedule shown in your account's Settings > Usage. A long agentic session on a large client codebase - lots of file reads, big diffs, multiple tool calls in a row - burns through the 5-hour window faster than a normal chat session would, which is exactly the situation you are in on a real client build.
The practical point is that both limits are on a clock, not a button. There is no way to instantly clear them by asking nicely or retrying, and repeatedly hammering the request only wastes the time you have left in the current window. Once you know the reset time, the only real decision left is what you do with the gap.
The First Two Minutes: What to Do the Moment You Hit It
The first move is to stop and save your state, not to keep pushing. Commit or otherwise capture whatever Claude Code has already produced so nothing sitting in an open session is at risk of getting lost or overwritten later.
- Commit or save the current work immediately, even if it is mid-task. A messy commit you can clean up later beats an uncommitted change you cannot get back to.
- Check Settings > Usage for the exact reset time on the 5-hour window and the weekly cap, so you know which one you actually hit and when you are unblocked.
- Stop retrying the same request. It does not speed up the reset and it burns the small amount of remaining capacity you might still need for something urgent.
- Switch to a task that does not need the model: read through what already shipped, write up test notes, draft the update you are about to send the client, or plan the next session's scope.
How to Tell the Client Without Losing Their Confidence
The thing that actually damages a client relationship is silence, not the limit itself. A client who hears nothing for three hours starts to wonder if the project stalled or if you disappeared. A client who gets a short, specific message reads it as normal operating friction and moves on with their day.
| What you do | What the client takes away |
|---|---|
| Go quiet and hope it resolves before they notice | Something is wrong and I am not being told |
| Send a vague "running into some technical issues" | Vague update, vague confidence in the person delivering |
| Send a specific message with a resume time and what you did in the meantime | This person is on top of it, even when something outside their control happens |
What costs you trust versus what does not
Build the Buffer Before It Happens
The builders who never let a rate limit become a client-facing problem are not the ones who never hit one - they are the ones who planned for it. The buffer belongs in the estimate and the schedule, not in the apology.
- Never schedule the single biggest build session for the day before a deadline. Put it two or three days out so a limit costs you hours, not the deadline itself.
- Break a large build into checkpoints you commit as you go, instead of one long uninterrupted session. A checkpointed build survives a rate limit; a single marathon session does not.
- If you are running heavy volume across multiple client builds in the same week, look at whether a Team or Enterprise seat's higher caps make more sense than staying on an individual plan.
- Keep one non-Claude-Code task always available for a given project - documentation, a manual QA pass, client communication - so a locked session has somewhere productive to go.
Turn a Rate Limit Into a Reliability Story
Handled well, a rate limit is invisible to the client or, at worst, a minor blip they barely register. Handled badly, it becomes the moment they start questioning whether you can deliver on time consistently. The difference is entirely in the two things covered above: commit and checkpoint often enough that a limit never threatens real work, and communicate specifically enough that the client never has to wonder what happened.
Short, practical drops on offers, outreach, pricing, and closing clients with Claude Code. No spam, unsubscribe anytime.
Frequently asked
What is a Claude Code rate limit?
It is a usage cap tied to your plan, not a penalty. Claude Code enforces a 5-hour rolling session window that tracks token usage and resets automatically, plus a separate weekly cap that resets on a fixed schedule. Both are visible in Settings > Usage, which shows the exact time each one resets.
How long until a Claude Code rate limit resets?
It depends on which limit you hit. The 5-hour window resets on a rolling basis once that window has passed since your first message in the session. The weekly cap resets on a fixed account-specific schedule. Settings > Usage shows the exact reset time for both rather than a general estimate.
Will hitting a rate limit lose my work?
Not if you commit or save what you have as soon as you notice you are close. The limit blocks new model requests, it does not erase what Claude Code has already produced in the session. The risk is only in uncommitted work sitting in an open session you cannot immediately return to.
Should I tell the client when I hit a limit mid-build?
Yes, and quickly. A short, specific message with the exact resume time and what you accomplished before the limit hit reads as normal operating friction. Going quiet is what actually damages the relationship, because the client fills the silence with worse assumptions than the truth.
How do I avoid hitting rate limits on big client builds?
Break large builds into checkpoints you commit as you go instead of one long uninterrupted session, avoid scheduling your biggest session the day before a deadline, and if you are running heavy volume across several client builds in the same week, look at whether a Team or Enterprise seat's higher caps fit better than an individual plan.
Last reviewed August 7, 2026.
Co-founder of the Claude Code Profit Room. Went from shipping software to closing paying clients, and now teaches builders the selling half of the equation.
More from David Iya →
