The terms "relay" and "proxy" are often used interchangeably in mainland China. Some people mean a reverse proxy, some mean resold quota, and some mean an AI gateway with a console. The name does not matter. What matters is what you are buying: a technical service, or someone else's upstream quota; who is responsible when something breaks; and whether the bill can be reconciled.

This article explains how to evaluate a MiniMax API relay along five dimensions: billing transparency, key and data risk, latency and error monitoring, migration, and acceptance. Model availability and pricing follow the model pricing page.

Note: MiniMax is a trademark of its owner. This article reflects common practices as of October 2026 and is not procurement or legal advice; interfaces, billing, and terms are subject to official documentation and the provider's contract.

1. Split "Relay" into Three Categories

Type Who maintains it What you get Main risk
Commercial relay/proxy A service provider One address, one key, an RMB invoice Opaque upstream, price changes, or shutdown
Managed AI gateway A service provider Unified interface, console, usage statistics One more hop, contractual lock-in
Self-hosted gateway Your own team Full control, multiple upstreams Operations, security, upstream accounts

A commercial relay may connect to the official API, to other upstreams, or to shared quota. Before purchasing, ask clearly who the upstream is, whether resale is permitted, and whether the model version is fixed. "Internal channel" or "stable supply" is not enough of a basis for production.

A managed AI gateway usually provides an OpenAI-compatible interface, key management, usage statistics, and invoices, which suits teams that do not want to run their own infrastructure. Self-hosted gateways commonly use New API, One API, or LiteLLM; they offer the most control, but key security, rate limiting, monitoring, and upgrades are all your responsibility.

2. Keys and Data: The Biggest Relay Risk

Requests pass through the relay, so the provider can technically see prompts and responses. This is not speculation; it follows from the architecture. What needs confirming: whether traffic is stored to disk, for how long, whether it is used for training or service improvement, who can access it, and how a breach would be notified. These points belong in the contract, not in verbal assurances.

Key risk has two layers. First, if you hand your official MiniMax key to a relay, the provider can spend your balance and see your usage. Second, if the provider gives you a shared key, your business shares quota with other customers; when they saturate it, you get rate-limited. Neither is suitable for production as-is.

Ways to reduce risk:

  • Keep production keys on the server only; never in front-end code, repositories, or support screenshots.
  • Split keys by project or environment, and set budgets and concurrency caps.
  • Rotate keys regularly, and revoke them immediately when an employee leaves or a partnership ends.
  • Prefer independent sub-accounts or project-level keys over a primary-account key.
  • Write data retention, deletion, and breach-notification responsibilities into the contract.

3. Which Billing Fields to Check for Transparency

Relays quote in many ways: per token, by multiplier, by subscription, by resource pack, or a combination. Do not compare only "price per million tokens"; break out the following:

  • Whether input and output tokens are priced separately.
  • Whether cache reads and writes, and reasoning or thinking tokens, are billed and how.
  • Whether there is a multiplier, minimum spend, tiered pricing, or subscription minimum.
  • Whether failed requests, retries, and interrupted streams are billed.
  • Whether long context, images, speech, and video use different billing units.
  • Billing cycle, settlement currency, refunds, and how price changes are announced.

The most reliable reconciliation method is a fixed request: run the same prompt, model, and parameters once directly and once through the relay, and record the returned usage, elapsed time, and charge. If the difference can be explained, billing is transparent. If it cannot, do not scale up yet.

from openai import OpenAI

client = OpenAI(
    api_key="the key provided by the relay service",
    base_url="https://your-relay-address/v1",
    timeout=60,
    max_retries=0,  # Disable automatic retries during reconciliation to avoid duplicate charges
)

resp = client.chat.completions.create(
    model="your model alias",
    messages=[{"role": "user", "content": "Reply with OK only"}],
)
print(resp.usage)

Disabling automatic retries during reconciliation shows exactly what one request costs. Re-enable retries and backoff in production as the workload requires.

4. Monitoring Latency and Errors

A relay adds a hop, so both latency and the error surface change. Do not judge stability from a single ping or a speed-test screenshot. Record on real requests:

  • p50 and p95 latency, plus first-token time for streaming requests.
  • Success rate, rate-limit ratio, 5xx ratio, and connection-drop ratio.
  • Input and output tokens, model name, and trace_id or request ID.
  • A comparison across peak and off-peak periods.

MiniMax official error codes are useful troubleshooting clues: 1002 rate limit exceeded, 2045 request rate rising too fast, 1041 connection limit, 1008 insufficient balance, 1004 and 2049 invalid key or insufficient permission, 1001 timeout, and 1033 downstream error. A relay may wrap upstream error codes in its own format, so ask about the mapping before purchasing; otherwise alerts will be misleading.

Set at least three kinds of alerts: error rate above a threshold for a sustained period, p95 latency clearly above baseline, and rate-limit or balance warnings. Alerts should carry the model name and request ID so you can quickly tell whether the problem is upstream, network, or the relay layer.

5. How to Validate a Relay Service

Do not judge a relay by its price page and support promises alone. Work through the following order:

  1. Entity and contract: confirm the service entity, terms of service, invoice type, data clauses, and liability for breach.
  2. Upstream disclosure: confirm whether the official API is used, whether resale or proxying is permitted, and whether model versions are fixed.
  3. Model list: check model names, context lengths, streaming, tool calling, and multimodal capabilities, and whether models can be retired without notice.
  4. Fixed-request tests: run short text, long text, streaming, tool calling, and multimodal groups, and save the outputs.
  5. Token reconciliation: compare usage and charges between direct and relayed requests for the same request, and confirm the difference is explainable.
  6. Error tests: use a wrong key, an over-limit request, and a long request to observe status codes, messages, and recovery time.
  7. Stability observation: observe for seven consecutive days covering peak and off-peak, recording success rate, p95, and rate limits.
  8. Exit mechanism: confirm that balance refunds, data export, key revocation, and migration assistance are written into the contract.

Item 5 is the most often skipped. Much of what looks "cheap" comes from shared quota, cache hits, model substitution, or hidden failure billing, and only reconciliation reveals it.

6. Migration Checklist: From Direct Access to a Relay

If the existing workload already calls MiniMax directly, do not switch everything at once. Follow this order:

  1. Inventory Base URLs, keys, model names, and parameters in the code, and list every call site.
  2. Establish a baseline with fixed requests: latency, tokens, output quality, and billing.
  3. Create a test key on the relay side and run non-production traffic first.
  4. Configure dual channels and keep direct access as the rollback path.
  5. Shift traffic gradually, starting at a low percentage, and watch error rate and p95.
  6. Compare outputs for the same batch of requests, focusing on long text, streaming, and tool calling.
  7. Reconcile for a week and confirm billing differences and refund rules.
  8. After stability is confirmed, retire the old key and retain logs and the contract.

For a relay that is OpenAI-compatible, migration usually means changing three settings: base_url, api_key, and model. Streaming, tool calling, error codes, multimodal inputs, and billing fields still need separate verification. Do not treat "it returns a sentence" as proof that migration is complete.

7. Contract and Exit Terms

The worst outcome with a relay is not a high price; it is a sudden shutdown, a balance that cannot be refunded, or data that cannot be accounted for. The contract should cover at least: service scope and model list, SLA or availability statement, billing method and price-change notice, whether failed requests are billed, data retention and deletion, security incident notification, refunds and termination, and migration assistance.

If the provider cannot supply a contract, an invoice, or clear data terms, it is better suited to temporary testing than to production. Enterprise procurement should also confirm the payment entity, invoicing cycle, and internal compliance process so the launch does not stall in finance.

FAQ

What is the difference between a relay and direct official access?

Direct official access calls MiniMax's interface directly. A relay adds a service layer between you and the upstream, maintained either by a provider or by your own team. A relay does not change model capability; its value is a unified entry point, billing, and operations, at the cost of one more hop and an extra trust boundary.

Is a cheap relay worth choosing?

Not necessarily. A low price may come from shared quota, rate limiting, model substitution, caching, or hidden failure billing. Test with a small budget and reconcile fixed requests before scaling.

Can a relay see my data?

Requests pass through the relay, so the provider can technically see the content. Whether it is stored, for how long, and whether it is used for training must be confirmed in writing. Desensitize sensitive data first or assess whether it should pass through a third party at all.

How much code has to change for migration?

If the relay is OpenAI-compatible, usually only base_url, api_key, and model. But streaming, tool calling, error codes, multimodal inputs, and billing fields need separate verification. Keep direct access as a rollback channel.

How do I tell whether a relay is stable?

Record success rate, p95, first-token time, rate limits, and 5xx for seven consecutive days across peak and off-peak, then run a failure drill. Do not rely on a single request, a speed-test screenshot, or support promises.

Next Steps

Create a test key on the ZSQH AI Gateway, then compare latency, success rate, and billing between direct access and the gateway using fixed requests before deciding to migrate. Models and prices follow model pricing.

Related reading: