The percentage is observable. The denominator is not.
A five-hour quota snapshot reports a rounded state at an instant. It does not publish an absolute token budget, explain internal weights, or tell us how many tokens the next run attempt will consume.
The proposed definition
It answers
How large is this task relative to one empirically observed full window on each candidate?
It does not answer
What the API costs, what the provider's official token limit is, or whether current headroom guarantees completion.
Two unknowns, not one
Effective window capacity
The meter may weight models, cache, reasoning, or other work differently. Percent snapshots identify a relationship to observed usage, not a literal provider token allowance.
Attempt token demand
Prompt size is only the starting point. Agent turns, context replay, tools, failure/cancellation outcomes, and model behavior determine one attempt's consumption.
task tokens / limit requires both a known task total and a known, compatible limit. At decision time we have neither.“Five hours” does not imply fixed clock buckets
The topology must be established per provider meter. A reset timestamp is useful evidence, not proof.
First use can start the clock
A start/end pair is comparable only inside the same logical window. Crossing a reset splits realized consumption across two windows.
Old use can expire while new use arrives
Endpoint delta = new use − expired use. It can be small or negative even when the measured task consumed quota.
UI rules that protect meaning
- Say “estimated percentage of one full effective window,” with plan/model scope, range, confidence, and as-of time.
- Show current headroom and reset separately. “4% of full window” is not “4% of the remaining 20%.”
- Do not clamp values above 100%; they reveal likely non-fit.
- Keep weekly and other provider limits visible as independent admission constraints.
- Return an explicit uncalibrated row when evidence is missing. Unknown is never free.