OpenAI has unbundled Codex and sold it separately.
OpenAI rolled out four major offerings in one go yesterday.
Agents API, GPT-Live-1 API, Data agent, and ChatGPT for Financial Services: in a single day, it covered four product lines spanning agents, voice, data, and financial services, each of which is well worth a dedicated deep dive.
But among these four moves, the most notable one is arguably the Agents API.
This is because this time, OpenAI is essentially "unbundling Codex for sale".
The set of capabilities previously hidden behind Codex, which is responsible for keeping agents running continuously, invoking tools, managing contexts, and coordinating multiple agents, has been extracted and packaged as a cloud API for all developers to call.
01 Codex as a Service?
In fact, OpenAI has been unbundling Codex for quite some time.
Back in April 2025, shortly after OpenAI released o3 and o4-mini, it open-sourced Codex CLI. It is somewhat like OpenAI's version of Claude Code, installed directly in the local terminal. How agents run and how they invoke tools are all fully documented on GitHub. If you are willing to tinker with it, you can take the code, modify it, and run it on your own.
But at that point, it only made the code available in a raw form. Whether you could use it properly and how you wanted to use it was entirely up to you.
A month later, the cloud version of Codex, the product we are familiar with today, was officially launched. Users can submit their code repositories to it, with one task corresponding to an independent cloud sandbox. Codex can modify code on its own, run tests, fix bugs, and handle multiple tasks simultaneously.
Several months later, in October 2025, OpenAI released the Codex SDK.
Simply put, the SDK is a set of toolkits for developers, enabling Codex to be used not only as a standalone product, but also embedded in third-party applications. The SDK allows developers to launch the same agent that powers Codex CLI with just a few lines of TypeScript code, obtain structured outputs, retain task status, and resume execution after pausing.
However, the SDK is mainly designed to invoke Codex within programs, and does not expose the full interactive capabilities of Codex. It works very well for backend workflows, automation scripts, and server-side programs. But if you want to build a full-fledged client like the Codex IDE, there are still noticeable limitations.
Then in February 2026, OpenAI officially unveiled the Codex App Server, and systematically explained the Codex Harness architecture for the first time.
OpenAI explicitly clarified that Codex Web, CLI, IDE extensions, and Mac App appear to be different products, but they all run on the same underlying Codex Harness, the layer that handles the agent loop, thread management, tool execution, authentication, and state management.
The App Server adds a set of bidirectional JSON-RPC interfaces to the entire Harness stack. JetBrains, Xcode, or other clients do not need to rebuild an agent loop from scratch. They can directly start the App Server to drive the full functionality of Codex.
With the App Server, other products can directly integrate the complete Codex Harness.
Even so, there was still one last pain point left unresolved.
The SDK controls local Codex agents, and the App Server itself is a resident process that developers need to start and maintain manually. Although integrating Codex into products has become feasible, running it stably as an online service still poses considerable challenges.
To give a specific example: if you use the App Server to build your own coding agent website, and the frontend has already connected to Codex, after the user clicks "fix this repository", you still need to figure out solutions for a large number of subsequent runtime and infrastructure issues on your own.
Then on August 19, OpenAI incorporated the CLI, SDK, and App Server that it had incrementally released over the past year into the overarching narrative of the "Open Codex Harness" platform, and explicitly elevated Codex from a standalone product to a full platform.
Shortly after, on September 10 US time, which was yesterday, the Agents API officially entered public beta.
This time, developers only need to tell the API four things: the task, the model, the tools, and the runtime environment, and they can directly create an agent. The Codex Harness, which handles long-session context compression, tool scheduling, and subagent collaboration, is fully hosted and maintained by OpenAI.
Developers can even choose the exact infrastructure where their agents run: they can use OpenAI's sandbox, their own infrastructure, or third-party environments such as Cloudflare, E2B, and Modal. The Harness is provided by OpenAI, while the execution environment is entirely up to the developer.
The official statement is clear: the Agents API itself does not incur additional fees. In other words, capabilities including Harness hosting and long-session management do not come with a separate agent platform surcharge.
Developers only pay for the model tokens and tools they actually use; if they use OpenAI's own hosted sandbox, computing resources are billed separately.
Looking back at the past year, OpenAI has been working on the same thing: breaking Codex down layer by layer from a concrete product into reusable capabilities, while reducing the operational burden on developers more and more.
If you want to give this product line a name, it is very similar to the SaaS concept that rose to prominence years ago, except that this time what is being delivered as a service is not software, but Codex.
Codex as a Service.
02 The Harness ecosystem is starting to diverge
OpenAI is far from the only player targeting the Harness space.
When DeepSeek Harness (hereinafter referred to as DSH) was released, it put forward a very well-known equation: Agent = Model + Harness.
From DeepSeek's perspective, the model is only half of an agent. The other half is the Harness, which is responsible for helping the agent understand the environment, invoke tools, manage state, and execute tasks continuously. The two components work in coordination to enable agents to complete real tasks.
DSH has built the Harness itself as a highly modular open framework: the model, tools, skills, session management, sandbox, storage, agent loop, scheduling, and even the UI can all be replaced.
The slogan "everything is a plugin" is not just empty talk. DeepSeek hopes that more developers will write plugins and adapt to DSH, so that no matter which model runs on top of the stack, whether it is DeepSeek or other third-party models, they can all run on the same underlying Harness.
This forms a very interesting contrast with the direction OpenAI is currently taking.
Although OpenAI has also open-sourced the Codex Harness, the Agents API is clearly moving in a different direction: you can use your own Harness, or you can use the open-source version, but if you do not want to deal with the hassle, you can leave all the work to OpenAI.
That is why we believe it is more of a "service" model. OpenAI is responsible for hosting and continuously maintaining the Harness, while developers only need to decide what tasks they want the agent to perform, what tools to use, and where to run them. Even future model upgrades and corresponding Harness adjustments will be handled by OpenAI.
In a sense, two distinct paths have emerged in the Harness layer:
The path represented by DeepSeek is more focused on building an open ecosystem, turning every component into a plugin that developers can assemble on their own. The path represented by OpenAI is more like betting on cloud services: as long as you pay for the resources and define your requirements, OpenAI will handle the rest for you.
We can even say that one path aims to make Harness more like Linux, while the other aims to make Harness more like AWS.
Of course, this is just a metaphor. OpenAI has open-sourced Codex Harness, and DeepSeek may also launch more hosted services in the future. But at least at the current stage, the core focus of the two parties' products is clearly different.
Interestingly, Anthropic actually moved earlier than OpenAI on the path of turning Harness into a service.
Back in September 2025, Anthropic launched the Claude Agent SDK, exposing the tools, context management, permission system, and subagent capabilities behind Claude Code to developers, so that third parties can also build their own agents on top of this stack.
In April this year, it launched Claude Managed Agents even earlier than OpenAI. It split sessions, Harness, and sandboxes into three independent layers: Anthropic is responsible for hosting the Harness and long-running tasks, while sandboxes can be provided by Anthropic or connected to other execution environments. This design concept is very close to today's Agents API, and Anthropic itself defines it as "a hosted service for long-running agent tasks".
In a sense, OpenAI is moving forward along the path that Anthropic has already paved, the only difference being that OpenAI has a far more "productized" Codex in its arsenal.
But because Codex and Claude Code have long established distinct product identities, even if they are telling the same story, the experience they deliver feels very different. Claude Code is perceived by users as a tool that lets developers sit in the terminal and write code alongside agents, while Codex App was initially designed with an interface that emphasizes "monitoring multiple long-running agents at the same time".
As a side note, Google has also joined this trend long ago. At the I/O conference in May this year, the Gemini API launched Managed Agents, which also turned the Antigravity Harness and sandboxes into hosted services. But Google's advantage extends far beyond that, which we will discuss later.
That said, the order of entry is not that important after all. Ultimately, the player that turns its own Harness into the default underlying layer for all developers will capture the largest market share.
03 Who is the biggest winner?
At the end of the day, why are all model vendors scrambling to enter the Harness space now?
Just like the equation put forward by DSH: Agent = Model + Harness. The model can tell the agent what to do next, but to complete a full task from start to finish, the agent also needs to know where the files are, which tool to invoke, how to recover from errors, and where to output the final results.
In other words, the model determines the upper limit of an agent's capabilities, while the Harness increasingly determines whether the agent can actually get the job done.
Once the dimension of competition shifts from "intelligence" to "execution capability", the players with the greatest advantage are not necessarily the AI companies that build the best models.
This is because the resources agents need to do real work — emails, documents, meetings, communications, account permissions, and so on — are mostly controlled by traditional platform companies.
The fiercely competitive "office agent war" that has recently broken out in the Chinese market is a very typical example. The assets that major tech giants accumulated in the internet platform era used to be just scattered features within their own ecosystems, but in the agent era, these assets are exactly the tools that agents need to invoke to perform real work.
When companies build office agents today, on the surface they are competing to see whose AI employee is smarter and more capable, but behind the scenes they are leveraging the platform advantages they have accumulated over the past decades. The companies that hold more enterprise data, documents, tools, and permissions will find it much easier to make their agents actually complete tasks.
Model companies need to gradually integrate the access points that they do not own, while companies that have developed office software and internet platforms for decades already have native control over these access points.
In other words, AI companies need to reconnect with the real world, while platform companies already hold a full set of keys to it.
Looking ahead along this path, if we have to pick the most well-positioned "full-stack" player, Google is arguably the most formidable one.
From TPUs, cloud infrastructure, and Gemini, to Search, Workspace, Chrome, and Android, Google covers almost all key links of AI development from underlying technology to end users. Products including Search, Gmail, Calendar, Drive, YouTube, and Maps naturally form a digital environment that can be invoked by agents. These assets were independent entry points in the previous generation of the internet, but in the agent era, they can be reorganized to work together under the same task.
In fact, Google has already started to converge the agent capabilities scattered across its various products into the same underlying execution system. Gemini Spark, Managed Agents in the Gemini API, and even some agent experiences in Search are gradually sharing the same Antigravity Harness.
But on the end user side, the experience is still fragmented.
Today, Google offers Gemini Spark, Workspace Studio, Antigravity, Gemini Enterprise, and the information agents built into Search. They target different users and scenarios, but for ordinary users, when they want to hand over a complex task entirely to Google, they still do not know which tool to use.
For Google, it already has most of the conditions needed to make this vision a reality. What it lacks is just a simple, unified product solution.
If Google manages to get this right — whether it builds a unified agent workspace, or makes the same agent execution system run across the entire Google ecosystem to make users accustomed to "turn to Google for any problem" — the competitive landscape of the global agent market will be reshaped.
That said, even if Google rolls out this full-stack agent ecosystem, most users in China will only be able to observe it from the sidelines for the time being.
Let's first wait and see how the domestic agent war unfolds in the next phase.
This article is from WeChat official account "Alpha AI", written by Yuan Xinyue, and published with authorization from 36Kr.