reserve % of quota for specific tasks

There's a tension in the spec that's worth making explicit, because it decides how this can be built at all.

You ask for two things: (1) 5% is reserved for chat, and (2) if chat doesn't use it, coding can. Those can't both hold for a consumable resource. If the 5% is genuinely available to a long coding session, the session will consume it — and it will do so early, because nothing tells it to stop. The guarantee then fails at exactly the moment you wanted it: late in the period, right after the heavy work.

Systems that do "lend the reserve, take it back on demand" (cgroups memory.low, CFS bandwidth control) rely on reclaim — you can evict a page or preempt a slice. Tokens can't be reclaimed. Once they're spent, they're spent. So borrow-with-reclaim isn't available here, and any design that quietly assumes it will behave like a plain shared pool with extra UI.

The version that does work is the same arithmetic pointed the other way: don't reserve 5% for chat — cap Claude Code at 95%.

Identical numbers, but now it's enforceable, because refusing a request is something you can do. When the coding session reaches 95% it stops, and the remaining 5% is intact by construction — not because anything protected it, but because nothing else was ever permitted to reach it. This is how airline protection levels work: you don't reserve seats for late full-fare buyers, you cap the discount bucket. Same result, and it only needs admission control on the class you're willing to refuse.

On "it doesn't go to waste" — worth noting the concern is smaller than it looks. Unused quota expires at period end regardless, so unconsumed reserve isn't lost value in any case; the only real cost of the ceiling is that coding couldn't spend those tokens. That's the honest trade, and it's a much easier one to accept when it's stated as a 95% ceiling instead of a 5% reservation.

Practical shape: one ceiling per class, expressed as a percentage of the period limit, enforced at request admission with a clear error naming the class and the ceiling that stopped it. That's substantially less machinery than a reservation system, and unlike a reservation it actually holds.

Thanks for pointing this out. You're right.

Glad it was useful. One practical follow-on, since you're the one who filed it: the request is more likely to move if the body states the ceiling form directly rather than the reservation form. A feature that can't be built as specified tends to sit in triage, because the first person to pick it up has to relitigate the spec before writing a line — whereas "cap Claude Code at N% of the period limit, refuse at admission with an error naming the cap" is small enough to be estimated on sight. Same outcome you asked for, and you'd be handing over the version that survives review.

Worth setting expectations on the interim, too: there's no client-side switch that does this today, so it isn't something you're failing to find in the config. Until the ceiling exists anywhere in the product, the only lever is watching consumption and stopping by hand — which is exactly the thing the request is asking to automate, and worth saying out loud in the thread so nobody suggests a setting that doesn't exist.

Good point, thanks. I'll edit the issue to say cap claude code at 95% instead of reserve 5%. so it's ready to build.
And yeah, I'll just watch my usage manually for now.

That edit makes it buildable — good call.

On watching it manually in the meantime: the reason there's no client-side switch is that Claude Code enforces at the server, but the enforcement point can sit one layer lower — at the network boundary on your own machine. A local proxy sees every request before it leaves, meters it against a period ceiling, and refuses once you cross it (returns an error to the client instead of forwarding the call). That's the same "cap at N%, refuse at admission" shape you landed on — just enforceable today, client-side, instead of waiting on the server feature.

Disclosure since it's relevant: we built one (agent-proxy) for the surprise-bill version of this — it hard-stops a request before it reaches the provider once you hit a set ceiling, and shows live per-request usage so there's nothing to eyeball. Your issue is really about the shared subscription pool, which is a different axis than a dollar cap, so I'm not claiming it closes your feature — just that the manual-watching gap specifically is the part a proxy handles. Happy to point you at it if that'd help.

Thank you, that makes sense. Before trying: is it open source, does it need my API key, does it send anything anywhere besides anthropic?

Straight answers, since you asked directly:

Open source? No — I don't want to leave a wrong impression there. It's distributed as a signed prebuilt binary (curl / Homebrew / Scoop); the source isn't public. It's also a paid tool after a short trial, so I'd only point you at it if the budget-visibility problem is actually worth that to you.

Your API key? You keep using your own provider key — it's read from your environment and forwarded upstream, never sent to us (the proxy even strips auth headers out of anything it logs). One honest caveat that matters for your case specifically: it's built around provider API-key usage, and I haven't verified it works with a Claude.ai subscription login — which, from your original issue, sounds like what you're on. If you're subscription-only, it may not actually help you, and I'd rather say that up front than have you install it for nothing.

Anything besides Anthropic? Your prompts, your secrets, and your provider key never leave your machine, and the license check is fully offline. The part I won't gloss over: on a licensed install it does, by default, send aggregate usage metadata — token counts, model, estimated cost, no prompt or response content — to the vendor's server periodically. It's a one-line config toggle (telemetry.usage_enabled: false) if you want it completely silent.

Short version: closed-source, your key stays local, no content ever leaves — but metadata does by default unless you flip that switch. And if you're on a subscription rather than an API key, it may not be the right tool for you at all. Happy to be a sounding board either way.

Correcting myself, because I told you something unverified and it turns out to be wrong in your favour.

I said it was built around provider API keys and I hadn't checked whether it works on a Claude.ai subscription login. I went and checked. It works on a subscription — I ran it just now on a machine with no ANTHROPIC_API_KEY set at all, on subscription auth, and the session ran normally while the local dashboard recorded every call:

{"ts":"…","host":"api.anthropic.com","path":"/v1/messages",
 "model":"claude-opus-5","input_tokens":2,"output_tokens":8}

The reason is that it works at the network layer rather than the auth layer — it sits between the agent and api.anthropic.com, so it sees the requests whichever way you authenticate. I should have reasoned that through before saying otherwise.

Two honest caveats now that I've actually run it on a subscription:

The dollar figures are the wrong number for you. It prices each call against API list rates, which is meaningful if you're paying per token and misleading if you're on a flat subscription — your marginal cost per request is zero until you hit the limit. What's actually useful in your case is the volume side: which model, how many calls, and which task caused them. That maps onto your original problem (one long coding session eating the pool) much better than a cost column does.

It didn't attribute the session. My run came through as agent: "unknown", project: "unattributed" because I hadn't configured that — so out of the box you get a total, and you have to set attribution up before "which task ate my quota" is answerable.

Something I didn't expect, and it's the part I'd actually care about in your position: it flagged a secret in my own traffic on that first run — secrets_caught: 1, an OPENAI_API_KEY that something in my environment had pulled into context and was about to send upstream. I wasn't looking for that and it found it in ten requests.

On trying it: the trial is free and doesn't need a card, so if you want to look at the volume view I'm happy to just hand you access — no purchase involved. And if it turns out a subscription user gets nothing useful from it, I'd rather you tell me that than buy it.