GLM-5.2 vs Kimi K3 API Supply: What Is Available?
Independent research — not an official Z.ai publication.Identity and provider disclosure
Evidence checked July 20, 2026, Asia/Hong_Kong. This page distinguishes first-party facts from our inferences and shows the test scope behind each availability claim.
The useful GLM-5.2 vs Kimi K3 API availability question is not “which landing page loads?” It is whether a new buyer can open the right account, receive enough quota, complete inference requests at the planned concurrency, and recover when one route becomes constrained.
That distinction matters during a high-demand launch. A vendor can pause a subscription product while an API stays online. A status page can stay green while one model or account tier hits a capacity ceiling. A documented model can return rate limits under a burst. Treat supply as a stack of evidence, not one binary label.
GLM52.ai did not use paid credentials or run an authenticated availability benchmark for this review. We therefore do not publish a measured uptime, latency, or success-rate winner.
In this availability guide
Section titled “In this availability guide”- Current status at a glance
- What the Kimi subscription pause means
- What the official API evidence proves
- How to read 429 and 503 errors
- Why agent availability compounds
- Fallback depth: hosted routes and weights
- A five-level availability test
- Deployment recommendations
- Common questions
- Sources and method
Current status at a glance
Section titled “Current status at a glance”The table describes what first-party pages showed at the check time. “Listed” means documented, not capacity reserved for a new account.
| Availability layer | GLM-5.2 | Kimi K3 | What it proves |
|---|---|---|---|
| Official direct API model | Z.ai documents glm-5.2 |
Kimi documents kimi-k3 |
A supported request route exists in vendor docs |
| Public service status | No comparable component page found in our check | Moonshot showed API Service and Open API operational | Public components reported healthy; not a K3 account test |
| Public capacity notice | No matching new-subscription pause found | New subscriptions temporarily paused because demand approached capacity | Kimi has pressure at the subscription intake layer |
| Rate-limit visibility | Account page after login; public error codes | User-level concurrency, RPM, TPM, and TPD rules | Your actual ceiling depends on account allocation |
| Overload signal | Error code 1305 may mean temporary overload | 429 engine_overloaded_error; 503 for temporary unavailability |
Both stacks anticipate capacity-related failure modes |
| Downloadable weights now | Yes, MIT checkpoint | Promised for July 27 | GLM has a self-operated escape path today |
| GLM52.ai authenticated test | Not run | Not run | No measured model success or latency comparison |
Our unauthenticated probe at 2026-07-20T08:03:42+08:00 received HTTP 401 from both chat-completion endpoints: Z.ai in 0.770 seconds and Moonshot in 0.798 seconds. That confirms the authentication edges answered. It says nothing about model allocation or inference reliability after login.
The honest headline is narrow: Kimi shows clearer first-party evidence of launch demand pressure, while GLM offers more fallback depth. Both official API products remain documented.
What the Kimi subscription pause means
Section titled “What the Kimi subscription pause means”Moonshot’s official Kimi account said demand had pushed close to its present capacity. It temporarily paused new subscriptions, kept existing subscribers unaffected, and said capacity additions would let places reopen in batches.
Three words control the interpretation: new subscriptions paused. The statement does not say the API was shut down. It does not give a K3 API success rate, regional latency, or a guaranteed quota for a newly funded developer account. Converting the notice into “Kimi K3 API unavailable” would overstate the source.
The notice does reveal a real supply constraint. Subscription admission is one way a provider protects service quality when compute demand approaches available capacity. Buyers should expect onboarding gates, changing allocation, or burst sensitivity until the vendor says capacity has expanded.
Moonshot’s public status page showed “All Systems Operational” during our check. It displayed API Service and Open API as operational, with 100.0% 90-day uptime on the visible components. The page did not expose a separate K3 component. A green aggregate component and a subscription pause can both be true because they measure different layers.
Use this wording in an internal launch decision:
Moonshot has acknowledged subscription-side capacity pressure. The public API components were operational at check time, but the team must verify K3 allocation and sustained throughput in its own account.
What the official API evidence proves
Section titled “What the official API evidence proves”Z.ai’s GLM-5.2 model guide supplies the glm-5.2 model ID, an OpenAI-compatible request example, and a 1,048,576-token context window. The page supports a claim that an official API product exists. It cannot support a claim that every account can send the planned tokens per minute.
Kimi’s API introduction lists kimi-k3 and the same 1,048,576-token context size. Its K3 price page remains published. Those pages support the same limited conclusion: K3 is an offered API model. They do not cancel the subscription-capacity warning.
Neither vendor posts a public model-specific supply inventory such as available GPUs, reserved tokens per minute, queue depth by region, or allocation lead time. Z.ai sends users to an authenticated rate-limit view. Moonshot explains limit classes in public docs, but the assigned ceilings remain account-level facts.
This creates four common but invalid shortcuts:
- a model in documentation does not prove new-account admission;
- HTTP 200 on documentation does not prove successful inference;
- HTTP 401 from an API edge does not prove model capacity;
- a green service component does not promise workload-shaped throughput.
The inverse shortcuts fail too. One 429 does not prove a provider-wide shortage, and one 503 does not prove a model has disappeared. Read the vendor error body, headers, account console, incident page, and request pattern together.
How to read 429 and 503 errors
Section titled “How to read 429 and 503 errors”Rate limits and overloads need different responses.
Z.ai’s API error-code reference identifies code 1302 as a rate-limit condition, 1305 as a service that may be temporarily overloaded, and 1308 as an account or usage cap. A client should preserve the response body instead of reducing all non-200 responses to “429.”
Kimi’s error guide describes account quota, organization concurrency, requests per minute, tokens per minute, and tokens per day. It includes 429 engine_overloaded_error. A 503 means temporary service unavailability, often tied to scaling or maintenance. These classes call for separate actions:
| Signal | First response | Escalate when |
|---|---|---|
| Account balance or quota | Check funding, entitlement, and daily allocation | The console and API disagree |
| RPM or TPM limit | Queue requests; lower the burst; request a larger tier | Planned steady-state demand exceeds the ceiling |
| Concurrency limit | Bound workers and release slots after each response | Long requests occupy the whole pool |
| Engine overload | Add jittered exponential backoff and a retry budget | Errors persist outside a short burst |
| 503 service unavailable | Stop aggressive retries; consult status/support; route safe traffic | The incident breaches the product objective |
| Authentication error | Fix credentials, organization, endpoint, and model access | A known-good credential keeps failing |
Kimi’s benchmark guidance recommends streaming, a low starting concurrency, and retries for overload, rate limits, and network errors. Treat that as provider operating guidance, not proof of the success rate your application will see.
Store provider, model, region, account tier, status code, vendor error code, retry count, queue time, time to first token, completion time, and token counts. Without those fields, “the API was slow” cannot guide capacity planning.
Why agent availability compounds
Section titled “Why agent availability compounds”A chat demo can succeed with one call. An agent may need planning, search, tool output repair, code generation, test analysis, and a final answer. Each required call creates another failure opportunity.
Under a simplifying assumption that calls fail independently, a workflow needing N successful calls with per-call success probability p has this clean-run probability before application retries:
P(all N calls succeed) = p^NFor a 20-call agent:
| Per-call success | Probability all 20 calls succeed |
|---|---|
| 99.5% | 90.5% |
| 99.0% | 81.8% |
| 98.0% | 66.8% |
| 95.0% | 35.8% |
The table does not predict either model. It explains why a small per-call gap can become a large workflow gap. The independence assumption is a teaching aid; correlated incidents make failures cluster, while retries can recover transient faults at the cost of latency and tokens.
Define two objectives rather than one:
availability SLO = accepted workflows / started workflowslatency SLO = accepted workflows completed inside the deadline / started workflowsA retry that saves a workflow after ten minutes may satisfy the first objective and fail the second. Measure the full task, not just endpoint uptime.
Fallback depth: hosted routes and weights
Section titled “Fallback depth: hosted routes and weights”GLM-5.2 has more distinct fallback paths as of July 20. Z.ai operates the direct API. The official GLM-5.2 model card provides a downloadable MIT checkpoint. That checkpoint demands server-class infrastructure, but it lets a capable team operate outside one API allocation.
Our GLM-5.2 API provider guide compares route-level tradeoffs. Teams considering weights should read the local hardware guide before calling self-hosting an emergency switch. A cold multi-node deployment is not an instant failover.
Kimi’s K3 launch post identifies the direct kimi-k3 API and says full weights should arrive by July 27. That date had not arrived at our check time. Moonshot also says it is working with inference partners, but a future or unnamed route cannot count as a tested production fallback today.
Fallback depth is not provider count. Two providers may share a cloud region, upstream model service, or deployment artifact. Ask whether credentials, billing, capacity, network, and inference stacks fail independently. Keep a portable request adapter and a reduced-capability fallback mode.
A five-level availability test
Section titled “A five-level availability test”Move through these evidence levels in order. Stop treating the lower level as proof once the launch depends on the next one.
1. Product listing
Section titled “1. Product listing”Confirm the exact model ID, endpoint, input types, context, region, and commercial terms on a first-party page. Save the access date. This catches stale model names and gateway limits.
2. Service status
Section titled “2. Service status”Check a public status page when one exists. Record the component name and whether it maps to the model. Absence of an incident means no disclosed incident, not a guarantee.
3. Account permission and quota
Section titled “3. Account permission and quota”Log in to the production organization. Confirm the model appears, funding works, and concurrency/RPM/TPM/TPD allocations cover the forecast. Ask support for written capacity guidance when the launch matters.
4. Authenticated smoke test
Section titled “4. Authenticated smoke test”Send a small streaming request through the production network and credential path. Validate output, usage fields, first-token time, finish reason, and error logging. Repeat from each deployment region.
5. Workload-shaped load test
Section titled “5. Workload-shaped load test”Replay a safe sample with the expected prompt sizes, output lengths, tool loops, concurrency ramp, and daily volume. Measure accepted-workflow rate, queue time, retry amplification, tail latency, and cost. Hold a steady plateau instead of sending one spike.
Do not load-test a third-party service beyond your contract or published rules. Coordinate a large test with the vendor. The goal is capacity evidence, not an accidental denial of service.
Deployment recommendations
Section titled “Deployment recommendations”If you need Kimi K3
Section titled “If you need Kimi K3”Keep K3 in the candidate set for visual and hard agent work; the broader GLM-5.2 vs Kimi K3 model comparison covers capability and price. For supply, confirm whether your account type is affected by the subscription pause, inspect its assigned limits, and run a low-concurrency authenticated test. Add bounded retries and a queue before raising workers.
Do not promise launch capacity from the aggregate status page. Obtain account-specific evidence and define a degraded path for tasks that can wait or use a smaller model.
If you need GLM-5.2
Section titled “If you need GLM-5.2”Check the authenticated Z.ai rate-limit view and record overload codes separately from quota codes. Use prompt caching to reduce repeated input work, but do not count cache savings as extra quota until telemetry confirms them.
Qualify a distinct hosted route if vendor concentration matters. Self-host only when the hardware, model files, serving stack, security controls, and on-call ownership already exist.
If you need both
Section titled “If you need both”Use a provider-neutral task envelope and a fresh conversation when switching models. Define which workloads may fail over, which must wait, and which require a person. Preserve vendor-specific reasoning histories and tool contracts; a blind mid-session model swap can corrupt the task.
Make the routing decision from accepted workflows, tail latency, and total cost. Supply pressure changes. A permanent architecture built from one launch-week notice will age poorly.
Common questions
Section titled “Common questions”Is the Kimi K3 API unavailable?
Section titled “Is the Kimi K3 API unavailable?”The first-party evidence does not support that blanket claim. Moonshot paused new subscriptions because demand approached capacity. Kimi K3 remains in official API documentation, and Moonshot’s public API components were operational when checked. Your account allocation and workload need a separate test.
Does GLM-5.2 have unlimited official API capacity?
Section titled “Does GLM-5.2 have unlimited official API capacity?”No. Z.ai documents rate-limit, account-cap, and temporary-overload error codes. We found no matching subscription-pause notice, but an absent notice is not unlimited supply. Check the limits assigned to your organization.
Does HTTP 429 prove a model shortage?
Section titled “Does HTTP 429 prove a model shortage?”No. A 429 can represent account quota, concurrency, RPM, TPM, TPD, or engine overload. Preserve and interpret the vendor error code and account state before assigning a cause.
Which model has better fallback availability?
Section titled “Which model has better fallback availability?”GLM-5.2 has the stronger documented fallback position today: official API, downloadable MIT weights, and a separate third-party hosted route. K3’s direct API exists, while its weights were promised for July 27. A route becomes a fallback only after your team tests and funds it.
Can a public status page replace a load test?
Section titled “Can a public status page replace a load test?”No. A status page reports vendor-selected components. It cannot know your account tier, region, prompt length, concurrency, retry policy, or workflow deadline.
Sources and method
Section titled “Sources and method”Primary sources checked July 20, 2026:
- Kimi capacity statement — new-subscription pause, existing-subscriber scope, and capacity expansion.
- Moonshot service status — public API Service and Open API component state at check time.
- Kimi API introduction and K3 pricing — model listing, context, and direct API offer.
- Kimi API errors and benchmark guidance — limit classes, overloads, temporary unavailability, streaming, and retry guidance.
- Kimi K3 launch post — direct model ID, weight schedule, and inference-partner statement.
- GLM-5.2 API guide, Z.ai error codes, and Z.ai FAQ — model route, overload semantics, and account limit location.
- GLM-5.2 model card — downloadable checkpoint and MIT license.
- Novita GLM-5.2 listing — distinct third-party serverless route.
We searched the exact comparison and close availability/capacity variants on July 20. No keyword-volume source was available. We used vendor pages for product facts and kept our recommendation separate. The unauthenticated probe tested edge reachability only. Recheck the Kimi subscription notice, K3 weight release, each account’s limits, and both vendors’ status before a production decision.