What a Provider Migration Means for Existing Rate-Limit Increases

A rate limit is an account property, not a contract you can port. On the target provider you start wherever a brand-new account starts, and on some providers there is nobody to ask — the limit is a function of what you have spent, and the only way up is calendar time.

Two kinds of limit, one of which you can ask for

Providers set limits one of two ways, and the migration plan is completely different depending on which you are facing.

Derived from a usage tier. OpenAI publishes a tier table in which an organisation moves up as its cumulative paid amount grows — Free, then Tier 1 at $5 paid, Tier 2 at $50, Tier 3 at $100, Tier 4 at $250 and Tier 5 at $1,000 — with each tier carrying its own monthly usage cap, and the documentation stating that graduation is automatic as spend rises. See OpenAI’s rate limits guide. There is no ticket that skips this. Higher tiers also carry a waiting period after the first payment on several providers, so even spending the money on day one does not necessarily move you on day one.

Negotiated. Elsewhere the limit is a number an account team sets, and raising it means a conversation with evidence attached. That conversation has a lead time you do not control and cannot reliably compress, which means it belongs on the migration critical path from the first week, not the last.

The practical consequence of the split: if your target is tier-derived, the lever is spend and time, so start spending early on non-critical traffic. If it is negotiated, the lever is evidence, so start assembling the demand profile below before you have anything to migrate.

Where the lead time actually goes

Teams budget for the approval and forget the three things around it. The limit is usually granted per model, so a grant on the model you benchmarked does not cover the model you ship — and switching model mid-migration resets you to that model’s pool. The limit is usually granted per account or project, so a grant on the account your platform team owns does not cover the project your application team created. And limits are frequently regional, so an approval that names one region leaves a failover region on default limits, which is precisely the moment you will need them.

Add to that the review cycle itself, and the honest planning assumption is that an elevated limit on a new provider is a multi-week item with a variable tail. Nothing in this page tells you how many weeks, because that number is set per customer and per provider and would be wrong for most readers. What you can plan on is that it is not same-day, and that the cutover date must not depend on it.

The demand profile you have to produce

Whether you are filing a request or sizing a ramp, you need the same artifact, and it is not your monthly token total. It is the peak minute.

From whatever sees every request — your proxy, your gateway, your application logs — produce, over at least fourteen days: requests per minute and total tokens per minute, bucketed to the minute, then take the p99 of each. Use p99 of the minute buckets rather than the mean, because a limit is enforced against the peak and a mean hides a traffic pattern that is four times the mean for ninety seconds every hour.

-- per-minute demand from a request log, 14 days
SELECT date_trunc('minute', ts) AS minute,
       count(*)                 AS reqs,
       sum(input_tokens + output_tokens) AS tokens
FROM llm_requests
WHERE ts > now() - interval '14 days'
GROUP BY 1;

-- then, over that result:
--   p99(reqs)   -> the RPM you must be granted
--   p99(tokens) -> the TPM you must be granted

Then apply two corrections, and label both as assumptions when you quote the result. First, headroom for growth over the migration window: if traffic grows g per month and the cutover is m months out, multiply by (1 + g) to the power m. Second, headroom for retries. A limit that is marginally too low does not shave the peak, it amplifies it — every 429 becomes a retry that arrives inside the same window, so a client retrying up to r times can present up to roughly r times the offered load during a saturation episode. Size against the amplified peak, or bound it in the client with the backoff discipline described in backoff parameters across providers.

Note which of the two numbers binds. Migrations almost always hit the token limit before the request limit, because prompts are long and request counts are modest. A request framed entirely in requests per minute asks for the wrong thing.

Sizing the cutover to the limit you have

The plan that works when the grant is late is one that never needed the full grant at once. If the target’s current TPM is T and your p99 demand is D, you can move a fraction of traffic no larger than T over D, minus headroom, and keep the rest on the source. That fraction is a number you can compute today, which makes it a schedule you can commit to without knowing when the grant lands.

Two details make the difference between that working and not. Route by proportion of requests rather than by service, because a service is a lumpy unit and its share of your peak minute is not its share of your daily volume. And keep the source path warm rather than decommissioned — a partial cutover whose fallback has already been deleted is not a partial cutover.

Verifying the limit before you need it

Do not take the limit from the documentation table or from the email confirming the increase. Read it from a live response. OpenAI returns x-ratelimit-limit-requests, x-ratelimit-remaining-requests, x-ratelimit-reset-requests and the token-denominated equivalents x-ratelimit-limit-tokens, x-ratelimit-remaining-tokens and x-ratelimit-reset-tokens, plus Retry-After on a 429, per the rate limits guide linked above. One request with headers dumped tells you the truth for your account, your project and that model.

Then keep reading them. Export the remaining-tokens header as a metric and alert when the minimum over a five-minute window drops below a fraction of the limit; that alert fires before the 429s, which is the only useful time for it to fire. The general mechanics of these headers, and what a 429 means underneath, are covered in how rate limits work, and the leaving-a-free-tier version of this problem is in moving off a free tier at scale.