xing61/zzz-api: a China-based OpenAI, Claude and Gemini API proxy

The problem zzz-api addresses for developers in China

Calling OpenAI, Anthropic or Google directly from mainland China involves a chain of obstacles that have nothing to do with writing code: an account, a foreign payment card, and a network path that is not guaranteed. The README frames the pitch in exactly those terms, saying you do not need to buy an account for OpenAI, Gemini or Claude, and do not need a US dollar bank card. The target reader is a developer or a small company that wants to keep using the official SDKs but cannot easily satisfy the account and payment requirements behind them.

The second audience is teams that already have OpenAI-compatible code. Because the proxy keeps the OpenAI request format, the documented migration is a base URL change plus a key swap, not a rewrite. The README also lists Anthropic, Google Gemini and xAI Grok official interface formats, so a codebase that talks to more than one vendor can point all of them at the same host. Domestic models are listed too: Baidu Wenxin, Alibaba, iFlytek Spark, ChatGLM and DeepSeek.

What this is not is a self-hosted gateway. There is no server code in the repository. The top-level entries are README.md, batch/, fine-tune/ and openai-api-desc.md, so the repository is documentation plus request examples for a service the vendor operates.

How the proxy works: base URL swap and bearer key

The mechanism is a single reverse-proxy endpoint. Every request goes to the base URL https://api.zhizengzeng.com/ over HTTPS, and authentication is an HTTP header carrying the user's API key, obtained from the vendor's management console. The README gives the header shape as Content-Type: application/json plus Authorization: Bearer api_key.

Because the path layout mirrors the official APIs, the SDK does the routing for you. You set the OpenAI base URL to https://api.zhizengzeng.com/v1/ where you would have used https://api.openai.com/v1/, and the library appends the endpoint path as usual. The README states the same substitution pattern applies to the Anthropic and Gemini official formats and to plain HTTP requests from any language, so the proxy is doing format translation and key management rather than exposing a new API surface.

The README claims support for streaming, function calling, embeddings, batch, the assistants API, fine-tuning, image generation with DALL-E-3, Whisper transcription and translation, and TTS models tts-1 and tts-1-hd. It also names gpt-5.6, gpt-5.5 and sora-2 in the supported model list. Treat that list as something to confirm against the dashboard rather than a fixed contract: the README is the only source here, and it does not state a deprecation policy or an availability guarantee for any individual model.

Installing and making a first call through zzz-api

There is nothing to install on the server side. You use the official client library for the vendor whose format you want, take an API key from the zzz-api management console, and point the client at the proxy base URL. The README's first documented pattern is the official openai Python package, and the only values it tells you to change are the key and the base URL: replace the official key sk-****** with the key from the console, and replace https://api.openai.com/v1/ with https://api.zhizengzeng.com/v1/. The request header the README specifies looks like this:

Content-Type: application/json
Authorization: Bearer api_key

With that header in place, the call itself follows the official format. The expected result is a normal response object in the vendor's own shape, because the proxy is not changing the schema. If you would rather not touch code, the README documents the same substitution through environment variables for LangChain: set OPENAI_API_KEY to the console key and OPENAI_API_BASE_URL to https://api.zhizengzeng.com/v1/. The third documented pattern is a raw HTTP request from any language, with the URL following the official format and the key in the Authorization header.

Where zzz-api stops being the right tool

The repository does not contain a server, so you cannot run this yourself, audit the routing logic, or keep working if the vendor endpoint is unreachable. That is the central limitation, and it is worth stating plainly because the README's advantages are all about convenience rather than control. If your project requires a self-hosted gateway, this is not it.

There is also no published licence. The repository metadata carries no license identifier, and the README does not discuss terms of use, data retention, or what happens to prompts sent through the proxy. For a team handling regulated or customer data, that silence matters more than the feature list. The README says nothing about logging, retention windows or a data processing agreement.

Availability is another gap. The README does not document an SLA, a status page, incident history or a rollback path, and no releases are listed. The last push to the repository was on 2026-09-13, so the documentation is current, but a recent commit is not the same as an operational guarantee. The related search phrase "zzz api down" reflects exactly this kind of concern, and the repository offers no answer to it.

Finally, the model list in the README mixes stable and fast-moving names. If your application depends on one specific model version, you are relying on a third party's routing decisions rather than on your own configuration.

How this differs from a self-hosted gateway such as LiteLLM

The obvious alternative for the same problem is a gateway you run yourself, and LiteLLM is the common example. The difference is where the credential and the routing live. With LiteLLM you deploy a proxy in your own infrastructure, hold the upstream provider keys yourself, and configure model routing, retries and logging in your own config file. With zzz-api the vendor holds the upstream relationship, and you hold only a key issued by the vendor console.

That trade is not one-sided. A self-hosted gateway requires you to solve the account and payment problems that zzz-api exists to remove, and it requires someone to operate the proxy. In exchange you get auditability, the ability to add your own logging, and no dependency on a third party's uptime. zzz-api gives you none of that, but it also gives you nothing to operate.

A second alternative is to call each vendor's official API directly. That keeps the official contract and support path, but it means separate accounts, separate billing, and separate SDK handling for OpenAI, Anthropic and Gemini. The README's claim that the proxy is a drop-in replacement for the OpenAI format is the specific thing that makes the single-endpoint approach attractive, and it is also the claim you should test first with a small script before moving any production traffic.

Maintenance, upgrade cost and the missing licence

Upgrade cost on your side is low in the common case. Because the proxy mirrors the official request formats, an SDK upgrade follows the upstream library's own changelog rather than anything in this repository. The README does not describe a versioned API for the proxy, so there is no proxy version to pin and no migration guide to follow. That cuts both ways: you also have no way to pin behaviour if the vendor changes routing.

The repository itself is documentation. The last push was on 2026-09-13, and no releases are listed, so there is no release cadence to plan around. If you depend on the examples in batch/ or fine-tune/, check them against the current console output rather than assuming they are maintained in step with the upstream APIs.

On licensing, there is nothing to analyse. No license identifier is present in the repository metadata, and the README does not state terms for the service itself. That is a question for the vendor, not for a licence file, and it is not something this article can resolve. If your organisation needs explicit terms before sending prompts to a third party, ask the vendor directly and get the answer in writing.

Editorial conclusion

zzz-api suits developers and small teams in China who already write against the OpenAI, Anthropic or Gemini SDKs and want to keep that code while paying through WeChat or a corporate account. It is the wrong choice if you need a self-hosted gateway, a published licence, or guaranteed uptime for a production system, because the repository contains no server code and no uptime commitment. Before adopting it, verify the current model list and pricing in the vendor dashboard, confirm that the Anthropic and Gemini base URLs still accept your SDK version, and check whether your own compliance rules allow prompts to leave your network.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. xing61/zzz-api on GitHub