DeepSeek Anthropic API Endpoint: api.deepseek.com/anthropic Routing Risks
How to use DeepSeek Anthropic API at api.deepseek.com/anthropic with Claude Code and the Anthropic SDK — plus the routing hazards around unsupported fields, cache_control, MCP tools, and silent fallback to deepseek-v4-flash.
Archive item produced with AI assistance from the cited source and published without individual review. Editor of record: Joe Werner.

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:
contentas string ortype="text"array — Fully Supportedtype="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 typescitations— ignoredis_erroron tool results — ignored
Not Supported:
type="image"— not supportedtype="document"— not supportedtype="search_result",type="web_search_tool_result"— not supportedtype="server_tool_use"— not supportedtype="mcp_tool_use",type="mcp_tool_result"— not supportedtype="code_execution_tool_result"— not supportedtype="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_controlusage 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.

DeepSeek Claude Code & OpenCode Integration: Official V4 API Setup Guide
DeepSeek's official integration guide for Claude Code, OpenCode, and OpenClaw — API setup, per-tier V4 model routing, and Anthropic-compatible endpoint configuration for coding agents.

Claude Code Origin Story Routing: Why Anthropic's Terminal Agent History Matters
Claude Code origin story routing turns Anthropic's official history into an operator checklist for terminal agents, permissions, context, and parallel swarms.

Claude Code security review routing: Alberta turns 466M lines into a governed agent lane
Claude Code security review routing moves from demo to government scale as Alberta scans 466M lines, runs 50 agents, and keeps human approval in the loop.