OpenAI Agents API Turns the Codex Harness Into Cloud Infrastructure

Key Takeaways

• OpenAI’s Agents API is not simply another agent SDK. It exposes the managed Codex harness as a cloud service, with OpenAI handling sessions, orchestration, context compaction, and recovery while developers provide the task, tools, data, and execution environment.
• The API entered public beta on September 10, 2026 and is available to developers without a separate Agents API fee. Model usage, OpenAI tools, and hosted sandbox compute are billed separately.
• Long-running agents can work across multiple context windows without requiring developers to build their own compaction layer. OpenAI positions the system for workflows that may run for hours or days.
• Native multi-agent orchestration lets a coordinator delegate work to parallel subagents. Each subagent gets its own context, while the coordinator combines the results. The documented default limit is six concurrent subagents, excluding the coordinator.
• Agents can use MCP servers, custom functions, web search, tool search, programmatic tool calling, skills, plugins, and vault-backed credentials.
• OpenAI-hosted sandboxes provide a Linux workspace with Python, Node.js, files, package installation, and command-line tools. Developers can also attach their own infrastructure or supported third-party sandboxes.
• The most important architectural shift is that the agent harness is becoming infrastructure. The competitive advantage for application companies moves upward toward proprietary workflows, data, permissions, integrations, domain expertise, and distribution.
• There is an important enterprise limitation: the Agents API currently supports U.S.-only data residency and does not support Zero Data Retention, even when the sandbox itself is self-hosted.

OpenAI Has Turned the Codex Harness Into an API

The most consequential part of OpenAI’s Agents API launch is easy to miss if it is treated as another entry in the growing list of agent frameworks.

The new API does not merely provide helper classes for building an agent loop. OpenAI is offering the managed harness that powers Codex as a cloud service.

That distinction matters.

A model API answers a request. An agent SDK helps developers write orchestration code. A managed agent harness takes responsibility for the persistent control loop around the model: maintaining sessions, deciding when to call tools, preserving useful context, recovering from interruptions, coordinating subagents, and keeping the task alive while execution happens somewhere else.

OpenAI’s own documentation describes the split directly: the Agents API gives an application access to the Codex harness, while OpenAI manages sessions, orchestration, context compaction, and recovery. The application supplies tools and chooses the execution environment.

That makes the Agents API closer to an Agent Runtime as a Service than to a conventional LLM endpoint.

Why the Agent Harness Matters More Than It Sounds

Modern agents are not just prompts wrapped around a model.

A production agent typically needs to solve several infrastructure problems:

• preserve state across many turns;
• decide which tools are relevant;
• execute tools safely;
• keep large tool outputs out of the model context when possible;
• compact context before the model reaches its limit;
• retry or recover after transient failures;
• coordinate parallel workers;
• maintain a filesystem or workspace;
• manage credentials;
• expose progress and traces to the application;
• continue running when a browser tab, client, or network connection disappears.

Codex already needed this machinery because coding tasks routinely span many steps, involve files and shells, and can run long enough that a simple request-response architecture breaks down.

OpenAI explained earlier in 2026 that Codex across the CLI, web product, IDE extension, and desktop surfaces is powered by the same underlying harness. That harness includes the core agent loop, thread persistence, tool execution, configuration, authentication, MCP integration, and skills.

The Agents API productizes that layer.

This is why describing the launch as “OpenAI released another agent SDK” materially understates what changed.

Agents API vs Responses API vs Agents SDK vs Codex App Server

The differences are easiest to understand as a question of who owns the loop.

The important dividing line is not whether all four can call a model. They can.

The dividing line is whether a development team wants to operate the agent control plane itself.

With the Agents SDK, the application remains responsible for running the agent runtime. With the Agents API, OpenAI runs the Codex harness and session state while the developer chooses where commands and files live. Third-party reference integrations from Vercel and Cloudflare explicitly describe this architectural difference.

The New Architecture: Harness and Sandbox Are Separate

One of the most important design decisions is the separation between the harness and the sandbox.

A simplified architecture looks like this:

Your product
    |
    v
Agents API
    |
    +-- durable session
    +-- agent loop
    +-- context management
    +-- tool orchestration
    +-- subagent coordination
    +-- recovery
    |
    v
Execution environment
    |
    +-- OpenAI-hosted sandbox
    +-- your own server / VPC
    +-- Cloudflare
    +-- E2B
    +-- Modal
    +-- Vercel
    +-- other supported providers

OpenAI hosts and evolves the harness. The developer can still decide where code executes and where files live. OpenAI’s launch announcement lists Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop, and Vercel as sandbox ecosystem partners.

This separation is strategically significant.

OpenAI is not requiring every agent workload to run inside an OpenAI VM. Instead, it is positioning the Codex harness as the control plane that can sit above interchangeable execution providers.

That resembles a familiar cloud pattern: one company can own orchestration while compute remains portable.

Long-Running Sessions and Automatic Context Compaction

The context window has historically been one of the least visible but most important constraints on autonomous agents.

A naive long-running agent tends to fail in one of two ways:

1. It keeps appending every event until the context becomes too large.
2. It implements a home-grown summarization strategy that eventually drops an important requirement, file path, decision, or intermediate result.

The Agents API moves this responsibility into the managed harness.

OpenAI states that the harness manages context compaction and that agents can operate across multiple context windows without developers implementing their own compaction logic.

Conceptually, the runtime can behave like this:

Context window A
      |
      v
Managed compaction
      |
      +-- preserved goals
      +-- key decisions
      +-- important tool state
      +-- relevant artifacts
      |
      v
Context window B
      |
      v
Managed compaction
      |
      v
Context window C

This does not make context management magically perfect. Compaction can still lose useful detail, and long tasks should still persist important state in files, databases, or structured artifacts.

But it changes who owns the generic mechanism.

For many teams, that means one less infrastructure layer to build, benchmark, and maintain.

Durable Sessions Change the Failure Model

A durable agent session is more than conversation history.

It allows the application to treat agent work as a continuing job rather than a single HTTP response.

OpenAI’s documentation says session state is retained so work can continue across turns without reconstructing the conversation context.

That enables workflows such as:

• incident investigation that continues while logs arrive;
• code migration across many files;
• research that fans out into several independent investigations;
• document review that pauses for approval;
• data analysis that creates intermediate artifacts;
• operational agents that resume after an environment reconnects.

The architectural implication is important: the client no longer has to be the source of truth for the agent’s progress.

That is the same lesson OpenAI documented when explaining Codex Web. A browser tab can disappear, networks can drop, and users can reconnect later; therefore, long-running task state has to live on the server side.

Native Multi-Agent Orchestration

Multi-agent systems have often been implemented as application-level glue code:

main agent
  -> create task A
  -> create task B
  -> create task C
  -> run workers
  -> poll workers
  -> collect outputs
  -> resolve failures
  -> synthesize answer

The Agents API makes delegation a first-class capability.

Developers can enable multi-agent behavior and set max_concurrent_subagents. OpenAI documents a default limit of six concurrent subagents, excluding the coordinator.

A minimal configuration resembles:

{
  "multi_agent": {
    "enabled": true,
    "max_concurrent_subagents": 3
  }
}

Each subagent maintains its own context, which is important because parallel workers do not need to contaminate one another with every intermediate detail. The coordinator remains responsible for the overall task and final synthesis.

When an execution environment is attached, the coordinator and subagents share that environment’s filesystem rather than automatically receiving separate sandboxes. OpenAI explicitly documents that creating a subagent does not create another environment.

That is both useful and dangerous.

It is useful because workers can collaborate through shared files without duplicating large workspaces.

It is dangerous because parallel agents can modify the same files or resources. Production systems should therefore design clear file ownership, working directories, locking, or task partitioning when simultaneous writes are possible.

Tool Search May Be as Important as Multi-Agent

Tool calling becomes difficult when the agent has access to hundreds or thousands of tools.

Sending every tool definition into every model request wastes tokens, reduces cache efficiency, and gives the model a larger decision surface.

OpenAI’s launch announcement introduces tool search, which loads relevant tool definitions as needed. It is explicitly positioned as a way to reduce token usage and cost while preserving model cache behavior.

This suggests a broader direction for agent architecture:

Task
  |
  v
Search available capabilities
  |
  v
Load only relevant tools
  |
  v
Execute

That architecture is much better suited to enterprise tool catalogs, MCP directories, plugin ecosystems, and large internal capability libraries than a static prompt containing every possible function schema.

The long-term implication is that capability discovery becomes part of the runtime.

MCP Is Now a Core Runtime Primitive

The Agents API supports MCP connections directly, making external tools and internal services first-class parts of the agent environment.

This matters because MCP moves integrations away from one-off function wrappers toward a reusable protocol boundary.

A company could expose:

• GitHub operations;
• observability systems;
• deployment systems;
• internal documentation;
• ticketing;
• databases;
• finance systems;
• CRM actions;
• private search;
• custom business APIs.

The agent then discovers and invokes those capabilities through the harness.

OpenAI also supports Vaults for MCP credentials. Vaults let an application attach credentials to agent sessions without giving the raw secret value to the model. OpenAI documents support for bearer tokens and existing OAuth grants.

That is an early form of an agent-specific identity and secret-management layer.

OpenAI-Hosted Sandboxes Are Real Linux Workspaces

An OpenAI-hosted sandbox gives an agent a Linux workspace with Python, Node.js, and command-line tools. OpenAI provisions the environment, while the application provides the task and retrieves the results.

Developers can configure packages, files, setup commands, and network behavior.

Network access can be:

• enabled for outbound access;
• disabled to block outbound access;
• restricted to allow only specified hosts.

This turns the agent from a text generator into a worker that can:

• inspect repositories;
• run tests;
• install dependencies;
• transform files;
• produce JSON, Markdown, CSV, reports, or code;
• execute Python or Node.js programs;
• use command-line tools;
• save artifacts for the application.

That execution model is much closer to a disposable cloud workstation than to a simple code-interpreter call.

Self-Hosted Compute Keeps the Data Plane Flexible

The self-hosted design is especially important for companies that already have private infrastructure.

OpenAI runs the harness, but the developer runs codex exec-server inside the chosen environment. The executor handles shell commands, file access, and local MCP servers at the harness’s request. It connects to OpenAI over WebSocket, and the documented connections are outbound. The executor can reconnect after a dropped connection.

That makes architectures like this possible:

OpenAI-managed harness
        |
        v
outbound WebSocket
        |
        v
Your VPC / container / server
        |
        +-- private repository
        +-- internal MCP
        +-- databases
        +-- files
        +-- build tools

Cloudflare’s launch-day integration demonstrates the pattern with Containers running codex exec-server while OpenAI maintains sessions, orchestration, context compaction, and recovery.

The design is strategically clever: OpenAI can own the harness without forcing the entire execution layer into OpenAI infrastructure.

A Practical TypeScript Shape

A managed session can be conceptually configured with a model, tools, multi-agent behavior, an environment, and an initial task:

import OpenAI from "openai";

const client = new OpenAI();

const session = await client.beta.agents.sessions.create({
  agent: {
    model: "gpt-6-astra",
    tools: [
      { type: "web_search" },
      {
        type: "mcp",
        server_label: "internal-tools",
        transport: {
          type: "http",
          server_url: "https://tools.example.com/mcp"
        }
      }
    ],
    multi_agent: {
      enabled: true,
      max_concurrent_subagents: 3
    }
  },
  environment: {
    type: "openai_hosted"
  },
  input: "Investigate the issue, delegate independent checks, and save a concise report."
});

The important part is not the syntax. It is what is absent from the application code.

There is no custom agent while loop, no hand-built context compactor, no subagent pool manager, and no bespoke session recovery layer in this simplified path.

Those responsibilities have moved downward into managed infrastructure.

Pricing: OpenAI Is Monetizing the Workload, Not the Harness

OpenAI says there is no additional fee for the Agents API itself during the public beta. Developers pay for the model tokens and tools their agents use, while OpenAI-hosted sandboxes use the applicable container pricing.

That pricing strategy matters competitively.

A separate “agent orchestration fee” would encourage teams to compare the harness as a standalone SaaS product.

Bundling the harness into the broader API economics makes a different comparison more likely:

Is operating a custom runtime worth the engineering cost when the managed harness is effectively included with the model and compute usage?

This resembles a classic cloud-platform strategy: make the orchestration layer easy to adopt, then monetize the compute, model usage, tools, and surrounding platform consumption.

Early Customer Metrics Are Promising but Not Independent Benchmarks

OpenAI’s launch page includes several strong customer claims.

Examples include:

• Ciridae reporting an evaluation score increase from 0.71 to 0.85 and a 4× latency reduction in a subagent workflow;
• SafetyKit reporting a 60% reduction in cost per case;
• Hypha reporting an 86% reduction in failed agent responses after separating the harness from the sandbox.

These numbers are useful signals, but they should not be treated as universal benchmark results.

They are customer testimonials selected for a product launch, and workload details vary.

The practical takeaway is narrower: teams that previously spent substantial engineering effort on orchestration may see meaningful gains when a mature harness replaces home-grown infrastructure. The actual benefit should still be measured against the specific workload.

The Biggest Limitation: Data Residency and ZDR

The managed control plane creates a trade-off.

OpenAI’s documentation currently says the Agents API supports data residency only in the United States and does not support Zero Data Retention. It also states that choosing a self-hosted sandbox does not make the Agents API ZDR-eligible.

This is a major consideration for:

• regulated financial systems;
• healthcare workloads;
• government deployments;
• companies with strict regional residency requirements;
• highly sensitive R&D;
• organizations that require ZDR by policy.

Self-hosting the sandbox controls where code execution and local files live, but it does not remove the OpenAI-managed harness from the architecture.

For many enterprises, this distinction will determine whether the Agents API can be used for production workloads today or only for lower-risk applications.

What the Agents API Does Not Eliminate

The launch does not mean every layer of agent engineering has disappeared.

Developers still need to design:

• authorization and permission models;
• business rules;
• high-quality tools;
• deterministic transaction boundaries;
• human approvals for risky actions;
• domain-specific memory;
• data retrieval;
• audit requirements;
• cost controls;
• evaluation suites;
• failure escalation;
• user experience;
• product-specific workflows.

The API also should not be confused with a complete long-term semantic memory system.

Durable sessions solve session continuity. They do not automatically solve every cross-session memory problem such as user-profile memory, episodic memory, knowledge consolidation, or organization-wide retrieval.

Likewise, a generic verifier is not yet the central abstraction of the Agents API. Verification still depends heavily on application-specific tests, graders, policies, and independent checks.

Which Agent Infrastructure Companies Face the Most Pressure?

The strongest competitive pressure falls on products whose primary value is generic harness plumbing.

Examples of commoditizing functionality include:

• model/tool loops;
• session persistence;
• context trimming;
• retries and recovery;
• basic subagent orchestration;
• sandbox lifecycle glue;
• generic tool routing.

If a startup’s value proposition is primarily “we turn an LLM into an agent by managing the loop,” buyers now have a credible reason to ask why they should not use the managed Codex harness instead.

However, the Agents API does not eliminate the need for all external agent frameworks.

There is still substantial room for systems optimized for:

• model-agnostic orchestration;
• multi-provider routing;
• on-premises execution;
• ZDR requirements;
• deterministic state machines;
• advanced policy engines;
• regulated approval workflows;
• specialized observability;
• custom memory architectures;
• workload-specific scheduling;
• cost optimization across model providers.

The market is not collapsing into one API. The generic center of the stack is becoming more commoditized.

The Agent Startup Moat Is Moving Up the Stack

The strategic implication is larger than OpenAI versus a particular framework.

A few years ago, a meaningful amount of product differentiation could come from building a reliable loop around a model.

That advantage is shrinking.

The emerging stack looks more like:

Product UX and distribution
        |
Domain workflow and policy
        |
Proprietary data and knowledge
        |
Tools / MCP / integrations
        |
Agent runtime / harness
        |
Sandbox / compute
        |
Foundation models

OpenAI is moving upward from the model layer into the runtime layer.

That means application companies should move upward too.

The most defensible assets increasingly become:

• exclusive or difficult-to-recreate data;
• deep vertical workflows;
• integrations embedded in customer operations;
• permission and governance models;
• accumulated user behavior and feedback;
• distribution;
• trusted brand;
• domain-specific evaluation data;
• workflow-specific automation.

A generic “AI agent” is becoming less differentiated. A deeply integrated agent that knows how a particular business actually operates remains much harder to replace.

When the Agents API Is a Strong Fit

The API is particularly attractive when the workload has several of these properties:

• tasks frequently last longer than a single model call;
• agents need a filesystem;
• code or command execution is required;
• workflows need multiple tools or MCP servers;
• context routinely becomes large;
• parallel investigation helps;
• sessions must survive client disconnects;
• developers want managed recovery;
• a self-hosted or partner sandbox is sufficient for execution requirements.

Examples include:

• autonomous coding and repository maintenance;
• incident response;
• security investigation;
• research assistants;
• large-scale document review;
• data analysis;
• support escalation;
• operational troubleshooting;
• migration and modernization agents.

When a Simpler API May Be Better

The Agents API is not automatically the best default for every AI feature.

A simpler Responses API call may be preferable when:

• the task usually finishes in one or two model turns;
• no filesystem is required;
• tools are minimal;
• deterministic application code can orchestrate the workflow more safely;
• the latency overhead of a full agent runtime is unnecessary;
• data residency or ZDR requirements are incompatible;
• the product needs model-provider independence.

Using a managed agent runtime for a simple extraction, classification, rewrite, or short retrieval task can add complexity without adding value.

A useful rule is:

Use an agent runtime when the task genuinely requires a runtime.

Common Implementation Mistakes

1. Giving the sandbox unrestricted network access by default

A coding agent with shell access and unrestricted egress is a powerful system.

OpenAI-hosted sandboxes support disabled or restricted network modes. Production deployments should start from the minimum network access required rather than treating unrestricted access as the default security posture.

2. Putting every credential inside the sandbox

Credentials that do not need to be exposed to the execution environment should remain outside it.

MCP Vaults are specifically designed so authenticated tools can be used without handing raw secret values to the model.

3. Letting parallel subagents overwrite the same files

Subagents can share one filesystem. Parallelism therefore introduces race conditions if task boundaries are poorly designed. Use separate directories, explicit ownership, atomic writes, or application-level locks when necessary.

4. Treating context compaction as a database

Compaction is a context-management mechanism, not a substitute for durable structured state.

Important facts such as transaction IDs, artifact paths, approvals, and workflow status should be stored explicitly.

5. Measuring only model quality

Production agent quality is multiplicative:

Agent quality
≈ model quality
× harness reliability
× tool quality
× context quality
× environment reliability
× workflow design

A stronger model cannot compensate for broken permissions, ambiguous tools, unreliable sandboxes, or missing evaluation coverage.

A Sensible Migration Strategy

Teams with an existing agent platform should avoid rewriting everything at once.

A safer migration path is:

1. Choose one long-running workflow that already suffers from session, retry, context, or orchestration complexity.
2. Keep business tools unchanged and expose them through MCP or well-defined function interfaces.
3. Run the harness through Agents API while preserving the existing execution environment where possible.
4. Compare reliability, latency, token usage, and engineering overhead against the existing stack.
5. Add multi-agent delegation only where tasks are actually independent.
6. Restrict sandbox permissions before expanding automation scope.
7. Create workload-specific evals before moving the workflow into unattended production.
8. Retain an abstraction boundary around the runtime if provider portability is strategically important.

The best initial candidate is usually not a trivial chatbot. It is a workflow where custom harness code is already consuming engineering time.

What This Means for the Agent Infrastructure Market

The release is another step in the same direction cloud computing followed.

Developers once built more infrastructure themselves because managed primitives did not exist. As the cloud matured, common layers became standardized services.

Agent systems appear to be following a similar path.

The layers being standardized now include:

• persistent sessions;
• context management;
• tool discovery;
• tool orchestration;
• subagent coordination;
• sandboxes;
• credential handling;
• tracing;
• recovery.

The economic question for application teams changes from:

Can this infrastructure be built?

to:

Is this infrastructure differentiated enough to justify owning it?

For most application companies, the answer will increasingly be no.

That does not make agent engineering less important. It changes where the important engineering happens.

Suggested Images and Visuals

For publication, original diagrams are preferable to hotlinking third-party assets. The following official visuals are strong references for recreating clean, copyright-safe diagrams in your own design language:

• Hero image — Agents API as an agent runtime stack: use the official Agents API launch visual as the factual reference, then recreate a 16:9 diagram showing Product → Agents API / Codex Harness → Tools + MCP → Sandbox → Data. The official launch page is the best visual reference for the product positioning.
• Codex harness architecture: OpenAI’s engineering article on the Codex App Server includes diagrams and product screenshots explaining how the harness sits behind Codex surfaces. This works well for a section explaining why the harness, rather than the model alone, is the key asset.
• Self-hosted sandbox diagram: OpenAI’s self-hosted environment documentation includes a diagram showing codex exec-server initiating an outbound connection to the Agents API. Recreate it as a simplified security architecture graphic.
• Harness versus sandbox separation: OpenAI’s sandbox documentation visually separates trusted orchestration from execution compute. This is ideal for illustrating why the Agents API does not require all compute to move into OpenAI infrastructure.
• Cloudflare deployment architecture: Cloudflare’s official integration guide includes an architecture where Workers, Containers, webhooks, and the OpenAI-managed harness cooperate. It is useful for a practical “bring your own compute” section.

A strong custom OG image would use very little text: “OpenAI Agents API” in the center, with five surrounding blocks labeled Context, Tools, Subagents, Sandbox, and Recovery, plus a small footer reading “Codex Harness as Infrastructure”.

Conclusion

OpenAI’s Agents API is important because it changes the abstraction developers are buying.

The company is no longer selling only model intelligence through an API. It is increasingly selling the runtime around the intelligence: durable sessions, context management, tool orchestration, subagents, recovery, and execution-environment integration.

The most accurate way to understand the launch is:

OpenAI has turned the Codex harness into managed cloud infrastructure.

For agent startups, this raises the bar. Generic orchestration is becoming easier to buy. Durable differentiation will increasingly come from the layers above it: proprietary data, unique tools, domain workflows, permissions, integrations, evaluation data, and distribution.

For developers, the practical next step is not to migrate every AI feature immediately. Identify one workflow where custom agent infrastructure is already expensive, run the same workload through the Agents API, and compare reliability, cost, latency, and engineering complexity.

That experiment will reveal whether the new managed harness is merely convenient—or whether it can replace an entire layer of an existing agent stack.