Rate-Limit & Tier Planner

A cost estimate answers whether you can afford to run a workload. This tool answers a different and often more urgent question: whether your account can actually push it through at the rate you need, before spend ever becomes the binding constraint.

Why this is a separate question from cost

Two workloads can cost the same and behave completely differently against a rate-limit ceiling, because RPM and TPM caps don't scale with price the way you might assume — the highest-priced models on this site's roster publish a requests-per-minute limit at the entry paid tier roughly a tenth of what every standard model gets, and one of them has a token ceiling small enough that a single maximum-length prompt takes many minutes of budget to clear. Neither of those facts shows up in a per-token price. They only show up in the published rate-limit tables, which is exactly what this planner checks your workload against.

What you enter

A request shape — tokens per request and the requests per minute you actually need to sustain — and the model and usage tier you're on or considering. The planner checks that shape against the real published RPM and TPM ceilings for that specific model and tier, not a generic number, since the tables genuinely differ across several distinct groups rather than scaling uniformly with price or capability.

Since October 6, 2026 the paid tiers are Build, Launch and Grow, replacing the old Tier 1 to Tier 5, and the planner's tier list follows the facts it reads. GPT-5.5, GPT-5.4 and GPT-5.4 Pro also publish a separate table for long-context requests, those over 272,000 input tokens. When a request you enter is that big, the planner checks it against the long-context table and says so, because that table, not the Standard one, is what governs it.

What "next tier" actually buys you

This is the detail worth checking before assuming an upgrade solves a throughput problem. Under the old five-step ladder, moving from the second tier to the third raised the monthly spend ceiling, token headroom and batch queue in most published limit groups — and left requests-per-minute exactly where it was. On today's tables every step raises both requests and tokens per minute for every model this site prices. The planner doesn't assume that stays true: it computes, from each model's own table, whether any step leaves a limit flat, and lists it in the box below the result if one ever does.

Reading a red flag correctly

If your entered workload exceeds the ceiling for your current tier, the planner shows exactly which limit you'd hit first — RPM or TPM, whichever binds — and what the next tier that actually raises that specific limit would look like, rather than just naming "the next tier up" generically. That distinction matters whenever the tables move: the fix for a token-per-minute ceiling and the fix for a requests-per-minute ceiling haven't always been the same upgrade.

Why account dashboards still win ties

Published tables are the honest default, and they're what this planner checks against — but limits can be raised for an individual account beyond the published defaults, and your own dashboard is the final authority on what you actually have access to right now. Treat a result here as what to expect before you've checked, and a genuine mismatch between this planner and your dashboard as a sign your account has a non-default limit, not a sign the planner is wrong.

Planning around a workload that's growing

A workload sized comfortably today against your current tier can outgrow it — more users, a busier CI schedule, a session that's started accumulating more context per call than it used to. Re-running this planner periodically as a workload's real shape changes, rather than checking it once at launch and assuming the answer stays true, is the cheap way to catch a throughput ceiling before it shows up as a wave of 429 responses in production instead.

The free tier and the first paid tier deserve a closer look than they usually get

It's tempting to treat the entry-level tiers as a formality you'll blow past quickly. The free usage tier is only offered in allowed geographies, and no model this planner covers supports it at all — every published table marks it unsupported — so Build, which needs $5 in total credit purchases, is the actual floor. It's a higher floor than the old Tier 1: Build carries the limits Tier 2 used to have. For a side project or an early prototype still deciding whether a workload is worth building out, checking whether it fits inside Build's ceiling before writing a line of production code is worth the few minutes it takes, since discovering a throttling problem after launch is a worse time to learn the answer was already knowable.

A 429 doesn't always mean "upgrade your tier"

A rejected request due to rate limiting can also mean a single burst exceeded the window rather than the account genuinely needing more sustained throughput — smoothing request timing, adding a client-side retry with backoff, or batching several small calls into fewer larger ones can solve a bursty pattern without touching your account tier at all. This planner is built around sustained, steady-state throughput specifically; a workload that's occasionally spiky rather than consistently near its ceiling is a different problem, and upgrading a tier to fix a spike you could smooth out instead is spending money on the wrong lever.