Introduction

Amux is an LLM API gateway. Requests sent to https://gateway.amux.ai are forwarded to upstream model providers according to your configuration and the results returned to you, with authentication, billing, routing, and observability handled in one place.

Amux neither trains nor hosts models. It covers only the call layer.

The problem#

Integrating a single model provider is straightforward. The difficulty appears when you integrate several: duplicated SDKs, different authentication schemes, scattered invoices, and per-provider availability handling all compound the maintenance cost.

Nor is this a one-time cost. Models keep changing and so do prices, yet switching models should not mean rewriting, retesting, and redeploying your code.

Amux consolidates that layer into a single integration surface.

Design principles#

No markup on inference#

The same model is usually offered by several providers, with different prices, context lengths, and supported protocols. We list each of them individually in the model catalog and bill at that provider's price. Discounts we negotiate upstream go straight into the unit price you see.

This shapes the rest of the platform: routing does not profit from price spreads, so there is no incentive to steer requests toward more expensive providers and no reason to hide prices. For how charges are calculated, see billing overview.

Native protocol support, not translation#

OpenAI Chat Completions, OpenAI Responses, Anthropic Messages, and Google Gemini are all implemented natively. Tools that speak only one protocol — Claude Code, Codex, Gemini CLI — usually need nothing more than a new base_url.

The same model can also be called across protocols: use the OpenAI SDK to call Claude, or the Anthropic SDK to call Gemini. For parameter differences across protocols, see protocol conversion compatibility.

Beyond the text protocols, the platform provides image generation and editing endpoints, native video endpoints from several vendors, and Amux Tasks, a unified asynchronous generation interface. The full endpoint list is in the API reference.

No silent degradation#

For unsupported capability combinations, the platform returns an explicit error rather than substituting approximate behavior, so that callers never receive results in production that differ from what they asked for.

The same principle applies to routing constraints. When a key is restricted to a supply tier or a set of providers and the target model has no available provider within that scope, the request fails instead of falling back to a provider outside it.

Your data is yours#

We do not use your requests or responses to train any model. Bodies of successful text and chat calls are not recorded — logs contain metadata only; failed calls are sampled for troubleshooting and kept for at most 15 days. Prompts for asynchronous generation tasks are stored with the task and cleared on a schedule. See the privacy policy.

Failures should be legible#

Error bodies preserve as much of the upstream response as possible, including details worth having when debugging, such as CUDA out of memory. Attempts that fail during routing retries are not billed.

Every call keeps a complete record: inputs, artifacts, usage, the provider that served it, and the upstream response when it failed. Records are searchable on the console's logs page by request ID, model, provider, and key.

What we do not do#

Clear boundaries are usually more useful than a broad list of capabilities:

• No model evaluations or leaderboards. Model quality depends heavily on the specific task, and a platform that sells inference is not well placed to also act as the neutral evaluator
• No prompt hosting, no agent framework. That layer is already crowded; we work on the one beneath it
• No lock-in. Model IDs use the standard vendor/model form and the protocols are the industry's own. Going back to a direct integration, or moving to another platform, still comes down to changing an address and a key

What is available today#

Shipped:

• Inference endpoints — native implementations of four text protocols, image generation and editing, native video endpoints from several vendors, and the unified asynchronous interface Amux Tasks
• Model catalog and price comparison — every provider's price, context length, and supported protocols listed per model, plus model comparison
• Routing — five sorting strategies, supply-tier constraints, pinned and preferred providers, cross-provider failover, and circuit breaking
• API keys — spend limits, model allowlists, per-key routing, and task callback signing secrets
• Billing — prepaid credit, itemized charges, top-ups and auto top-up, balance alerts, receipts and invoices, refunds
• Organizations and workspaces — multiple workspaces, member roles, member spend limits, invitations
• Console — usage analytics, cost analytics, call logs, playground, tickets, and notifications

Planned: subscription billing. This page describes only what has shipped, and is updated as that changes.

Where to start#

• Quickstart — create a key and make your first request
• Core concepts — how accounts, workspaces, keys, models, and credit relate
• Routing and failover — which provider a request lands on when several offer the same model
• Billing overview — how charges arise and are settled
• Accounts, organizations, and workspaces — structure for team use

Already integrated and want to know what the platform does with your data: data retention and privacy controls.

For legal text, see the terms of service, privacy policy, and acceptable use policy.