Claude Code doubled its limits. Your codebase context is the new bottleneck.

Anthropic quietly posted this on May 6th:

The 5-hour rolling limits are doubled. Peak-hour reductions are gone. Opus API limits up. If you missed it, that's the whole announcement — no blog post, no launch event, just a tweet.

But it matters more than it looks.

What actually changed

Three things moved at once:

Doubled 5-hour usage limits. The per-5-hour cap on Claude Code sessions was the practical ceiling for anyone doing a long feature branch in a single sitting. An afternoon of iterating on a complex refactor, a morning debugging a tricky data pipeline — these used to hit the wall. Now they don't.

Peak-hour reductions removed. Previously, Anthropic throttled Claude Code harder during peak usage windows. You'd notice it most on weekday mornings and early afternoons — the exact hours you're most likely to be in deep work. That's gone.

Opus API limits raised. Claude Opus has always been the model you reach for on the hardest reasoning tasks. The tighter limits meant rationing it. More headroom there changes which model you default to for edge cases.

None of these are headline-grabbing. Together, they meaningfully change the daily shape of working with Claude Code.

What interrupted work actually costs

The productivity literature on interruptions is consistent: breaking flow is expensive. Every time Claude Code hit the 5-hour wall, you got yanked out of context — not just out of the model's context, but out of your own. The problem you were debugging, the abstraction you were building toward, the shape of the change you had in your head — those things aren't in the error message you get back.

You know this. The cost isn't the 15 minutes you lose switching tabs. It's the 45 minutes it takes to get back to where you were.

Doubled limits means fewer of those interruptions per day. For the builders who run Claude Code all day — not as a chat tool, but as a working loop — this is a real quality-of-life change.

The predictability shift matters as much as the capacity

Peak-hour reductions were the more subtle problem. A 5-hour limit you can plan around. A variable throttle you can't — or rather, you can only plan around it by avoiding peak hours, which means working around your own schedule instead of the model's.

Removing peak-hour reductions doesn't double your throughput. It makes your throughput consistent. That's actually more useful for the way most people work. You can commit to an ambitious task in the morning without wondering whether you'll hit a wall halfway through.

Predictability is underrated in developer tooling. It's why npm ci beat npm install in CI pipelines. It's why git blame is more useful than "I think I remember who touched this." You can plan around a fixed constraint. You can't plan around a random one.

The benchmark shifted

Until recently, the key question for AI coding tools was: which model gives the best completions? That's still relevant, but it's no longer the whole question.

For daily users — people running Claude Code through entire features, not just one-off questions — reliability and headroom are at least as important as raw quality. The best response in the world doesn't help you if you can't get it when you need it.

Anthropic moving on limits this aggressively signals they understand this. Cursor already figured it out on the editor side. The competition is increasingly about who can give you a consistent, interruption-free working environment — not just who has the smartest model.

The constraint moved

Here's the thing that doesn't get said enough: for builders who've optimized their Claude Code setup, usage limits were never the real bottleneck anyway.

The real bottleneck is context.

If you're opening Claude Code, typing your question, waiting for an answer, and then closing it — you're not in flow. You're using a slightly better search engine. The value compounds when you give the model real context: your conventions, your schema, your existing components, the decisions you've already made. That context has to come from somewhere.

The builders getting the most out of doubled limits are the ones who have:

• A CLAUDE.md that tells the model what this codebase is, what patterns matter, and what never to do
• .cursorrules or equivalent for the other tools in the loop
• A library of tested prompts for the recurring operations — add a feature, add a screen, wire an auth flow

Without those, more usage is more of the same. With them, more usage means more of the high-quality, context-aware work that actually saves hours.

This is exactly what OTF kits ship: CLAUDE.md with full project context, .cursorrules that mirror it, and 20+ tested prompts at ai/prompts/ for the operations you run most. Not as an afterthought — as the primary deliverable.

What to do with the extra headroom

If you've been rationing Claude Code because of limits, the ceiling just moved. A few things worth doing with that:

Don't ration Opus. With higher Opus limits, use it on the tasks where it actually matters — complex reasoning, refactoring large surfaces, anything where you've been getting wrong answers and blaming the model. Sometimes the answer is better prompting. Sometimes the answer is a smarter model.

Run longer loops. The 5-hour window was designed around shorter sessions. With doubled limits, you can run the kind of long agent loops that weren't practical before — let Claude Code work through a whole feature, verify as it goes, handle the edge cases. The session cost is lower. The compounding is higher.

Invest in context, not just prompts. Every hour you'd have spent working around limits can go into better CLAUDE.md files, better prompt libraries, better project scaffolds. The returns on good context compound in a way that good prompts alone don't.

The limits moved. The question is whether your context is keeping up.