OpenAI's Agents API Kills the Orchestration Layer Developers Hate Building

OpenAI just pulled the harness out of Codex and turned it into a general purpose product. The new Agents API is a managed service that runs the agent loop, coordinating model calls, tool use, subagents, and context management on OpenAI's infrastructure, while you decide what tools the agent has and where its code actually executes.

It is available in public beta to all developers, with no additional fees beyond the tokens and tools the agents consume. That framing matters, because this is a way to skip building your own orchestration layer on top of the chat completions or Responses APIs, not a new SKU to budget for.

What OpenAI runs, and what you still own

The split is clean. OpenAI hosts and maintains the harness, while you choose the agent's compute environment: an OpenAI-managed sandbox, your own infrastructure, or one of the sandbox partners. The harness itself is the same one that powers Codex and ChatGPT for Work, and it is built on the open-source Codex codebase, so you can read exactly how the loop coordinates model calls, tools, and context.

Sandbox choice is where this gets interesting for anyone with compliance or GPU constraints. OpenAI is shipping first-class integrations with Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop, and Vercel, covering fully managed environments, VPC deployments, and different CPU/GPU/memory profiles. For teams who just want to move fast, there is also an OpenAI-hosted sandbox that inherits the infrastructure behind Codex.

The harness features that actually matter

Three capabilities in the harness are worth calling out, because they are the parts most teams end up reimplementing badly:

• Automatic context compaction. The Agents API compacts earlier context as a session approaches its context limit, preserving information the agent needs to continue. This is what lets sessions run for hours or days without you writing summarization logic.
• Tool search and programmatic tool calling. Tool search loads relevant tool definitions on demand to reduce token usage while preserving the model's cache. Programmatic calling lets agents fire requests in parallel, chain related operations, and filter or combine results in code, so they can process large volumes of data while only pulling the relevant slices back into context.
• Subagents. Multi-agent support breaks complex tasks into independent pieces and delegates them to subagents that work in parallel, each maintaining its own context while the main agent coordinates and merges results.

Enabling that last piece is a config flag. A minimal session setup looks like this:

const session = await client.beta.agents.sessions.create({
  agent: {
    model: "gpt-6-astra",
    tools: [{ type: "mcp", server_label: "observability",
      transport: { type: "http", server_url: "https://observability.example.com/mcp" }}],
    multi_agent: { enabled: true, max_concurrent_subagents: 3 },
  },
  environment: { type: "openai_hosted" },
  input: "Investigate service-api's elevated 5xx rate over the last 30 minutes...",
});

The tool layer supports MCP servers, custom functions, and built-in tools like web search, so most existing tool ecosystems drop in without a rewrite.

Early numbers from launch customers

OpenAI shipped a batch of customer quotes that suggest real gains rather than marketing fluff. Ciridae reported that their evaluation score climbed from 0.71 to 0.85, with a 4x latency reduction on subagent flows compared to their previous orchestration setup. SafetyKit saw a 60% reduction in cost per case after migrating their case review workflow, and Hypha reported an 86% drop in failed agent responses by separating the harness from the sandbox.

Who eats the orchestration layer

Until now, anyone running long-horizon agents in production has been assembling their own harness: retry logic, context window management, tool routing, subagent coordination, and sandbox lifecycle. Frameworks like LangGraph and CrewAI helped, but the operational burden of keeping agents alive for hours or days stayed with the developer.

The Agents API absorbs that layer and versions it against model releases, so harness improvements ship with each new model rather than requiring you to rewire prompts and tool definitions. The tradeoff is obvious: you are locking the orchestration layer to OpenAI's implementation. For teams whose differentiation is the tools, data, and workflows rather than the agent loop itself, that is likely a trade worth making. For teams building multi-provider agent platforms, the open-source Codex harness on GitHub is the more relevant artifact.