The catalog holds 7,799 rate-limit artifacts covering 25,694 individual documented limits. Against 25,932 providers, that means roughly 30% of the catalog has any reconciled rate-limit description at all.
Seven in ten providers will throttle you without telling you where the line is.
The distribution
| Enumerated limits | Providers |
|---|---|
| 0 | 1,096 |
| 1 | 1,253 |
| 2 | 863 |
| 3 | 731 |
| 4 or more | 3,856 |
The first row is the one to sit with. 1,096 providers have a rate-limit artifact with zero numeric limits in it.
An artifact that says “there are limits”
Those 1,096 are not a data gap on our side. They are providers whose published material asserts that rate limiting exists and never states a number.
The Requesty artifact is a fair example of the honest version. It records that the free tier is capped at 200 requests per day on free models, that pay-as-you-go traffic is governed by per-key spending limits and budget caps rather than fixed request quotas, and that effective throughput depends on the underlying provider’s limits for the routed model. Then it says plainly that specific per-account numeric throttles are not reconciled in this artifact.
That is the right way to record an unknown: state what is documented, state what governs it, and refuse to invent the number that is not published. A rate-limit artifact whose job is to say “we could not find a number” is more useful than one that guesses.
Why zero is often architecturally true
For a growing set of providers there genuinely is no request-per-second number, because the constraint moved.
Gateways and AI routers do not throttle on requests — they throttle on spend. Your limit is a budget cap, a token allowance, and whatever the upstream model provider is enforcing on the key being routed. Ask “what is the rate limit” and the correct answer is a function of three variables, none of which is a request count.
That is a real change in what integrators need to know. The old question was how many calls per second before a 429. The new one is what does this cost, what stops it, and who owns the ceiling I am actually hitting — the upstream provider’s, or my own budget’s.
Why this is scored
A documented rate limit is the difference between a backoff strategy and a guess. An integration built against an undocumented limit works in development, works in staging, and discovers the ceiling in production at the worst possible moment — usually during a launch, which is when traffic spikes and when nobody wants to be reading a support forum.
An agent has it worse. A human who gets a 429 reads the docs. An agent retries.
That is why the rate-limit signal is a graded input to agent readiness, and why the grading distinguishes a limit verified in a contract from one merely asserted on a documentation page. A number in a spec is something a client can respect automatically. A number in a paragraph is something somebody has to read.
Takeaway
7,799 artifacts, 25,694 documented limits, and 1,096 providers whose rate-limit description contains no number. Thirty percent of the catalog describes its throttling at all — and for a growing slice of the rest, the honest answer is that the limit is a budget, not a rate.
Rate-limit artifacts appear on every provider profile across apis.io.