The September 14 limit cut, and living across five subscriptions.

We hit the wall first.

Luminair is built inside Luminair, on several Claude logins at once, so every change to plan limits lands on us the same week it lands on you. Most of the code in this post exists because a turn stopped when it should not have.

The clearest case came on 16 September. Four Claude accounts were connected on one Mac. The first ran out, the turn failed, and three accounts with room sat unused. The fix from that day is in section 06. The same week, Google's Antigravity engine reported a spent five-hour bucket in words our code read as a passing server hiccup, so it retried a plan that was already empty. Both bugs were found by using the app, and both fixes carry a Claude co-author line in git.

Luminair · several sessions, several engines

A raise that was a cut.

The background, in brief. In May, Anthropic raised Claude Code's weekly limits by 50% for Pro, Max, Team and seat-based Enterprise plans, labelled temporary, then extended it several times. At the end of August the answer came: the boost would end after 13 September, replaced on the 14th by a permanent increase of 25% over the old baseline.

The arithmetic is simple. As MindStudio put it: “Today, with the temporary boost, users get 150 units a week. After September 14, they get 125. That's a 17% reduction from what heavy users have actually been working with for the past four months.” Startup Fortune quotes Anthropic's own announcement: “Starting September 14, we're permanently raising standard weekly limits in Claude Code by 25% for Pro, Max, Team, and seat-based Enterprise plans.”

MindStudio also lists what softens it. The doubled five-hour session limits from May stay. Claude Code can continue a session on its own once a limit resets. Extra usage can be bought at API rates. And Startup Fortune's advice to heavy users is practical: “Move the heaviest work earlier in the week, switch models when you don't need the most expensive one.”

Claude is not the only one. The same Startup Fortune piece points out that OpenAI publishes Codex usage per five-hour window and per week too. A developer who pays for two or three of these plans now manages several tanks, each with its own gauge, reset time and wording for “empty”.

Every gauge, one shape.

Luminair counts five subscription lanes, from a small billing function in its routing code: Claude (in two lanes, SDK and command line), Codex, Gemini, Antigravity and Kimi. Others, such as Meta or an OpenAI API key, are metered per token, and local models cost nothing.

Each engine that can report usage does it in its own file, and returns the same row shape: a list of buckets, each with a label, a percentage and a reset time. The account menu draws them without knowing whose they are. What differs is where the numbers come from.

Claude: every bucket the server sends

The Claude meter asks Anthropic's usage endpoint about each signed-in login. An early version read only the weekly bucket and labelled it “Week”. It showed 100% while Claude's own panel showed the weekly allowance at 60%. The code comment calls that “one bucket presented as the whole truth”, and the rule since then is to keep every bucket under the server's own key: 5h, Week, Wk Opus, Wk Sonnet and any model-scoped line such as Fable. A bucket Anthropic adds later still shows up instead of vanishing.

Kimi: the call its own CLI makes

Kimi's meter calls GET https://api.kimi.com/coding/v1/usages with the access token the Kimi command-line tool already stored, the same call its built-in usage panel makes, plus /me for the name on the row. It reads the token and never refreshes it; the next Kimi turn does that. The code is honest that it was written from the CLI's source: when it shipped, no Kimi account had been signed in on the build Mac to see a live answer.

Meta: no quota, so an estimate

Meta publishes no quota. Every usage, billing and account path Luminair tried on 15 September answered 404. What Meta does publish is a price per model, in USD per million tokens, in its launcher's catalog. So the Meta meter multiplies Luminair's own per-model token count for today by that price: one dollar row per Meta model, reset at local midnight, marked as an estimate for this computer only.

The server says when.

A meter is a hint. It can be a few minutes old, or wrong. So the most important rule in this part of the code is a comment in main.js, dated 23 July:

// LUMINAIR NEVER DECIDES A LIMIT. Claude's servers do.
// Luminair always sends the prompt to Anthropic and only
// reports a limit when the SERVER ITSELF says so, in its
// own words.

The reason is written right below it. An earlier version used one loose pattern for “rate limit, 429, quota, exceeded” over any error. It fired on things that were not limits at all: “Maximum number of turns (5) exceeded”, a prompt that was too long, a session id that happened to contain 429. Each false alarm switched accounts, failed again, and after two hops announced that both accounts were spent while the real meter sat at 70% and 60%.

Today there are two classifiers, because Luminair runs engines two ways. Claude through the Agent SDK goes through SERVER_USAGE_LIMIT_RE in main.js. Every command-line engine (the Claude CLI, Codex, Gemini, Antigravity, Kimi and more) goes through ACCOUNT_LIMIT_RE in engines/failure-policy.js. Both list only the phrasing providers use for a spent plan. The trouble with two lists is that one can learn a phrase the other has not.

The shaded rows tell the story. On 10 September, the SDK lane learned “out of usage credits”, because the commit message says Anthropic's credit message “doesn't say limit/reached/exceeded”, so Auto Switch never fired. The command-line lane did not get the same phrase until 16 September, along with “requires usage credits” and Google's “Individual quota reached”. For six days, the same empty account was a limit in one lane and a plain error in the other.

The last two rows matter as much. A bare 429 means the provider is busy right now, not that your plan is spent, so it is retried rather than treated as a reason to switch accounts. And a turn cap is not a usage limit at all.

Try every account, then stop.

With two or more accounts connected, the account menu shows an Auto Switch toggle at the top. It is on by default. It does two things.

You see a line like this in the chat: Codex hit a usage limit on “Primary”. Switched to “Secondary” and is resending. If the failure was a model that needs paid credits on that login, the message says so instead, so it does not contradict a meter sitting at 43%.

The 16 September fix is about the word every. The rescue used to be allowed once per turn. If the spare was spent too, the turn stopped with the rest of your accounts untried. Now each hop remembers every account already tried in this turn, and the picker runs until none is left. Only then does the limit message reach you. The list of accounts bounds it, with a hard ceiling of sixteen tries, so it cannot loop.

// Now each hop excludes every account already tried this turn;
// the picker runs dry when all are spent, and only then does
// the message surface.
const acctTried = Array.isArray(ctx.__acctTried) ? ctx.__acctTried : [];
if ((failureKind === 'account-limit'
     || failureKind === 'account-blocked')
    && pickSpareAccount && !acctTried.includes(acc.id)
    && acctTried.length < 16 && !stopped) {

When no account has room, Luminair tries to work out when the window reopens, from the server's own timestamp where it gives one, so the session can say when it will retry rather than just “later”.

Spend the roomy pool first.

Switching accounts rescues a turn. Picking the model is the other half. Luminair's decision models (Laya on your Mac, Jev hosted) size up each prompt, and since 27 September automatic routing can take remaining allowance into account. The setting is Consider remaining allowance, on by default, with a description that says what it cannot do: “Old or missing readings stay unknown; percentages are not token counts.”

Under the hood, a model's remaining allowance is 100 minus the fullest bucket that applies to it. A Fable or Opus bucket only counts for that model family. A reading older than three minutes, or one whose reset time has passed, counts as unknown rather than as a guess. Then the ranking adds a penalty as the pool gets tight:

The effect is gentle on purpose. A model with 30% left is barely touched; one with 5% left needs a clear advantage elsewhere to win. Other settings nearby, Prefer subscription models and Allow switching into paid API models (off by default), keep a tight week from quietly turning into an API bill. Every automatic choice comes with a short reason, such as the task kind, the precision level and “62% remaining (Week)”.

Three places to look.

1. 1Open the account menu from your account button. Each connected account shows its meter rows; add a second login on the same engine to see the Auto Switch toggle at the top.
2. 2Drag accounts into the order you want them tried. Auto Switch walks the list top to bottom.
3. 3For allowance-aware model choice, open Settings › Models, pick the Decision segment, and check Auto switch working model and Consider remaining allowance. Turn on Show decision summary to see each choice and its reason.

What this does not fix.

Sources

• Startup Fortune · 30 August 2026Claude Code's usage limit boost ends September 14 with a real cut
• MindStudio · 1 September 2026Claude Code's September rate limit change is a cut dressed as an increase