Rate limits usually arrive defensively. Something got hammered, someone added a cap, and the cap stayed. That origin story explains why the number is so often arbitrary — chosen to stop a specific incident rather than to describe what a reasonable caller should expect — and why nobody revisits it once the incident is forgotten. But the limit doesn’t stay an internal protection. The moment it’s enforced, it becomes a statement to every integrator about how much use this system considers acceptable, and most of them are phrased badly enough that the message doesn’t land.

The bad phrasing has a recognizable shape: a request fails with a generic error, no indication of which limit was hit, no indication of when it’s safe to try again. From the caller’s side that’s indistinguishable from a bug, and the natural response — retry immediately — is the worst possible one, because it converts a limit into the retry storm the retries thread described. A limit that doesn’t say retry after this long is asking clients to guess, and clients guess badly, in the direction that hurts you most.

What a good limit response communicates is small and specific: that the limit was the reason, which limit it was, and when to come back. That last part is what turns an error into an instruction — with it, a well-behaved client waits exactly as long as required and no longer, and the system’s load smooths out instead of spiking. It also makes the difference between an integrator who thinks your API is flaky and one who thinks it’s strict but fair, which is a durable difference in how people treat a platform.

There’s also a design question about what the limit is protecting and whether it’s shaped right. A single global cap per key treats an expensive report the same as a trivial lookup, which either strangles cheap calls or leaves the expensive path unprotected. Limits per operation class, or budgets weighted by actual cost, describe the underlying constraint more honestly. And the constraint is usually not “requests” at all — it’s database load, a downstream quota, or spend. When the limit is a proxy for the real thing, it’s worth knowing how good a proxy it is, because the day the relationship breaks is the day the limit stops protecting anything.

Finally: the number is a product decision, not only an engineering one. It determines which integrations are possible, which customers hit friction, and what people believe about the platform’s generosity. That’s exactly the pattern from the permissions thread — infrastructure that behaves like product, evaluated by users, expensive to change once anyone has built against it. Worth choosing on purpose, saying clearly, and revisiting occasionally, rather than leaving at whatever value stopped the incident nobody remembers.