Author | Rhea, Editors | Li Na, Cen Feng
In every era, people face the same dilemma: whether in grand narratives or life decisions, the problems before them are too complex, while resources and time are insufficient. One must decide what to prioritize and what to give up.
From Hegel's dialectics in 1812, to Marx and Lenin, and then to Mao Zedong's "On Contradiction" written in Yan'an in 1915, over the course of more than a century, this philosophy has ultimately been applied to a very practical issue: in complex entities, there are many contradictions, but what truly matters is identifying the principal contradiction that determines the others.
Today's large language model (LLM) industry is no exception. The main issues currently facing the industry are as follows:
1. The contradiction between the growth rate of model capabilities and the ability to translate these capabilities into reliable outputs (the model is strong, but the outputs lack value).
2. The contradiction between limited computing resources and infinite capability demands (people always complain that AI is too dumb).
3. The contradiction between rapidly declining unit prices and rising actual bills (models are cheaper, but monthly spending is higher).
4. The contradiction between pursuing artificial general intelligence (AGI) and delivering a usable product (simple ones are not useful, and useful ones are not simple).
These contradictions constitute the intertwined, upward-developing industry and opportunities. No one can escape these choices, and DeepSeek is no exception.
We conducted several rounds of empirical testing on deepseek-v4-Pro and Harness: direct API probing, seven coding task runs (four of which were control tests changing only one variable), testing with the context compressed to 920,000 tokens, plus a thorough review of its 198,000 lines of source code and 217,000 lines of tests. We attempted to answer the following questions:
1. What is v4-Pro really like, and what are the differences compared to the flash and preview versions?
2. What is going on with many users reporting that connecting to other Harnesses causes a drop in intelligence?
3. What are the actual usage costs? Can they be quantified?
4. What problems does Harness solve, and who is it suitable for?
In short, the research and usage over the past few days have been quite fascinating. Through v4-Pro and Harness, we can even catch a glimpse of DeepSeek's judgments and cognition regarding technology, human nature, and even the world.
01. Let's Look at the Model First: Where Exactly is DeepSeek V4 Pro Strong?
Pro Likely Underwent a Highly Advanced Post-Training Redo
There are actually quite a few versions of the Pro and Flash models. Let's pull them all out and take a look:
[Pro vs. Flash Full Parameter Comparison, Including Field Definitions]
We will discover two interesting conclusions:
1. Compared to Flash, Pro has made significant progress at the model level in depth, width, attention, expert pool, and intra-expert width.
2. However, these five dimensions are all determined during the pre-training phase and are not variables introduced by post-training.
(One thing is the same: each token actually activates only 6 experts, and both models use 6.)
There is also an Easter egg, which we will call back to later: the factory default model for the DeepSeek Harness is written as deepseek-v4-flash.
[agent-default-model in packages/bundle/base/cordis.patch.yml]
Why was the official release of Pro delayed until after Flash was officially launched? Rumors actually predicted that Pro should have arrived much earlier.
We all know that model pre-training sets the ceiling, while post-training determines the actual performance. If we look back at the past, we will find that the April version of v4-Pro-Preview actually had a flaw: it ranked first in three competitive coding tasks, but its Terminal Bench 2.0 score was only 67.9. On July 31, Flash was officially launched, and the official post showed its Terminal Bench 2.1 score was 82.7, while in the same table, Pro-Preview was 72.1. This means that the Terminal Bench score of the official Flash version is already significantly higher than that of the flagship model Pro. I reasonably speculate that DeepSeek tried out a better post-training method on the Flash version, and therefore, v4-Pro was remelted and reforged.
[Official Self-Test Evaluation Scores of the Current v4 Family and Several Flagship Models]
Looking at the several leaps in v4-pro-0813, Terminal Bench 2.1 exactly jumped from 72.1 to 87.9, DeepSWE from 12.8 to 62.7, and the internal full-stack test set from 41.8 to 71.1.
I also created two problems myself to verify this, because an increase in scores and the ability to actually do the job well are two different things. One problem required the same modification to be applied to five scattered call points, one of which was registered with a string that grep couldn't even search for; the other involved two cascading failures, where getting the repair order wrong would render the changes useless. In the empirical tests, all six runs scored full marks, and it even found the point that couldn't be searched. (The problems we created ourselves have small samples and are not compared side-by-side with official or third-party scores.)
In other words, what this version makes up for is the ability to complete a task independently. Previously, you probably had to stand by and supervise; now, you can hand over a task with clear acceptance criteria and walk away. (And it does it even better.)
But there is another half to this official table, which neither Chinese nor English media has mentioned. The media narrative is "approaching Claude Fable 5." However, in the comparison table posted by DeepSeek itself, Kimi K3 still leads 0813 in most agentic items, such as Terminal Bench 2.1 at 88.3 vs. 87.9, DeepSWE 67.5 vs. 62.7, Toolathlon 76.5 vs. 74.1, and Agents' Last Exam 27.6 vs. 25.7. 0813 only leads in three items. (This is the official self-test table; the official source for the scores of K3 and GLM is not specified.)
Presumably, the narrative DeepSeek wants to convey is happening among domestic open-source models, with no intention of seriously competing with foreign closed-source models.
There is also a more interesting piece of data: in the official changelog, Flash-0731 and Pro-0813 use the same internal test set and the same Harness, so they can be directly placed side by side:
[Flash-0731 vs. Pro-0813: Nine Items with the Same Caliber]
Pro's total parameters are 5.6 times that of Flash, and its active parameters are 3.8 times. But what it gets in return is a single-digit lead. For the most difficult item, Agents' Last Exam, the scores are 25.2 vs. 25.7, almost tied. Moreover, the factory default model in its own framework is written as deepseek-v4-flash; on the coding agent leaderboard of the third-party evaluation agency AA, the DeepSeek row also uses Flash; and before the two old model names were taken offline, they also pointed to Flash.
[On AA's Coding Agent Leaderboard, the DeepSeek Row Uses Codex+Flash]
Several independent clues all point to the same thing: Flash is the recognized mainstream cost-performance tier, while Pro is the upper-limit tier.
However, the official side has not disclosed that the 0813 version redid the post-training, only stating that it is built upon the structure of the Preview and has an external speculative decoding module attached. But the same series' Flash-0731 explicitly states: "keeps the same model architecture and size … and was only re-post-trained." Therefore, the idea that the Pro model underwent post-training again is merely our own inference.
[Flash-0731 Official Explicit Statement "Only Re-Post-Trained"]
There is also an industry phenomenon worth mentioning: GLM-5.3, released a day later, also uses the same 744B base, without changing the architecture or re-pre-training. All improvements come from extended post-training, and it also focuses on agentic capabilities. Does the fact that the two leading open-source models made the exact same move a day apart indicate that the main battlefield for flagship upgrades in this generation has shifted from pre-training to post-training?
The Truth Behind the 1M Context
This is the most exclusive finding in this round, and anyone can verify it themselves.
[The rope_scaling Lines in config.json on Hugging Face]
65536 × 16 = 1,048,576, exactly 1M. This means that this 1M was not natively trained; it was extrapolated 16 times from a 64K base using a method called YaRN. It's like asking someone who has only trained on a 100-meter track to run 1600 meters. It's not that they can't run it, but the quality in the last few hundred meters is likely to drop precipitously. Moreover, this is unique among peers. All three claim 1M:
[Three Different Paths to 1M Among the Three]
We can see that among the three open-source flagships that all claim 1M, only DeepSeek explicitly uses extrapolation scaling in its configuration.
Kimi K3 does not have this field; it replaced the attention mechanism itself. GLM-5.2 also lacks extrapolation parameters; it pulled the rope_theta to 8 million. However, it must be clarified that the configuration can only prove whether positional scaling is done during inference, not directly prove the training length, so the accurate statement is that only it explicitly uses extrapolation. Additionally, the open-sourcing of GLM-5.3 weights was delayed by about two weeks; this column compares against the verifiable configuration of 5.2.
By the way: the architecture class name of GLM-5.2 is GlmMoeDsaForCausalLM, its indexer field has the same name as DeepSeek V4, and the index_head_dim value is exactly the same at 128. And Zhipu explicitly wrote in its official model card: "GLM-5 also integrates DeepSeek Sparse Attention (DSA), largely reducing deployment cost while preserving long-context capacity."
This is no longer an inference; it is explicitly written by the other party.
[Zhipu's Official Model Card Acknowledges Integrating DSA, with a Positive Acknowledgment Expression]
Then, according to common engineering knowledge, the cost of long context obtained through extrapolation will appear in the latter part of the window, meaning the quality will be worse the further you go.
I ran a script to test this empirically, embedding objectively verifiable facts into different positions of a long text to see if it could retrieve them.
[Self-Test Hit Rates and Embedding Depths at Five Positions]
The corpus has 3,857,465 characters = 923,858 input tokens. Two facts were embedded at each of the five positions, 10/10 all hit, zero fabrication, zero not mentioned in the document. Among them, the 95% position fell at approximately 902,000 tokens (the true tail fragment).
So the conclusion is that extrapolation did not lead to degradation in the latter part of the window. However, we still didn't touch the last approximately 8%, but it is enough to show that running 1440 meters hasn't caused a drop in speed; it's just that the last 160 meters weren't tested. However, in the official integration recommendations for Claude Code, the automatic compression window is set to 768K, which is three-quarters of 1M. Their recommendation is simply not to max out the 1M.
[Integrate with Claude Code - 768K Auto-Compression Window Recommendation]
02. Is V4 Pro Really Expensive?
Unit Price is Relatively High, but Cost per Task is Low
The third-party evaluation agency Artificial Analysis explicitly labels its input price as expensive. The median for similar models is $0.33 per million tokens, while it is $1.32. But it only costs $0.25 per task, making it the second lowest among the same batch of 106 open-source large models.
[AA Cost per Task × Intelligence Index, Including Cache Economics]
The stronger Kimi K3 costs $0.84 per task, 3.4 times more expensive; GLM-5.2, which has the same score, is $0.32; the strongest Claude Opus 5 is $2.34, 9.4 times more expensive. This means its starting price is more expensive than others, but the route is shorter and has fewer detours, so the total cost for one trip is still relatively cheap.
What Really Saves Money is the Cache
The way agents work is inherently circuitous. If reading once isn't enough, read it twice; if a change is wrong, change it back. Circuitousness burns tokens. Therefore, when calculating the real cost, one shouldn't look at the unit price, but rather how much it costs to complete a single task.
We happened to measure this exact number in the long-context test: for the same 920,000-token context, the first query cost about ¥9.00, while the second to fifth queries combined cost only about ¥0.28. The cached parts in the five queries were completely identical: 923,776 tokens, with only 143 to 151 tokens being new. And our cache hit rate for the four coding tasks was between 93% and 98%. This is like simmering a hot pot base. The first simmer is very expensive, and afterwards, each time you add ingredients, you only add a little new stuff. But if the base is altered even slightly, it has to be re-simmered from scratch. This means it doesn't matter if you let it try a few more times; anyway, the bulk of the cost is incurred on the first try.
Cost-Saving is Written into the Engineering
We found in its 219 packages that 215 READMEs must answer the same question: What impact do I have on KV cache prefix stability?
Moreover, it has a plan mode that only allows planning and forbids execution. The normal practice is to remove tools like writing files and modifying code from the tool list; once removed, the model cannot call them. But dsh didn't remove them. The factory prompt explicitly states:
The tool catalog stays the same across modes for request-cache stability … those tools remain listed only to keep the request shape stable.
[packages/bundle/base/cordis.patch.yml]
It would rather bear the risk of the model being disobedient and actually calling forbidden tools, just to keep the request prefix unchanged and maintain cache hits. Because it is highly likely that removing a single tool would require the entire cache hit to start over. Moreover, there is another engineering setting: tool results exceeding 8,192 characters are truncated, keeping the first 4,096 and the last 1,024; those exceeding 50,000 bytes are directly written to disk and not included in the context; even generating a title for a session has an output limit of 64 tokens. Calculating tokens at every turn is truly not just a vision or slogan; DeepSeek genuinely cares about your wallet.
[Three Engineering Constants, All from the Same File packages/bundle/base/cordis.patch.yml]
The price increase officially took effect at 00:00 on August 17 (the English page states 16:00 UTC, Aug 16, which exactly equals Beijing time 8-17 00:00).
[Pricing Page Peak and Off-Peak Two Tiers + UTC Peak Hours Footnote]
Multipliers compared to old prices: cache hits increased by 6 to 12 times, misses increased by 1.5 to 3.0 times, and outputs increased by 2.25 to 4.5 times. Peak hours are UTC 01:00–04:00 and 06:00–10:00, which is Beijing time 9:00 to 12:00 and 14:00 to 18:00.
Note that the biggest increase is for cache hits. And our cache hit rate for the four coding tasks was between 93% and 98% (the highest was 1,431,040 vs. 30,672). Therefore, the ones who truly feel the pain from this price increase are those who use the cache the best.
Connecting the previous chapters, you will find that the same thing repeats itself at different levels.
Architecture layer: MoE makes total parameters look like 1.6T and compute like 49B.
Pricing layer: unit price is relatively high, cost per task is the second lowest.
Cache layer: 920,000 tokens cost ¥9 for the first time, and ¥0.28 for the next four times.
Engineering specification layer: 215 packages must answer the cache prefix question, plan mode prefers not to remove tools, and even session titles are limited to 64 tokens.
DeepSeek has always been doing the same thing: buying the same output with less compute and less context. And after DeepSeek open-sourced its own Harness, we found that this sensitivity to computational cost is not only reflected in the model and pricing but is directly written into the way the Agent operates.
03. Why Does the Model Seem "Dumber" When Switching to a Different Harness?
Users on social media and Zhihu have long conducted empirical tests: connecting V4 Pro to Claude Code noticeably degrades performance, while switching to OpenCode for the same task works normally. The author themselves said they couldn't tell if it was a model issue or a tool issue. We conducted actual tests, hit the API, and found the answer is caused by official routing.
To allow tools from the Claude ecosystem to connect directly, DeepSeek implemented a layer of model name translation. Anthropic has three tiers (Opus flagship, Sonnet mainstream, Haiku lightweight), while DeepSeek only has two. Thus, claude-opus corresponds to Pro, while claude-sonnet and claude-haiku both correspond to Flash. The model field in the response is returned this way.
[DeepSeek API Docs - Mapping Anthropic's Three Tiers to Two]
The problem occurs right here with Sonnet, which is the mainstream workhorse on Anthropic's side, with capabilities closer to Opus, but in this mapping, it is grouped with Haiku into the 284B Flash.
This is a compatibility layer that can be targeted. We tried non-claude names: foobar-9000 and gpt-5-turbo both directly returned 400, and the error message explicitly stated that only those two DeepSeek model names are supported. Only names starting with claude-* will silently fall back to a certain DeepSeek model.
Therefore, it is inevitable, not accidental, that users in the Claude ecosystem hit this.
There is also an easier pitfall to fall into: any non-current-generation claude name written in the configuration might fall back to Flash. For example, claude-3-opus-20240229 has "opus" in the name, but it ultimately falls back to Flash. Whereas claude-opus-4-6 falls back to Pro. If developers copy old tutorials and old scripts, they will almost inevitably fall into this pit, thinking they are using Pro, when in reality, Flash is running.
At this point, users might ask: "Wait, you're not charging me Pro prices while actually running Flash quality, are you?!" We actually sent 23 requests that would be mapped to Flash, accumulated the output to 103,000 tokens, and made the balance drop by ¥1.00. The closest among the four pricing hypotheses is pricing by Flash (predicted ¥0.925, difference of ¥0.075; the next closest, "pricing by Pro," has a difference of ¥0.388, which is 5 times further).
So this is not a money issue; the main problem is that I thought I was using the 1.6T flagship, but in reality, part of the work is being done by the 284B small model, without any prompts. If developers use such an environment for evaluation and running tasks, the actual work is being done by a mixture of two models.
Therefore, for developers, when using tools from the Claude ecosystem to connect to it, the four environment variables ANTHROPIC_MODEL, ANTHROPIC_DEFAULT_OPUS_MODEL, ANTHROPIC_DEFAULT_SONNET_MODEL, and CLAUDE_CODE_SUBAGENT_MODEL must be explicitly overridden together.
This test also made us realize that in the Agent stage, just discussing the model itself is no longer enough. What Harness the model connects to, what tools it sees, and how it manages the context will equally directly affect the final performance.
04. DeepSeek Harness:
What Problem Does It Actually Solve?
At 19:19 on the evening of August 13, the official announcement for V4-Pro was released. 76 minutes later, DeepSeek open-sourced its own set of scaffolding.
The last point it wrote in the first line of the repository description:
[Harness Timeline Ten Lines + One-Way Open Source Four Fields]
Official Scores Can Finally Be Reproduced
When vendors report benchmark scores, they all use their own scaffolding, which is not made public. Therefore, the scores we see are the results of this model paired with that scaffolding, not actually the model's own scores, because the environment is inaccessible and thus cannot be reproduced.
DeepSeek itself also explained this in the announcement footnotes: the Code Agent scores for 0813 were run using "DeepSeek Harness minimal mode" plus the max thinking tier, and proactively declared that "results under other frameworks may vary slightly":
It put this set of configurations directly into the repository:
[Key Sections of minimal.cordis.yml]
In minimal mode, the only tools the model can see are two: a persistent bash and a string replacement editor. Context compression: off. System prompt: one sentence. And the stream idle timeout is 172,800,000 milliseconds, or 48 hours. What they expect are tasks that can run for two days.
And interestingly, Claude Code is exactly the opposite: heavy system prompts, a ton of tools, with automatic compression. The two are almost at opposite ends of the spectrum.
We ran it according to their setup, and both problems scored full marks. So how much does the official note of "vary slightly" actually differ? We ran both sides with the same batch of problems:
[Empirical Test: Three Configurations × Two Problems Matrix]
For the same multi-file refactoring problem, the standard mode took 42 steps, while the official minimal mode took 65 steps (55% more). For the other terminal troubleshooting problem, it was 20 steps vs. 27 steps, 35% more. The minimal mode got both problems right, but the cost for the densely modified problem was 58% higher, and the cumulative cache hit volume was 2.4 times that of the standard mode (it has no context compression, so all 65 steps accumulate on a single chain).
To use an analogy, it's like giving you only a Swiss Army knife to fix a car, compared to giving you a whole toolbox. The knife can do a little bit of everything, so you can indeed fix it, but you have to twist many more times. Fewer tools do not equal more savings; it trades steps for the number of tools.
Everything is a Plugin
Everything is a Plugin, but what exactly is a Plugin? I understand it's actually the relationship between an OS and an APP. When Apple built the iPhone, it had no idea that ten years later there would be an app called "Xiaohongshu." The core remains unchanged; I only need to strengthen the platform environment, while capabilities grow infinitely. This is the imagination that plugins can bring.
To what extent has dsh pushed this? Model adapters, tool registries, session logs, sandbox policies, and even the main loop that dispatches tasks itself, are all plugins and can be replaced from the configuration. It sounds like all additional capabilities, but the essential difference between this and skills is that skills teach the model what to do, whereas dsh's plugins can overturn the underlying layers, including kernel components like the file system backend, compression strategies, and loop drivers.
Moreover, it took an extra step, which is also the practical engineering implementation of the vision of self-evolution: it prepared five tools for the model, allowing the model to write, mount, execute, and stop plugins within the running process itself.
[From the First Two Paragraphs of packages/extensions/tool-cordis/README.md]
The first sentence of the official text: "The self-referential Cordis toolset: five model-facing tools over the live runtime in the current DSH process." Among them, cordis_define allows the model to write a package itself—name, purpose, host-side code, and optional browser-side code; it is registered after syntax checking, and the user will see a card with a start button in the conversation; cordis_run executes it in a VM sandbox.
This is equivalent to allowing an App to write a new App at runtime and then immediately install it into the system. And the official explanation for this is very candid:
The sandbox only isolates global objects, it is not a security boundary …… helper functions in the host domain make escape possible. Treat this set of tools as bash permissions.
In other words, it hands you a loaded gun while very seriously telling you that this gun has no safety catch.
To be honest, taking "everything is a plugin" to this extent can no longer be explained away. Because what plugins have always pursued is flexibility, but flexibility has its margins. I understand making tools into plugins, and I understand making compression strategies into plugins, but making the main loop that dispatches tasks into a plugin, and specifically providing the model with a set of "write your own plugins" tools, has already exceeded the scope of what can be explained by facilitating user customization.
It has a feature where it can treat competitors as sub-agents, meaning it can make Claude and Codex work as subordinates for dsh. We tested this empirically:
[ps Output of Test Task E7, dsh Main Process + Spawned Claude Subprocess]
The Claude subprocess was indeed spawned, and we even caught Claude Code cloning its official plugin marketplace. So this path is genuinely connected to the Claude Code binary, not just a configuration decoration. But the delegation failed twice in a row, returning Error: subagent run failed. The model then downgraded itself to a normal sub-agent to complete the task, and proactively reported that it had switched tools and why.
[Agent Output Admits Downgrade]
V4 Pro and Harness Are Two Completely Different Products
Using V4-Pro and using dsh are two different things. The former is very simple: get an API key, connect it to the Claude Code, Codex, or OpenCode you are currently using, and you're done (refer to the four environment variables in Chapter 2); this is all most people need. And v4-Pro is almost a product, delivered as a finished good to users. But dsh is completely and purely a development tool, absolutely not a highly integrated, packaged, one-time delivery product.
To use dsh well, you need the following four things:
You must know how to modify configurations and know what you are modifying. Which model to choose, how many tools to provide, whether to compress the context, how to open the sandbox, all are in YAML, and there is no such thing as recommended settings.
You must judge for yourself which mode to turn on. It gives you a switch: are tools "called directly" or "called by writing a program"? And the conclusion of this switch on our two problems is opposite: one is 22% more expensive, and the other saves 23%. We ran this boundary four times before we figured it out.
You must be able to tolerate things changing at any moment, and no one to help when problems arise. It labels itself as developer preview, explicitly stating there will be breaking changes. And Issues are closed; you cannot ask questions, you can only read the code yourself. The suggestion on line 7 of its architecture document is: "It is recommended to use an agent to explore this codebase."
You must judge the security boundary yourself. It's the gun without a safety catch from the previous chapter. It writes the risks very clearly, but the decision of whether to turn it on is yours.
To summarize: if you are in the right column, the answer is very straightforward: use the API to connect to your current tools, do not install dsh.
We had a 920,000-token request that was killed by a timeout on the client side, with nothing saved locally, but the server side had fully processed and billed it, so that ¥9.00 was spent just like that. Client timeout does not equal no money spent; the dish is still cooked and the money is still paid, it's just that I didn't get to eat it. There is also a positive observation, although the sample size is only one: after the delegation tool failed twice in a row, the model didn't force it or pretend to succeed; it switched plans to complete the task and proactively reported that it had switched tools and why.
Back to the table above. You will find that dsh probably never intended to serve these scenarios. This is interesting; why did DeepSeek deliver such a thing?
05. Who Did DeepSeek Hand the Power of Judgment to?
Everything begins with the theory of contradiction and ends with it; the essence of things is contradictory. Solving one contradiction generates new ones, leaving new opportunities, and so the cycle continues.
Below, based on this research and empirical testing, let's discuss the new contradictions I see DeepSeek solving and generating:
Freedom and the Cost of Choice Are Handed to the User Together
[Top of GitHub Repository Page: Three Numbers for star / fork / watch, Note No Issues in the Navigation Bar]
The facts are four API fields: the Issues feature is closed, the total number of external PRs is 0, only the discussion area is open, and 330 watches vs. 85,268 stars (data scraped on 2026-08-14). And the repository comes with a complete issue governance pipeline—policy, lifecycle, templates, even unit tests are written, it's just not turned on.
[Issue Governance Facilities in .github/workflows/]
If the goal is to allow rich individuals to create freely, why not accept an external PR? Open source that truly aims for co-creation will open its arms to accept contributions. Its posture seems to be giving you the freedom to modify, but don't come collaborate with me. It's like IKEA giving users all the boards, screws, and blueprints, but not accepting any improvement suggestions from users.
[Line 7 of docs/architecture.md: dsh Recommends Using an Agent to Read, Rather Than Reading It Yourself]
But if we shift our perspective, after experiencing the above deconstruction and research, you will find that under its assumptions, this is actually self-consistent. If everyone knows what they want, then raising an issue for me to change it is inherently redundant; why not just take it and change your own copy.
We empirically tested two identical problems, but the results went in opposite directions:
[Three Configurations × Two Problems Matrix]
For the multi-file refactoring problem, the write-program mode was 22% more expensive and 34% slower; for the terminal troubleshooting problem, it saved 23% and was 38% faster. Why? The number of tool calls indeed decreased (from 67 to 44), but output tokens increased by 42% and thinking tokens increased by 53%. The official side also left room by saying Code Mode "does not promise a universal reduction in tokens."
[From packages/core/tools/README.md]
In other words, what exactly you want and how much price you are willing to pay, you need to figure out yourself, or try to find out personally. Just as the saying goes, freedom does not equal prosperity; if you do not have extremely strong control over freedom, the result is likely to be unsatisfactory.
While DeepSeek gives you the power of choice, it also hands you the cognitive cost required to make these choices.
Is Harness Actually for Humans or for Models?
[Who Is This Codebase Organized For: Nine Anomalies × Two Explanations]
It can also be seen from the above figure that this codebase is organized to be friendly to Agents rather than to humans. All nine pieces of evidence are public source code, which anyone can verify. As for whether they did this to allow the model to iterate autonomously (of course, this is my judgment, not the official statement). Going back to the previous question, taking "everything is a plugin" to the extent that "even the main loop can be changed, and a set of tools for the model to write its own plugins is provided" cannot be explained by "facilitating user customization." But changing the assumption makes everything click: what if the expected user is not a human, but the model itself?
A system that needs to run itself and modify itself in the long term needs exactly these:
Every link is replaceable (otherwise it can't be modified)
All decisions are logged (686 articles, even the 11 rejected ones are kept)
Tests are more than source code and 100% coverage for each file (otherwise no one will know if it's broken)
Packages are broken down extremely finely (so the modification surface is small)
Unit cost is pushed to the limit (otherwise it won't run for long)
Under this assumption, these contradictions all become logical. The assumption for closing Issues is that if the subject of iteration is the model, issues raised by humans are inherently not on this pipeline. The assumption of doing the most trivial things for the highest goal is that the model runs itself in the long term, and unit cost is the ceiling.
I have also been a veteran struggling in product positions for many years. The product I understand is built on numerous judgments and assumptions about users. Who the user is, what they want to do, where they will click first, which step they are willing to wait an extra three seconds for—behind every default value is a judgment we have made for them. But I found that DeepSeek refuses to make these judgments.
It has no recommended settings, no default modes, and doesn't tell you which switch to turn on, because giving you a default value is equivalent to making a judgment for you once. For example, iOS is a platform, but the iPhone is a completely usable finished product for ordinary users; you don't need to install any apps, and you can make calls, take photos, and surf the web right after turning it on. Apple did two layers: for developers, it is a platform, handing over the power of judgment; for users, it is a product, bearing the judgment. The true meaning of easy to learn, hard to master is that these two layers exist simultaneously.
And dsh only did the platform layer. In other words, it is an OS with only a kernel and no factory-installed system. The real counterpart is AOSP—phone manufacturers take it to make their own distributions; HyperOS and OriginOS are created this way. AOSP doesn't accept your issues either; you fork it and maintain it yourself. From this perspective, closing Issues is not arrogance; it is the norm for this model.
[Four-Tier Delivery Ladder]
Apple has been paying tribute to highly creative people for decades, but what it delivers is always a product. Equally believing that users have creativity, one paves the way for you, and the other hands you the parts. There is no better or worse, only different choices, that's all. DeepSeek's judgment of the world is that it assumes the subject before it is autonomous, whether that subject is a human or a model.
I think the ultimate principal contradiction can be summarized in one sentence: the contradiction between the thoroughness of DeepSeek handing back the power of judgment and the capability and cost required to take over this power of judgment.
The contradiction lies precisely in the thoroughness. If it's not thorough, it's not a contradiction; giving half the freedom and leaving a set of default values is what Claude Code does. But it hands back the power of judgment completely, including places where you don't even know you need to judge (which mode to turn on, what the default model is, whether that gun has a safety catch). In fact, the subject does not always possess the conditions to take over this power of judgment.
So why did it choose this? I think there are at least three explanations:
First layer: They do not have the resources or willingness to build a product. The team composition is researchers, with compute and personnel all pressed onto the model. (Many in the community are calling for them to hire a product manager, because using dsh is indeed torturous.)
Second layer: The marginal return of productization is too low. C-end users can't be driven away, and B-end relies on APIs, which is enough.
Third layer: The premise of a product is to make judgments for users, and they choose not to make this judgment. Maybe because they can't judge, or maybe because they truly believe human thoughts are diverse enough and shouldn't be consolidated by a set of default values.
I lean towards the third explanation; only it can explain both the model side and the user side simultaneously. The first two cannot explain why they specifically built a set of tools for the model to write its own plugins (which is actually quite thankless). It is a parts box delivered to an autonomous subject, and the most important autonomous subject of this generation might not be us now. It might be aimed at future models or people. (It gets sci-fi in an instant.)
I work in product myself; actually, a product manager's job is to make those assumptions for users. So after reading through all this, I naturally thought, if not making assumptions is a more respectful posture towards people, then what is the meaning of my position? I think the essence of making assumptions is bearing the cognitive cost for users. DeepSeek returned this cost to us, while Apple swallowed it for us.
Both are choices, just with different costs; ultimately, it depends on what people want and what this company believes.
This article itself is also a product of combination. Four self-created problems, seven runs, two rounds of empirical testing; all conclusions only hold within this specific combination. Moreover, from the very beginning, we kept asking if it could do the job, and only realized very late that we should ask a question: Who is it made for, and am I suitable to use it?
Looking back at V4 Pro and DeepSeek Harness, what is truly interesting this time might not just be how much stronger a model has become. As models become increasingly powerful, contexts grow longer, and Agents can do more and more, new problems also emerge: how capabilities should be used, where costs should be spent, which judgments should be handed over to products, and which should be left to humans, or even to the models themselves. The answer DeepSeek gives is not easy—it opens up more capabilities and hands over more choices and responsibilities at the same time. As AI begins to independently complete increasingly complex tasks, what is truly scarce may no longer be just stronger models, but knowing exactly what you want it to do, and being willing to bear the cost for this freedom.