OpenAI "took apart and sold" Codex

Because this time, OpenAI "took apart and sold" the Codex.

The set of capabilities originally hidden behind the Codex and responsible for allowing the Agent to continue working, calling tools, managing context, and coordinating multiple Agents were extracted and packaged into a cloud API for all developers to call.

Codex as a service?

In fact, OpenAI has been dismantling the Codex for a long time.

As early as April 2025, when OpenAI first released o3 and o4-mini, it open sourced the Codex CLI. It is a bit like the OpenAI version of Claude Code, installed directly in the local terminal. How to run the Agent and how to call the tools are all clearly posted on GitHub. If you are willing to put in the effort, you can take it back, modify it, and run it yourself.

But at that time, things were simply given out. Whether you can use them and how you want to use them is still your own business.

One month later, the Codex cloud version, the product we are familiar with today, was officially launched. Users can hand over the code warehouse to it, and each task corresponds to an independent cloud sandbox. Codex can modify the code, run tests, fix bugs, and handle multiple tasks at the same time.

A few months later, in October 2025, OpenAI released the Codex SDK.

To put it simply, the SDK is a toolkit for developers, so that Codex can not only be used as a standalone product, but can also be integrated into other people's applications. The SDK allows developers to use a few lines of TypeScript code to start the same Agent that drives the Codex CLI, get structured output, retain the task status, and continue running after being paused.

However, the SDK is mainly suitable for calling Codex in programs, and has not yet opened up the complete Codex interaction capabilities. It is very suitable for background workflows, automated scripts, and server-side programs. But if you want to make a complete client like Codex IDE, it is still a bit difficult.

So in February 2026, OpenAI officially released the Codex App Server, and for the first time systematically explained the Harness in the Codex clearly.

OpenAI clearly explained that Codex Web, CLI, IDE extensions and Mac App appear to be different products, but they are actually running the same Codex Harness underneath, which is the layer responsible for Agent Loop, Thread, tool execution, authentication and management status.

App Server adds a bidirectional JSON-RPC interface to this complete set of Harness. JetBrains, Xcode or other clients do not need to re-create an Agent Loop. They can directly start the App Server to drive the complete Codex.

With App Server, other products can be directly connected to the complete Codex Harness.

But at this point, there is one last problem that remains to be solved.

The SDK controls the local Codex Agent, and the App Server itself is also a resident process that needs to be started and maintained by developers. Although the issue of integrating Codex into the product has been solved, it is still a bit difficult to stably run it into an online service.

To give a more specific example, if you use App Server to build your own Coding Agent website, the front end has been connected to Codex, but when the user clicks "Repair this warehouse", you will still need to find a way to solve a large number of subsequent operation and infrastructure problems.

Then August 19th came. On this day, OpenAI unified the CLI, SDK, and App Server that had been opened in the past year into the platform narrative of "Open Codex Harness", and clearly upgraded Codex from a product to a platform.

Then on September 10th (US time), which is yesterday, the Agents API was officially opened for public testing.

This time, developers only need to tell the API four things - tasks, models, tools, and running environments - to directly create an Agent. Codex Harness, which is responsible for long session context compression, tool scheduling and subagent collaboration, is hosted and maintained by OpenAI itself.

You can even choose the machine on which the Agent actually works. You can choose whether to use OpenAI's sandbox, your own infrastructure, or third-party environments such as Cloudflare, E2B, and Modal. Harness is provided by OpenAI, and the execution environment is determined by the developer.

The official statement is very clear, there is no additional charge for the Agents API itself. In other words, Harness hosting, long session management and other capabilities do not charge a separate layer of Agent platform fees.

Developers pay based on the model tokens and tools actually used; if OpenAI’s own hosting sandbox is used, computing resources are calculated separately.

For more than a year, OpenAI has been doing the same thing: splitting Codex from a specific product into reusable capabilities layer by layer, while allowing developers to worry less and less about themselves.

If you must give this product line a name, it is actually very similar to SaaS back then, except that this time it is not software that is being serviced, but Codex.

Codex as a Service.

Harness has also begun to fork

Of course OpenAI is not the only one eyeing Harness.

When DeepSeek Harness (hereinafter referred to as DSH) was released, a very loud equation was given:

Agent = Model + Harness.

In DeepSeek's view, the model is only half of the Agent, and the other half is the Harness that is responsible for letting it understand the environment, call tools, manage status, and continue to execute tasks. Only when the two coordinate with each other can the Agent actually perform its tasks.

DSH has made Harness itself into a highly modular open framework: models, tools, Skills, Sessions, sandboxes, storage, Agent Loop, scheduling, and even UI can all be replaced.

The slogan "Everything is a plug-in" is not just a joke. It is best for everyone to write plug-ins and adapt to DSH. In the end, regardless of whether DeepSeek or other models are running on top, the same set of Harness can be used underneath.

This is an interesting contrast to the direction OpenAI is taking now.

Although OpenAI has also open sourced the Codex harness, the Agents API is obviously going in the other direction: you can use your own Harness, or you can take the open source one, but if you find it troublesome, you can just ignore it and let me arrange it for you.

So we think of it as more of a "service". OpenAI is responsible for hosting and continuously maintaining Harness. Developers only need to decide what they want the Agent to do, what tools to use, and where to execute it. Even if the model is upgraded in the future, if Harness changes accordingly, OpenAI will also prepare to package it together.

In a sense, there are two vague routes on the Harness level:

The route represented by DeepSeek is more like building an open ecosystem, making every part into a plug-in for developers to assemble themselves; while the party represented by OpenAI is like betting on cloud services, putting money and demand in place, and I will help you solve the rest.

We can even think that one wants to make Harness more and more like Linux, and the other wants to make Harness more and more like AWS.

Of course, this is just a metaphor. OpenAI has also open sourced Codex Harness, and it is not impossible for DeepSeek to provide more hosting services in the future. But at least at this stage, the focus of the two products is obviously different.

Interestingly, Anthropic is actually one step ahead of OpenAI in turning Harness into a service.

As early as September 2025, Anthropic launched the Claude Agent SDK, opening the tools, context management, permission system and subagent capabilities behind Claude Code to developers, so that others can use this set of things as agents.

In April this year, it launched Claude Managed Agents even earlier than OpenAI. Session, harness, and sandbox are split into three independent layers: Anthropic is responsible for hosting harness and long tasks. The sandbox can be provided by Anthropic or can be connected to other execution environments. This idea is actually quite close to today's Agents API. Anthropic itself defines it as "a hosting service for long-term Agent tasks."

So in a sense, OpenAI is continuing to move forward along the path Anthropic has taken this time. The difference is that OpenAI has a more "productized" Codex.

However, because Codex and Claude Code have given different product impressions for a long time, even if they tell the same story, they bring about very different feelings. Claude Code feels more like letting developers sit in the terminal and write code together with Agent, while Codex App emphasizes the interface of "simultaneously supervising multiple long-term Agents" from the beginning.

By the way, Google has already joined this route. At the I/O conference in May this year, Gemini API launched Managed Agents, which also turned Antigravity Harness and sandbox into managed services. But Google’s cards don’t stop there, which we’ll discuss later.

But having said that, it doesn’t seem to be that important who comes first... In the end, of course, whoever turns their Harness into the default layer for developers will be able to eat the biggest cake.

Who is the big winner?

After all, why are model companies now starting to grab Harness?

Just like the equation given by DSH, Agent = Model + Harness, the model can tell the Agent what to do next, but to really run a task from beginning to end, it still has to know where the file is, which tool needs to be called, how to recover when an error occurs, and where the results are finally written.

In other words, the model determines the upper limit of the Agent's ability, and Harness increasingly determines whether it can complete the job.

Once the dimension of competition shifts from "intelligence" to "execution," the ones with the most advantage may not be those AI companies with the best models.

Because after the Agent actually starts working, the things it needs—emails, documents, meetings, communications, account permissions, etc.—are often in the hands of traditional platform companies.

The recently heated “Office Agent War” in China is actually a very typical example: the things that big companies accumulated in the era of Internet platforms used to be more of just part of the functions in their respective ecosystems, but in the era of Agents, these things happen to be the tools that Agents need to call when they really work.

Nowadays, everyone is working as an office agent. On the surface, they are smarter and more capable than anyone else's AI employees. Behind the scenes, they are actually reusing the platform advantages they have accumulated in the past. Whoever has more enterprise data, documents, tools and permissions will have an easier time letting the Agent get things done.

Model companies need to gain access to portals they do not have, and those companies that have been making office software and Internet platforms for more than ten years already have these portals.

In other words,

AI companies want to reconnect with the real world, and platform companies already have a bunch of keys in their hands.

Looking along this road, if we have to find a "family bucket" player with the most advantages, Google is probably the most exaggerated one.

From TPU, cloud infrastructure, Gemini, to Search, Workspace, Chrome and Android, Google covers almost all key aspects of AI from underlying technology to end users. Search, Gmail, Calendar, Drive, YouTube, Maps and other products naturally form a digital environment that can be called by Agents. These assets were independent portals in the previous generation of Internet, but in the Agent era, they can be reorganized into the same task.

In fact, Google has begun to integrate the Agent capabilities scattered in various products into the same execution system at the bottom. Gemini Spark, Managed Agents in Gemini API, and even some Agent experiences in Search are gradually sharing the same Antigravity Harness behind them.

But on the user side, things are still a bit messy.

Today Google also has Gemini Spark, Workspace Studio, Antigravity, Gemini Enterprise, and Information agents in Search. They face different users and scenarios, but for ordinary people, when they want to hand over a complex matter to Google, they still don't know who to turn to.

For Google, it already has most of the conditions needed to accomplish all this. What is missing is a simple enough product answer.

And if Google really understands this matter - whether it is creating a unified Agent workbench, or letting the same Agent execution system penetrate the entire Google ecosystem, so that users will become accustomed to "finding Google when they have problems", the competitive landscape of the global Agent market will probably change again.

Having said that, even if Google really puts this "family bucket" into an Agent, domestic users will most likely only be able to watch it first.

Let’s take a look at the domestic Agent war first and see how it will be fought next.