In May 2026, on DeepSeek’s hiring page, the top featured job listing read “Agent Harness Product Manager” (DeepSeek hiring page). A company known for its model capabilities started hiring people to build the execution environment for coding tools. Combined with the fact that it had not previously released a first-party harness, this move can be understood as DeepSeek filling a product gap it left open before.
DeepSeek’s previous strategy on coding agents was to only provide models and APIs, leaving the harness to third-party coding tools. Claude Code, Codex, OpenCode, and WorkBuddy could all connect to DeepSeek’s models; users chose their own tools, and DeepSeek collected API fees. During the phase of model-layer competition, this logic made sense: if the model is cheap enough and good enough, it can secure the position of underlying provider.
However, the limitations of selling APIs alone quickly surfaced. What model providers directly see are merely individual API calls. The model outputs code, but how users use the tool, at which step an error occurred, how many rounds of edits it took to run successfully, which code snippets users accepted and which they rejected—these details are held within third-party tools and their execution environments, and do not naturally flow back to the model provider. Without feedback from real coding scenarios, model improvements on complex tasks lack leverage. LangChain’s benchmark data corroborates this: for the exact same model, having a targeted execution environment configuration can make a 10 to 20 percentage point difference in performance on complex tasks (LangChain blog).
As DeepSeek turns back to recruit for harness product and runtime infrastructure roles, the competitive logic of this track becomes clear. Once models can autonomously carry out end-to-end tasks, the role of the harness changes: it is no longer just a client that helps users invoke models, but can also serve as an instrument for observing behavioral data. Only when vendors own the harness do they have the prerequisite, within the scope of user authorization and data policies, to record behavioral sequences of models in real tasks and use that data to improve the models.
If this assessment holds true, the emergence of every new form factor over the past six months should be explainable through the lens of data competition. Laying them out one by one, the facts indeed confirm this.
What first caught attention was the concentrated emergence of desktop applications. OpenAI launched a standalone Codex desktop app in February 2026, positioned as a command center for agents (Codex app), and merged it into the ChatGPT desktop client in July. At the time, many speculated that the Codex project had been consolidated or that CLI tools were exiting the stage. But OpenAI’s own architecture documentation explicitly states: CLI tools, IDE extensions, web clients, and desktop apps share the same underlying Codex harness (Codex App Server). What was merged was merely the desktop product shell; the Codex product and harness did not disappear.
So why build an extra desktop app? From a data perspective, the answer is straightforward. The command line in a terminal is flexible enough to plug into scripts, CI pipelines, or other automation logic, making it comfortable for senior developers. But for those unaccustomed to the terminal, it presents a barrier. The desktop app lowers this barrier, attracting more people to place their development tasks inside the vendor’s execution environment. More users mean more data. Desktop apps also carry computer use and browser use more naturally. In April 2026, Codex added OS control and an in-app browser (Codex for almost everything), while Antigravity 2.0 also treated browser interaction as a core capability. Every time an agent clicks a page or reads a web element, it generates interaction traces that traditional model API requests simply do not contain.
The command line didn’t disappear because it serves a different cohort and produces a different type of data. High-frequency users who run complex tasks in the terminal, write custom skills, and orchestrate automation pipelines are often solving harder engineering problems. Through the data framework of this article, such traces reflect real pain points in complex refactoring and debugging more directly. Abandoning the command line would mean severing this source of data. Therefore, vendors adopt a parallel dual-entry strategy to cover user groups with different data densities.
Taking a step beyond desktop applications is moving the execution environment itself into the vendor’s cloud. Claude Code launched its web version in October 2025, running tasks in Anthropic-managed cloud environments (Claude Code on the web). When Codex debuted in May 2025, it was a cloud-native agent running each task inside an isolated cloud sandbox (Introducing Codex). Cursor launched Background Agent in May 2025, running in remote environments, later renamed it Cloud Agent, and upgraded it into a full virtual machine by February 2026 (Cursor 0.50; Cursor 2.0; Cursor agent computer use).
The timelines for all three companies heavily overlap, and in every case, model providers or companies expanding into the model layer acted first. This is no coincidence. When tasks run inside vendor-controlled virtual machines, vendors have the prerequisite to observe tool calls, error retries, and user approval or rejection logs, with the actual scope of collection depending on product telemetry and data policies. If an agent runs entirely on a user’s local machine and the harness does not separately report telemetry back, those behavioral details remain on the user’s machine, and model providers see only API requests. OpenAI chose cloud architecture early on, Anthropic added hosted cloud sessions, and Cursor upgraded its background agents to cloud VMs. Viewed through data competition, all of them are staking claims on behavioral data within the execution environment. Model vendors need this data layer to improve their models; IDE vendors follow suit to retain data gateways in long-task scenarios.
Remote control seems unrelated to data competition at first glance, appearing to be merely a convenience feature for someone who launches a long task, goes for coffee, and returns to inspect the results. However, mobile access relieves waiting anxiety, making more long-running tasks viable. A task that runs continuously for 20 minutes—enduring network disconnections and reconnections, multiple rounds of test validation, and cross-file edits—exposes engineering scenario complexity far beyond a simple function tweak. Within the data framework of this article, the value of remote control lies in enabling longer and more complex real-world data to be generated continuously. For model improvement, such long-task data may be significantly more valuable than numerous short interactions, as it contains failure recovery, multi-step reasoning, and real toolchain friction.
Desktop apps lower barriers to expand data gateways, the command line retains high-quality data producers, managed agents directly own the execution environment with the prerequisites to build data pipelines, and remote control allows longer and harder data to be continuously generated. These form factor shifts may seem independent, but they are all positioned along the exact same data chain.
Competition along the data chain takes place at the execution layer, but what the outside world sees most easily is the UI layer. Over the past six months, interfaces of coding tools both domestically and internationally have rapidly converged. Task lists, approval cards, diff previews, status tracking, and multi-task kanban boards—these frontend interaction patterns carry low replication costs. Codex’s command center, Cursor’s Agents Window, Antigravity 2.0’s standalone client, TRAE Work’s task workbench, and ZCode’s desktop environment are almost identical in visual design and interactive experience.
Interface convergence easily creates an illusion that products have become seamlessly interchangeable. Beneath the interface, however, the execution layer is accelerating in its divergence. There are four primary execution locations: the user’s local machine, user-configured SSH hosts, vendor-provided managed virtual machines, and enterprise self-hosted runner nodes. Beyond affecting network stability and failure probability, the core difference among these four architectures lies in where execution traces originate and who controls them. Local execution traces remain inside the user’s environment first, while managed VM traces are hosted on vendor infrastructure; whether data is further transmitted back or used for training still depends on telemetry settings and data policies.
Remote control is an easily misread example. For a time, a popular narrative claimed that Cursor’s ability to control cloud tasks via mobile phone demonstrated superior remote technology, while ZCode and Codex requiring local computers to stay powered on reflected technical shortcomings. In reality, all host-based remote control relies on the host machine staying operational; ZCode, Codex, and Claude Code are no different in this regard. Cursor’s mobile client actually supports both modes: when controlling a cloud Agent, the phone connects to the vendor’s cloud without needing local computer involvement; when controlling a local Agent, it still relies on the local host to run. The difference in the former mode stems from whether managed agents exist, not from remote control technology itself.
Geographical differences are also easily misread. Domestic (Chinese) products have indeed been fast to follow UI trends. The WorkBuddy team stated directly in an interview that after seeing Anthropic launch Claude Cowork, they realized “everyone’s ideas are highly aligned”; the same report noted that the subsequent OpenClaw wave pushed the team to refactor their product within a week and move from closed beta to public beta (TMTPost). In Kimi CLI’s open-source discussion area, a user proposed introducing a skill mechanism with the rationale “inspired by Anthropic’s Claude Code skill mechanism,” and the code indeed reused components from Codex (Kimi issue #107; Kimi NOTICE). These represent genuine evidence of following suit.
However, summarizing domestic products as mere imitation does not fit the facts. ByteDance’s TRAE released its IDE in January 2025, predating Claude Code’s February and Codex’s May debuts (TRAE 2025 Unwrapped), and the subsequently launched TRAE Work similarly possesses cloud-managed execution capabilities. At least from public product form factors, one cannot infer a significant technical gap between domestic and overseas vendors; the differences shown in this article’s sample reflect strategic focus: WorkBuddy deeply integrates WeChat, WeChat Work, Feishu, and DingTalk, while ZCode queues tasks to wait for idle inference capacity. These layouts are building defensive moats just as well; while some products focus on distribution channels and supply strategies, TRAE Work has already stepped into cloud execution environments.
If DeepSeek’s path is viewed as a cautionary case, it is because it took the extreme route on coding agents: releasing no first-party harness and instead connecting its models into third-party tools. The data gateway inside execution environments was thus held by third parties, preventing DeepSeek from naturally acquiring real-scenario feedback. Recruiting for harness product and infrastructure roles now aligns with the inference that it is filling this layer, though this is not DeepSeek’s official statement, nor can job postings alone prove the original strategy failed. Other domestic vendors at least built their own harnesses, giving them the prerequisite to access behavioral data within their own tools under user authorization and data policy constraints; along the path of third-party coding harnesses, DeepSeek directly holds primarily model API calls. The gap is not in model capabilities, but in the depth of data visible to each player.
When evaluating a coding tool product, ticking off checkmarks for task lists, subagents, remote control, or background tasks will barely reveal any difference anymore. These feature panels carry low replication costs and cannot reflect core moats. To see a tool’s true capabilities, one needs to set aside surface-level checkboxes and follow the trajectory of data flow within the product architecture.
Question 1: Who controls the execution environment? For products executing locally, behavioral traces remain on the user side first; if the harness does not separately report telemetry, model providers see only API requests. Products with managed cloud environments give vendors the prerequisite to observe agent behavior traces in real tasks, though the actual scope still depends on telemetry and data policies. Different execution environments determine which system gets to store the data first.
Question 2: Who can see the data? Open-source CLIs and public status files enhance the ability of users and communities to inspect execution details; telemetry implementations in closed-source desktop apps usually cannot be fully audited by external users. As a buyer or user, you need to clarify whether operational logs are sent back, who can view them, and whether they will be used to improve models.
Question 3: Who is inside the data flywheel? Under the premise of user authorization and data policies, model vendors build execution environments, execution environments collect real behavior feedback to improve models, stronger models attract more users to adoption, and more users produce more high-quality data. Once this loop starts, participants lacking their own execution environments are left outside the loop, missing out on the momentum for continuous evolution. According to the inference in this article, DeepSeek’s risk lies right here: it has models, price advantages, and an open-source ecosystem, but as of the verification date lacks the first-party harness layer, making it difficult to establish the same data flywheel.
Misjudging product maturity often comes from measuring execution-layer strength using surface-level UI features. A product may have a polished interface and full feature set, but if hosted execution and data loopback are not connected, its long-term competitiveness remains questionable. Conversely, a product with a crude UI, if it holds the execution environment in its own hands and uses the data to improve models under user authorization and data policies, could very well leapfrog in the next version.
For individual developers who simply need a convenient tool, feature lists remain useful. But for observers who want to discern industry trends and judge who is building long-term moats, the UI layer conveys less and less information—only the execution layer reveals the true competitive landscape.