AI Coding Quota: Two Ratios That Predict the Wall, and a Preheating Trick

Hi everyone, I'm Fei Ge, a developer who moved from Java to AI applications.

At around 3 pm, I was halfway through fixing a bug online when Claude Code stopped: the quota was used up, and it would only recover at 8 pm.

Thinking back on the morning: I read an unfamiliar module, ran two rounds of tests, and tidied up a few commit messages. None of these was heavy alone, but together, they cost me the most important hour of the afternoon.

Having hit this wall many times, I decided to treat it as an engineering problem: how quotas are calculated, how to know in advance that you're about to hit the wall, and what the least costly way out is once you've hit it.

Hitting the wall right when it's busiest

The service side gives you only three numbers

As I understand it, there are three common quota algorithms, each with its own way of hitting the wall:

Metering	Reset	When it's easy to hit	Who uses it (as I understand)
Short window (e.g., 5 hours)	Counts from the first message, then clears the whole thing	After 2-3 hours of continuous dense calls	Claude Code, Codex session windows
Long period (week, month)	Clears on a fixed period, some have per-model limits	Used too hard in early days, then waiting later	Claude Code, Codex weekly limits; Cursor monthly
Per request count (daily)	Fixed count each day, bucketed by model	One question at a time, small steps	Gemini CLI

Short windows are often called "rolling windows," but they're not the same as sliding windows in rate limiting: the sliding window's start moves every second, but here the start is set when you send your first message. Remember this; the preheating later relies on it.

The service side tells you very little:

// Illustration: a quota window, field names differ by vendor, but roughly these fields
interface UsageWindow {
  kind: 'session' | 'weekly' | 'monthly' | 'daily'
  model: string | null      // only when per-model limit
  usedPercent: number       // percentage used
  windowMinutes: number     // window length
  resetsAt: number | null   // next reset time
}

No tokens, no money, only percentage and time. All subsequent judgments rely solely on these two quantities.

Tempo: compare two ratios

To judge if you're using too fast, just compare two numbers: how much time has elapsed in the window, and how much quota has been used.

Look at tempo, don't wait to hit the wall

If used clearly runs ahead of time, you're using too fast. Extrapolate at this speed, the exhaustion point falls before reset, and the gap in between is what you'll have to wait idly. Conversely, if the window has only a quarter left but you still have a large portion of quota, that part will be cleared at reset, which is essentially wasted.

In code, I use these thresholds, adjustable to your own habits:

If projected to exceed 110%, consider it too fast.
If less than a quarter of time remains, and it's projected that at least 25% will go unused, consider it over-allocated.
Don't judge when less than 10% of the window has passed: reading a large module at the start can legitimately use 30% in 10% of the time.

There's a subtler pitfall: extrapolate using the recent speed, not the whole window's average.

Extrapolate with recent speed

If the morning was idle for two hours and the last hour was intensive, the average speed tells you it's just enough, but the recent speed tells you it'll be gone in 48 minutes.

Could you just let the model judge? Not cost-effective: asking "how much do I have left" itself costs quota, and the same input can give different answers. For this, fixed rules suffice.

When you're going too fast: switch models first, not agents

When you're going too fast but still have room, the cheapest action is to switch models. On services with per-model limits, the large model's weekly quota often runs out first, but light tasks like writing titles, commit messages, or translating comments don't need it.

The session stays, the context stays; you just swap the "brain" for the next round.

Switching agents is the most expensive. Claude Code's session has read files and discussed plans; Codex doesn't know any of that; you'd have to re-feed it all.

After hitting the wall: wait, switch accounts, switch agents

First wait, then switch accounts, last switch agents

Wait: If a short window is less than an hour from reset, wait. Don't wait idly; schedule a message to send automatically once quota recovers, and go do something else.
Switch accounts: A second subscription of the same agent. If both accounts share session history, switching over restores the original session (how is described later).
Switch agents: If the task doesn't depend on the original context, or can be described in a few sentences, hand it over. How to carry context when handing over is covered separately in part 3 of the series.

The most easily misjudged scenario: you hit the wall with a 5-hour window and only 40 minutes until reset. In a panic, you hand over to another agent and lose half the context. Waiting 40 minutes would let you continue exactly where you were, but instead you have to re-explain everything.

Only when you hit a weekly window do you need to switch accounts or agents.

Preheating: shift the reset to mealtime

Since a short window starts from the first message, when the window starts is actually determined by you.

Shift the reset to mealtime

If you start work at 10:00, the window is 10:00 to 15:00, and reset lands right when you're working. Send a minimal request at 8:00, and you get two full windows: one in the morning, one in the afternoon, with reset falling at lunch.

Another approach is "preheat as soon as the window resets": when the previous window expires, send one request so the next window starts timing immediately, back-to-back, so you don't have to wait until you sit down.

A few reminders:

Preheating doesn't add to the total; it just shifts the boundary. For people with irregular schedules, preheating only costs one extra request.
It's useless for weekly, monthly, and per-request limits; they don't depend on "when you start."
As I understand, some service providers adjust the reset time for idle windows. After preheating, leave a cooldown period, or it will trigger repeatedly and waste quota.

Multi-account: only swap keys, not the house

CLIs like Claude Code and Codex put login state and session history in the same config directory, which is determined by environment variables (CLAUDE_CONFIG_DIR, CODEX_HOME). So switching accounts means switching the directory it reads at startup.

Credentials separate, history shared

The trouble is that the two directories each manage their own things; session history isn't shared, so switching over means talking to a stranger. The solution is to symlink the history directory to the same place, letting only credentials remain independent.

Two walls here:

settings.json cannot be symlinked: The CLI writes it by creating a new file and renaming it, so a symlink gets replaced with a regular file. You have to copy it before each startup.
The path must match exactly: Since Claude Code 2.1, on macOS Keychain, credentials are named by the literal config directory path; if the same directory is written differently, it can't find the login.

Additionally, whether an individual opening multiple subscriptions complies with service terms is something you need to check yourself.

What came out of this

The practices described here went into Antumi, which I'm building: a status bar always shows each agent's usage and recovery time, judges whether it's too fast or over-allocated based on the rules above, and if no account is available, waits and automatically continues after recovery; preheating can be triggered at daily times or after window reset.

It's an open-source multi-agent workbench. Agents still work normally; the copy-paste work between windows is left to it.

GitHub: 𝗳𝗹𝘆𝗵𝗲𝗿𝗼/𝗮𝗻𝘁𝘂𝗺𝗶