56 chat models × 4 client protocols (OpenAI Chat / Anthropic Messages / OpenAI Responses / Gemini Native), marked per model as native / gateway-translated / upstream-converted / unsupported, generated from the live channel table
The platform exposes four client protocol endpoints, all reachable with the same sk-gpushare-* API key:
Protocol
Endpoint
Typical clients
OpenAI Chat
POST /v1/chat/completions
the OpenAI SDK and most third-party clients
Anthropic Messages
POST /v1/messages
the Anthropic SDK, Claude Code
OpenAI Responses
POST /v1/responses
the OpenAI Responses SDK, Codex CLI
Gemini Native
POST /v1beta/models/{model}:generateContent / :streamGenerateContent
Google's genai SDK
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". The table below is generated per model from the live channel table; see the legend for what each cell means.
Native pass-through — the client protocol matches the upstream channel's, and the gateway forwards bytes verbatim
🔄 T1 / 🔄 T2
Gateway-side translation — the gateway converts; the response carries an X-Protocol-Translation header (see below)
🔄 upstream
Upstream-side conversion — the gateway forwards bytes verbatim and the relay converts internally, so there is noX-Protocol-Translation header
—
No channel — returns 503 no_channel_available (note: 503, not 404)
A /v1/responses request with the image_generation / shell / code_interpreter tools works on the models marked for drawing or the cloud sandbox in the model list even where the OpenAI Responses cell below is —: the platform takes such a request over and runs every round on the model's own protocol.
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 in the table): the gateway forwards bytes verbatim and the conversion happens inside the upstream service, so there is noX-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.
✅ in production (/v1/chat/completions traffic on the Claude and trial pools)
T2
OpenAI Chat → Gemini upstream
openai_chat_to_gemini_native
✅ in production (/v1/chat/completions traffic on the Gemini pool)
T3
Anthropic Messages → OpenAI upstream
anthropic_messages_to_openai_chat
implemented, no channel combination currently triggers it
T4
Gemini Native → OpenAI upstream
gemini_native_to_openai_chat
implemented, no channel combination currently triggers it
T6
Gemini Native → Anthropic upstream
anthropic_messages_to_gemini_native
implemented, no channel combination currently triggers it
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.
The Source column uses opaque codes: x1 = in-house account pool, x2 = third-party relay, x3 = Tencent. Several codes on one model means it has several channels for failover (the column is the union over all of them).
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
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.
# send a request with your key and look at the HTTP status and response headers
curl -i https://api.dflop.top/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).
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.
The tables on this page are generated from the live channel table (last generated 2026-08-18); they need regenerating whenever channel wiring changes. 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)
