One key, two protocols: why ByteSpike routes DeepSeek through both OpenAI and Anthropic shapes
DeepSeek's HTTP API quietly speaks both protocols. We wrapped both behind one ByteSpike key so your agent code and your chat code can use the same model without holding two credentials.
Until ByteSpike's last gateway update, customers who wanted both protocols on DeepSeek had to do the work twice. One key for `api.deepseek.com/v1/chat/completions`, a different account for `api.deepseek.com/anthropic/v1/messages`. Two sets of credentials in the secrets manager, two sets of base URLs in the SDK config, two reconciliation paths on the bill.
It worked. It was ugly. And it was specifically annoying for teams running mixed workloads — a Cursor-style chat client on OpenAI Chat Completions, and a DOSIA-style agent harness on Anthropic Messages — that both wanted to hit `deepseek-v4-pro` for the same model quality.
The fix: one key, route by path
ByteSpike now resolves both DeepSeek protocols off the same upstream credential. When you call `/v1/chat/completions`, we send the request to DeepSeek's OpenAI-shape endpoint. When you call `/v1/messages`, we send the same upstream key to DeepSeek's anthropic-compat endpoint. Same model name (`deepseek-v4-pro`), same response quality, two protocol shapes — your client picks the one it already speaks.
What this looks like in practice
If you have OpenAI-SDK code, swap `base_url` and the model name. Done.
`curl https://llm.bytespike.ai/v1/chat/completions -H "Authorization: Bearer $BYTESPIKE_API_KEY" -d '{"model":"deepseek-v4-pro", ...}'`
If you have Anthropic-SDK code, swap the base URL and the model name. Done. Same key.
`curl https://llm.bytespike.ai/v1/messages -H "x-api-key: $BYTESPIKE_API_KEY" -H "anthropic-version: 2023-06-01" -d '{"model":"deepseek-v4-pro", "max_tokens":1024, ...}'`
Why this matters
- **Agent code stays Agent code.** DOSIA Agent mode talks `tool_use` blocks; it never has to learn the OpenAI shape to call DeepSeek.
- **Chat code stays Chat code.** Cursor / Cline keep their OpenAI Chat Completions adapter; they don't have to teach their codebase about anthropic-version headers.
- **One bill, one credential, one rotation cadence.** When you rotate the ByteSpike key, you rotate both protocol surfaces at once — no risk of one half going dark while the other works.
What's underneath
The admin who configures the DeepSeek upstream account fills in two base URLs: the OpenAI-shape one and the anthropic-compat one. ByteSpike's routing layer treats them as two faces of the same channel. The customer-facing API key never knows which face served any given request — that detail surfaces only in the `x-bytespike-channel` response header for debugging.
The pattern generalizes. Moonshot, Zhipu, and MiniMax all expose dual-protocol upstreams the same way; ByteSpike wraps them with the same one-key abstraction. You'll see this multi-endpoint model spread across the rest of the provider catalog as upstreams ship the second protocol surface.
Get started
Existing ByteSpike key holders can use both protocols today against `deepseek-v4-pro` and `deepseek-v4-flash`. New users can sign up at console.bytespike.ai. Full provider doc: docs.bytespike.ai/providers/deepseek.