A GLM API relay or proxy is often treated as a one-line base_url change. After launch, teams discover that four questions decide the experience: who the request passes through, who owns the key, how fees are calculated, and who handles failures. If those four answers are unclear, a lower price is not a reason to put production traffic on it.

This article compares direct access, self-built proxies, and managed gateways, focusing on billing transparency, rate limits, key risk, failover, and migration validation. Available models and prices follow the site's model pricing page.

Note: Zhipu, GLM, and BigModel are trademarks of their respective owners. This article is for technical explanation only; it has no affiliation with or agency relationship to Zhipu. The relay market changes quickly, and nothing here endorses any particular provider.

1. Separate the key concepts first

  • Official direct access: the application calls Zhipu's open-platform API directly; the key, bill, and rate limits belong to your own account.
  • Network proxy: solves reachability only and does not change API semantics; the key remains yours.
  • Self-built proxy or gateway: you deploy forwarding, authentication, rate limiting, and logging; the upstream is still an official account or a compliant supplier.
  • Commercial relay: a third party forwards requests and settles fees, possibly with credits, packages, or shared keys; the boundaries depend on the operator.
  • Unified AI gateway: an OpenAI-compatible entry that aggregates multiple models and unifies keys, billing, and the console; it can be managed or self-hosted.

These terms are often mixed up, and the result is treating a network problem as a model problem. Before signing, ask one question: whose identity does the request finally arrive under at the upstream?

2. The options side by side

Dimension Official direct Self-built proxy Managed gateway
Billing transparency Official bill with a clear basis Upstream bill plus your own costs Depends on pricing rules and usage detail
Network stability Affected by the local egress Depends on servers and routes Depends on the gateway's routes and upstream
Rate-limit basis Account or project level You control it, but upstream limits still apply Check package rules and whether pools are shared
Key and data You hold the key; data goes straight upstream Under your control; you can audit Confirm dedicated keys and privacy policy
Operations cost Low Servers, certificates, and on-call are yours Shifted to the provider, bounded by its availability

No option suits every team. If you use only GLM and network and payment are smooth, prefer direct access. If you need a fixed egress and auditing, build your own. If you need a multi-model entry but lack operations staff, evaluate a managed gateway.

3. Billing: the terms behind the multiplier

Relay quotes commonly take the form of "official price times a multiplier" or "token packages." The multiplier is only the entry point; the bill is decided by these eight items:

  1. Whether input and output are priced separately, and whether the multiplier is the same for both.
  2. Whether cache-hit input gets a discount, and which price version the discount is based on.
  3. Whether thinking tokens from reasoning models are counted as output.
  4. Whether failures, retries, and streaming interruptions are billed.
  5. Whether streaming responses return complete usage data.
  6. The minimum top-up, validity period, and refund conditions.
  7. Whether invoices are available, and how the settlement currency and exchange rate are set.
  8. Whether bills can be split by project, key, and model.

Put these eight items into a comparison table and replay the same batch of requests to calculate the real cost. Site prices are on the model pricing page; prices change with models and promotions.

4. Stability: metrics, probes, and failover

Stability is not judged by marketing claims but by six metrics: success rate, P50/P95 latency, time to first token, timeout rate, share of 429s, and output speed. Test with prompts of realistic length, covering streaming, long context, and concurrency, and observe at least one peak cycle.

Failover is not simply configuring two addresses. Switch only on connection failures, 5xx responses, and explicit rate-limit codes. Configuration errors such as 401, 403, and 400 usually fail on the backup as well. For requests with side effects, confirm whether they were executed before retrying to avoid duplicate charges.

import os
from openai import OpenAI

ENDPOINTS = [
    {
        "name": "primary",
        "base_url": os.environ["GLM_BASE_URL"],
        "api_key": os.environ["GLM_API_KEY"],
    },
    {
        "name": "backup",
        "base_url": os.environ["BACKUP_BASE_URL"],
        "api_key": os.environ["BACKUP_API_KEY"],
    },
]

def ask(prompt: str) -> str:
    last_error = None
    for endpoint in ENDPOINTS:
        client = OpenAI(
            base_url=endpoint["base_url"],
            api_key=endpoint["api_key"],
            timeout=60,
            max_retries=0,
        )
        try:
            resp = client.chat.completions.create(
                model=os.environ["GLM_MODEL"],
                messages=[{"role": "user", "content": prompt}],
                max_tokens=512,
            )
            return resp.choices[0].message.content
        except Exception as exc:
            last_error = exc
            print(f"{endpoint['name']} failed: {type(exc).__name__}")
    raise RuntimeError("Both primary and backup endpoints failed") from last_error

The model capabilities, context length, and parameter support of the primary and backup entries may differ. Compare outputs on a fixed test set before switching, and do not treat the backup as fully equivalent.

5. Rate limits and concurrency: the hidden cost of shared pools

Official direct rate limits usually attach to an account or project, and the basis may be concurrency, requests per minute, or token rate, varying by plan and model. Refer to the console and official documentation for specifics.

If a commercial relay uses a shared pool, your peak stacks on everyone else's: normal most of the day, then a cluster of 429s at the evening peak, with error bodies mentioning arrears or plan limits. When you see a 429, read the business code first; do not retry reflexively.

Another commonly overlooked issue is a retry storm. If three services each retry four times, the upstream may receive several times the original request volume. The right approach is client-side concurrency limits, queue-based smoothing, exponential backoff with jitter, and a global retry budget at the gateway.

6. Key ownership and data boundaries

The most common pitfall with relays is the key. Shared or resold keys and credits of unknown origin bring four problems: an upstream ban interrupts the business; multiple tenants crowd each other's rate limits; request content passes through a third party with opaque logging and retention; and the terms of service may prohibit resale, leaving no basis in a dispute.

When choosing a provider, confirm at least: the legal entity, terms of service, privacy policy, invoicing capability, failure contact, and exit mechanism. In heavily regulated sectors such as finance and healthcare, prioritize official direct access, private deployment, or a provider willing to sign a data processing agreement.

One more bottom line: do not hand your official key to a relay for top-ups or custody. Once a key leaves your account, usage and permissions are no longer under your control.

7. Migration steps: change one variable at a time

  1. Record a baseline: success rate, P50/P95, timeout rate, share of 429s, token usage per thousand requests, and the bill.
  2. Inventory dependencies: model names, thinking parameters, tools, JSON output, streaming, and image input.
  3. Create separate test and production keys, each with quota limits and alerts.
  4. Change only base_url and api_key, and make a minimal request work in staging.
  5. Replay real prompts and compare output quality, latency, and usage accounting.
  6. Verify error mapping: whether 401, 403, 429, 5xx, and timeouts are recognized correctly.
  7. Canary 5%–10% of traffic for 3–7 days, keeping the original entry as a fallback.
  8. After full cutover, reconcile for another week to confirm bills, usage, and logs agree.

Do not change the model, edit prompts, and migrate the gateway at the same time, or you will not be able to attribute problems.

8. Verification checklist: judging whether an entry is reliable

Check Method Warning sign
Latency Send the same prompt repeatedly and compare P50/P95 High variance or consistently slower than direct access
Error rate Measure the share of 429s, 5xxs, and timeouts Failures cluster at peak hours
Usage Compare response usage with the back-office bill They do not match, or streaming omits usage
Model identity Compare capability boundaries and output style on a fixed test set Clear capability drop or shorter context
Key isolation Confirm dedicated keys and whether keys can be rotated Refusal to explain where keys come from
Contract and support Check the entity, terms, invoices, and ticket response Only a personal contact, no terms

Red flags: prices persistently far below official rates, promises of zero downtime, refusal to provide usage detail, requests to hand over official keys, or an inability to explain where data is stored. If any appears, validate with a small traffic share first; do not migrate production all at once.

9. When self-hosting is the better fit

Build your own when you need a fixed egress IP, unified auditing, multi-upstream routing, or keys that you must hold yourself. A common pattern combines a reverse proxy with key management, rate limiting, logging, and alerting, while the upstream remains an official account or a compliant supplier.

Count the full cost: servers, bandwidth, certificates, upgrades, vulnerability fixes, and on-call time are all real expenses. With low call volume and no operations staff, self-hosting is often more expensive and still cannot bypass upstream rate limits.

10. Recommendation: rank by constraints

  1. Start with network and payment: if the official entry is stable and top-ups work smoothly, prefer direct access.
  2. Then consider control: if you need a fixed egress, auditing, or private keys, evaluate self-hosting.
  3. Then consider model range: if one entry must serve multiple models, evaluate a managed gateway.
  4. Finally consider service capability: entity, terms, invoicing, tickets, and data policy.

If you need a unified entry, create a test key on ZSQH AI Gateway and get it working before migrating; available models and billing are on the model pricing page. Do not treat "cheap" as the only criterion.

11. FAQ

1. What is the difference between a relay and a proxy?

A proxy usually means network-layer forwarding that only solves reachability; a relay also involves accounts, billing, or key distribution. Clarify the boundary and key ownership before signing.

2. A relay price is lower than official. Can I trust it?

It may come from bulk purchasing, route subsidies, or resold credits, and it may come with shared keys and instability. Check the billing basis, usage detail, and terms, then test with a small traffic share.

3. How can I tell whether a relay has swapped the model?

Do not rely on the model field alone; it can be rewritten. Compare capability boundaries, context length, output style, and usage structure on a fixed test set, keeping direct access as a control.

4. How much code has to change to migrate to a gateway?

Most OpenAI SDK projects change only base_url and api_key, adjusting model names per the pricing page. If you use thinking, tools, or special response fields, run compatibility tests.

5. When should I build my own proxy?

When you need a fixed egress IP, unified auditing, multi-upstream routing, or compliance requires you to hold the key yourself. With low volume and no operations staff, self-hosting usually costs more.