OpenAI Unbundles Codex: Agent Competition Enters Runtime Era

Introduction

OpenAI's recent product release appears to add an Agents API, but the underlying change is far more significant. Previously, developers building persistent agents had to handle context management, tool invocation, task state, sandboxes, failure recovery, and multi-agent coordination themselves. The model was only one component; the engineering skeleton that made the system run had to be built by application teams.

Now OpenAI has extracted the Harness behind Codex and exposed it as a cloud capability. Developers specify the task, model, tools, and execution environment, while the platform manages long-session context, tool scheduling, and subagent collaboration.

This marks a clear product trajectory: Codex is no longer just a coding application but a composable Agent Runtime that can be embedded in other products.

How Codex Was Unbundled Step by Step

Starting with Local CLI

In April 2025, OpenAI open-sourced Codex CLI. It runs directly in the local terminal, making the agent loop and tool calls visible and modifiable by developers. This step solved the problem of letting developers study and customize Codex, though they still had to manage the runtime environment, task orchestration, and production stability.

A month later, the cloud version of Codex launched. Repositories were placed in independent cloud sandboxes, each task getting its own execution space where the agent could modify code, run tests, fix issues, and handle multiple tasks concurrently. Codex had become a cloud product with an execution environment, but developers still consumed it as a complete product rather than calling a specific layer.

SDK Embeds Codex into Other Programs

In October 2025, OpenAI released the Codex SDK. Its value lies not in adding a chat entry point but in letting developers launch Codex CLI-driven agents inside their own programs. The SDK provides structured output, preserves task state, and allows resumption after pauses, making Codex suitable for background workflows, automation scripts, and server-side tasks.

However, the SDK mainly addresses how to invoke Codex programmatically. Building a full IDE client or letting users supervise multiple tasks continuously still required more interaction and runtime management capabilities than the SDK exposed.

App Server Exposes the Full Harness

In February 2026, Codex App Server was made public, and OpenAI clarified the internal Harness. Codex Web, CLI, IDE extensions, and Mac App are different front ends running the same Codex Harness, which handles the Agent Loop, Threads, tool execution, authentication, and task state management.

App Server provides a bidirectional JSON-RPC interface for this Harness. Clients like JetBrains or Xcode no longer need to reimplement the Agent Loop; they can drive the full Codex by starting App Server. This step enables reuse of Codex's complete execution capability by other clients, but SDK and App Server still require developers to deploy and maintain them.

For example, if you build a coding agent website with App Server, task queuing, process keep-alive, resource isolation, state recovery, and exception handling remain the application team's responsibility.

From Open Harness to Agents API

On August 19, 2026, OpenAI unified CLI, SDK, and App Server under the "Open Codex Harness" platform narrative, elevating Codex from a single product to a platform. On September 10, Agents API entered public beta. Developers only need to describe four things to the API:

Task – what goal the agent should achieve

Model – which model handles reasoning and decisions

Tools – which external capabilities the agent can access

Execution Environment – where code and tools actually run

The Harness responsible for long-session context compression, tool scheduling, and subagent collaboration is hosted and maintained by OpenAI. The machines that actually carry out tasks can be chosen by developers: OpenAI sandboxes, self-hosted infrastructure, or third-party environments like Cloudflare, E2B, or Modal.

A notable layering emerges:

Harness manages how the agent runs continuously

Execution environment manages where the agent works

Model understands the goal and decides the next step

Tools connect the agent to real systems

OpenAI turns the first layer into a service, letting developers retain control over the execution environment while reducing the burden of maintaining the agent runtime.

What Agents API Actually Sells

Not a Single Model Call, but a Sustainably Running Task

Standard model APIs resemble request-response. Complex agents require continuous execution: reading files, invoking tools, analyzing results, modifying state, and continuing until completion or human takeover. In this chain, the model does not handle everything; it must know the current task progress, which tools have been used, which approaches failed, and whether to proceed or roll back. Simply stitching history messages at the application layer quickly leads to exploding context, unrecoverable state, and expanding error branches.

Agents API's value is to uniformly manage these runtime capabilities required for long-running tasks outside the model call.

Context Management Becomes Infrastructure

Long tasks cannot stuff all historical interactions into every round. The runtime must organize early content as context approaches critical limits, preserving state still needed for execution. For a coding agent, valuable state includes:

Current repository and working directory

Completed modifications

Invoked tools and their results

Confirmed configurations and permissions

Failed handling paths

Unresolved issues and next hypotheses

If this state is not correctly saved, the agent appears to continue working but has actually lost task memory. Context compression is therefore not merely deleting old messages but extracting information useful for subsequent execution.

Tool Scheduling Determines How Far an Agent Can Go

A production-grade agent often connects to code repositories, log platforms, databases, search services, ticketing systems, and internal APIs. With many tools, stuffing all descriptions unscreened into context is impossible. The runtime must:

Judge which capabilities the current task needs

Select appropriate tools and parameter descriptions

Execute tools and save results

Decide whether to continue calling other tools based on results

Poor tool scheduling can stall even a strong reasoning model due to wrong tool selection, incomplete parameters, or inability to handle error returns.

Subagent Collaboration Changes Task Decomposition

When a goal can be split into independent workstreams, the main agent can delegate subtasks to multiple subagents and aggregate results. For instance, a code quality analysis task can be divided into:

One agent checks dependencies and build configuration

One agent scans test coverage and failing cases

One agent analyzes performance logs

Main agent merges conclusions and proposes modification order

This reduces single-context complexity, but concurrency is not always better. More subtasks increase tool calls, result merging, and resource consumption, and the main agent must resolve conflicting conclusions across subtasks.

Harness Splits into Two Strategic Lines

OpenAI is not alone in targeting the Harness. DeepSeek Harness states directly: Agent = Model + Harness. In this formula, the model handles understanding and reasoning, while Harness enables the agent to perceive the environment, invoke tools, manage state, and continuously execute tasks. Only together can they carry a complex goal from start to finish.

DeepSeek: Building an Open Ecosystem for the Runtime

DeepSeek Harness adopts a highly modular approach. Models, tools, Skills, Sessions, sandboxes, storage, Agent Loop, scheduling, and even UI are replaceable. The "everything is a plugin" design aims to let different models plug into the same underlying Harness. Developers choose components and assemble their own runtime environment; the framework itself becomes part of an open ecosystem.

OpenAI: Turning Complex Runtime into a Cloud Service

OpenAI also opens Codex Harness, but Agents API takes a different path: you can use the open-source Harness yourself, use only parts of it, or offload runtime maintenance to OpenAI. This simplifies developer responsibility boundaries:

Business teams define the agent's task

Application teams declare models and tools

Infrastructure teams choose execution environments

OpenAI hosts the Harness and long-task capabilities

The two lines can be roughly understood as: DeepSeek builds an assemblable open foundation, while OpenAI provides an out-of-the-box cloud runtime. The former gives control to developers; the latter shifts maintenance cost to the platform.

Anthropic and Google Compete at the Same Layer

In September 2025, Anthropic launched Claude Agent SDK, opening the tools, context management, permission system, and subagent capabilities behind Claude Code. In April 2026, Anthropic introduced Claude Managed Agents, splitting Session, Harness, and sandbox into independent layers. Anthropic hosts the Harness and long tasks, while sandboxes can use Anthropic's environment or integrate others.

Google has also launched Managed Agents in the Gemini API, turning the Antigravity Harness and sandbox into a managed service. Vendor naming differs, but the competitive layer is converging: whoever makes it easier for developers to run long tasks stably will likely become the default foundation for agent applications.

Why Agent Competition Moves from Model to Runtime

Models can tell an agent what to do next, but to actually finish a task the system must know:

Where files are located

Which tool to invoke

How to recover from tool failures

Where to store intermediate results

How to leave an auditable state after completion

Model capability sets the agent's ceiling; Harness increasingly determines whether the agent can complete the task. As competition shifts from "reasoning ability" to "execution ability," platform companies with real-world entry points gain new advantages. Email, documents, meetings, contacts, account permissions, and enterprise data are all necessary tools for agents to get work done.

Domestic office agent competition reflects this change. On the surface, vendors compare whose AI employee is smarter; underneath, they compete over who connects more enterprise data, business tools, and organizational permissions.

This is also why traditional platforms regain initiative. Model companies must gradually integrate data and tools they lack, while companies that have long operated office software and internet platforms already control the entrances to many real-world systems.

Google's "Full Stack" Advantage

Looking at resource coverage, Google is a formidable competitor in the agent era. From TPUs, cloud infrastructure, and Gemini to Search, Workspace, Chrome, Android, and further to Gmail, Calendar, Drive, YouTube, and Maps, Google simultaneously covers underlying compute, models, cloud services, user entry points, and digital environments callable by agents.

In the previous internet generation, these products were scattered entry points. In the agent era, they can recombine around a single task: search materials, read emails, organize documents, schedule meetings, generate content, and deliver results to user-specified locations.

Google is gradually consolidating agent capabilities scattered across products into a shared execution system. Gemini Spark, Gemini API's Managed Agents, and Search's agent experiences are all moving toward a shared Antigravity Harness.

However, Google faces a product-level challenge: Gemini Spark, Workspace Studio, Antigravity, Gemini Enterprise, and Search's Information Agents target different users and scenarios. Google already possesses most components needed for complex agent tasks; what it lacks is a sufficiently simple product answer. If it can make a single execution system permeate the entire ecosystem so users only need to "ask Google," the market landscape may shift further.

How Developers Should Choose a Runtime

First Distinguish Short Tasks from Long Tasks

Single Q&A, code completion, or simple text generation may not need a full Harness. Only when tasks involve multi-round tool calls, cross-file modifications, external system operations, parallel subtasks, and continuous debugging does the runtime noticeably affect outcomes. Turning every request into an agent adds system complexity and cost. Determining whether a task truly requires continuous execution is the first filter.

Then Examine Data and Permission Boundaries

Agents touch code, files, logs, database records, and internal systems. Before using a managed Harness, clarify which layer data enters, what permissions tools run with, whether sandboxes can access the intranet, and how long intermediate task states are retained. Don't only look at model API inputs and outputs; tool return values, subagent intermediate results, and sandbox temporary files may also contain sensitive information.

Finally Evaluate Recovery and Observability Capabilities

An agent that passes a demo is not necessarily production-ready. At minimum, answer these questions:

Can the task resume from the last stable state after interruption?

Do tool failures have explicit retry and backoff strategies?

Who arbitrates when subagent results conflict?

Can sandboxes and processes be cleaned up promptly after user cancellation?

Can you measure model tokens, tool calls, execution duration, and human takeover rates?

If these questions lack answers, you are integrating not an operable agent but a temporarily working automation script.

Cloud-Hosted vs. Self-Hosted Harness

Cloud-hosted Harness suits rapid product validation and teams unwilling to maintain runtime; trade-off: data, cost, and platform capability lock-in.

Self-hosted Harness suits strong control requirements over data boundaries, execution logic, and deployment location; trade-off: you must maintain scheduling, state, sandboxes, and observability yourself.

Hybrid Deployment suits public tasks on cloud, sensitive tasks in self-hosted environments; trade-off: architecture and permission management become more complex.

OpenAI's Agents API itself charges no extra platform licensing fee; developers pay for actual model tokens and tool usage. If using OpenAI-hosted sandboxes, compute resources are billed separately. "Framework not charged separately" does not mean zero agent cost; multi-agent concurrency, repeated tool calls, and long sandbox runs expand the total bill.

For domestic teams, model access and network environment often add another layer of friction. When unified management of model endpoints and credentials is needed, consider Code80 to streamline the access layer first, then decide which tasks go to managed runtime and which stay in self-hosted environments.

Frequently Asked Questions

1. What is the difference between Agents API and regular model API?

Regular model API mainly handles single or multi-turn reasoning; Agents API further provides the Harness needed for long tasks, including context management, tool scheduling, task state, and subagent collaboration.

2. Is Codex Harness a model?

No. The model understands goals, plans steps, and generates decisions; Harness connects tools, saves state, continuously executes, and handles the runtime process.

3. Do I still need to prepare an execution environment after using Agents API?

Not necessarily. You can choose OpenAI sandboxes, your own infrastructure, or integrate third-party execution environments like Cloudflare, E2B, or Modal. Harness and execution environment are two different layers.

4. Do multiple subagents working together always make things faster?

Not necessarily. Only independent, parallelizable tasks benefit from splitting. Excessive concurrency increases tool calls, result merging, sandbox resource consumption, and may force the main agent to handle contradictory conclusions.

5. How to choose between open-source Codex Harness and managed Agents API?

For rapid product validation and reduced infrastructure maintenance, prefer managed runtime; for strict control over data, permissions, execution logic, and deployment location, evaluate self-hosted or hybrid deployment.

6. How can domestic developers reduce integration complexity?

First confirm model permissions, endpoints, data residency, tool protocols, and execution environments, then decouple model calls from business agents. For easier API access, check Code80 for available channels.

Conclusion

OpenAI's move is not simply adding an entry point to Codex but decomposing it into reusable layers: CLI for local execution, SDK for programmatic invocation, App Server for full interaction, and Agents API for servitizing the Harness.

Going forward, the gap between agent products will not only reflect how human-like model answers are. Whoever manages context more stably, schedules tools more accurately, runs tasks more securely, and connects these capabilities to real enterprise data and permission systems will become the foundation developers rely on long-term.