Z.ai international and BigModel CN Coding Plan routes should be separate provider profiles.
If a GLM client works against api.z.ai but fails against open.bigmodel.cn, or the other way around, do not treat it as one generic Z.ai OpenAI-compatible provider. Region, account system, model catalog, and billing plan can all differ.
Use this only when provider signup, China-region payment, endpoint support, or client routing is blocking a tiny first test. Pay $5, create an account, send the receipt, and get manually credited for one real request.
Do not paste real keys into public issues. Share only the route family, region, endpoint host, model id, and whether the credential comes from an international Z.ai account, a BigModel CN account, or a coding-plan subscription.
1. Split the two route families
| Route family | Typical base URL | Use it when | Common mistake |
|---|---|---|---|
| Z.ai international Coding Plan | https://api.z.ai/api/coding/paas/v4 |
The user has a Z.ai international coding-plan account and wants GLM coding models. | Reading metadata from a regular zai provider profile instead of zai-coding-plan. |
| BigModel CN Coding Plan | https://open.bigmodel.cn/api/coding/paas/v4 |
The user has a mainland China BigModel/Zhipu account and CN-region access. | Sending a CN credential to the international Z.ai host or assuming the same account works in both regions. |
| Regular OpenAI-compatible GLM route | Provider-specific regular API host | The app only needs standard chat completions and does not rely on coding-plan behavior. | Using coding-plan-only models as if every OpenAI-compatible client can call them. |
2. Log the exact request tuple
Before changing model code, print the final network tuple. This prevents a client from silently mixing a live provider client with a stale model id or wrong region.
provider_profile: zai-coding-plan | bigmodel-cn-coding-plan | zai-regular
final_base_url: https://api.z.ai/api/coding/paas/v4
final_request_path: /chat/completions
upstream_model_id: glm-5.2
account_region: international | cn
credential_source: env name or config slot, not the secret value3. Do not key model metadata only by visible provider name
A provider label like zai is too broad. GLM-5.2 context length, vision model availability, reasoning controls, and subscription gates can differ by route. A safer client uses separate provider identifiers:
providers:
zai-coding-plan:
base_url: https://api.z.ai/api/coding/paas/v4
models_dev_provider: zai-coding-plan
bigmodel-cn-coding-plan:
base_url: https://open.bigmodel.cn/api/coding/paas/v4
account_region: cn
zai-regular:
base_url: https://api.z.ai/api/paas/v44. When a user asks for CN version support
The clean product answer is not a checkbox called "Z.ai CN". It should be a separate profile with its own host, credential slot, model list, and smoke test. Ask the user for these redacted facts:
- Which dashboard/account issued the key or token.
- Which endpoint host the account docs show.
- One raw curl status code with the model id and key redacted.
- Whether the model is a regular GLM API model or a Coding Plan model.
5. If onboarding is the real blocker
If the developer already has a working Z.ai or BigModel account, direct provider access is cleaner. If the blocker is China phone verification, China payment, CN dashboard onboarding, or a client that cannot yet speak the right route, use a small independent gateway test before changing the whole integration.
Black Eagle AI is an independent gateway, not an official Z.ai, BigModel, or Zhipu partner. The starter flow is for teams that need a small prepaid OpenAI-compatible test while direct provider access is still blocked.
curl https://api.blackeaglecambodia.com/v1/chat/completions \
-H "Authorization: Bearer sk-your-black-eagle-token" \
-H "Content-Type: application/json" \
-d '{
"model": "deepseek-v4-flash",
"messages": [{"role": "user", "content": "Say hello in one sentence."}]
}'