The Wrong Mental Model
Ahmed looked at his usage panel and saw two numbers:
- Session (5h): 62%, resets in 3 hours
- Weekly (7 day): 40%, resets in 2 days
His question was reasonable: should I use up my weekly allocation before it resets, or will I lose it?
The question assumes a bucket model — a fixed amount of resource that gets filled and emptied on a schedule. Use it or lose it. Like mobile data that expires at the end of the month.
That’s not how it works. And the difference between the two mental models changes what you should actually do.
Ceiling, Not Bucket
The weekly cap is a ceiling on how much compute you can burn in a rolling 7-day window. It’s not an allocation that gets handed to you and taken away.
If you’ve used 40% of the weekly cap, the remaining 60% is headroom — space you haven’t consumed. When the weekly window rolls forward, your oldest usage ages out and your headroom grows back. Nothing was taken from you. You never had a 60% bucket to spend; you just have a 100% ceiling you haven’t hit.
The practical consequence: there’s no benefit to artificially consuming your remaining weekly capacity before the reset. You’d be burning tokens on nothing to “use up” something that wasn’t yours to lose in the first place. The reset doesn’t zero out a balance you built up — it ages out old usage you already burned.
The Two Windows and What They Actually Mean
There are two independent limits running simultaneously, and they measure different things.
The session window (5 hours) tracks recent compute intensity. It’s the short-term throttle. When it fills, you’ve done a lot of heavy work in a short period and the system slows you down until the oldest charges age out. At 62% with 3 hours left, you have room for moderate work but would likely hit the cap before the reset if you ran a heavy build session.
The weekly window (7 days) is the outer boundary — an aggregate ceiling above the rolling session window. Even if your session window keeps recovering, there’s a harder limit on total compute over the week. At 40%, you have significant headroom and no pressure here.
Most people never hit the weekly cap through normal use. It becomes relevant if you’re running long automated sessions, doing heavy multi-hour builds every day, or working at high intensity across many consecutive sessions. For typical project work, the session window is the one that matters day to day.
What to Actually Do With This Information
The session window is the useful signal. It tells you how much runway you have right now and when it will recover.
Given the numbers Ahmed was looking at — 62% session, 3 hours to reset — there are two sensible moves:
Use the remaining headroom now. 38% of a 5-hour window is meaningful. Short answer sessions, file edits, moderate-length tool chains — these fit comfortably. A full multi-file phase implementation might push you into the cap before the reset.
Wait for the reset if the work is heavy. If you have a large task queued — implementing an ExtKit phase, a long analysis session, a multi-file build — running it right after the reset gives you a full 5-hour window of clean headroom. Three hours is not a long wait for that kind of benefit.
The weekly at 40% changes nothing about this calculation. You’re not under any pressure there.
Scheduling Around the Windows
Part 9 of this series covered the mechanics of the rolling window in detail. The practical extension of that is: the session window is a budget you can schedule around if you’re deliberate about it.
Heavy work — large builds, long reasoning chains, sessions with many file reads and tool calls — draws down the session budget fast. Light work — short answers, single-file edits, conversational clarifications — barely touches it.
If you have a week of work ahead, the rough scheduling principle is:
- Put heavy work at the start of a fresh session window
- Put light work or review tasks toward the end of a window when headroom is lower
- Don’t try to run a full phase implementation in the last 20% of a session window
None of this requires watching the percentage constantly. A quick check when starting a heavy task is enough — if the session is above 70%, either do lighter work first or wait for the reset.
The Number That Actually Matters
Of the two numbers on the panel, the weekly percentage is almost never actionable. It’s informational — good to know you’re not near the outer boundary, not much else.
The session percentage is the one to read before starting something expensive. Not because you need to optimize every session, but because starting a large task at 80% session and hitting the cap halfway through is genuinely disruptive. A three-to-five hour wait mid-implementation is worse than a two-hour wait before starting.
The ceiling model makes this cleaner than the bucket model would. You’re not managing a diminishing resource — you’re managing timing. The compute is always available up to the ceiling. The question is just whether you have enough runway in the current window to finish what you’re starting.
Next: Part 15 — TBD