DeepSeek’s launch of Harness, arriving around the same time as the V4 Pro price increase, has led to a broader debate over what the company is trying to win next. In a MarsBit commentary by 「版面之外」 author 「画画」, the argument is that these two moves point in the same direction: DeepSeek may be looking beyond the model itself and toward the layer where model calls actually turn into work.
For much of the past two years, DeepSeek built its reputation on making advanced AI cheaper. The article says V3 and R1 helped establish two ideas at once: that a China-based team could build world-class foundation models, and that training and inference efficiency could be pushed very far under constrained resources. After that, pricing became a central part of the company’s identity. DeepSeek kept driving costs lower, and the market came to associate top-tier capability with lower expense.
It then expanded the reach of those capabilities through open-source distribution. According to the piece, the company’s earlier logic was internally consistent: build stronger models, cut prices, open access, and let more developers and users build on top. That progression extended from model weights to APIs and then into the developer ecosystem.
V4 Pro changed the tone. The model improved, but the price did not keep moving down. The article does not treat the price hike, by itself, as the most important development. What stands out is that it happened almost alongside the release of DeepSeek Harness. Read together, the two launches suggest that DeepSeek may now be calculating a different kind of value.
From model call volume to control over the runtime layer
The commentary frames this as a shift from fighting for model usage volume to fighting for the environment in which usage takes place. Those are not the same contest. A model only creates practical value once it passes through an execution layer that handles tools, file access, permissions, and task orchestration. In many existing products, that layer is hidden from the user. The user sees a clean interface and a completed task, not the machinery in the middle.
Harness is described as DeepSeek’s first clear attempt to pull that machinery into view as a distinct product object. In that reading, V4 Pro and Harness act like two coordinated moves. One puts the model back inside a clearer commercial ledger. The other reaches outward into infrastructure beyond the model.
The article’s point is not simply that DeepSeek released another Agent-related product. It argues that the company may be repositioning itself around the place where intelligence becomes execution, and around the environment that governs that process.
Harness breaks the Agent into replaceable parts
To explain why Harness matters, the commentary uses Apple as a contrast. Apple’s product logic, it says, is to absorb complexity on the user’s behalf. Users do not need to think about CPU scheduling, memory allocation, or file system behavior. They just open a Mac or an iPhone and use it.
That same design instinct has shaped many Agent products. The article names Claude Code, Codex, and WorkBuddy as examples of systems that package together the tools, Skills, sandboxes, permissions, and workflows an Agent needs. The user only states the objective. The product decides the rest.
Harness moves in the other direction. Instead of hiding complexity, it exposes it as modules. In the article’s description, the model, tools, Skills, workflow, and UI can each be swapped out independently. Even plugins running inside the system can be dynamically loaded, removed, and recombined.
That is why the piece places so much weight on the product’s boundaries. The older software instinct is to wrap complexity into a finished interface. Harness, by contrast, takes that complexity apart and hands the right to modify it back to the developer.
The naming matters here as well, in the author’s view. It is called Harness, not DeepSeek Code, because the emphasis is not just on a use case. It is on an operating environment. The article boils that idea down into a simple formula: Agent = model + Harness. The model thinks. Harness turns that thinking into action. In many products, that second layer sits behind the curtain. DeepSeek has now made the curtain itself a thing developers can work with.
Cordis points to Agents that can change while running
The article then moves to Cordis, the plugin kernel underneath Harness. If Harness were only meant to be a conventional Agent product, the author argues, some of DeepSeek’s choices would look unusual, especially for a model company. Why would such a company make room for other vendors’ models? The answer, the piece suggests, sits outside the usual product framing.
Cordis is presented as the low-level mechanism that governs how plugins are installed, removed, and coordinated. The article stresses that its scope is narrow by design. It does not define the model, the tools, or the Agent’s concrete skills. It focuses on one job: allowing plugins to be dynamically loaded, unloaded, and managed while keeping the system stable through those changes.
That design, according to the commentary, touches two technical ideas. One is “temporal composability,” which asks whether the effects of a plugin can be fully rolled back after the plugin is removed. The other is “spatial composability,” which asks whether one plugin can reconnect its dependencies if another plugin it relies on disappears or changes.
Those terms are technical, but the larger question is straightforward: can an Agent change itself while it is running? Traditional software usually does not work that way. Once a program starts, its abilities are largely fixed. You can update the software, but it does not usually stop mid-task, realize it lacks a function, install that function, and then continue.
The article says Cordis is meant to open that possibility. In Harness’s so-called creation mode, an Agent can inspect its own running environment, discover what capability is missing, produce it on the spot, attach it back into the system, and keep going.
The author gives two examples described in the piece. One is a security audit Agent that can only read code and is not allowed to modify files. Another is an enterprise research Agent connected to internal search, fixed to a specific model, and equipped with three dedicated Skills. Older Agent setups, the article says, usually need a person to define such arrangements in advance. Harness explores a different route: the person states the goal, and the Agent adjusts its own execution environment to pursue it.
The metaphor used in the commentary is simple. It is like a machine noticing it is missing a part while already operating, then manufacturing that part on site and fitting it in before continuing.
An open model layer suggests a runtime platform strategy
One of the most commercially significant details in the article is that Harness does not lock users into DeepSeek’s own models. For a model company, the more natural move would be to bind the Agent layer tightly to the in-house model. The commentary names OpenAI, Anthropic, and Google as examples of companies whose Agent path naturally reinforces usage of GPT, Claude, or Gemini.
DeepSeek did not take that route, at least as described in the MarsBit piece. Harness allows developers to customize the model, the protocol, and the Base URL. It can also connect to outside models. In theory, a developer could run a competing model inside DeepSeek Harness.
Viewed narrowly as an Agent product, that can look odd. Viewed as infrastructure, the logic changes. The article argues that DeepSeek may care less about forcing model choice than about shaping the runtime underneath the model. In that reading, the company is trying to control the execution layer on which future Agents operate.
The piece compares that ambition to an operating system. Windows does not need to build every software application itself. Android does not either. The value of the platform lies in getting others to develop on top of it. More developers lead to more software. More software pulls in more users. Over time, the platform becomes heavier and harder to ignore.
Harness, the author suggests, is aiming at a similar dynamic. Its real competitors may not be limited to products such as Claude Code or Codex. The more important contest could be over the Agent-era runtime itself. Whoever controls that runtime, in this framing, gets a say in how future Agents actually run.
The V4 Pro price increase gets a new interpretation
Once Harness is placed inside an ecosystem story, the V4 Pro price increase also looks different. The article says DeepSeek’s earlier flywheel relied on low-cost models bringing in more users, more users generating more calls, and that scale feeding back into developer attention, influence, and eventually stronger models.
Harness introduces another loop. In this newer version, the model’s position changes. It is no longer just the destination at the end of the product chain. It becomes the engine inside a larger Agent ecosystem. DeepSeek is no longer only trying to attract users to a cheap model. It is trying to create conditions in which an entire Agent ecosystem continuously consumes model capability.
That is also how the commentary explains why Harness does not force the use of DeepSeek models. If the real objective is to make the runtime itself the ecosystem anchor, then the identity of the underlying model becomes a secondary issue. Once the runtime becomes the place where Agents live and work, model calls follow from that position.
In that sense, the article treats higher pricing not as a contradiction of DeepSeek’s earlier image, but as a sign that the role of the model is changing. The model no longer has to act forever as the price-cutting weapon. It can start functioning as a machine that generates recurring cash flow inside a broader platform structure.
A product that feels hard to use may be aimed at builders first
The commentary closes by returning to the product experience itself. The author says that on first opening DeepSeek Harness, it is not obvious how to use it. The interface feels engineered for technical users, and the documentation is filled with specialized terms. A typical first reaction, the piece says, would be to ask who the product is really for.
That may be the point. The author argues that DeepSeek may not see ordinary users as the first audience that matters. At the beginning of a platform cycle, builders come before consumers. The article cites Windows, Linux, and Android as examples of ecosystems that started with developers rather than with mass-market ease of use.
By that measure, Harness should not be judged first by download numbers. It should be judged by whether plugins appear, whether Agents get built on top of it, and whether people begin constructing new things around it. The commentary goes one step further: if developers begin using Harness to build their own versions of Harness, that would be a stronger sign that the platform is actually growing.
The final argument is broader than any single release. Today, Agents are often treated as products. But if they can eventually be built, modified, recombined, and even extended by other Agents in the same way software is, then today’s understanding of the term may only describe its earliest form.
The article ends with a line about ambition. Sometimes a company’s ambitions are visible in what it releases. Sometimes they are visible in what it chooses not to finish for the user. DeepSeek Harness, in the author’s reading, is not a completed Agent product. It is an unfinished object handed to developers. For a company trying to become infrastructure, that unfinished quality may be exactly where the opportunity lies.