Token bucket vs fixed window: what a reset header means

With a token bucket, capacity refills continuously, so a reset time is only when the bucket is full again. With a fixed window, the count returns to full at one moment. Anthropic's page says it uses a token bucket, and Sume's docs describe ratelimit-reset as the seconds until the window resets, so on both, pace on retry-after rather than on the reset value.

Anthropic facts are from its Rate limits page (cited under Sources) and Sume facts from Authentication, read 2026-09-30.

What does each provider say about how limits refill?

Anthropic's page says its API uses the token bucket algorithm, so capacity is continuously replenished up to your maximum limit rather than being reset at fixed intervals.

Why does a burst still fail with requests left?

Anthropic's page says capacity is replenished continuously rather than reset at fixed intervals, so the moment you have spent is not the moment everything returns. Sume's docs do not describe a sub-window rule, so on Sume treat the headers as the authority: they describe whichever budget the current request spent from, and a 429 names it in error.details.scope as read or write.

How should one client pace both?

Read ratelimit-remaining on Sume responses and slow down as it nears zero, spread submits instead of sending them together, and on any 429 wait the retry-after seconds. Sume's docs say to back off on retry-after and not to retry unsafe submits without an Idempotency-Key. Polling is cheap: reads have their own, larger budget, so a status loop cannot 429 your submits.

What are the limits of this answer?

Sume's docs name the value ratelimit-reset as seconds until the window resets but do not name the algorithm behind the window. Do not assume it matches a token bucket; rely on the headers on each response.