Short window vs weekly window: two clocks, not one

Two windows, two behaviours

The official material refers to a short window and a weekly window as separate Codex usage windows. They behave differently in the one way that matters for planning your day:

• The short window rolls. It is about recent activity, so its reset arrives relatively soon and then keeps moving as you keep working. There is no fixed “clock time” that applies to everyone.
• The weekly window is a longer cycle with a date. It is the one whose reset date can change — for example after a full banked reset is applied.

That difference is exactly why a single countdown cannot describe your situation. A countdown answers “when does this one thing happen”. If you have two things, you need two answers.

How they interact

From the documented description of a full banked reset: it refreshes both windows and changes the weekly reset date.

Two practical consequences:

• Refreshing one does not imply the other is fresh. Check both rather than assuming.
• The weekly date is the one that moves after a reset. If you wrote down a weekly date and then applied a reset, your note is stale.

Why a shared public timer misleads here

Public announcements describe events, not your rolling short window. An announcement can refresh your windows, which is genuinely useful. But your short window’s next reset depends on your own usage pattern, and nobody else can compute it for you.

So the honest model is:

• Read your own state from Settings, the usage dashboard or /status.
• Track your own dates deliberately, especially the weekly one, because it is the one that moves.
• Treat public events as additional information, not as a replacement for your own numbers.

Setting up two timers without confusing yourself

This site’s personal timer supports two named timers for exactly this reason. If you use it:

1. Name them. “Short window” and “Weekly” is enough. A label you cannot read at a glance is a label you will misread later.
2. Enter the time your account shows, in your own timezone. The tool displays both your local time and UTC, and records the offset you confirmed, so a later timezone mistake is visible rather than silent.
3. Do not derive one from the other. Five hours from now is not a weekly reset, and the weekly date is not the end of the short window.
4. Re-set them after anything that moves a date. A banked reset, a plan change or a workspace policy change all invalidate your notes.

Quick checks when the two disagree with reality

1. Which window was actually exhausted? The usage screen tells you; a countdown does not.
2. Did you apply a reset since you set the timer? Then the weekly date changed.
3. Are you on a workspace plan? An administrator may control your effective limit and reset period.
4. Did you cross a daylight-saving change? Your local time moved; the instant did not. Compare in UTC if you are unsure.

What this guide deliberately does not do

It does not state how many requests or how much usage any window allows, and it does not state fixed window lengths beyond the qualitative description in the source. Those numbers vary by plan and change; inventing them would make every countdown built on them wrong.

Known limits of this guidance

• Evidence level: documentary, from the official help article as read on the review date.
• The source refers to the two windows but does not fully specify how the short window’s rolling behaviour is computed. This guide therefore describes behaviour qualitatively and avoids arithmetic that the source does not support.
• Other allowance types, such as credits or workspace budgets, are separate again and are covered by their own guides.