One million tokens of context, a price tag that’s almost embarrassing to compare, and a genuinely uncomfortable list of things my own code had been quietly getting away with for months.
I’ll admit the motive up front: I didn’t try this because I was curious about DeepSeek’s architecture. I tried it because the bill for running my usual full-codebase audit through a frontier model was starting to feel silly, and I’d seen enough people mention DeepSeek V4’s pricing to wonder if it was too good to be true.
It mostly wasn’t. Here’s exactly what I did, what it found, and where it genuinely fell short.
DeepSeek V4 shipped as a preview on April 24, 2026, and moved to full general availability on July 20, 2026. It comes in two flavors: V4-Pro, a 1.6-trillion-parameter mixture-of-experts model with 49 billion active parameters per token, and V4-Flash, a smaller 284-billion-parameter variant with 13 billion active. Both ship with a 1-million-token context window and support up to 384,000 tokens of output in a single response. It’s released under the MIT license, with weights available on Hugging Face genuinely open, not open-in-name-only.
The number that actually got my attention was the price. V4-Pro runs $0.435 per million input tokens and $0.87 per million output tokens, with cached input priced down at roughly $0.0036 per million. For context, that’s a small fraction of what Claude Opus or GPT-5.5-class models charge for the same job one comparison I found puts V4-Pro at somewhere around 1/34th the input cost of Claude Opus 4.7. I’m not going to pretend I did the arithmetic more precisely than that, but even a rough version of that ratio is enough to change how you think about running an expensive task like a full-repository audit.
I used V4-Pro specifically. It has an architectural detail worth knowing about if you’re doing exactly what I did: a hybrid attention mechanism combining what DeepSeek calls CSA and HCA, which makes long-context calls meaningfully cheaper per token than the previous generation at a full 1-million-token prompt, V4-Pro reportedly uses about 27% of the inference compute that V3.2 needed for the same call.
This is the part that felt genuinely different from how I usually work. Normally, auditing a real codebase means chunking it feeding a model file by file, or module by module, and hoping it retains enough of the earlier context to catch cross file issues by the time it reaches the later ones.
With a full 1 million token window as the default, not a premium tier you have to pay extra to unlock, I didn’t have to do that. I pointed it at a moderate-sized internal project a few hundred files, a mix of an API layer, a data pipeline, and a reasonably old frontend that had accumulated its share of “we’ll fix this later” comments and loaded essentially the whole thing in one pass.
The API itself speaks both OpenAI’s ChatCompletions format and Anthropic’s Messages format, so it dropped into my existing Claude Code setup without needing a translation layer or proxy. That was a genuinely pleasant surprise I expected at least one afternoon of adapter writing, and didn’t need it.
I asked for a straightforward, honest audit: security concerns, dead code, obvious inefficiencies, and anywhere error handling looked incomplete. No leading questions, no hints about where I already suspected problems existed.
It caught a real security gap. One of our internal endpoints was missing input validation on a field that, further downstream, fed directly into a database query. Nothing catastrophic in isolation, but exactly the kind of gap that compounds badly later. It flagged this without me pointing anywhere near that file.
It found meaningfully more dead code than I expected. A handful of utility functions that hadn’t been called anywhere in the codebase for what git blame confirmed was several months, quietly still being imported and bundled. Small in isolation, but the kind of thing that accumulates into real weight over a year of “we’ll clean it up later.”
**It flagged an inefficient query pattern **a classic N+1 problem in a loop that fetched related records one at a time instead of batching them, buried in a part of the code I honestly hadn’t looked at closely in a while.
It caught inconsistent error handling across the API layer specifically some routes returning structured error objects, others letting raw exceptions leak straight to the response. This is exactly the kind of cross-file consistency issue that’s genuinely hard to catch when you’re reviewing chunk by chunk, because no single file looks wrong in isolation. It only becomes obvious when something can see the whole pattern at once which is precisely what the full-context pass was for.
Where it was noticeably weaker: it occasionally over flagged stylistic differences as if they were substantive issues, and once suggested “fixing” a function that was actually intentionally structured that way for a reason documented two files away that it apparently didn’t weight heavily enough. Nothing dangerous, but a reminder that a full-repo pass still benefits from a human doing the final triage on what’s a real issue versus a style preference.
I don’t love leaning entirely on benchmark tables, but they’re worth knowing before you decide whether this fits your own workload.
The SWE-bench Verified number is the one I’d flag as most meaningful for real engineering work, because it’s specifically about resolving genuine, verified GitHub issues and landing statistically tied with a frontier closed model, from an open-weights model priced at a fraction of the cost, is a genuinely significant milestone for where open models are right now.
A few things I ran into that are worth knowing before you try this yourself.
It’s text-only. No vision, no image or diagram input, in either shipped variant. If part of your audit involves reading architecture diagrams or screenshots, you’ll need something else alongside it.
Quantization varies by provider. Most serverless hosts running V4 quantize activations to fp8 to cut cost, which shifts output slightly away from the reference weights. If you need output that matches the published weights exactly, you have to specifically seek out a provider running full 16-bit precision it’s not the default everywhere.
There’s a real API migration deadline to know about. DeepSeek’s legacy model aliases deepseek-chat and deepseek-reasoner stopped working entirely as of July 24, 2026, at 15:59 UTC, with no grace period. If you're building on this today, use the explicit V4 model IDs from the start rather than the old alias names.
**The **reasoning_content field trips up popular clients. Both V4 variants support Thinking and Non-Thinking modes natively, and the way reasoning output gets returned has apparently broken more than one popular API client that wasn't built expecting it. Worth testing your integration carefully rather than assuming it'll behave like whatever you were using before.
This is the part that made the whole exercise worth writing about. Running the same full-repository audit through a frontier closed model at, conservatively, $5-plus per million input tokens would have put my one off audit well into meaningful territory once you account for a full 1 million token repository load plus the output. Running the identical pass through V4-Pro landed at a small fraction of that. To be fair to the closed-model side of this comparison: I don’t think V4-Pro fully replaces a frontier model for the hardest, most nuanced architectural judgment calls the kind of thing where you’re weighing tradeoffs that don’t have an obviously correct answer. But for a first-pass audit surfacing the concrete, verifiable issues before you bring in more expensive judgment for the genuinely ambiguous ones it did the job at a cost that makes running this kind of audit monthly instead of quarterly suddenly reasonable.
Yes, and I already have I’ve started running this as a lighter, more frequent first pass before reaching for a pricier model on anything genuinely ambiguous. The 1million token context window being the default, not an upsell, is the detail that actually changes my workflow, not just my bill. I stopped chunking my repo into artificial pieces and just let the model see what I see.
If you’re sitting on a codebase that’s accumulated a few months of “we’ll deal with that later,” this is a genuinely cheap way to find out exactly what “that” is before it becomes a much more expensive problem to fix later. AI code reviews don’t have to be expensive to be useful. DeepSeek V4 proved that frequent, full repository audits are finally practical instead of something you save for special occasions. For me, that’s a much bigger workflow shift than any benchmark score.
If you’ve run a similar full-repo audit with an open-weight model, I’d love to hear what it turned up for you in the comments. And if this saves you the cost of your next audit, a clap goes a long way. I Gave DeepSeek V4 My Entire Codebase. Here’s What It Found. was originally published in Stackademic on Medium, where people are continuing the conversation by highlighting and responding to this story.