Feature Request: Add “Rate Limits” Column to Models Table

Feature Request: Add “Rate Limits” Column to Models Table

Summary

Add a Rate Limits column to the models listing (on models.dev) to display how many requests (and/or tokens) per time unit (seconds, minutes) each model permits. This will help users choose models based not just on cost, latency, etc., but also throughput constraints.

Motivation / Why

• Many API users hit limitations not from the cost or latency, but from rate limits: e.g. how many requests/minute, tokens/minute.
• Not having this visible forces users to hunt through docs or test by trial and error.
• Transparency improves developer experience: if I know upfront that model X only allows 60 requests/minute but model Y allows 1000/minute, I can architect accordingly.
• It’s already a best practice in API design to include rate limit info in documentation and in headers. Examples:
  • Speakeasy: Use requests per second/minute, expose headers like X-RateLimit-Limit, X-RateLimit-Remaining, Retry-After.
  • RestfulAPI.net: Common formats like “20 requests/second”, “1000 requests/minute”, “100,000/day”.
  • Moesif: Clear rate limits prevent developer frustration and improve adoption.

Proposal

Add a Rate Limits column in the model list table. For each model, show:

Additional details:

• If rate limits differ between usage tiers (free, paid, enterprise), show multiple values with labels or the lowest common value.
• If a provider does not publish limits, display “undisclosed”.
• Allow notes for burst handling (e.g. token bucket), whether limits are per-user, per-org, or per-API key.

Considerations

• Data sourcing: Requires gathering and maintaining provider-specific values (OpenAI, Anthropic, etc.).
• Updating: Limits may change frequently, so a refresh process is needed (gh action)
• Differences: Providers vary—some limit requests, some tokens, some both. Need a consistent format.
• UI/UX: Extra column may make the table wide; consider responsive design (hide/collapse on mobile, or tooltips for details).

Best Practices for Rate Limit Values

From industry references (Speakeasy, RestfulAPI.net, Moesif):

• Always express in requests per second/minute and tokens per minute (if relevant).
• Prefer sliding windows over fixed windows for fairness.
• Return standard headers:
  • X-RateLimit-Limit
  • X-RateLimit-Remaining
  • Retry-After
• Return 429 Too Many Requests on limit exceeded.
• Support multiple tiers: free, paid, enterprise.
• Allow short burst capacity via token bucket / leaky bucket algorithms.

Expected Outcome

A new Rate Limits column on models.dev provides developers with instant visibility into throughput constraints, leading to better architectural decisions and improved developer experience.

No files, tests, or entry points are named. Start by locating the models listing and the model data source, then determine how provider-specific limits and tiers are represented. Done means the table displays the requested rate-limit information, handles undisclosed or tiered values, and accounts for responsive presentation and refresh needs.