Check whether an AI vendor can actually serve you

You chose your model the way most people do. You ran it on a few tasks you actually care about, compared the answers, looked at the price per million tokens, and moved on. Six weeks later, the thing that goes wrong is not quality. It is an error code at 9am on a Tuesday, or a model name that suddenly stops resolving, or a client asking why the weekly summary never arrived. Nothing you compared during selection said anything about any of that.

The awkward part is that none of it was hidden. Every serious vendor publishes its availability, in four separate places that almost nobody reads together: the rate limit table, the service tier page, the status history, and the deprecation policy. Between them they tell you what you can send, what happens when the vendor is busy, how often it has been broken lately, and how much warning you get before the model you built on disappears. Reading all four takes about fifteen minutes and tells you more about whether you can run a business process on a vendor than any benchmark will. This guide is for a solo operator or small team calling an API directly, or through a tool you configure yourself. If you have a negotiated enterprise contract with committed capacity, your availability is defined in that contract and you should be reading the contract instead.

Your ceiling is set by what you have spent, not by the model you picked

The model is the same for everyone. Your access to it is not. Every major vendor gates throughput behind a tier, and your tier is a function of money and elapsed time.

Anthropic places organizations on a tier automatically “based on usage history and account standing” and moves them up over time [1]. At the Start tier, most Claude models allow 1,000 requests per minute, 2,000,000 input tokens per minute and 400,000 output tokens per minute, against a monthly spend cap of $500 [1]. Build raises the cap to $1,000, Scale to $200,000, and Custom removes it [1]. There is a floor below the floor, too: new organizations “may start in the Evaluation tier, with limits below the standard limits shown on this page while account history is established” [1].

Google’s Gemini API uses the same shape with the time gates made explicit. Tier 1 needs an active linked billing account and carries a $250 billing cap. Tier 2 needs “Paid $100 + 3 days from first successful payment” and raises the cap to $2,000. Tier 3 needs “Paid $1,000 + 30 days from first successful payment” [6]. Alongside the per-minute limits there is a spend guard on a rolling 10-minute window, at $10, $50 and $200 for tiers 1, 2 and 3, and crossing it returns a 429 [6].

Moonshot’s Kimi platform is the clearest illustration of why this matters, because its bottom tier is so low. A $1 top-up puts you on Tier0, which allows a concurrency of 1, 3 requests per minute, 500,000 tokens per minute and 1,500,000 tokens per day [7]. Tier1 at $10 jumps to 15 concurrent requests and 100 RPM; Tier5, at $3,000 cumulative, reaches 100 concurrent and 300 RPM [7]. Three requests per minute is enough to convince yourself a model is good. It is not enough to run anything.

That gap is the trap. You evaluate on a trial account, the model performs, you commit, and then discover that the throughput you need sits two tiers and thirty days away. Before you pick, find your tier’s numbers, find the next tier’s requirements, and check whether the requirement is money you can spend today or time you have to wait out.

The default tier is best-effort, and the vendors say so in writing

There is a widespread assumption that paying for an API buys you a claim on capacity. Read the service tier pages and you will find the opposite stated plainly.

Anthropic describes its standard tier, the default for all API requests, this way: “The API prioritizes these requests alongside all other requests with best-effort availability” [2]. The tier that behaved differently was Priority Tier, which “prioritizes requests in this tier over all other requests” to minimise “server overloaded” errors “even during peak times”, and which “targets 99.5% uptime with prioritized computational resources” [2]. That tier is now closed: “Priority Tier capacity commitments are no longer available for purchase”, with existing commitments running to their contract end date and guaranteed capacity handled through sales [2].

Google is blunter still. The Gemini rate limits page carries the sentence “Specified rate limits are not guaranteed and actual capacity may vary” [6]. The table you planned around is a description of intent, not a floor.

Moonshot puts the same idea in the operational voice. Its rate limit documentation reserves the right to “take temporary measures to adjust the rate limits” when cluster capacity reaches its limit [7]. So the number in the table is the number you get when the vendor has room.

None of this is a scandal. It is how metered shared infrastructure has always worked, and pausing or throttling is a more responsible response to a demand spike than degrading everyone quietly. But it does mean the correct mental model is a utility with weather, not a contract with a floor. If your process cannot tolerate a bad afternoon, the tolerance has to live in your design, because it does not live in the vendor’s documentation.

The status page is a 90-day record, and the record is the useful part

Most people look at a status page once, see a green banner, and conclude the vendor is fine. The banner is the least informative thing on the page. Scroll past it to the history.

Today, status.claude.com reports “All Systems Operational” [4]. Underneath, the 90-day uptime figures are 99.4% for claude.ai, 99.93% for the Console, 99.5% for the API, 99.44% for Claude Code, 99.43% for Claude Cowork and 100% for Claude for Government [4]. The incident log for the same week lists “Elevated errors for multiple models” affecting Opus 4.8, Opus 5 and the Fable and Mythos versions on September 3, 2026, resolved at 16:23 UTC; “Elevated errors for Claude Sonnet 5” on September 2 running 21:05 to 21:19 UTC; “Delays in credit purchases” the same day; and degraded performance on claude.ai and Claude Code on August 31 [4].

That is a well-run API belonging to a large vendor, and it still had four bad days in a week. 99.5% over 90 days works out to roughly 10.8 hours unavailable. Nobody who depends on that API has been ruined by it, because most of those hours landed on people who retried and forgot. If you are running a job that only fires once, at a fixed time, with a human waiting downstream, those same hours land very differently.

Two details in that list are worth generalising. The first is that the surface matters: Claude Code sat at 99.44% against the raw API’s 99.5% [4], and every product layer you add sits on top of the layer below it and can only be less reliable. The second is that “Delays in credit purchases” is a billing incident, not a model incident, and a billing failure locks you out just as effectively as a capacity failure does. When you read a status history, count everything that stopped you working, not only the entries with a model name in them.

The retirement notice is the number that sets your switching cost

Capacity problems are loud and temporary. Retirement is quiet and permanent, and it is the one that actually forces work onto your calendar. The question to ask about any vendor is how many days of warning it promises before a model you depend on stops answering.

Anthropic publishes a figure: it notifies customers with active deployments and provides “at least 60 days’ notice before model retirement for publicly released models” [3]. It also publishes the vocabulary, so you can tell how much runway a model has. Active means fully supported, Legacy means no more updates, Deprecated means still working but with a replacement and a retirement date assigned, and Retired means “Requests to retired models will fail” [3]. The table gives dates in both directions: claude-opus-4-1-20250805 retired on August 5, 2026, claude-sonnet-4-20250514 and claude-opus-4-20250514 on June 15, 2026, while claude-sonnet-5 is listed as retiring not sooner than June 30, 2027 and claude-fable-5-1 not sooner than September 1, 2027 [3].

OpenAI publishes a longer figure with more gradations: “Unless safety or compliance concerns require a faster timeline, we provide the following minimum notice periods before model retirement: Generally available models: At least 6 months”, with specialised model variants at 3 months and preview models retirable with as little as 2 weeks [5]. Its own schedule shows what that looks like in practice, with Sora 2 and the Videos API shutting down on September 24, 2026, gpt-3.5-turbo-0125 and gpt-4-0613 on October 23, 2026, and the gpt-5-2025-08-07 and o3-2025-04-16 snapshots on December 11, 2026 [5].

Then there is the version where you find out on the day. Moonshot’s platform changelog entry for August 31, 2026 records that “the kimi-k2.5 and all moonshot-v1 series models” were “retired across all platforms at 16:00 today”, with users required to migrate to Kimi K3 [8]. Whatever notice preceded it, the changelog is where a developer would have gone looking, and what it contains is a retirement in the past tense.

So look for the sentence. Anthropic prints 60 days [3]. OpenAI prints 6 months [5]. If you cannot find an equivalent sentence anywhere on a vendor’s site, treat that absence as the answer and size your dependency accordingly. Two habits follow from this. Pin the dated model version rather than a floating alias, so that changes arrive when you choose rather than overnight. And on the day you adopt a model, put its published retirement date in your calendar with a reminder 90 days before, because that is the meeting where you decide what replaces it.

Rehearse the refusal that has no retry

When people plan for vendor failure they picture an outage: the API is down, requests fail, the API comes back, everything catches up. That failure mode mostly takes care of itself, because official SDKs retry transient errors with backoff. The failures worth rehearsing are the ones where retrying is exactly the wrong thing to do.

The first is bursting. Anthropic notes that a limit stated per minute may be enforced far more finely, so “a rate of 60 requests per minute (RPM) might be enforced as 1 request per second”, and short bursts can exceed the limit and trigger errors even when your minute-level average is well inside it [1]. A batch job that fires 40 requests in two seconds will fail against a limit it never actually breached.

The second is the spend cap, which is a 429 that no amount of patience fixes. Anthropic’s documentation shows the error text naming the exact moment access returns, and states that once you reach your tier’s spend cap “API usage pauses until 00:00 UTC on the first day of the next month, unless you request a higher limit sooner” [1]. That error has no useful retry window attached. If your system treats every 429 the same way, it will sit in a retry loop for the rest of the month.

The third is account-level enforcement. Moonshot’s rate limit page describes a risk control policy triggered by abnormal activity on an account, and adds the sentence worth pinning above your desk: “Once triggered, the restriction cannot be lifted.” [7]

The practical response is small. Distinguish the retryable 429 from the terminal one in whatever code or automation you run, so the terminal one produces an alert to a human rather than a queue. Keep a working key with a second vendor, and send a real request through it at least monthly, because a fallback you have never executed is a plan, not a fallback. And ramp new workloads gradually rather than switching a large job over in one step, since consistent usage patterns are what move you up a tier in the first place [1].

What still goes wrong

Uptime percentages are the vendor’s own measurement against the vendor’s own definition of operational, published by the vendor. A component that is slow but answering often never trips, so a green 99.5% and an afternoon where everything took 40 seconds can be the same afternoon. Read the incident titles rather than trusting the percentage, and keep your own rough log of the days work did not happen. Yours is the only measurement calibrated to your workload.

A second vendor is not a free hedge. Prompts that were tuned on one model rarely land identically on another, output formats drift, tool-calling conventions differ, and the tier problem from the first section applies to the backup too, which means your fallback probably sits on an untested account with a low ceiling. Budget real time for keeping it warm, or be honest that you have a manual fallback in which you do the work yourself for a day.

None of this predicts the genuinely novel failure. A policy change that puts your use case out of bounds, a regional restriction, a suspended account, an acquisition, or a price move large enough to end the business case will not show up in a rate limit table or a status history. Reading those four pages lowers your surprise rate, it does not take it to zero. And if you have a negotiated contract with committed capacity, everything here is background reading, because your actual availability is whatever your contract says it is.