Rate limits belong on the pricing page, not only in the docs

The limit is the other half of the price

Rate limits belong on the pricing page because they decide how much of the listed rate a buyer can actually buy. A per-token price tells them the cost of a request. The limit tells them how many requests a minute they may send at that cost, on the tier they can reach, and buyers comparing providers need both before either means anything.

A page that hides the limit in the documentation is compared as if the limit were unknown, and an unknown limit is easy to read as a low one. Making a reader open a second site for a number invites the guess that the number does not help the sale.

Where buyers run into limits

Rarely in the prototype. The first wall is often launch week, when real traffic arrives in bursts and the account is still on its starting tier. The second is a backfill or evaluation run that sends thousands of requests in an hour. The third is a long-context feature where a handful of requests use up the token allowance before the request allowance is close.

Each of these is predictable from the page if the page gives requests per minute and tokens per minute, separately, for each tier. With those figures a team can work out which wall it hits first and plan around it, or choose a provider whose walls are further away.

Without them, the safe plan is the worst case: smaller batches, more retries, a second provider on standby. All of that is cost counted against your rate.

Tiers, and how a buyer moves up

Where limits rise with spend or account age, say what moves an account from one tier to the next: an amount spent, a number of days, a request to sales, or a mix. State whether it happens automatically.

A launch date raises the question of whether the needed tier can be reached by then. If the only route is a conversation with sales, say that and say how long it usually takes. Silence on this point makes a provider that did write it down look safer, even at a higher rate.

Say also whether limits ever go down, for example after a period of low spend. An account that reached a tier for a launch and loses it in a quiet month should not have to learn that from an error.

Units that can be compared

Requests per minute, input tokens per minute and output tokens per minute are the units buyers expect. Some providers count input and output together. Some count per day. Some count per model and some per account across all models. Each is defensible and each must be named, because a limit in the wrong unit compared against one in the right unit produces a wrong answer with confidence.

Say what happens at the limit as well. An error that the client must retry, a queue that delays the response, or overage billing at a different rate are three different products. A buyer writing retry logic needs to know which one they bought.

Give the limits for each model where they differ. An account-wide limit shared by every model behaves very differently from a separate allowance per model, and a buyer running several models on one account needs to know which applies.

If limits differ by region or endpoint, name the region on the row. Otherwise traffic routed to the nearest region gets planned on a limit that only applies somewhere else.

A tier table that answers the question

Rows are tiers, named by how they are reached. Columns are requests per minute, input tokens per minute, output tokens per minute, and any daily cap. If limits differ by model, the table repeats per model or carries a column for it. A header row states whether the limits apply per key, per project or per organisation.

Below the table, three sentences: how an account moves up, how long that takes, and what happens at the cap. Put the price of a dedicated or reserved capacity option here too, if one exists, or say that it is quoted on request. That is everything a buyer needs to judge whether your rate will hold under their traffic.

Keep the documentation copy as the detailed reference, with headers and examples. The pricing page copy is the summary a buyer compares. When the two disagree, the lower figure is the safe one to plan on, so update both together and date the change.

What we can and cannot show

Our token price table holds rates, not limits, and our cost calculator prices a monthly volume as if every request is accepted. A buyer using either will reach a figure your page has to complete.

That is the case for putting the limits next to the rates. A claimed listing can also answer the questions asked of the inference API category with a source, which is the place a limit policy can be stated in your own words.

Gateways and routers sit between buyers and several providers, and one use for them is spreading traffic across limits. The gateway and router category lists them. Limits printed plainly give their users something to configure against.

Until limits are printed next to rates, a buyer's cost estimate from published figures is an upper bound on what they can buy, never a promise that they can buy it.