- Book: AI Agents Pocket Guide
- Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go
- My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
- Me: xgabriel.com | GitHub
It's Thursday afternoon. The migration is half done, two tests are red on purpose, and Claude Code stops mid-turn to tell you that you've hit your usage limit. The reset is hours away. The plan for the rest of the branch lives in a conversation you can't continue.
Nothing in production broke. Your production line did.
Versions of that afternoon reached Claude Code users three times in 2026. None of them were the user's fault, and Anthropic explained or fixed each one. If a vendor's usage window can stop your workday while nothing goes wrong on your side, it is a dependency, and you should treat it like one.
Three stoppages in one year
January. In the first days of the year, developers told The Register they were running out of Claude Code usage far faster than before. One said they hit limits within 10 to 15 minutes on Sonnet. Anthropic tied the complaints to the end of a holiday bonus that had doubled usage limits from December 25 to 31, and denied that limits had been cut below the old baseline.
March. Claude Code Max subscribers reported their quota running out "in as little as 19 minutes instead of the expected 5 hours." Those are user reports, not a measurement. Anthropic posted on Reddit: "We're aware people are hitting usage limits in Claude Code way faster than expected." Around the same time it started adjusting 5-hour session limits during weekday peak hours. In April, Anthropic's Lydia Hallie named two main causes: tighter peak-hour limits, and 1-million-token sessions that keep growing. Some bugs were fixed along the way, and she said none of them led to incorrect billing.
June. On June 19, about 3% of Claude Code Pro and Max subscribers were shown a wrong usage limit, and some couldn't send messages at all (ASCII.jp). Anthropic's @ClaudeDevs post closed it the same day: "This is fixed, and we're resetting 5-hour and weekly limits for everyone affected. Apologies for the disruption."
Each cause was different, and each one landed the same way at your desk: the agent stopped, and the work stopped with it.
A dependency you don't control
Anthropic's pricing page describes the deal plainly: "Every plan has usage limits that reset on a rolling five-hour session window, and paid plans add weekly limits on top." Claude Code "shares the same usage limits as the rest of your plan, so your work in the terminal and your chats draw from one pool."
Then comes the multiplier. Claude Code's agent view docs say that "running ten agents in parallel uses quota roughly ten times as fast as running one." Parallel agents in separate worktrees are a common way to work now, so the faster your workflow gets, the sooner you meet the window.
And the terms move on the vendor's schedule. In August, Anthropic announced a permanent 25% raise to weekly Claude Code limits from September 14, then clarified that against the temporary boost users had at that moment, "this works out to a 17% reduction in weekly limits on Claude Code." OpenAI does the same thing. Codex's 5-hour limit for ChatGPT Plus came back on August 25 after a pause of several weeks, while the $100 and $200 Pro plans stay exempt "for the upcoming months."
None of this is a scandal. Compute is finite, and a flat-price plan has to ration it somehow. But read it the way you'd read any upstream service: a rate limit you can't see coming, a burn rate that depends on how many agents you run, and terms that change with a post on X. If a payment API looked like that, you wouldn't ship without a fallback.
One cable to one hourglass socket. The second socket is the failover nobody plugged in.
The failover plan, in four parts
You don't need a new tool for any of this. You need to decide before the limit hits.
1. A second vendor, already warmed up. Sign in now, before you need it, give it a real task on this repo, and learn its approval prompts. The afternoon your main agent is locked out is the wrong time to find out the other one misreads your test setup. A second account with the same vendor is not failover: it shares the vendor's outages and bugs. Check the vendor's terms before you use extra accounts to stretch a limit.
2. One instruction file both agents read. Codex reads AGENTS.md from the project root down to your working directory. Claude Code reads AGENTS.md too when there's no CLAUDE.md (v2.1.277 or later). If you already have a CLAUDE.md, one line at the top pulls the shared file in:
@AGENTS.md
Put your build command, test command and house rules in AGENTS.md once, and the second agent starts with the same instructions as the first.
3. Task state in git, not in a conversation. The context your stuck agent built up stays with that agent. Another vendor's agent can't read it. What carries over is the branch and whatever you wrote down, so keep a short notes file on the task branch and ask the agent to update it after every step:
# 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 limit hits, park the work and start the other agent. Codex takes an optional first prompt as an argument (CLI reference), and so does claude (CLI reference):
#!/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."
git add -A stages everything git doesn't ignore, so check that .gitignore covers your .env before you rely on it. Swap codex for claude and the script works in the other direction.
4. A meter you actually look at. In Claude Code, /usage shows session cost, plan usage limits and activity stats, and on Pro, Max, Team and Enterprise plans it breaks down what counts against your limits. Check it before you fan out five agents.
Where Hermes IDE fits
I build Hermes IDE, so weigh this section with that in mind. The account and handoff parts of it exist for this exact failure.
By default, Hermes runs each agent in a real terminal with the agent's own sign-in, and it never asks for your tokens. You can add more than one account per agent, which is useful for keeping a work seat and a personal plan apart. In the ⌘N launcher (Ctrl+Shift+N on Windows and Linux) you pick the agent, model, effort and account per task, and you can save combinations you use often as presets.
Every task gets its own hermes/<name> branch and worktree. That covers part 3 of the plan: the work already lives on a branch. When an agent hits its usage limit, you can continue the task in another agent, and you decide when and where. Hermes never answers a permission prompt for you or types into a terminal on its own.
When one window closes, the branch moves to the agent whose window is still open.
For part 4, each session shows the spend its agent reports, or an estimate that is clearly marked as one, with token totals. Queued tasks and two-agent launches respect your running-agents limit instead of all starting at once, which matters when ten agents burn quota ten times as fast.
Now the gaps. Hermes is a desktop app, and agents run in terminals it opens on your machine or over SSH. It can't move Claude's conversation into Codex, and I don't know of a tool that can; what crosses over is the branch. The current release, 2.3.1, came out on October 13 (changelog). It's free to download, source-available under BSL 1.1, on macOS, Windows and Linux, and it is not affiliated with Anthropic, OpenAI, Nous Research or any agent vendor. The four-part plan works with plain terminals too. Hermes keeps the bookkeeping.
When this is overkill
A second vendor is another subscription. Claude Pro alone lists at $20 a month, and the other side costs money too. If you code with agents a few hours a week, waiting for the reset is a perfectly good plan.
Agents also aren't interchangeable. The other model makes different calls, and a handoff mid-refactor can leave you reviewing two agents' styles in one diff. And the June counter bug was fixed the day it appeared, with a reset announced alongside the fix.
So the take is narrower than "pay two vendors." Decide in advance what happens when the window closes. For a side project, that can be "I wait." For a team whose sprint runs through agents, "I wait" can cost the rest of the afternoon, so set up the second vendor this week.
What's your plan the next time the limit message shows up at 3 p.m.? Wait for the reset, switch vendors, or pay per token on an API key? Tell me in the comments.
If this was useful
I build Hermes IDE for people who run more than one coding agent. Download it free, add the second agent you already pay for, and start one task on each from the same launcher. If keeping agents swappable matters to you, star it on GitHub. If you build agents yourself, the AI Agents Pocket Guide covers the patterns behind loops, handoffs and guardrails.
Top comments (0)