ZenMux API access is sold on a promise that almost nobody else in the model-gateway business is making out loud: when the model gives you a bad answer, you get money back. Not a support ticket. Not a goodwill gesture you have to argue for. An automatic credit, detected daily and paid the next day, for outputs the platform’s own monitoring flags as unsatisfactory. That single mechanism is why a gateway most UK development teams have never heard of is worth an hour of anyone’s attention.
The rest of the product is more familiar territory. ZenMux is a unified gateway that puts a large language model catalogue from OpenAI, Anthropic, Google, DeepSeek, xAI, Moonshot, MiniMax, Baidu and others behind one account and one key. The ZenMux API speaks four protocols, three of which are lifted straight from the vendors themselves, so the switching cost from a direct integration is two lines of configuration.
It also routes across multiple providers for the same model, falls back automatically when one of them breaks, and publishes a per-channel benchmark of the whole catalogue on GitHub. If you have read our coverage of the Stripe and OpenRouter gateway deal, you already know why this category matters commercially — and why a differentiator like the ZenMux API insurance mechanism is worth taking seriously rather than dismissing as marketing.
What follows is a working read of the ZenMux API built entirely from the vendor’s own documentation, checked page by page on 5 September 2026: what the endpoints actually do, exactly how the hallucination credits work, what the documentation does not tell you about them, and where the whole thing sits against a direct provider integration. Where a claim is a marketing claim rather than a documented mechanic, this article says so.
Table of contents
- What the ZenMux API Actually Is
- ZenMux API OpenAI Compatibility, Endpoint by Endpoint
- Credits for Hallucinations: How the ZenMux API Insurance Works
- What the ZenMux API Insurance Does Not Cover
- ZenMux API Routing: Models, Providers and Fallbacks
- ZenMux API Pricing: Pay As You Go Versus the Builder Plan
- Billing Transparency and the Cost Fields the ZenMux API Returns
- The ZenMux Benchmark and Why Channel-Level Testing Matters
- What the ZenMux API Insurance Changes About Buying LLM Capacity
- Should You Route Production Through the ZenMux API?
- Frequently Asked Questions About the ZenMux API
- The Practical Read on the ZenMux API
- References and Further Reading
What the ZenMux API Actually Is
ZenMux describes itself on its homepage as a “Unified API for 100+ AI Models” and, in its own platform overview documentation, as “the world’s first enterprise-grade large model aggregation platform with an insurance payout mechanism.” Both halves of that sentence matter, and the second half is the differentiator.
One gateway, four protocols
Most aggregation layers give you one dialect and expect you to adapt. The ZenMux API gives you four: OpenAI Chat Completions, OpenAI Responses, Anthropic Messages, and Google Gemini. Each is served on its own base path, each works with the vendor’s own SDK, and — this is the part that is genuinely unusual — any of them can call any model in the catalogue. The documentation calls this protocol agnosticism, and gives the example of using the OpenAI SDK to call Claude models, or the Anthropic SDK to call Gemini.
Who runs it, and since when
The platform is operated by NexaMind Singapore Pte. Ltd., whose copyright line sits in the footer of every page on the site. ZenMux publishes a public analytics dashboard covering platform data back to its launch on 29 September 2025, including total tokens processed and — unusually — the total insurance compensation amount paid out in US dollars. Very few infrastructure vendors publish the size of their own service-failure bill.
How many models the ZenMux API reaches
The headline number is “100+”. The model sitemap tells a fuller story: on 5 September 2026 it listed 271 individual model pages. Models come from official providers or authorised cloud partners — the homepage is explicit that there are “no proxies, no degraded copies” — and most popular models are integrated through more than one provider channel at once, which is what makes the failover behaviour possible.
What sits underneath the requests
ZenMux API requests are served through Cloudflare’s global edge network, and ZenMux maintains multiple provider channels plus reserve capacity for each model. The stated behaviour when a provider hits its rate limits, fails, or becomes unavailable in a region is an automatic switch to a backup channel. For teams already thinking about resilience in their AI strategy, that is the pitch: one integration, several suppliers behind it.
ZenMux API OpenAI Compatibility, Endpoint by Endpoint
The OpenAI compatibility story is the easiest part of the ZenMux API to evaluate, because it is either true or it is not, and it takes about ninety seconds to test.
The base URL and the two-line switch
The OpenAI-compatible endpoint is https://zenmux.ai/api/v1. The documentation’s own words are that the endpoint “is fully compatible with the OpenAI Chat Completions API” and that you “just change base_url and api_key to switch seamlessly.” In the Python SDK that is exactly two lines inside the client constructor:
client = OpenAI(
    base_url=”https://zenmux.ai/api/v1″,
    api_key=”<your ZENMUX_API_KEY>”,
)
completion = client.chat.completions.create(
    model=”google/gemini-3.1-pro-preview”,
    messages=[{“role”: “user”, “content”: “What is the meaning of life?”}],
)
Nothing else in your call site changes, which is the whole ZenMux API compatibility claim in one sentence. The same base URL also accepts a raw cURL request against /chat/completions with a bearer token, which is the quickest way to prove the ZenMux API works before touching application code.
Chat Completions and Responses share one base URL
ZenMux also supports OpenAI’s newer Responses API, and it lives on the same https://zenmux.ai/api/v1 base URL as Chat Completions. In practice that means client.responses.create(model=..., input=...) works against the ZenMux API without a second endpoint or a second client. Teams part-way through migrating from Chat Completions to Responses do not have to finish that migration before switching gateway.
The other two protocols
Anthropic Messages is served at https://zenmux.ai/api/anthropic and works with the Anthropic SDK. Google Gemini is served at https://zenmux.ai/api/vertex-ai and works with the Google GenAI SDK. Both sit alongside the OpenAI routes on the same ZenMux API key. There is also a ZenMux-native video generation endpoint documented separately, plus OpenAI-shaped routes for embeddings, image generation and editing, audio speech and transcription, and reranking.
| Protocol | Base URL | SDK | Best for |
|---|---|---|---|
| OpenAI Chat Completions | zenmux.ai/api/v1 | OpenAI SDK | Existing OpenAI integrations |
| OpenAI Responses | zenmux.ai/api/v1 | OpenAI SDK | Newer agent-shaped calls |
| Anthropic Messages | zenmux.ai/api/anthropic | Anthropic SDK | Claude-native tooling |
| Google Gemini | zenmux.ai/api/vertex-ai | Google GenAI SDK | Gemini-native tooling |
Model slugs are provider-scoped
Every model on the platform carries a unique slug in provider/model-name form — anthropic/claude-sonnet-4, google/gemini-3.1-pro-preview, and so on. That is the one string in your codebase that genuinely changes when you adopt the ZenMux API, and it is also the string that makes swapping models a config edit rather than a rewrite.
The compatibility caveat worth stating
Protocol compatibility is not capability parity. A model reached through the OpenAI protocol still only supports the features that model actually has, and vendor-specific extras generally arrive through extra_body rather than first-class SDK parameters. The ZenMux API removes the integration work; it does not homogenise what the models can do.
Credits for Hallucinations: How the ZenMux API Insurance Works
This is the feature nobody else in the category leads with, and it is the reason the ZenMux API deserves a proper read rather than a skim.
What is actually underwritten
The platform overview is direct about the scope: “We underwrite scenarios such as poor performance, hallucinations, and excessive latency during LLM usage. Through daily automated detection and payouts, we provide a quality backstop for your AI applications.” The homepage restates it in blunter marketing language — “Built-In Insurance: Get Paid When AI Disappoints” — and adds low throughput to the list of triggers.
Detection runs daily, payouts land next day
There is no claim to file with the ZenMux API. The stated model is automated daily detection with next-day payouts, which means the ZenMux API is monitoring your traffic for failures on your behalf rather than waiting for you to notice one and complain. That is a meaningfully different operating posture from every other gateway in the market, where a bad generation is your problem and your cost.
What the compensation record shows you
The ZenMux API console carries a dedicated Insurance Compensation page. At the top sit four aggregate metrics: Total Compensation, Compensation Count, Average Per Compensation, and Average Compensation / Day. Below that, the data can be viewed by credits or by number of events, and broken down two ways — by compensation type and by model. The second breakdown is the interesting one: it tells you which models are costing the platform money on your workload, which is a proxy for which models are failing you.
| Field in the compensation record | What it tells you |
|---|---|
| Timestamp | When the request ran, to the millisecond |
| Model | The model slug invoked |
| Input / Output Tokens | Request complexity and response length |
| Cost | Actual cost of the request, including the compensated portion |
| Latency | Processing time in milliseconds |
| Throughput | Tokens processed per second |
| Finish | Completion status — stop, length, error |
| Payout | The compensation actually paid for that request |
Two named compensation categories
The detail table splits records into two tabs: Unsatisfactory Content, described as compensation triggered by substandard generated content quality, and High Latency, triggered by excessive response time. Note the gap against the marketing copy — low throughput appears on the homepage as a trigger and appears in the record as a data column, but it does not appear as its own compensation category in the documented interface. That is the sort of detail worth confirming with the vendor before you build a business case on it.
Where the credits land in your balance
Compensation does not come back as cash. The Pay As You Go balance is split into three buckets: Total Balance, Top-Up Credits, and Bonus & Compensation Credits — the last of which explicitly includes insurance compensation alongside top-up bonuses and referral rewards. Credits are denominated in US dollars, where one credit equals one dollar of API usage, and consumption draws down bonus credits first, then top-up credits. In cash-flow terms the payout is a discount on future usage, not a refund.
What the ZenMux API Insurance Does Not Cover
Two entirely different mechanisms on this platform get called “getting money back”, and confusing them is the easiest mistake to make when evaluating the ZenMux API.
Insurance is not the refund policy
The refund policy is about unsatisfied purchases, not unsatisfactory outputs. It gives you a 24-hour window after a top-up or a subscription to recover money you have not spent, and it is processed through the original payment method. The insurance mechanism is about the quality of individual API responses and pays into your credit balance. They share no thresholds, no window and no process.
The 5% platform service fee
Refunds are not made whole. The terms state that “a platform service fees equal to 5% of the refundable amount will be deducted,” and both refund formulas apply it: pay-as-you-go refunds are the unused paid credits × (1 − 5%), and subscription refunds are (subscription fee − consumption fee) × (1 − 5%). Self-service refunds settle in one to three business days; requests raised by email take up to seven business days to review plus three to ten banking days to land.
Compensation credits are forfeited on a refund
Here is the sting in the tail, and it is the single most important line in the refund documentation for anyone weighing up the ZenMux API insurance. Bonus credits are non-refundable and are forfeited upon approval of a refund. Since insurance payouts land in the same Bonus & Compensation bucket, taking a cash refund on your unused top-up wipes out the compensation you have accrued. The two mechanisms are not just separate — they are mutually exclusive at the point you use them.
What the documentation does not publish
Read the insurance pages carefully and you will notice what is absent: there is no published latency threshold, no throughput floor, no stated method for deciding that generated content is substandard, and no payout formula. The dashboard shows you what was paid; nothing in the public documentation lets you predict it in advance or audit it afterwards. Treat the insurance as a genuine goodwill mechanism with real money behind it, not as a contractual service credit you could model in a spreadsheet.
| Dimension | LLM insurance payout | Purchase refund |
|---|---|---|
| Triggered by | Unsatisfactory content, high latency | Buyer’s remorse within 24 hours |
| You receive | Platform credits | Money to your original payment method |
| Who initiates | The platform, automatically | You, through the console or email |
| Timing | Daily detection, next-day payout | 1–3 business days, or up to 17 by email |
| Deduction | None stated | 5% platform service fee |
| Interaction | Taking a refund forfeits accrued compensation credits | |
ZenMux API Routing: Models, Providers and Fallbacks
Three separate routing mechanisms ship with the ZenMux API, and they operate at different layers. Getting them straight is most of the value of reading the documentation.
Model routing picks which model runs
Set model to zenmux/auto and supply a model_routing_config block with an available_models list and a preference such as balanced, and the platform selects the model for each request based on prompt content and task characteristics. Omit available_models and it selects from the platform’s entire pool — powerful, and probably not what you want in production. The response returns the model that actually ran, so the decision is auditable per call.
Provider routing picks which supplier serves it
For a given model, the default strategy is documented as three rules: prefer the model’s original developer, fail over automatically if that channel is unavailable, and order the remaining providers by first-token latency, lowest first. You can override this with a provider_routing_strategy block of type specified_providers and an ordered list of provider slugs — anthropic/anthropic_endpoint, google-vertex/VertexAIAnthropic, amazon-bedrock/BedrockAnthropic and so on. The gateway then tries them in order and stops at the first success. Name only one provider and you have pinned it, errors included.
Fallback catches everything else
Separately again, a provider.fallback parameter names a different model to run if the primary model or the routing strategy fails outright. It can be set per request, or configured once in the console as a global Default Fallback Model that every request inherits, with the per-request value taking priority. Combined with intelligent routing, the fallback fires only when every candidate model the router selected has failed.
Why three layers, not one
Each layer answers a different question: which model is right for this prompt, which supplier should serve that model right now, and what should happen when both of those answers turn out to be wrong. Teams running autonomous AI agents in production will recognise the pattern — it is the same defence-in-depth logic as a retry budget layered over a circuit breaker.
ZenMux API Pricing: Pay As You Go Versus the Builder Plan
The commercial model splits cleanly in two, and the split is enforced by policy rather than merely recommended.
Pay As You Go is the production plan
Pay As You Go is a prepaid balance drawn down by token-level billing. The documented characteristics are no rate limit, no concurrency limit, production-grade stability with SLA coverage plus the AI insurance mechanism, and enterprise reporting — full request logs, cost analytics and billing statistics. Top-ups run from $5 to $25,000 through Stripe, Alipay and others, and credits apply immediately.
The Builder Plan is for everything that is not production
The Builder Plan is a fixed monthly fee in four tiers, and the documentation is unambiguous that it “must not be used in production,” with violations potentially affecting your account. Rate limits sit at 10–15 requests per minute and a weekly concurrency cap applies. The Free tier does not include API access at all — it is Studio Chat on the web only.
| Plan | Monthly fee | 5-hour quota | Model coverage | API access |
|---|---|---|---|---|
| Free | $0 | 5 Flows | Basic models | No — Studio Chat only |
| Starter | $20 | 50 Flows | Basic + rotating premium | Yes |
| Max | $100 | 300 Flows | Basic + premium | Yes |
| Ultra | $200 | 800 Flows | All models | Yes |
| Pay As You Go | Usage | Unlimited | All models | Yes — the only production option |
What a Flow is, and what it is not
A Flow is ZenMux’s composite billing unit for subscriptions, accounting for both token consumption and API call overhead. It is not a request and it is not a token, which makes cross-shopping the Builder Plan against per-token pricing genuinely hard. The quota resets on a rolling five-hour window, and paid tiers get a number of bonus window resets each month — four on Starter, three on Max, two on Ultra.
The tiers get cheaper per unit as they get bigger
Dividing each monthly fee by its five-hour Flow allowance gives the unit economics the pricing page does not spell out. Starter costs $0.40 per Flow of quota, Max costs about $0.33, and Ultra costs $0.25. Ultra is 10× the price of Starter for 16× the quota, which is a real discount rather than a cosmetic one — and the documentation adds a useful honesty note that Max and Ultra cover nearly identical model lists, so the decision between them is about volume, not access.
Limited batches are a real constraint
The Builder Plan is released in limited batches with a “SPOTS REMAINING” counter on the pricing page. If a subscription tier is your intended route onto the ZenMux API, availability is not guaranteed on the day you decide to buy — another reason production teams should be looking at pay as you go regardless.
Billing Transparency and the Cost Fields the ZenMux API Returns
Gateways make their margin in the gap between what the provider charges and what you are billed. ZenMux’s answer is to expose the arithmetic.
Ten billing item types
ZenMux API costs are itemised across ten categories: prompt, completion, image, request, web_search, input_cache_read, input_cache_write, input_cache_write_5_min, input_cache_write_1_h, and internal_reasoning. The last one is worth flagging for anyone budgeting reasoning-model workloads — thinking tokens are a separate, visible line rather than something folded into completion.
The four cost fields on every call
API response metadata carries originAmount, billAmount, discountAmount and realAmount, with the documented relationship realAmount = billAmount − discountAmount. That is enough to reconcile a ZenMux API invoice against your own request logs without asking anyone for a breakdown, which is more than most gateways offer.
Where to read it in the console
Per-call costs and token usage appear on the Activity page, a rate breakdown sits in Log Details, and the Cost Statistics page filters by current range, today or this month. Pricing itself is shown per provider on each model’s detail page, with tiered rates displayed by usage band where they apply. If cost attribution matters to you, create separate API keys per project or environment — the documentation recommends exactly that, and the keys carry names and tags for the purpose.
The ZenMux Benchmark and Why Channel-Level Testing Matters
The most quietly useful thing ZenMux publishes has nothing to do with the ZenMux API itself.
Every provider channel is tested separately
ZenMux-Benchmark evaluates every model across every provider channel available on the platform, independently. The same model served by its original vendor and by a cloud partner is two separate results, which is the only way to see that provider choice changes measured performance and stability rather than just billing. Given that provider routing is a core feature, testing at channel level is the honest way to do it.
Humanity’s Last Exam as the dataset
The primary dataset is Scale AI’s publicly released Humanity’s Last Exam (Text Only), run across the whole ZenMux API catalogue. Using a public, third-party benchmark rather than an in-house evaluation removes the most obvious conflict of interest from a vendor-published leaderboard — though it does mean the results measure hard-reasoning breadth rather than anything resembling your workload.
Scoring and cost normalisation
Some models cannot complete every question because of content filtering or other vendor constraints. ZenMux handles this by scoring against the number of questions the model actually answered, and normalising cost proportionally to the completion rate so cost-effectiveness comparisons stay fair. The full test code, procedures and raw results are on GitHub, so the methodology is checkable rather than merely described.
Performance metrics you can act on
Model detail pages compare providers on latency measured as time to first token, throughput measured in tokens per minute, and uptime. Those are the three numbers that decide whether a provider pin is worth setting — and, not coincidentally, two of the three are also the things the insurance mechanism pays out on.
What the ZenMux API Insurance Changes About Buying LLM Capacity
Strip away the marketing and there is a real structural argument underneath the ZenMux API.
Incentive alignment is the actual product
A gateway that pays when the model disappoints has a direct financial reason to route your request to the provider channel least likely to disappoint. Every other gateway is indifferent: a hallucinated response bills exactly the same as a good one. That is a genuine alignment shift, and it is more interesting than the size of any individual payout — which, given the undisclosed formula, nobody outside ZenMux can forecast anyway.
The bad-case flywheel
ZenMux’s stated intent is that every compensated case is analysed, anonymised and fed back to the customer as a high-value bad case. If that works as described, the credit is the smaller half of the benefit; a curated stream of your own worst generations is exactly the input a serious evaluation harness needs. Our guide to hallucination monitoring and model drift covers what to do with that data once you have it.
What it does not replace
An insurance payout is compensation for a cost, not prevention of a harm. If a hallucinated output reaches a customer, a few cents of credit does not touch the actual damage. Grounding, retrieval, output validation, human review on high-stakes paths and your own monitoring all still apply. The ZenMux API insurance reduces the price of failure; it does not reduce the rate of failure, and no vendor mechanism will.
Should You Route Production Through the ZenMux API?
A fair verdict on the ZenMux API needs to separate what is documented from what is merely claimed.
Where it fits well
Multi-model applications that genuinely switch between vendors, teams that want provider redundancy without negotiating three contracts, and anyone whose workload spans text, image, video and embeddings and would rather hold one key. The four-protocol support means an existing OpenAI, Anthropic or Google integration can be pointed at the ZenMux API in an afternoon and pointed back just as quickly, which makes a trial cheap. Cross-protocol calling is a real convenience for polyglot codebases — using one SDK to reach a computer vision model, a reasoning model and a Claude model is not something you get from the vendors directly.
Where to be careful
Any gateway, the ZenMux API included, is a dependency and a data path, so read the compliance and privacy pages against your own obligations before routing regulated data through it. The insurance mechanism has no published thresholds or formula, so it cannot be relied on as a service credit. And the subscription tiers are explicitly barred from production use — building a prototype on Starter and quietly scaling it is a policy breach, not a growth path.
A staged evaluation that costs almost nothing
Point a non-critical workload at the OpenAI-compatible endpoint for a fortnight on pay as you go, keep your existing integration warm behind a feature flag, and read three things at the end: the Cost Statistics page against your own logs, the ZenMux API compensation dashboard for whether anything paid out at all, and the per-channel benchmark for the models you actually use. That is a two-week test with a reversible exit, and it answers the only question that matters — whether the insurance is a real backstop on your traffic or a line on a landing page.
Frequently Asked Questions About the ZenMux API
Is the ZenMux API really OpenAI-compatible?
Yes, for the Chat Completions and Responses shapes. The documented base URL is https://zenmux.ai/api/v1 and the stated migration is changing base_url and api_key in your existing OpenAI SDK client. Model names change to provider/model-name slugs.
How do I get credits for hallucinations?
You do not request them. ZenMux runs automated daily detection across your API calls and pays compensation the following day into your Bonus & Compensation Credits balance. Payouts appear on the Insurance Compensation page in the console, categorised as Unsatisfactory Content or High Latency.
Are the compensation credits worth real money?
They are denominated in US dollars at one credit to one dollar of API usage, and they are consumed before your topped-up credits. They are not cash: they cannot be withdrawn, and they are forfeited if you take a refund on an unused top-up.
Can I use a Builder Plan subscription for a live product?
No. The documentation states production use of the subscription plan is prohibited and may affect your account. Live and commercialising projects must use Pay As You Go, which also removes the 10–15 RPM rate limit and the weekly concurrency cap.
What happens if a provider goes down mid-request?
Provider routing fails over automatically to another channel for the same model, ordered by first-token latency. If every candidate fails, a configured provider.fallback model handles the request. Both behaviours are transparent to your application code.
How many models does the ZenMux API actually cover?
The homepage claims 100+; the site’s model sitemap listed 271 model pages on 5 September 2026. Coverage varies by plan — the Free tier has no API access at all, and only Ultra and Pay As You Go are documented as reaching every model.
The Practical Read on the ZenMux API
The ZenMux API is, on the evidence of its own documentation, a competent multi-protocol gateway with an unusually honest billing surface and one genuinely novel commercial idea attached. The OpenAI compatibility is real and cheap to test. The routing, fallback and per-channel benchmarking are better thought through than the category norm. The insurance is the reason to look, and also the part that most needs a direct conversation with the vendor, because the public documentation shows you the payouts without ever telling you how they are calculated.
Treat it as our whole AI models and tools hub treats every new platform: run the two-week test, read your own numbers, and keep the exit warm. If you would like help designing that evaluation — or working out whether a gateway belongs in your architecture at all — that is a conversation worth having before the integration, not after it.
References and Further Reading
ZenMux — Unified API for 100+ AI Models
ZenMux Documentation — Platform Overview
ZenMux Documentation — Quick Start and Supported API Protocols
ZenMux Documentation — Insurance Compensation
ZenMux Documentation — Pay As You Go
ZenMux Documentation — Subscription Plans
ZenMux Documentation — Refund Policy
ZenMux Documentation — Provider Routing
ZenMux Documentation — Model Routing
ZenMux Documentation — Fallback Mechanism
ZenMux Documentation — Billing Transparency
ZenMux Documentation — Models and Providers
ZenMux Documentation — ZenMux-Benchmark Leaderboard
ZenMux Documentation — Frequently Asked Questions
More AI coverage: explore Progressive Robot's AI Models, Tools & Releases hub — hands-on reviews, setup guides and benchmarks in one place.