TL;DR — DeepSeek ships an Anthropic-compatible API endpoint that lets Claude Code treat DeepSeek V4 Pro like a drop-in replacement for Claude Opus. The setup is eight environment variables, and it works — including tool calling, sub-agent spawning, and native web search. At $0.435/M input tokens (permanent price after the initial launch promo), it’s roughly 4–17× cheaper than Claude Opus 4.7. This is a practical guide based on a real setup we run daily.

Why This Matters

Claude Code is Anthropic’s terminal-based AI coding agent. It reads your codebase, runs bash commands, spawns sub-agents, and writes edits — all through Anthropic’s API. The problem: it only speaks Anthropic’s message format. You can’t point it at OpenAI, Gemini, or a local Ollama instance without a translation layer.

DeepSeek solved this the obvious way: they built an Anthropic-compatible API endpoint at https://api.deepseek.com/anthropic and documented the Claude Code integration on day one. No proxy, no wrapper, no SDK fork. Just environment variables.

We’ve been running this setup in production — managing a multi-project workspace with six active sub-projects, MCP servers, and daily coding sessions. Here’s what works, what doesn’t, and the exact configuration.

Step 1: Get a DeepSeek API Key

Sign up at platform.deepseek.com and create an API key. DeepSeek uses prepaid balance — top up what you need, no subscription.

Two models matter for Claude Code:

After the initial launch promotion ends (2026-05-31), DeepSeek permanently adjusts the official price to 1/4 of the original — so $0.435/M input becomes the new normal, not a temporary deal. That’s still 34× cheaper than Claude Opus 4.7 ($15/M input, ~$75/M output) on input tokens. V4 Flash stays as-is.

Cache hits are absurdly cheap: $0.003625/M for V4 Pro and $0.0028/M for V4 Flash. Claude Code generates a lot of repetitive context (system prompts, CLAUDE.md files, tool definitions), so cache hits dominate real usage.

Step 2: Configure Environment Variables

Create a shell script (we call ours claude.sh) and source it before launching Claude Code:

1
2
3
4
5
6
7
8

export ANTHROPIC_BASE_URL=https://api.deepseek.com/anthropic
export ANTHROPIC_AUTH_TOKEN=<your-deepseek-api-key>
export ANTHROPIC_MODEL=deepseek-v4-pro[1m]
export ANTHROPIC_DEFAULT_OPUS_MODEL=deepseek-v4-pro[1m]
export ANTHROPIC_DEFAULT_SONNET_MODEL=deepseek-v4-pro[1m]
export ANTHROPIC_DEFAULT_HAIKU_MODEL=deepseek-v4-flash
export CLAUDE_CODE_SUBAGENT_MODEL=deepseek-v4-flash
export CLAUDE_CODE_EFFORT_LEVEL=max

Then launch:

1
2
3

source claude.sh
cd /path/to/your/project
claude

What each variable does:

The [1m] suffix on model names is a DeepSeek convention for requesting the 1M-token context window. Without it, you get the default context length.

Step 3: Understand Model Mapping

DeepSeek does automatic model name mapping. When Claude Code internally requests claude-opus-4-7, DeepSeek’s API maps it:

claude-opus-*    →  deepseek-v4-pro
claude-sonnet-*  →  deepseek-v4-flash
claude-haiku-*   →  deepseek-v4-flash

This means you don’t need to patch Claude Code’s source. When the agent decides it needs “Opus-level” reasoning, DeepSeek routes it to V4 Pro. When it wants Haiku for a fast sub-agent, it gets V4 Flash.

We explicitly set the model variables anyway (rather than relying on mapping) because it gives us control over which model handles sub-agents. V4 Flash is fast enough for search and file-reading sub-agents, and it’s 3× cheaper than V4 Pro on input.

What Actually Works

Tool Calling

DeepSeek’s Anthropic API fully supports tool_use and tool_result message types. Claude Code’s entire agent loop is built on tool calling — Read, Write, Edit, Bash, Grep, Glob — and all of it works.

Message: array, type = "tool_use"
  - id:           Fully Supported
  - input:        Fully Supported
  - name:         Fully Supported
  - cache_control: Ignored

Message: array, type = "tool_result"
  - tool_use_id:  Fully Supported
  - content:      Fully Supported
  - is_error:     Ignored

Sub-Agent Spawning

Claude Code spawns specialized sub-agents (Explore for file search, Plan for architecture, etc.) using the Agent tool. Each sub-agent is itself a tool-calling loop with restricted permissions. This works on DeepSeek — we’ve tested multi-agent sessions where the main V4 Pro agent spawns V4 Flash sub-agents for file search, and the results flow back correctly.

Web Search (the surprising part)

This is the feature that caught us off guard. DeepSeek’s API natively supports Claude Code’s built-in Web Search tool. When the model determines your question needs web results, it invokes the search tool through DeepSeek’s own search infrastructure — not Anthropic’s.

From DeepSeek’s documentation:

“The DeepSeek API natively supports the Web Search feature in Claude Code. When using Claude Code, if the model determines that your question requires a web search, it will invoke the Web Search tool and perform the search through the API provided by DeepSeek.”

In practice: ask Claude Code “what’s the latest version of LangGraph?” and it will trigger a web search, get results, and summarize them — all through DeepSeek. The web_search_tool_result message type is fully supported in the API.

Cost caveat: Each web search triggers additional LLM API calls to summarize the retrieved content. DeepSeek bills these as normal token usage. A single search-then-summarize cycle might consume 5–20K extra input tokens.

Thinking Mode

DeepSeek V4 supports thinking mode (extended reasoning). The thinking field in the API is supported, though budget_tokens is ignored — DeepSeek manages its own reasoning budget internally. Setting CLAUDE_CODE_EFFORT_LEVEL=max gives the model maximum latitude to think.

Streaming

Fully supported. Responses stream token-by-token just like native Claude.

What Doesn’t Work

Being honest about limitations matters. DeepSeek’s Anthropic API is not a perfect clone — it’s a pragmatic subset.

No Image or Document Input

array, type = "image"     →  Not Supported
array, type = "document"  →  Not Supported

You can’t paste screenshots or upload PDFs through Claude Code when using DeepSeek. If your workflow involves vision tasks (analyzing UI mockups, reading diagrams), you need native Claude or a vision-capable model for those sessions.

No Prompt Caching

cache_control  →  Ignored (on tools, messages, and tool results)

DeepSeek has its own context caching (cache hits are priced separately), but the Anthropic-compatible endpoint ignores cache_control markers. Caching happens at DeepSeek’s discretion based on content similarity, not explicit breakpoints.

No MCP Tool Passthrough

array, type = "mcp_tool_use"     →  Not Supported
array, type = "mcp_tool_result"  →  Not Supported

MCP (Model Context Protocol) tools work differently — they’re handled client-side by Claude Code, not server-side by the API. So MCP tools like SearXNG, filesystem watchers, or database connectors still work because Claude Code intercepts them before they hit the API. The “not supported” here means DeepSeek’s API won’t process MCP messages natively, which doesn’t affect actual functionality.

Minor Field Ignorances

• top_k — ignored
• anthropic-beta / anthropic-version headers — ignored
• stop_sequences — fully supported
• container, mcp_servers, service_tier — ignored

None of these affect core Claude Code functionality.

Cost Comparison

A realistic Claude Code session: ~500K input tokens (system prompt + context + tool definitions) and ~50K output tokens.

With the main agent on V4 Pro and sub-agents on V4 Flash, a typical mixed session costs around $0.15–0.30. That’s roughly 30–70× cheaper than Claude Opus direct — and it’s the permanent price, not a limited-time promo.

The cache hit pricing makes repetitive sessions (same project, same CLAUDE.md, same tool definitions) even cheaper. Our workspace loads ~80K tokens of context on every session start — most of that hits cache at $0.003625/M.

Real-World Tips

Use a wrapper script

Don’t export environment variables in your .bashrc globally — you’ll accidentally use DeepSeek for tools that need native Claude (like vision tasks). We use a claude.sh script:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

#!/bin/bash
export ANTHROPIC_BASE_URL=https://api.deepseek.com/anthropic
export ANTHROPIC_AUTH_TOKEN=sk-your-key-here
export ANTHROPIC_MODEL=deepseek-v4-pro[1m]
export ANTHROPIC_DEFAULT_OPUS_MODEL=deepseek-v4-pro[1m]
export ANTHROPIC_DEFAULT_SONNET_MODEL=deepseek-v4-pro[1m]
export ANTHROPIC_DEFAULT_HAIKU_MODEL=deepseek-v4-flash
export CLAUDE_CODE_SUBAGENT_MODEL=deepseek-v4-flash
export CLAUDE_CODE_EFFORT_LEVEL=max
export ANTHROPIC_USER_ID="your-username"

exec claude "$@"

Run it with bash claude.sh or source claude.sh && claude.

The ANTHROPIC_USER_ID matters

DeepSeek supports the user_id metadata field for rate limit isolation. Setting ANTHROPIC_USER_ID ensures your requests are bucketed separately from other users on the same API key — useful if you share a key across projects.

V4 Flash for routine work

If you’re doing routine file editing, formatting, or batch operations, swap ANTHROPIC_MODEL to deepseek-v4-flash. It’s 3× cheaper and fast enough for non-reasoning tasks. Save V4 Pro for architecture decisions, debugging, and complex multi-step problems.

The Bottom Line

DeepSeek’s Anthropic-compatible API is the most seamless third-party Claude Code integration available. No proxy server, no SDK patches, no feature gaps on the things that matter (tool calling, sub-agents, web search). The only real limitation is vision — if you need image input, you still need native Claude.

For pure coding work, the cost savings are dramatic enough that there’s no reason not to try it. Eight environment variables, one API key, and you’re running.

The Configuration

1
2
3
4
5
6
7
8
9

# claude.sh — Source this before running `claude`
export ANTHROPIC_BASE_URL=https://api.deepseek.com/anthropic
export ANTHROPIC_AUTH_TOKEN=<your-key>
export ANTHROPIC_MODEL=deepseek-v4-pro[1m]
export ANTHROPIC_DEFAULT_OPUS_MODEL=deepseek-v4-pro[1m]
export ANTHROPIC_DEFAULT_SONNET_MODEL=deepseek-v4-pro[1m]
export ANTHROPIC_DEFAULT_HAIKU_MODEL=deepseek-v4-flash
export CLAUDE_CODE_SUBAGENT_MODEL=deepseek-v4-flash
export CLAUDE_CODE_EFFORT_LEVEL=max

References

• DeepSeek API: Integrate with Claude Code
• DeepSeek API: Anthropic API Compatibility
• DeepSeek API: Models & Pricing
• Claude Code Official Documentation

Built with: Claude Code (latest), DeepSeek V4 Pro + V4 Flash, Node.js 22. Written from a real multi-project workspace running this setup daily.

TL;DR — We reverse-engineered Claude Code’s agent architecture from its TypeScript source to understand how it handles security, complex tasks, and tool permissions. Then we applied those patterns to an open-source Terraria AI bridge that lets players talk to an LLM inside the game. Here’s what we found, what we built, and what we learned about practical agent design.

Why We Cracked Open Claude Code’s Source

Claude Code isn’t just a coding assistant. Under the hood it’s an agent runtime — it spawns sub-agents, manages file permissions, runs bash commands, and decides when to ask the user vs. just doing the thing. We wanted to understand how it works so we could apply the same ideas to a completely different domain: a Terraria game server.

Our project, terra_llm_bridge, connects a Terraria TShock server to an LLM. Players type @ai in chat and get responses — but the LLM can also act: give items, change weather, teleport players, even toggle hardmode. That last one is where we learned our lesson.

The first time a player asked the AI to set the weather to rain, the LLM autonomously decided to call terra_world_hardmode(confirm=True) — toggling irreversible hardmode for the entire server. No player had asked for it. The model just… did it.

We needed a real permission system. So we went looking at how Claude Code does it.

Claude Code’s 7-Layer Permission Architecture

Reading through ~1,500 lines of src/utils/permissions/permissions.ts plus the Agent tool infrastructure (~3,800 lines), a clear architecture emerged. Claude Code doesn’t have one security check — it has seven:

Layer 1a: Deny rules   →  "Never allow Bash(git push --force)"
Layer 1b: Ask rules    →  "Always prompt for Bash(curl *)"
Layer 1c: Tool self-check  →  Each tool's checkPermissions() method
Layer 1d: Tool self-deny   →  Read tool whitelists specific paths
Layer 1f: Content-specific rules  →  "Even in bypass mode, ask for npm publish"
Layer 1g: Safety checks  →  ".git/, .claude/ are ALWAYS bypass-immune"
Layer 2:  Mode-based bypass  →  bypassPermissions / auto / acceptEdits / dontAsk
Layer 3:  YOLO classifier →  AI reads the transcript, decides if safe

The most interesting layer is the YOLO classifier — a separate small model that reads the full conversation transcript and classifies each tool call as safe or dangerous. It’s a two-stage system: a fast classifier for obvious cases, and a deeper thinking classifier for edge cases.

But the layer that matters most for our use case isn’t the AI classifier. It’s how Claude Code structurally prevents certain tools from being called in the wrong context — through tool allowlists, denylists, and sub-agent specialization.

The Agent Pattern: Not Multi-Agent, but Specialized Workers

Claude Code doesn’t use multi-agent “collaboration” in the negotiation sense. It uses a single coordinator that spawns specialized workers:

Main Agent (Tool Calling, all tools)
  │
  ├─ Simple: "read file X" → Read tool
  │
  └─ Complex: "audit this branch" → Agent("Explore")
                                       │
                                       ├─ Tools: [Read, Grep, Glob]  ← whitelist
                                       ├─ Disallowed: [Edit, Write]   ← denylist
                                       ├─ System prompt: "You are a file search specialist"
                                       └─ Returns findings → Main agent acts on them

Each sub-agent type is defined by three things:

1. Tool permissions (allowlist + denylist) — what it can touch
2. System prompt — specialized instructions for its role
3. Model — Explore agents use Haiku ($) for speed; Plan agents use Sonnet for reasoning

The key insight: the main agent doesn’t get more complex. It stays simple but has ONE tool (Agent) that lets it offload complex work. The sub-agent is just another Tool Calling loop with restricted tools and a different prompt.

This architecture is elegant because it composes: each piece is simple, but the combination handles complexity that would overwhelm a single prompt.

How We Applied This to terra_llm_bridge

Our Terraria bridge has a simpler job than Claude Code — 46 tools instead of hundreds, and the “security” problem is “don’t let the AI toggle hardmode when the player asked about weather” rather than “don’t let the AI rm -rf /”. But the patterns transfer directly.

The Problem

Before: our LLM saw all 46 tools at once. When a player asked “give me the strongest armor set,” the LLM would fire wiki_search AND give_item in parallel — researching while also pre-committing to Solar Flare Armor before reading the wiki results. Sometimes it guessed right. Sometimes it gave a summoner player melee gear.

Our Solution: Two-Phase Tool Access

We didn’t add sub-agents — that would be overkill for 46 tools. Instead, we applied the tool restriction pattern at the graph level:

route → llm(research)  ⇄  tool      →  escalate  →  llm(action)  ⇄  authorize  ⇄  tool  →  output
         17 read tools                            46 full tools     keyword gate
         wiki, lookup, status                     give, kick, spawn

The graph has two phases:

Research phase — the LLM gets only 17 read-only tools (wiki_search, item_lookup, player_list, world_info, etc.). It cannot call give_item, kick, spawn, or any destructive tool. It researches first.

Escalate — when the LLM produces text (no more tool calls needed), the graph automatically flips to action mode and injects a hint: “You now have access to ALL tools.”

Action phase — the LLM gets the full 46-tool set and can act on what it found.

This is structurally enforced. Not a prompt suggestion. The LLM physically cannot call give_item during research because the tool isn’t bound.

The Permission Gate

Before the two-phase split, we also added authorize_node — a hard gate between the LLM and ToolNode that checks whether the player’s recent chat messages contain keywords for the tool’s domain:

1
2
3
4
5
6

GATED_TOOLS = {
    "terra_world_hardmode": {"hardmode", "hard mode", "肉山", "困难模式"},
    "terra_player_kick":    {"kick", "踢出", "踢了"},
    "terra_server_stop":    {"stop server", "关服", "停服"},
    # ... 8 more
}

If the player says “set weather to rain” and the LLM tries to call world_hardmode, authorize_node checks: do any of the hardmode keywords appear in the player’s recent messages? No? Blocked. The tool call is replaced with a BLOCKED message before ToolNode ever sees it.

This is a coarse filter — it checks what the player mentioned, not what they requested. “上次打肉山的时候” (last time when I fought Wall of Flesh) would pass the keyword check even though the player didn’t ask for hardmode. But coarse is fine here: the goal is blocking catastrophic mismatches (weather → hardmode), not perfect intent understanding.

What We Chose NOT to Build

No YOLO Classifier

Claude Code’s AI classifier reads the full transcript and classifies tool calls as safe/dangerous. We didn’t build this because:

• It adds latency — an extra LLM call before every gated tool execution
• Terraria chat is low-stakes — a false positive (giving the wrong armor) is fixable
• Keyword matching catches the catastrophic cases

No Sub-Agent Spawning

Claude Code spawns sub-agent processes for complex tasks. We didn’t need this because:

• Terraria tool surface is small (46 tools)
• Multi-turn tool calling handles the complexity we actually face
• Spawning sub-processes for a game chat bot is over-engineering

No ReAct Pattern

The classic Thought → Action → Observation loop would add token overhead without changing our core capability. DeepSeek’s thinking tokens already handle the reasoning, and the two-phase tool access enforces “research before action” more reliably than prompt-based ReAct would.

The Architecture in One Diagram

┌──────────────────────────────────────────────────────────┐
│  Terraria Server (TShock + C# plugin, 24 game hooks)      │
│  Player types "@ai give me the best armor"                │
└──────────────────────┬───────────────────────────────────┘
                       │ JSON webhook
┌──────────────────────▼───────────────────────────────────┐
│  Python aiohttp listener (:9876)                          │
└──────────────────────┬───────────────────────────────────┘
                       │
┌──────────────────────▼───────────────────────────────────┐
│  LangGraph StateGraph                                     │
│                                                           │
│  route  →  llm(research)  ⇄  tool    17 read tools      │
│               │                                           │
│          escalate  →  llm(action)  ⇄  authorize  ⇄  tool │
│                          46 full tools    keyword gate    │
│               │                                           │
│             output  →  broadcast to game chat             │
│                                                           │
│  Memory: AsyncSqliteSaver per player (thread_id)          │
└──────────────────────────────────────────────────────────┘
                       │
         ┌─────────────┴──────────────┐
         ▼                            ▼
   TShock REST API              Terraria Wiki API
   (give / kick / spawn)        (terraria.wiki.gg)

Source Diving Lessons

Reading Claude Code’s source taught us three things that apply to any agent project:

1. Security is layered, not binary. A single confirm parameter is a soft suggestion to the LLM. Real security needs structural enforcement — the LLM shouldn’t be able to call a tool it isn’t authorized to use, same way a web server shouldn’t let you access endpoints without authentication, no matter how nicely you ask.

2. Tool restrictions are the cheapest and most reliable form of safety. Claude Code’s Explore agent is “read-only” not because of a prompt — because Edit and Write aren’t in its tool list. Our research phase isn’t “research-first” because of a prompt — because give_item literally isn’t bound. You can’t prompt-inject your way past a tool that doesn’t exist.

3. Specialization beats complexity. Claude Code’s sub-agents aren’t smarter than the main agent — they’re more constrained. Fewer tools + focused prompt = more reliable behavior. Our two-phase system does the same: constrain first, expand only when ready.

The Project

terra_llm_bridge is an open-source project connecting Terraria game servers to LLMs. It features:

• 24 game hooks — custom C# TShock plugin captures chat, boss kills, deaths, logins, and 20 more events
• 46 admin tools — give items, manage players, control weather, spawn NPCs, manage regions and permissions
• Two-phase agent — research (17 tools) → action (46 tools)
• Hard permission gate — keyword-based authorize_node blocks unauthorized tool calls
• MCP server — same 46 tools exposed to Claude Code for server administration
• Persistent memory — per-player conversation history via LangGraph’s AsyncSqliteSaver

The project is currently in active testing and not yet published on GitHub. We’re running it on a private Terraria server, iterating on the agent architecture before open-sourcing. If you’re interested in the code or want early access, reach out.

Built with: Python 3.14, LangGraph 1.x, DeepSeek (Anthropic-compatible API), C# .NET 9, TShock v6.1.0, aiohttp, httpx.