AI coding agent usage limits: what actually resets, and when
Most confusion about AI usage limits is not about the numbers. It is about the fact that every vendor meters something different, on more than one clock, and the word "reset" means at least three unrelated things depending on whose product you are using.
I lost an afternoon to this. I hit a wall mid-refactor, assumed I was out until the next billing period, and shelved the work. I was actually only out on the short clock and would have been fine after a coffee.
So: the general mental model that holds across tools, then the practical part — how to scope work so limits stop mattering much. No specific figures anywhere in this post, deliberately, and I will explain why.
First: what is being counted?
Before you can reason about a limit, you have to know its unit. Broadly there are three, and tools mix them:
Tokens. The most common for API-billed usage. Roughly, chunks of text - both what you send and what comes back. Two things people miss: output usually costs more than input, and the entire conversation is re-sent on every turn. Which means turn 40 of a session is dramatically more expensive than turn 4, even if you typed the same number of words. More on why that matters below.
Requests or messages. Some subscription tools count interactions rather than volume, sometimes labelled "premium requests" or similar. Under this model a huge task and a one-line question cost the same, which inverts your strategy completely — batching is free, and asking many small questions is what hurts.
Credits. An abstraction over the other two, usually with different models drawing at different rates.
The single most useful thing you can do is find out which of these your tool uses, because strategies that help under one model actively hurt under another.
Second: there is usually more than one clock
A short rolling window. Covers a few hours of heavy use, then rolls off. Critically it is rolling, not a calendar bucket — usage from early in the window ages out continuously, which is why you can sometimes come back in twenty minutes and have room. This is the limit you hit most and panic about most unnecessarily.
A longer ceiling tied to a week or a billing cycle. This is the one that genuinely ends your week, and the reason a single very heavy day can quietly cost you Thursday.
Per-model sub-limits. The most capable models are almost always metered harder than the cheap ones, whether by a separate cap or a higher credit rate.
"Reset" can therefore mean: a rolling window aging off, a calendar period flipping, or a credit balance refilling on your billing date. Three different behaviours. Worth knowing which one you are waiting for before you decide to wait.
On actual numbers: I am not quoting any. They differ by vendor and plan and they get revised constantly — anything I wrote today would be wrong by the time you found this via search. Check your vendor's own limits page, and treat any blog post quoting hard figures (including ones ranking above this) as possibly stale. The structure above is stable even as the numbers move, and you can plan against structure.
Why "just wait for the reset" is worse than it looks
The cost people underestimate is not the agent's. It is yours.
The context you built over the last hour is perishable. You had three approaches in your head, rejected two for reasons you never wrote down, and had just worked out that the legacy adapter is load-bearing.
Come back five hours later and that is gone. You will re-litigate a decision you already made, and possibly land on the approach you already rejected.
So the real question is not "how do I get more quota." It is "how do I stop accumulating expensive undocumented context that a five-hour gap destroys."
Four strategies, in the order I reach for them
- Batch the work, then get out of the loop.
Under token metering this is the big one, because of the re-sending problem. Twenty small conversational nudges each re-send the whole accumulated context — you pay for the same history twenty times. One well-specified task costs a fraction and produces a better audit trail.
Caveat: if your tool counts requests rather than tokens, this is already free and you should ignore it.
- Scope tasks to fit one window.
If a task cannot finish inside a single short window, it is usually not one task. "Migrate the auth module" is a programme of work. "Auth should make one network call per session instead of one per request; auth_spec must still pass" is a task, and it fits.
The forcing function: if you cannot state the definition of done as a command and its expected output, the task is not scoped yet. Better to find that out before spending the quota.
- Put cheap models on mechanical work.
Since top-tier models are metered hardest everywhere, spending them on rote work is the most common way people burn a week. Renames across files, the obvious test, mechanical format translation — none of that needs your most expensive model. Save the tightly-metered capacity for work where reasoning quality changes the outcome.
Biggest difference for me, costs nothing to adopt, works on every vendor.
- Hand the task off rather than sit on it.
If a teammate has capacity and the work is genuinely unblocked, the work should move. The trap is how most teams do it: pasting an API key into Slack, or letting someone log into your account. Now you have a shared secret with no scope, no expiry and no audit trail, in a DM that is still searchable in two years.
The principle that fixes it: the unit you share is the task, not the account. Whoever picks it up authenticates as themselves, against their own subscription, with a credential scoped to that one task.
That requires the task to be written down properly — which loops back to strategy 2. A handoff is only as good as its specification.
Reach for this one last. Fix scoping first; it makes everything else smaller.
The part that surprised me
Every strategy here is good practice regardless of limits.
Batching produces better diffs. Tight scoping produces checkable outcomes. Model tiering saves money on any plan. Written-down tasks are easier to resume even if nobody else touches them.
So limits are not really a constraint you work around. They are a forcing function toward habits you should have had anyway. I write better task descriptions now than when I had effectively unlimited quota, purely because sloppiness got expensive.
We build Wagglet around the handoff half of this — documenting a task so someone else can claim it and run it on their own subscription, whichever vendor that is, with per-task scoped credentials instead of a shared account. If that is your bottleneck: using unused agent capacity across a team and writing a task two audiences can both read.
Disclosure: I work on Wagglet. The metering, scoping and model-tiering advice above is vendor-neutral and free.
What does your tool actually count — tokens, requests, or credits? I am increasingly convinced most people do not know, and that it is the root of most bad quota strategy
Top comments (0)