DeepSeek Now Speaks Anthropic: What the New Dual-Format API Means for Your Routing Layer

If your team uses the Anthropic SDK natively — not just Claude Code, but any codebase built against import anthropic — DeepSeek's new Anthropic API compatibility endpoint changes your provider switching calculus. You no longer need an OpenAI-compatible wrapper or a translation layer to route Anthropic-format requests to DeepSeek V4 models. The endpoint is live and documented.

What happened

DeepSeek has added official support for the Anthropic API message format, accessible at:

https://api.deepseek.com/anthropic

Using the standard Anthropic Python SDK, you can now target deepseek-v4-pro or deepseek-v4-flash directly:

import anthropic

client = anthropic.Anthropic(
    base_url="https://api.deepseek.com/anthropic",
    api_key="<your DeepSeek API key>"
)

message = client.messages.create(
    model="deepseek-v4-pro",
    max_tokens=1000,
    system="You are a helpful assistant.",
    messages=[{"role": "user", "content": "Hello"}]
)

DeepSeek published a full field compatibility matrix alongside the endpoint. The key capabilities and gaps:

Supported:

• content as string or type="text" array — Fully Supported
• type="thinking" — Supported (extended thinking works)
• type="tool_use" — Fully Supported (id, input, name)
• type="tool_result" — Fully Supported

Silently Ignored:

• cache_control — ignored on all content types
• citations — ignored
• is_error on tool results — ignored

Not Supported:

• type="image" — not supported
• type="document" — not supported
• type="search_result", type="web_search_tool_result" — not supported
• type="server_tool_use" — not supported
• type="mcp_tool_use", type="mcp_tool_result" — not supported
• type="code_execution_tool_result" — not supported
• type="container_upload" — not supported

One critical routing behavior to note: if you pass an unrecognized model name, DeepSeek silently maps it to deepseek-v4-flash, not an error. That silent fallback has significant operational implications.

Why it matters for AI engineering teams

Before this endpoint existed, teams using the Anthropic SDK had two paths for provider switching: rewrite the SDK layer to OpenAI format, or use a proxy that translates on the fly. Both paths add friction and potential breakage. The new endpoint eliminates that translation problem for the Anthropic format path.

For Claude Code users specifically, the env var setup from DeepSeek's earlier guide (ANTHROPIC_BASE_URL=https://api.deepseek.com/anthropic) now points to a documented, officially supported endpoint rather than an undocumented compatibility shim. The support matrix tells you precisely what will and won't work.

For teams with Anthropic-native codebases, the endpoint means you can evaluate DeepSeek V4 models without SDK migration. Set the base_url and api_key, keep the rest of your application code unchanged, and observe behavior against the feature matrix.

The cost arithmetic shifts significantly. Teams running claude-3-sonnet workloads that only use text content, tool calls, and extended thinking can likely route through DeepSeek V4 Pro at substantially lower cost with no code changes. The latency and quality profile differs, but the API surface is compatible for those specific content types.

The router/operator angle

The field support matrix is the most operationally important artifact from this release. It defines a precision routing decision boundary — not a binary compatible/incompatible divide, but a per-feature compatibility map that a routing gateway needs to understand.

Three issues demand attention for any team running a routing gateway in front of Anthropic-format requests:

1. The silent model fallback is a routing hazard. If your gateway passes an unknown model string (e.g., a versioned alias like claude-3-5-sonnet-20241022) through to DeepSeek's Anthropic endpoint without rewriting it, DeepSeek silently serves deepseek-v4-flash — a cheaper, faster model — without signaling the substitution in the response. Your billing records will show flash usage; your application expects pro-tier quality. This creates a silent quality regression that is difficult to detect without response observability.

The correct pattern: Always explicitly set the DeepSeek model ID (deepseek-v4-pro or deepseek-v4-flash) when routing to this endpoint. Never pass Anthropic model aliases through unchanged.

2. cache_control is silently ignored. If your application relies on Anthropic prompt caching to control costs on long system prompts or repeated context, that caching does not apply on DeepSeek's endpoint — but no error is returned. You'll pay per-token rates without caching benefit. Teams that rely heavily on prompt caching should not route those workloads through this endpoint without accounting for the cost difference.

3. MCP tool calls and server tools are not supported. As agentic workflows move toward MCP-native tool architectures, this becomes a meaningful routing constraint. If your agent uses mcp_tool_use or server_tool_use content blocks, those requests must stay on an Anthropic endpoint. The router/operator decision: tag MCP-heavy agent sessions and prevent them from being rerouted to DeepSeek's Anthropic endpoint.

Decision framework for routing teams:

| Workload type | Compatible with DeepSeek Anthropic endpoint? | |---|---| | Text + tool calls only | ✅ Yes — directly compatible | | Extended thinking (type="thinking") | ✅ Yes — supported | | Image input (type="image") | ❌ No — not supported | | Prompt caching (cache_control) | ⚠️ Silent — no error, no benefit | | MCP tools (mcp_tool_use) | ❌ No — not supported | | Unknown model name passed as-is | ⚠️ Silent fallback to v4-flash | | Anthropic model aliases (e.g. claude-3-5-sonnet-*) | ⚠️ Rewrite required |

What TheRouter users should watch or try

If you're operating a routing gateway that handles Anthropic-format traffic, the patterns here directly apply to your routing policy configuration. Specifically:

• Rewrite model IDs before forwarding to DeepSeek's Anthropic endpoint: always map to an explicit DeepSeek model ID, never pass Anthropic aliases through.
• Tag and route MCP-agent sessions separately: MCP tool calls must stay on Anthropic; text-only or tool-use sessions can route to DeepSeek.
• Monitor for cache_control usage in your request pipeline: if prompt caching is a cost control mechanism for your application, account for the cost difference when routing those requests to DeepSeek.
• Validate with your specific workload mix before shifting production traffic: run evals on tool-call-heavy and extended-thinking workloads to confirm quality parity before moving budget.

Watch the DeepSeek Anthropic API docs for additions to the support matrix — particularly type="image" support and cache_control behavior, which would materially expand the workload range this endpoint covers.