AI coding agent rate limits: the fix is architectural, not a retry loop

Three sessions are working. The fourth just stopped mid-tool-call with a message you have seen before: usage limit reached, resets in two hours and eleven minutes.

Bad timing, obviously. It always is. The task in that fourth session is the one blocking tomorrow's release, and now it is stuck behind a clock instead of a merge conflict.

Nothing about this is a bug. Every coding agent you can run today, Claude Code, Codex CLI, Gemini CLI, rations you on purpose: a session window, a weekly cap, a per-minute request ceiling, or some mix of the three. The rationing is not the problem. Running a fleet against a system sized for one session at a time is.

Why rate limits bite harder once you run more than one agent

A single developer running a single session barely notices the cap. You type, you read the reply, you think about it: the pace of an ordinary conversation never gets close to the ceiling.

Run three or four sessions the way a solo developer runs a fleet, each one looping on its own task, and the pace changes completely. Four agents polling files, rerunning tests, and retrying failed calls burn through a shared window in a fraction of the time one careful human would need. The limit was sized for a person. You are running a team.

Gate: know which of your sessions are attended and which are not, before a stall teaches you which one mattered more.

How Claude Code, Codex and Gemini CLI each ration you

The mechanics differ enough that "just check your usage" is three separate habits, not one.

Claude Code meters two ways at once: a rolling five-hour session window, plus a weekly cap split into two tracks, one for Opus and one for every other model. Burn the session window running Opus, and Sonnet can still have room left for the rest of the afternoon.

Codex CLI runs on a similar shape, a five-hour window plus a weekly quota, but counted by task rather than by message: one long autonomous turn costs more of the window than a quick question does.

Gemini CLI skips the time window and caps you by request instead. Free tiers get 1,000 requests a day and 60 a minute on a personal Google account, or 250 a day and 10 a minute on a free API key, before you ever add a paid plan.

Three systems, three different failure clocks. Nothing forces them to run out at the same time, and that gap is the whole fix.

Spread the load before you hit the wall, not after

The naive response to a stall is to wait it out, or to upgrade the plan and buy a bigger version of the same wall. Neither changes the shape of the problem: everything still depends on one clock.

Route by what the task needs, not by habit. A file search, a changelog read, a "does this function exist" check does not need your best model. Send that traffic to the cheapest model that can still do the job: the same triage picking a model per task already asks you to do, and the same math as cutting token costs, just counted in requests instead of dollars.

Mix providers on purpose, not by accident. If every session in your fleet runs the same engine, one outage or one exhausted quota takes the whole fleet down at once. Running Claude Code, Codex and Gemini side by side is not indecision, it is what keeps a single vendor's cap from being a single point of failure.

Stagger what you can schedule. A long unattended loop does not care whether it runs at 2pm or 2am. Move it off the hours you need headroom for interactive work, and the two stop competing for the same window.

The check that stops one loop from burning the week's quota

The stall that actually hurts is never the interactive one, you notice that immediately. It is the unattended session that ran all night and quietly spent Friday's budget by breakfast.

One habit prevents most of it: before you start anything unattended, check what is left in the window it will run against, and estimate whether the job fits. If it does not, split it, point it at a cheaper model, or move it to a session with its own separate quota instead of the one you need for tomorrow morning.

Where rate-limit workarounds go wrong, and what they really cost

Pooling proxies trade one limit for one outage. A gateway that merges everyone's keys into a shared pool widens the ceiling, and it also becomes the one service that takes your whole team down when it has a bad day. Read what you are trading before you adopt one.

A bigger plan is not an architecture. Upgrading buys you a wider version of the same single clock. It postpones the day you run five sessions instead of four, it does not remove it.

Splitting across providers costs consistency. Different models phrase commit messages differently, follow instructions with different strictness, and have different blind spots. That is a real cost, worth paying for the work that benefits from headroom, not worth paying by default for every task.

A stall mid-task can leave half a change committed and half not. The session that hits its limit mid-edit does not always stop at a clean boundary. Small, frequent commits are what make that recoverable instead of a mystery diff tomorrow, the same discipline a git history you can revert already argues for.

A grid that already spreads sessions across models

Fleet-level rationing is easiest to manage when the fleet is visible in one place instead of scattered across terminal tabs, each running whatever engine you happened to open.

SanuDesk is a desktop app built for exactly that. Your Claude Code, Codex and Gemini sessions tile into one grid, so which engine each pane is running, and how close it is to a wall, is something you can see rather than remember. It is bring-your-own-model by design: point different panes at different providers, and one provider's cap stops being a fleet-wide stop. A Kanban board sits beside the grid, deploying a card to whichever session has room to take it. Recurring unattended work becomes a Loop you can schedule for the hours nobody is competing with it, journaled per run. The grid and board are in the free plan (see pricing).

Check your ceiling tonight

Open every agent you are currently running and check what each one reports as remaining, by whatever command or status line it gives you. Write down which engine, which plan, and how much room is left.

If the answer is "I don't know" for more than one of them, that is the gap. You cannot route around a wall you have not located. Fix that first, tonight, before the next unattended loop finds it for you at 3am.

Download SanuDesk free to run your fleet across models in one grid, or see how the grid, the board and Loops fit together on the features page.