DeepSeek V4 in Claude Code: I Built a Complete Skill for $3 -- Here's What Worked and What Didn't

TL;DR -- DeepSeek V4 works inside Claude Code via four environment variables. I gave it one vague instruction, and it autonomously built a 532-line image-generation Skill, wrote a full article, and produced matching illustrations. API cost: $3. It reads documentation before coding, makes smart architectural decisions, and knows its own limits. But Skill invocation is unreliable, and reasoning depth trails Opus 4.6. Good for long-context scanning and greenfield builds. Not ready to be your only coding agent backend.

The question arrives about once a quarter, phrased slightly differently each time, and it is never really about the model: is the cheaper one good enough for what we do? The honest answer is never yes or no - it is a list of jobs where it holds and jobs where it does not. Asked that way it has no answer, because "good enough" is a property of the task rather than of the tool. The useful version splits work into jobs where dropping a tier costs nothing and jobs where it quietly costs a day. So this got tested rather than argued, at a total spend under five dollars. If you are deciding whether your AI assistant for business can drop a tier, this is the shape of the answer you want.

Most DeepSeek V4 reviews stop at "here's how to configure the environment variables." They walk through the DeepSeek V4 Claude Code setup, verify the connection, and call it a day. They run a hello-world prompt and publish the tutorial.

I wanted to know something different: what happens when you give DeepSeek V4 a real task inside Claude Code -- not a demo, but a vague, open-ended assignment -- and walk away?

So that is what I did. One instruction, no file paths, no code scaffolding, no step-by-step plan. Just natural language describing what I wanted. Then I left my desk.

When I came back: 15 files, 532 lines of Python, a complete article, and a set of visually consistent illustrations. All produced autonomously by DeepSeek V4-Pro running inside Claude Code. The API bill? About $3.

This article covers the full picture -- setup, the real test, what went right, what broke, and the one lesson most model reviews completely skip.

What Is DeepSeek V4 and Why Should Coding Agent Users Care?

DeepSeek shipped V4 Preview on April 24, 2026. Two tiers: deepseek-v4-pro (1.6 trillion total parameters) and the lighter deepseek-v4-flash. Both come with 1M token context and 384K max output by default.

A million tokens of context is not a marketing gimmick. That is roughly 750,000 words -- enough to fit three full novels into a single conversation window. For developers, it means feeding an entire codebase or a comprehensive knowledge base without chunking or summarization.

Three things matter for Claude Code users specifically:

It is text-only. No images, audio, or video -- not as input, not as output. If your workflow needs image understanding, route those tasks to a multimodal model like GPT-5 or Gemini. V4 can call external image generation APIs (which is exactly what happened in my test), but it cannot see or analyze images itself. This is a meaningful difference from Claude Opus 4.6, which handles multimodal input natively. See the Claude Code documentation for the full list of supported capabilities.

The Anthropic-compatible endpoint is official. DeepSeek exposes /anthropic as a documented integration path. This is not a hack -- their own coding agents guide walks through the Claude Code setup.

The pricing makes experimentation cheap. Here is the current rate card:

A typical coding session -- 50K tokens in, 10K tokens out -- costs under $0.15 with Pro. Under $0.02 with Flash. At these rates, running experiments costs less than a coffee.

DeepSeek has stated that pricing may change after the preview period. Check their official pricing page for current rates.

How to Set Up DeepSeek V4 in Claude Code (Step by Step)

Five steps. The whole thing takes under five minutes if you already have a DeepSeek API key.

Step 1: Get your API key. Sign up at platform.deepseek.com, add credits, and generate an API key (starts with sk-).

Step 2: Clear old Anthropic credentials. If you have previously logged into Claude with an Anthropic account on this machine, residual OAuth tokens will conflict with the DeepSeek endpoint. This is the number one cause of persistent 401 errors after switching providers. Clear your cached credentials before proceeding -- check ~/.claude/ for any stored tokens or session files.

Step 3: Add the configuration. Add the following to the env section of ~/.claude/settings.json:

"env": {
  "ANTHROPIC_BASE_URL": "https://api.deepseek.com/anthropic",
  "ANTHROPIC_AUTH_TOKEN": "sk-your-deepseek-key-here",
  "ANTHROPIC_MODEL": "deepseek-v4-pro[1m]",
  "ANTHROPIC_DEFAULT_HAIKU_MODEL": "deepseek-v4-flash",
  "ANTHROPIC_DEFAULT_SONNET_MODEL": "deepseek-v4-pro",
  "ANTHROPIC_DEFAULT_OPUS_MODEL": "deepseek-v4-pro",
  "CLAUDE_CODE_SUBAGENT_MODEL": "deepseek-v4-pro",
  "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1",
  "CLAUDE_CODE_DISABLE_NONSTREAMING_FALLBACK": "1",
  "CLAUDE_CODE_EFFORT_LEVEL": "max",
  "API_TIMEOUT_MS": "3000000",
  "CLAUDE_CODE_MAX_OUTPUT_TOKENS": "384000"
}

Step 4: Avoid three common pitfalls.

Step 5: Verify. Open a new terminal, launch Claude Code, and ask: "What model are you running?" If the response mentions deepseek, you are connected.

Cost-Saving Configuration

The template above routes everything through Pro. For daily use, I recommend splitting: Pro for your main model, Flash for subagents. Change CLAUDE_CODE_SUBAGENT_MODEL to deepseek-v4-flash. Same workflow, roughly 70% less on the API bill.

I was wrong about needing Pro for everything. After testing both tiers, Flash handles lightweight subtasks -- file scanning, formatting, translation -- without noticeable quality loss. Save Pro for the decisions that matter.

The Real Test: Building a Skill From a Single Vague Prompt

Setup guides are everywhere. I wanted to test something harder: can DeepSeek V4 handle ambiguity?

I gave it one instruction:

Reference the existing image Skill, build a new one using GPT Image 2, then use it to generate illustrations for this article. Write the whole process up as a blog post in my writing style.

No file paths. No code skeleton. No step-by-step breakdown. Just one paragraph of natural language.

Then I got up and did something else.

Phase 1: It Read the Rules First

I expected it to start coding immediately. It did not.

V4 navigated to my knowledge base and read my writing style guide end to end. It picked up the third-person voice I use, the transitional phrases I prefer, and a 24-item banned word list for AI-sounding language.

After the style guide, it pulled three official GPT Image 2 documentation pages. Three search rounds, six page fetches, tens of thousands of words of technical documentation.

Only then did it write its first line of code.

This matters. The "read first, build second" pattern is exactly what separates useful agent output from generic slop. But I should note: this behavior was not consistent across every test. In a different scenario -- taking over an existing project -- V4 skipped the research phase entirely and started modifying files without checking constraints. More on that in the failure section.

Phase 2: It Found Its Own Reference Materials

My knowledge base contained two resources V4 had never seen. It found them on its own.

One was a 17-file, 30,000-word Skill development specification covering naming conventions, directory structure, step formats, script boundaries, and error classification. The other was an existing image-generation Skill I had built previously using a different model.

V4 scanned both, then made a deliberate architectural choice: it did not copy the old Skill. It recognized that GPT Image 2 handles Chinese text rendering at pixel-level precision, making the reference-image overlay from the old Skill unnecessary. It stripped the overlay pipeline and replaced it with a visual parameter matrix.

But it kept the cloud storage tri-mode (Tencent Cloud COS, Cloudflare R2, local) and the language gate. It could tell the difference between infrastructure (keep) and mechanism (upgrade).

Phase 3: The Output

After research and planning, it built:

A style system. Content split into 7 domains (tech, finance, health, education, lifestyle, history, general), each with 5 visual parameter dimensions (color, lighting, composition, layout, texture), plus an auto-matching table for 50+ keywords.

The core mechanism: a visual signature. Every illustration in a single article shares one set of style parameters, injected at the start of each image prompt. That is why all the images in a set look like they belong together.

Two Python scripts. generate_fal.py (359 lines, calls fal.ai for image generation) and upload_cos.py (173 lines, uploads to cloud storage). 532 lines total. Zero syntax errors on static analysis.

Syntax-clean is not production-ready, though. Edge cases -- retry logic on API failures, timeout handling for oversized images, graceful degradation when the image API is down -- all need real-world testing under load before you trust it in a pipeline.

One full article. V4 went back to the knowledge base, read the writing style guide again, checked a library of high-performing articles for structural patterns, then wrote. The draft needed about 40-50% manual editing to sound natural -- usable as a strong starting point, but not publishable as-is.

The Bill: $3

One session, start to finish, no context compression. Context usage: 21% of the 1M window. API cost: approximately $3.

I did not use the cost-saving configuration for this test -- I wanted to see the ceiling. With Flash handling subagents, the same workflow would cost under $1.

The remaining 79% of context could fit four more tasks of equal complexity.

What DeepSeek V4 Got Right

Proactive context gathering. Most models guess. V4 reads. It went to the style guide, the Skill spec, and the official API docs before writing a single line of code. This alone prevented the entire class of "it works but doesn't match my conventions" failures.

Smart add/subtract decisions. It did not copy-paste the old Skill and swap the API endpoint. It analyzed what each component did, decided which parts were infrastructure worth keeping, and which were mechanisms worth replacing. That requires understanding why a design exists, not just what it does.

Self-aware limitations. At the end of the Skill documentation it generated, V4 added a note -- unprompted -- stating that the Skill had been structurally validated but not end-to-end tested on real articles. It knew the difference between "I built it" and "I proved it works." I have seen more experienced human developers skip that distinction.

Where DeepSeek V4 Fell Short

Skill invocation detection is unreliable -- and this is the biggest issue. When I told V4 to "check something on the server," it had access to a dedicated server management Skill. Sometimes it used it. Sometimes it forgot the Skill existed and tried to accomplish the task manually. The trigger had to be extremely explicit before V4 would route to the right tool.

Worse: on a separate test where I asked V4 to take over an existing project with a detailed specification and project-level CLAUDE.md, it skipped the global search, ignored the constraint files, and started modifying code twenty minutes before I caught it. Constraint adherence fails under complexity. GLM-5.2, tested on the same task, was noticeably more reliable at following existing project rules.

Occasional language mixing. In a workflow configured for English output, V4 would occasionally drop in a line of Chinese -- typically at the end of a step log, something like「执行成功」(execution completed successfully) Minor, fixable, but it happened 2-3 times per session.

Edit tool precision issues. Claude Code's Edit tool requires exact string matching. V4 sometimes "remembered approximately" -- missing a space, slightly misquoting a variable name -- causing the first edit attempt to fail. It recovered by re-reading and retrying, but it burned extra tokens each time.

Output stalls on long generation. While generating the 359-line Python script, output froze at roughly the 70% mark for nearly a minute. No error, no timeout -- just silence. My hand was on Escape, ready to kill the process. It resumed on its own. For production batch workflows, that unpredictability is a liability.

Reasoning depth trails Opus 4.6. On tasks requiring cross-file inference across a large knowledge base, V4 was slower to connect the dots and occasionally made shallower decisions. This is not a bug -- it is a capability gap at the model level. Opus still has the edge on deep, multi-step reasoning chains.

When to Use DeepSeek V4 (and When Not To)

Not every task deserves the same model. Here is how I route DeepSeek V4 in my Claude Code workflows after a week of testing:

My daily DeepSeek V4 setup in Claude Code: V4 handles long-context scanning, draft generation, and bulk material processing. Mission-critical code and strict-constraint tasks stay on Opus or GLM. I will re-evaluate when V4 exits preview -- especially whether the Skill invocation issue gets fixed. That single weakness is what keeps V4 out of my primary coding slot.

The Lesson Most Reviews Miss: Your Knowledge Base Is the Real Moat

This is the part I need to be direct about. If you copy my prompt, plug it into a fresh DeepSeek V4 instance with no knowledge base, you will get a functional Skill skeleton. Maybe. It will not match your naming conventions. It will not follow your error handling patterns. It will not write in your voice.

V4 produced quality output in my test because it had three things to draw from:

• A 17-file Skill development specification (30,000 words of naming rules, directory conventions, step formats, validation patterns). Without it, the Skill runs but has no consistency with the rest of the system.
• An existing image-generation Skill as a reference architecture. Without it, V4 would have invented everything from scratch -- and the result would not integrate with existing tools.
• A brand identity layer (writing style guide, structural patterns, audience profile). Without it, the article reads like a generic tech blog post.

The model is the engine. The knowledge base is the fuel. Swap the engine and the car still drives. Remove the fuel and nothing moves.

Every few weeks, a new model drops and developers scramble to switch. I get it -- I used to do the same thing. But that energy is misplaced. Models are commodities -- everyone gets access to the same capabilities within weeks of launch. The lasting advantage is the knowledge base you build around your work: your conventions, your specifications, your accumulated decisions, your institutional memory.

Here is a concrete example. When DeepSeek V4 launched, I plugged it into my existing knowledge base and got high-quality output on day one. Developers without that foundation spent days writing custom prompts to get similar results -- and their output still lacked the consistency that comes from structured specifications.

I have been building my knowledge base for over a year. It contains style guides, Skill specifications, workflow definitions, editorial standards, and tool configurations. When a new model arrives, I plug it in and it immediately operates at a higher level -- because the context is already there.

I was wrong about this for a long time. I used to chase model releases, thinking the next one would finally "get it right" without setup. It never did. The setup is the work. The knowledge base is the product.

Build yours. It compounds.

Ready-to-Use Prompt: Decide Whether DeepSeek V4 Fits as a Claude Code Backend for Your Task

What this does: Confirms the four-env-var setup, scores your task against DeepSeek V4's real strengths and shortcomings, decides whether it can be your only backend, routes cost-sensitive work to it, and re-anchors on the real moat — your knowledge base, not the model.
Based on: DeepSeek V4 in Claude Code: I Built a Complete Skill for $3 — Here's What Worked and What Didn't — https://aiworkflowpro.com/deepseek-v4-claude-code/
Time to run: ~4 minutes

Copy this prompt into Claude Code, ChatGPT, or any AI assistant:

ROLE: You are an AI-backend evaluator. Your job: decide whether DeepSeek V4 fits as a Claude Code backend for one task — where it shines, where it falls short, and whether it can be the only backend — while keeping the real moat (your knowledge base) in view.

CONTEXT — DEEPSEEK V4 FIT DECISION:
DeepSeek V4 runs inside Claude Code via four environment variables and can build a full Skill from one vague prompt for about $3 — it reads docs before coding, makes smart architectural calls, and knows its own limits. But it is not a flat upgrade: Skill invocation is unreliable, and reasoning depth trails Opus 4.6. So it fits some jobs (long-context scanning, greenfield builds, cost-sensitive volume) and not others (reliability-critical orchestration, hard reasoning). The lesson most reviews miss: swapping models is cheap and transient — your knowledge base (CLAUDE.md, context engineering) is the real moat, because any model's output rises or falls on the context you feed it.

INPUTS (fill in before running):
- TASK: YOUR_TASK_HERE (the job — greenfield build, long-context scan, tricky bug, orchestration, etc.)
- RELIABILITY_NEED: YOUR_STAKES_HERE (must-work-unattended / best-effort / exploratory)
- IS_ONLY_BACKEND: YOUR_ANSWER_HERE (would DeepSeek V4 be your only coding agent backend? yes/no)
- BUDGET_PRESSURE: YOUR_CONCERN_HERE (cost-sensitive / moderate / cost-no-object)

METHOD — 6 STEPS:

Step 1 — Confirm setup is viable
Verify the four-environment-variable setup is in place (model base URL, API key, model name, the Claude Code provider override). If not configured, that is step zero — no evaluation proceeds on a hello-world connection.

Step 2 — Match task to DeepSeek V4's strengths
Score TASK fit: long-context scanning and greenfield builds → high fit (reads docs first, smart architectural calls, knows its limits). Tricky reasoning or reliability-critical work → low fit (reasoning trails Opus 4.6).

Step 3 — Check the known shortcomings
Flag where it falls short for TASK: unreliable Skill invocation (do not depend on auto-Skill calls) and shallower reasoning than frontier models. If RELIABILITY_NEED = must-work-unattended and the task leans on either weakness, reject V4 for this task.

Step 4 — Decide backend role
If IS_ONLY_BACKEND = yes and the task mix includes reliability-critical or hard-reasoning work, do not make V4 the only backend — pair it with a frontier model for those tasks. V4 is a strong secondary/cost-saver, not a universal replacement.

Step 5 — Factor cost
If BUDGET_PRESSURE = cost-sensitive and TASK is a V4 strength (Step 2 high), V4's ~$3-per-Skill economics win — route volume there. If cost is no object and the task is a weakness, use the frontier model; the savings are not worth the reliability hit.

Step 6 — Re-anchor on the real moat
State the lesson: the model swap is cheap and transient; the knowledge base (CLAUDE.md, context engineering, your specs) is the real moat. Whatever the verdict, the highest-leverage move is strengthening context, not chasing the model — V4's $3 Skill succeeded on the strength of the surrounding context, not the model alone.

RULES:
- Do not make DeepSeek V4 your only backend if your task mix includes reliability-critical or hard-reasoning work.
- Do not depend on its Skill invocation for must-work-unattended tasks — it is unreliable.
- Route cost-sensitive volume (greenfield, long-context scan) to V4; route hard reasoning to a frontier model.
- The knowledge base is the moat — context quality beats model choice; never optimize the model before the context.

OUTPUT FORMAT:
Output six sections:
1. **Setup check** — the four env vars present? (Y/N) + any missing.
2. **Task fit** — fit score (high/low) + the strength it matches.
3. **Shortcoming flags** — Skill-invocation + reasoning-depth risk for this TASK.
4. **Backend role** — V4 as only / secondary / rejected + why, against IS_ONLY_BACKEND.
5. **Cost routing** — whether V4's economics win for this TASK + budget.
6. **Moat reminder** — the one highest-leverage context improvement to make regardless of verdict.

Save as @templates/deepseek-v4-claude-code.md and run before routing a task to DeepSeek V4, then re-run when the task type, reliability need, or backend strategy changes.

Frequently Asked Questions

How do I connect DeepSeek V4 to Claude Code?

Set four environment variables: point ANTHROPIC_BASE_URL to https://api.deepseek.com/anthropic, put your DeepSeek API key in ANTHROPIC_AUTH_TOKEN (not ANTHROPIC_API_KEY), set ANTHROPIC_MODEL to deepseek-v4-pro[1m], and disable NONSTREAMING_FALLBACK. Open a new terminal, launch Claude Code, and ask it which model it is running. It should respond with deepseek.

Should I use V4-Pro or V4-Flash for coding?

Use V4-Pro as your main model for reasoning-heavy and complex tasks. Use V4-Flash for subagent operations, file scanning, and lightweight jobs. The input cost difference is roughly 12x. Splitting tiers can cut your total API spend by 70% with minimal quality loss on the subtasks.

Is DeepSeek V4 ready to replace Claude or GPT as a primary coding agent?

Not yet. V4 handles open-ended greenfield tasks well and excels at long-context work. But Skill invocation detection, constraint adherence on existing projects, and deep multi-step reasoning are weaker than Claude Opus 4.6 or GLM-5.2. Use it as a cost-effective complement -- long scans, drafts, bulk processing -- while keeping a frontier model for critical code paths.

How much does a typical Claude Code session cost with DeepSeek V4?

A standard coding session (50K input, 10K output) costs under $0.15 with Pro, under $0.02 with Flash. The full autonomous Skill build described in this article -- including document reading, code generation, and article writing -- cost approximately $3 with Pro-only routing.

Why test a model inside an agent workflow instead of running benchmarks?

Benchmarks test whether a model can answer a question. Agent workflows test whether it can read existing rules, invoke the right tools, maintain context across dozens of files, and deliver a complete, specification-compliant output. In production, model capability must land inside a system of documents, conventions, tools, and validation loops. A model that scores well on benchmarks but ignores your project's CLAUDE.md is not useful.

Configuration Reference

Full Environment Variable Template

"env": {
  "ANTHROPIC_BASE_URL": "https://api.deepseek.com/anthropic",
  "ANTHROPIC_AUTH_TOKEN": "sk-your-deepseek-key-here",
  "ANTHROPIC_MODEL": "deepseek-v4-pro[1m]",
  "ANTHROPIC_DEFAULT_HAIKU_MODEL": "deepseek-v4-flash",
  "ANTHROPIC_DEFAULT_SONNET_MODEL": "deepseek-v4-pro",
  "ANTHROPIC_DEFAULT_OPUS_MODEL": "deepseek-v4-pro",
  "CLAUDE_CODE_SUBAGENT_MODEL": "deepseek-v4-pro",
  "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1",
  "CLAUDE_CODE_DISABLE_NONSTREAMING_FALLBACK": "1",
  "CLAUDE_CODE_EFFORT_LEVEL": "max",
  "API_TIMEOUT_MS": "3000000",
  "CLAUDE_CODE_MAX_OUTPUT_TOKENS": "384000"
}

Cost-Saving Variant

Change CLAUDE_CODE_SUBAGENT_MODEL to deepseek-v4-flash. Main model stays on Pro for quality; subagents run on Flash for cost efficiency. In my testing, this dropped the total API cost from ~$3 to under $1 for the same workflow.

Official Documentation

• DeepSeek Pricing
• Claude Code Integration Guide
• Anthropic-Compatible API

Related Reading

• Claude Code Complete Guide 2026 -- The full Claude Code reference, from setup to advanced workflows
• Claude Code Skills: Build Custom Tools That Actually Work -- If you want to build Skills like the one in this test, start here
• Claude Code CLAUDE.md: The Configuration File That Changes Everything -- How to set up the project-level instructions V4 reads from
• Claude Code MCP Connections: Extend Your Agent's Reach -- Connect Claude Code to external tools and services
• Claude Code Prompt Patterns That Actually Work -- The prompting techniques behind the test in this article
• Common Claude Code Tutorial Mistakes (and How to Avoid Them) -- Pitfalls to watch for when following setup guides

— hh