OpenAI Agents API: managed harness, your choice of sandbox

OpenAI has put the Codex agent harness behind a managed API. Developers can now use it to run longer tasks, coordinate subagents, and retain work across a session without operating that harness themselves. The Agents API entered public beta on September 10.

The architectural choice is more flexible than “run everything at OpenAI.” You can use an OpenAI-hosted sandbox, your own compute, or a sandbox partner. But choosing your own execution environment does not move the managed session service into your infrastructure. That distinction matters when deciding which part of an automation to buy and which part to keep under your control.

The harness and the sandbox do different jobs

A model produces responses. A harness coordinates the work around those responses: providing context, invoking tools, managing a session, and deciding how to continue. A sandbox is the environment in which commands execute and files are available.

In the Agents API, OpenAI operates the Codex harness. The official overview says it manages sessions, orchestration, context compaction, and recovery. Your application supplies tools and chooses the execution environment.

That split lets a software team adopt managed orchestration without necessarily replacing the environment its agent needs. OpenAI's announcement lists partner options with different deployment, storage, CPU, GPU, and memory configurations. The right environment depends on the work: its dependencies, files, resource needs, and connection to other systems.

The open-source Codex codebase provides visibility into the harness's core logic. With this API, however, OpenAI runs and maintains the harness. Inspectable code and a managed service are compatible; inspection does not make the service a self-hosted deployment.

A session can continue after the first answer

The API's central unit is a durable session. An application configures the agent and its environment, gives it a task, then follows output through a stream or webhooks. It can send another task to the same session or steer work already in progress.

The documented capabilities include executing commands, editing files, connecting to MCP servers, applying skills, producing artifacts, and delegating subtasks. The harness can summarize prior work to manage the context window and resume a session where it left off.

For a file-based business workflow, that changes the integration you build. Instead of treating each answer as an isolated text response, the application can follow a task that produces intermediate work and saved outputs. It still needs to decide what those outputs mean and when they are acceptable to use.

A document-processing trial, for example, could ask the agent to examine a set of approved sample files and produce a structured report. This is a suggested evaluation, not a result we have measured. Checking the report against the source files would show whether the workflow is useful more directly than counting how many subagents it launched.

Self-hosted compute does not make the API ZDR-eligible

The current documentation states that the Agents API supports data residency only in the United States and does not support Zero Data Retention, or ZDR. It explicitly says that choosing a self-hosted sandbox does not change ZDR eligibility.

This is an important qualification to the environment choice. Your own sandbox can determine where commands run and files are accessed, while the API still retains session state so work can continue across turns. The documentation says sessions and published artifacts can be deleted when they are no longer needed; that is different from ZDR support.

If a workload requires ZDR or non-US residency, the current Agents API is not a fit for that requirement. Do not treat a private execution environment as evidence that the full service meets it. Resolve this before uploading business material, rather than after a successful demonstration creates pressure to expand the trial.

Compare the environment using one repeatable task

For a workload whose data requirements fit, start with the environment that is simplest to configure. OpenAI's hosted option provisions and manages the sandbox, and can be configured with files, packages, skills, and plugins. Another environment may be appropriate when the workload needs a particular compute configuration or deployment arrangement.

Keep the task and expected output consistent when comparing environments. Check whether the agent can access the intended tools and files, whether saved artifacts are complete, and what happens when work is interrupted. This tests the boundary between the managed service and your execution setup, where configuration problems can otherwise be mistaken for model limitations.

Include the full usage cost. OpenAI says there is no additional Agents API fee, but the documentation lists model usage at the selected model's API rates, tools at their standard rates, and OpenAI-hosted sandboxes at standard container rates. A partner or self-hosted environment also needs its own cost assessment. “No additional API fee” does not mean free execution.

For teams already weighing runtime choices, our explanation of Google's Agent Executor covers why long-running work needs infrastructure beyond a model call. OpenAI's new option offers a specific division of responsibility: buy the managed Codex harness, choose where its tools execute, and keep responsibility for the business result.