Usage Limits on AI Coding Tools Are Becoming a Production Dependency

Thursday afternoon, halfway through a migration, two tests still intentionally failing, and Claude Code suddenly stops to tell you the usage quota is exhausted. There are still hours until the reset, and the rest of the plan for this branch exists entirely inside a conversation you can no longer continue.

Nothing in production broke. What broke was your production line.

Three Outages in a Year, Each With a Different Cause

This experience happened at least three times in 2026, and none of them were the user's fault.

January. In the first few days of the year, developers told The Register that Claude Code was burning through quotas far faster than before, with some reporting they exhausted Sonnet in 10 to 15 minutes. Anthropic attributed the problem to the end of holiday bonus credits (doubled from December 25 to 31) and denied lowering limits below the previous baseline.

March. Claude Code Max subscribers reported quotas "running out in as little as 19 minutes instead of the expected 5 hours." Anthropic responded on Reddit that it was aware users were hitting usage limits in Claude Code far faster than expected, and began adjusting 5-hour session limits during weekday peak hours. According to Anthropic's Lydia Hallie, there were two main causes: tightened limits during peak hours, and ever-ballooning million-token sessions.

June. On June 19, roughly 3% of Claude Code Pro and Max subscribers were shown incorrect usage limits, and some users couldn't send messages at all. Anthropic announced the fix that same day on @ClaudeDevs and reset both 5-hour and weekly limits for affected users.

The root causes of the three incidents were all different, but on the developer's desktop the outcome was identical: the agent stopped, and the work stopped with it.

This Is a Dependency You Can't Control

Anthropic's pricing page lays out the rules clearly: every plan has usage limits that reset on a rolling 5-hour window, paid plans layer on weekly caps, and Claude Code shares the same quota with the rest of your plan — terminal work and chat windows draw from the same pool.

The multiplier problem is even more critical. Claude Code's agent view documentation states plainly: "Running ten agents in parallel consumes quota roughly ten times faster than running one." And running agents in parallel across separate worktrees is now standard practice — the faster your workflow, the sooner you hit the window.

The terms can also change at any time. Anthropic announced a permanent 25% increase to Claude Code's weekly limits, then clarified that relative to users' temporary credits at the time, this "actually amounts to a 17% weekly limit reduction." OpenAI has done the same: ChatGPT Plus Codex 5-hour limits returned after a weeks-long pause, while the pricier Pro plan was temporarily exempted.

This isn't a scandal. Compute is finite, and flat-rate plans have to ration somehow. But if you read it as an upstream service, what you see is: invisible throttling, consumption rates that depend on how many agents you run, and terms that a single tweet can change. If a payments API looked like this, you wouldn't ship without a fallback.

How the "5-Hour Rolling Window" and "Weekly Limits" Stack

The so-called 5-hour rolling window means the system always looks back at what you've consumed in the last 5 hours, rather than resetting from a fixed clock time. This means any burst of usage within the window immediately reflects in your remaining quota, and recovery is continuous and gradual rather than a clean on-the-hour reset. Paid plans add a weekly cap on top of this to prevent a single day of heavy use from blowing up the average.

With both layers stacked, the typical experience is: things run smoothly early in the week, you start hitting the ceiling frequently mid-week, and each hit slows your pace further. Layer on the near-linear consumption amplification from parallel agents, and a refactor you estimated would take half a day might hit the weekly limit by mid-morning. Understanding this helps you build buffer into your schedule instead of treating the agent as infinitely available compute.

Four Steps to Handle Quota Exhaustion

You don't need new tools. You just need to make decisions before the limit hits.

Step one: get a second vendor warmed up in advance. Log in now, not when you need it. Give it a real task on this repo and get familiar with its approval prompts. The afternoon your primary agent gets locked isn't the time to discover the other one can't parse your test config. A second account with the same vendor doesn't count as failover — it shares the same outages and bugs. Check vendor terms before using extra accounts to bypass limits.

Step two: one instruction file both agents read. Codex reads AGENTS.md layer by layer from the project root to the working directory; Claude Code also reads it when no CLAUDE.md is present (v2.1.277 and above). If you already have a CLAUDE.md, add one line at the top to pull in the shared file:

@AGENTS.md

Write build commands, test commands, and team rules into AGENTS.md once, and the second agent starts from the same instruction set as the first.

Step three: task state goes into git, not the conversation. A stuck agent's accumulated context stays with it, and another vendor's agent can't read it. What carries across is the branch and what you wrote down, so maintain a short notes file on the task branch and have the agent update it after every completed step:

**Why `AGENTS.md` Works Across Vendors**

`AGENTS.md` is a plain Markdown instruction file placed in the project repository, with no proprietary schema and no vendor lock-in. Its conventional usage is: one copy in the project root, plus one in each subdirectory, describing the build commands, test commands, code standards, and off-limits areas for that level. Codex reads and layers these files from the repo root downward; Claude Code falls back to reading `AGENTS.md` when it can't find `CLAUDE.md`. Because it's just a file path convention, any agent willing to support it can read the same rules, and no prompt rewriting is needed when migrating.

Note that it doesn't carry "context": `AGENTS.md` holds long-term, stable project knowledge, not temporary state like "why this test is still failing." The latter is carried by the notes file in the next step plus git commit history. Mixing the two into one file will make the instruction file balloon, diluting the constraints that actually matter.

**Putting Task State in Git Instead of the Conversation**

An agent's conversation history is vendor-side data and doesn't travel with your repository. When you've accumulated dozens of turns of context in Claude Code and switch to another vendor's agent, all of it has to be retold — and retelling costs tokens and loses details. A git branch plus a short notes file lives entirely in your own repo: the branch records the actual code changes, and the notes record goals, completed items, next steps, and off-limits areas.

This turns handoff into an ordinary code review action — the new agent reads the notes, looks at the diff, and picks up where you left off. Keep notes deliberately short; they're a compass, not a log. The real details belong to the code and commit messages. Having the agent update notes after each step seems to cost a few extra seconds, but it saves an entire afternoon of reconstruction when the quota unexpectedly runs out.
# NOTES.md: fix the flaky login test
Goal: login test passes 50 runs in a row
Done: mocked the clock in auth.test.ts
Next: remove the sleep in session.ts
Don't touch: the public login() signature

When the quota runs out, park the work and start another agent. Both Codex and claude accept a first prompt as an argument, so a handoff script can look like this:

#!/bin/sh
# handoff.sh [base]: commit the work, start Codex on it
set -e
base="${1:-main}"
git add -A
git diff --cached --quiet || git commit -m "wip: handoff"
codex "Read NOTES.md and git diff $base...HEAD, then continue."

Swap codex for claude and the script works in reverse. Note that git add -A stages all non-ignored files, so make sure .gitignore covers .env before relying on it.

Step four: a dashboard you'll actually look at. /usage in Claude Code shows session cost, plan usage limits, and activity stats, and on Pro, Max, Team, and Enterprise plans it breaks down what counts toward limits. Before spinning up five agents, take a look.

Where Hermes IDE Fits In

I make Hermes IDE, so read this section with that conflict of interest in mind. Its account and handoff features were built for exactly this failure scenario.

By default, Hermes runs each agent's own login flow in a real terminal and never asks for your tokens. You can add multiple accounts for the same agent, making it easy to separate your work seat from your personal plan. In the ⌘N launcher (Ctrl+Shift+N on Windows and Linux), you can pick the agent, model, effort, and account per task, and save common combinations as presets.

Every task gets its own hermes/<name> branch and worktree, which covers step three exactly: the work already lives in branches. When one agent hits its usage limit, you can continue the task in another agent, whenever and wherever you choose. Hermes won't answer permission prompts for you or type into the terminal on its own.

Step four is covered by: each session shows the agent-reported cost, or a token total explicitly marked as an estimate. Queued tasks and dual-agent launches respect the running-agent cap you set, rather than opening everything at once — which matters when ten agents are burning quota ten times as fast.

The limitations, to be clear. Hermes is a desktop app, and agents run in terminals on your machine or opened over SSH. It can't migrate a Claude conversation to Codex, and I haven't heard of a tool that can; only the branch crosses over. The current version, 2.3.1, shipped on October 13, is free to download, open source under BSL 1.1, and supports macOS, Windows, and Linux. It's unaffiliated with Anthropic, OpenAI, Nous Research, or any agent vendor. This four-step approach works fine in a plain terminal; Hermes just helps you keep the books straight.

When This Approach Is Overkill

A second vendor means a second subscription. Claude Pro alone is listed at $20 a month, and the other side costs money too. If you only use agents for a few hours a week, waiting for the reset is a perfectly good plan.

Agents aren't freely interchangeable either. Switching models means different judgment calls, and a mid-refactor handoff might leave you reviewing two styles of code in a single diff. And the June counting bug was fixed the same day, with a reset announcement attached.

So the conclusion is narrower than "pay two vendors": decide in advance what happens when the window closes. For a side project, that decision can be "I'll wait." For a team whose sprint process depends on agents, "I'll wait" can mean losing an entire afternoon — so set up that second vendor this week.

Next time the usage limit message pops up at 3 p.m., what's your plan? Wait for the reset, switch vendors, or pay per token with an API key?

One-line Summary

Claude Code usage limits are becoming an uncontrollable production dependency; the author offers a four-step failover plan.

Paragraph Summary

Starting from a real scenario of a quota running out mid-migration, the article reviews three Claude Code usage outages in January, March, and June 2026, noting that while root causes differ, the outcome for developers is the same: the agent stops and the work stops with it. The author argues that plan usage limits are essentially an uncontrollable upstream dependency — invisible throttling, consumption rates that multiply with parallel agents, and terms that can change at any time. To address this, the article proposes four fallback steps: warm up a second vendor in advance, unify instructions with a shared AGENTS.md, put task state into git branches and notes files rather than the conversation, and monitor quota with dashboards like /usage. It also concedes that conversation context can't be migrated across vendors — only the branch crosses over — and discusses how this approach may be overkill for low-frequency use cases.