Chinese Models

Call GLM / Kimi / DeepSeek / Qwen with the same QCode.cc cr_ key: current ids on sale, protocol paths, a curl self-test, and pairing with the Claude 5 family

QCode.cc sells more than Claude / GPT / Gemini. The same cr_ key also reaches Zhipu GLM, Moonshot Kimi, DeepSeek and Qwen. This page only answers "how do requests land on these ids" — no style comparisons, no marketing.

The daily default should still be the Claude 5 family (see Model Selection Guide). The Chinese families shine at: Chinese office and long-form text, cheaper bulk volume, and as a control against Claude. Never put a name into a client that does not appear on qcode.cc/models.

What is on sale now¶

The ids below appeared on 2026-09-18 both on qcode.cc/models and on the public endpoint GET https://api.qcode.cc/api/v1/models (cross-checked; live unit prices and context sizes are whatever qcode.cc/models shows — this page deliberately does not copy numbers).

Names you may still see in old examples but which are no longer sold: qwen3.7-max, kimi-k2.6, glm-5.1 — gone from both live lists; entering them in a client will fail, switch to the ids above.

No grok. The live list: qcode.cc/models or GET https://api.qcode.cc/v1/models with your key.

Which protocol¶

The protocol is decided by the path; the key does not care about families. Source of truth: Endpoints and API paths.

Do not put Chinese-family ids behind the Gemini /gemini prefix, and do not point OpenAI-compatible tools at https://api.qcode.cc/api (that is the Anthropic Messages prefix).

Non-Claude models may lose native features like Extended Thinking inside Claude Code — Model Selection Guide documents the same caveat for GPT. When in doubt, treat them as a supplementary tier, not a replacement.

curl self-test¶

Same interpretation as the endpoints doc: 400 = path and key both fine (missing body expected), 401 = key invalid, 404 = wrong prefix.

KEY="cr_your-QCode-key"

# path check only
curl -s -o /dev/null -w '%{http_code}\n' -X POST https://api.qcode.cc/openai/v1/chat/completions \
  -H "Authorization: Bearer $KEY"

# end-to-end with one id on sale (replace glm-5.3 with the id you want)
curl -sS https://api.qcode.cc/openai/v1/chat/completions \
  -H "Authorization: Bearer $KEY" \
  -H "content-type: application/json" \
  -d '{"model":"glm-5.3","messages":[{"role":"user","content":"ping"}]}'

From mainland China swap the host to asia.qcode.cc and test again. One key works on all three domains.

Reference OpenAI Python client (set base_url to /openai/v1, no trailing slash):

from openai import OpenAI

client = OpenAI(
    api_key="cr_your-QCode-key",
    base_url="https://api.qcode.cc/openai/v1",
)
resp = client.chat.completions.create(
    model="glm-5.3",
    messages=[{"role": "user", "content": "ping"}],
)

Pairing with the Claude 5 family¶

The 4.x generation (claude-sonnet-4-6, claude-opus-4-8) is still on sale, just no longer the default. Prices and windows: qcode.cc/models.

Same key in an office desktop client: see WorkBuddy Integration. Switching Claude Code / Codex: CC Switch Setup.

FAQ¶

Filled the id but got 404 / an empty list¶

The id must look like glm-5.3 in the table, not "GLM-5.3" or a display name. OpenAI-compatible mode often lists nothing — type the id manually.

401¶

The key starts with cr_, no stray spaces. Verify in qcode.cc/dashboard.

Can I call GLM over Anthropic's /api/v1/messages?¶

The gateway picks the protocol by path. /openai/v1/chat/completions is the documented path for OpenAI-compatible clients. With Claude Code already pointed at QCode, just /model <id> — no hand-built Messages calls for the Chinese tier.

How about WorkBuddy / Cline¶

WorkBuddy: provider Custom, endpoint https://api.qcode.cc/openai/v1, model name = an id from the table; step-by-step in WorkBuddy Integration. Cline uses the same Base URL and Model ID under "OpenAI Compatible".

Next steps¶

• Endpoints and API paths
• Model Selection Guide
• Billing
• WorkBuddy Integration
• Live ids: qcode.cc/models