If you run a coding agent in 2026, you run against at least one clock you did not configure: a usage window that starts when the session does, a weekly budget beneath it, and in some tooling a per-model cap on top. Those clocks are a contract between a person and a subscription. They are not a contract between an app and an API — and confusing the two is how teams meet bills that do not look like the UX they expected, and terms violations they did not intend.
This post separates the three clocks, what they do and do not bound, and what an application key means by contrast.
Clock 1: the session window
The window resets on a clock, not on activity: the most common shape in the most-discussed tooling is a rolling window of a few hours, and usage is tracked against what the session actually spent. When the window fills, tokens stop flowing and the interface says so — then the clock rolls and the session resumes.
Two properties matter for cost reasoning:
- What the window measures is session spend — tokens, billed against the model class the session is using. It is a real accounting mechanism, and for a long-running agent it is a genuine cost floor: the UX stops at a known number.
- The window is per human seat. It does not scale with parallel sessions. A "helper" session on a second seat, or shared credentials on the same login, multiplies usage while sharing a budget — and the terms around that exact pattern keep tightening, thread by thread.
Clock 2: the weekly budget
Beneath the window is a slower clock: a weekly usage budget that, in sustained agent work, is usually the one that determines how much a person can do in a month. It behaves as a design decision rather than an error: the UX throttles or pauses, it does not 429.
The intent is legible. A subscription converts an unbounded token budget into a bounded planning assumption, so a person can work hard without reading the invoice. The window handles the burst; the weekly budget handles the month.
Clock 3: the per-model caps
Newer and less documented: caps that apply to a specific model class within the session or week — a fast model, a long-context model, a frontier model where its quota is shared with others. These turn out to be the most visible exactly where people push hardest (agent loops on the frontier class) and least visible where they matter most (the same loop on the mid tier runs far further before touching a cap).
The mechanism, not the numbers, is the point of this section: the figures and reset rules move with releases, and a screenshot from last month is a stale spec. What does not move — and what this post is really about — is that all three clocks are UX throttle mechanisms, not billing primitives. They bound what a person can do in a period. They do not bound what an application can do.
What an API key means, by contrast
An application key to a provider's API has no window, no weekly budget, and no per-model UX cap. Metering is purely token-based: spend equals tokens times price, and the only ceilings are the ones you — or the platform holding the key — configure. This is why agent tooling advertises both paths: a human at the keyboard on the subscription, and programmatic use on a key. And it is why the same tooling behaves visibly differently when pointed at a metered endpoint: there is no window to pause a task, there is a clean error when the budget you set is exhausted, and there is a per-key ceiling that is a load-bearing wall rather than a UI message.
That difference is the whole reason this post exists. The clocks bound a person. An app that assumes the clocks are there for it will behave like an app with no floor at all — until it meets one that was never there.
The trap to route around
The tempting "hack" is to proxy subscription session credentials through tooling so a script or agent can use the same flat rate. Do not. Two independent reasons:
- The terms. Consumer session usage is for interactive, human-operated use. Infrastructure traffic on it is a terms violation at every major provider.
- The mechanics. Session credentials routed through a proxy return rate-limit errors that direct requests do not, each with retry semantics that do not match plain rate limiting — you get the worst of both worlds: subscription-shape failures on infrastructure traffic.
The clean pattern is two pools with two budgets:
- A subscription pool for human-operated sessions. Windows and weekly budgets as designed. No keys shared into it.
- An API pool for programmatic usage, keyed separately, with caps per key, metered per token, logged per request.
Two budgets, two sets of clocks, two kinds of error semantics. Nothing is broken, nothing is a violation, and when a bill arrives, each half of it explains itself.
Choosing the pool correctly
The boundary is one question: is a person in the loop making the requests?
- A person at the keyboard, pacing their own review of diffs between steps: subscription. The flat rate is the right shape for human-paced, bursty work.
- Anything that runs while the person is not there — batch jobs, CI, scheduled agents, a product's API: an API key. No window protects it, and that is by design; the protection has to come from caps and budgets that are yours.
Hybrid plans exist — and will keep existing, because some usage in a single product is human-paced and some is machine-paced. The rule holds at the request level, not the product level: classify each request class by who operates it, and send it through its pool.
Windows for the subscription, per-key metering for the API — both halves of the same bill. The exact per-key semantics, including caps, budgets, and what a limit-reached response looks like and how to handle it, are in the docs.