Compatibility matrix

The platform exposes four client protocol endpoints, all reachable with the same sk-gpushare-* API key:

Not every model supports all four. The matrix is determined by channel wiring — which kind of upstream channel serves a model, and which protocols that channel declares — not by reasoning from "vendor × protocol". Models in the same channel pool share a protocol surface, so the tables below are grouped by channel family (production wiring as of July 2026).

Legend#

The two kinds of 🔄 can be told apart from the response headers:

• Gateway-side translation (T1 / T2 below): the gateway converts the request body into the upstream protocol and converts the response back, and the response carries an X-Protocol-Translation header.
• Upstream-side conversion (marked "upstream conversion"): the gateway forwards bytes verbatim and the conversion happens inside the upstream service, so there is no X-Protocol-Translation header. The protocol shape is complete for the client, but features unique to the other protocol (Anthropic's cache_control, thinking blocks) aren't guaranteed to survive semantically.

Gateway-side translation paths#

T3, T4 and T6 are reserved for future wiring: today all cross-protocol Anthropic Messages and Gemini Native traffic is absorbed by upstream-side conversion, so routing never reaches those three gateway translators.

Overview#

¹ /v1/messages requests for gpt-5.x are absorbed by an upstream-internal conversion: the gateway forwards near-verbatim (it only fills in a default max_tokens) and there is no X-Protocol-Translation header. Anthropic-only features (cache_control, thinking blocks) aren't guaranteed to survive — if you depend on them heavily, use a Claude model instead.

² In the trial pool, the models named gemini-* actually speak the Anthropic protocol upstream — so they specifically cannot be called on the Gemini Native endpoint (503).

A single cell may be backed by several channels for failover; the matrix shows the primary path.

Group detail#

GPT pool (X1, 2 models)#

gpt-5.4 gpt-5.5

• OpenAI Chat ✅: requests carrying the built-in tools (web_search / image_generation) run over a WS V2 channel internally, with no change to the external protocol shape.
• OpenAI Responses ✅: native upstream Responses protocol, passed straight through. This is the preferred endpoint for GPT-5.x built-in tools plus reasoning (it's what Codex CLI uses).

Claude pool (X1, 5 models)#

claude-opus-4-6 claude-opus-4-7 claude-opus-4-8 claude-sonnet-4-6 claude-haiku-4-5-20251001

• Anthropic Messages ✅: native byte pass-through, with extended thinking and server_tool_use blocks fully preserved — the preferred endpoint for the Claude line.
• OpenAI Chat 🔄 T1: translated by the gateway to the Anthropic upstream; the response carries X-Protocol-Translation: openai_chat_to_anthropic_messages.
• OpenAI Responses ✅: served directly by a separate channel.

Gemini pool (X1, 3 models)#

Text: gemini-2.5-flash gemini-3-flash-preview

• Gemini Native ✅ natively; OpenAI Chat 🔄 T2 (gateway translation, with X-Protocol-Translation: openai_chat_to_gemini_native).
• The image SKUs (the nano family) aren't in this matrix: since 2026-07-08, nano-banana, nano-banana-pro and nano-banana-2 all bill per image through POST /v1/images/generations (older ids such as gemini-3.1-flash-image resolve as aliases onto the canonical entries).

Multi-vendor pool (X2, 13 models)#

• OpenAI Chat ✅ only (these upstreams are OpenAI-compatible themselves); every other protocol is — (503).
• Since 2026-07-07, deepseek-v3.2, deepseek-v4-flash, deepseek-v4-pro, kimi-k2.5, kimi-k2.6, MiniMax-M2.5, MiniMax-M2.7 and glm-5 are served exclusively by X3 channels, with no change to the protocol surface.

Hunyuan / DeepSeek dedicated pool (X3, 5 models)#

hunyuan-2.0-instruct-20251111 hunyuan-2.0-thinking-20251109 hunyuan-role-latest deepseek-v3-0324 deepseek-v3.1-terminus

• OpenAI Chat ✅ only; every other protocol is — (503).

Doubao pool (X4, 21 models)#

Doubao 1.5: doubao-1-5-lite-32k-250115 doubao-1-5-pro-32k-250115 doubao-1-5-pro-32k-character-250715 doubao-1-5-vision-pro-32k-250115 Doubao Seed 1.6: doubao-seed-1-6-250615 doubao-seed-1-6-251015 doubao-seed-1-6-flash-250615 doubao-seed-1-6-flash-250828 doubao-seed-1-6-vision-250815 Doubao Seed 1.8 / 2.0: doubao-seed-1-8-251228 doubao-seed-2-0-pro-260215 doubao-seed-2-0-lite-260215 doubao-seed-2-0-lite-260428 doubao-seed-2-0-mini-260215 doubao-seed-2-0-mini-260428 doubao-seed-2-0-code-preview-260215 Specialised: doubao-seed-character-251128 doubao-seed-code-preview-251028 doubao-seed-translation-250915 Version-suffixed routing aliases: glm-4-7-251222 deepseek-v3-2-251201

• OpenAI Chat ✅ only; every other protocol is — (503).

Grok pool (X1, 8 models)#

grok-4.3 grok-4.20-0309-reasoning grok-4.20-0309-non-reasoning grok-4.20-multi-agent-0309 grok-build-0.1 grok-3-mini grok-3-mini-fast grok-composer-2.5-fast

• OpenAI Chat ✅ only; every other protocol is — (503). (The five grok-4 models live in the X2 multi-vendor pool above.)

Image SKUs (grok-imagine-*, doubao-seedream-*) and video SKUs (doubao-seedance-*, grok-imagine-video*) use separate endpoint families and aren't part of this four-protocol matrix — see Image / video APIs.

Side effects of a translated path#

On a gateway-side translation (T1 / T2) the response carries diagnostic headers:

X-Protocol-Translation: openai_chat_to_anthropic_messages
X-Protocol-Warning: response_format=json_object dropped (Anthropic has no equivalent); n=2 dropped (Anthropic returns one completion)

• The X-Protocol-Translation value is {client protocol}_to_{upstream protocol} (see the table above).
• X-Protocol-Warning is generated from the fields actually dropped on this request, joined with ; . The header is absent when nothing was dropped. Common drops:
  • OpenAI Chat → Anthropic (T1): response_format, n, tools.image_generation and other fields Anthropic has no concept of
  • Anthropic → OpenAI (T3, reserved): cache_control markers
  • Gemini → Anthropic (T6, reserved): safetySettings / cachedContent / codeExecution

If your request depends heavily on those fields, pick a protocol endpoint that carries them natively (the ✅ columns). Upstream-side conversion (the "upstream conversion" cells) carries neither header — the gateway only sees a byte stream, and what gets dropped is up to the upstream.

Checking a combination yourself#

# send a request with your key and look at the HTTP status and response headers
curl -i https://jiuye.zsopc.com/v1/chat/completions \
  -H "Authorization: Bearer sk-gpushare-xxx" \
  -H "Content-Type: application/json" \
  -d '{"model":"<model-id>","messages":[{"role":"user","content":"hi"}]}'

• 200 — the combination works. An X-Protocol-Translation header means a gateway-side translation path; its absence means native pass-through or upstream-side conversion.
• 400 model_not_found — the model id isn't in the registry at all (typo, or retired). Identical on every protocol, with a message like model `xxx` is not available.
• 503 no_channel_available — the model exists but has no channel on the protocol you used. Try an endpoint marked ✅ or 🔄 in the matrix (/v1/messages, /v1/responses or /v1beta/models/{id}:generateContent).

Test the ❔ cells this way before relying on them in production. If a — cell returns 200 in practice, trust the response — channel wiring changes ahead of the docs. Note that the three protocols return differently shaped error bodies (each follows its own official schema) — see Error codes.

How current is this?#

The matrix is updated as channel wiring changes (this page was checked in July 2026). For the latest model list:

• Public catalog: GET /api/v1/models/public (no auth; includes callable=false placeholder SKUs and non-chat SKUs, so filter on callable and endpoint_type when consuming it from a script)
• Model plaza: jiuye.zsopc.com/models