# Limit Ladder

> Check a public API's rate-limit policy so integrators can predict, observe and adapt to throttling instead of
> discovering each ceiling by tripping it. List the tiers and paste one throttled response; the browser normalises
> every rate, catches burst equal to sustained, works out refill time and the per-region multiplier, diffs documented
> against enforced limits, reads the response (429 or a throttle inside 200, the Retry-After form, legacy and IETF
> headers, reset semantics, caching), checks fairness, overrides and change notice, and ranks the algorithm and header
> family. Metered runs write the published policy, and the override and change rollout. Built on the SkillSafe skill
> @samber/api-rate-limit-policy, from samber/developer-platform-skills (MIT), by Samuel Berthe.

https://limit-ladder.skillsafe.ai/

## What is free
- Metering and algorithm: one model per paradigm, a named algorithm whose behaviour matches its name, the fixed-window boundary worked out.
- Tiers: every rate normalised to a per-second figure, burst and sustained as two numbers, refill time from empty, a key per tier, global or per-region scope with the real global throughput, documented-versus-enforced drift, a documented secondary guard, numbers as hints rather than an SLA.
- Fairness: a tenant ceiling, a per-user limit inside it, carve-outs, load shedding admitted.
- Headers and the throttle response: not the IETF fields alone, documented reset semantics, 429 rather than 200, Retry-After in delay-seconds, the chosen header family present, reset value matching the docs, a machine-readable code, which limit was hit, never cached, retry guidance published.
- Overrides and change: a named override path keyed to a principal, at least six weeks' notice, reset semantics never changed silently.
- The rankings: algorithm (token, sliding, leaky, fixed) and header family (legacy, both, or none with retrying SDKs), fairness layers or deferred.
- A published limits table, an example 429 in the ranked header family, and exports: the checks (.csv), everything (.json).

## The metered lanes
Two tasks on gpt-terra, metered per run, routed by `task`. Input string fields: `task` (policy or rollout), `api`, `limits`, `carry` (rollout only: the policy's decisions) and `facts`.
- `policy` replies with `summary`, `metering`, `algorithm`, `tiers`, `carveouts`, `fairness`, `secondary`, `headers`, `throttle`, `sla` and `caveats`; the page builds the example 429 from the reply's tiers.
- `rollout` replies with `summary`, `override`, `notice`, `phases` (observe, baseline, refine), `retry`, `gates` (machine-readable, parity), `trends` and `caveats`.
The page holds every reply to its own facts: the ranked rungs, a behaviour matching the algorithm, every tier with two numbers, a key and a scope, 429 with Retry-After in seconds; a named override keyed to a principal, at least 42 days' notice, the three phases in order, Retry-After and jitter, both gates.

## Links
- API tutorial: https://limit-ladder.skillsafe.ai/api.html
- Source skill: https://skillsafe.ai/skill/@samber/api-rate-limit-policy