OpenAI Agents API: what the Codex harness takes over

OpenAI’s Agents API, released in public beta on 10 September 2026, lets developers use the managed infrastructure behind Codex in their own applications. OpenAI runs the agent loop, while the application supplies work and receives results. The useful change is less infrastructure to build around a model, with decisions about tools and access still belonging to the developer. [1] [2]

How is the Agents API different from Responses and the Agents SDK?

The main difference is who runs the agent. With the Agents API, OpenAI hosts the harness. With the Agents SDK, your code runs a framework that manages the loop. Direct use of the Responses API gives your application more responsibility for deciding what happens between model responses. OpenAI’s architecture and SDK documentation make that distinction explicit. [2] [9]

A harness is the software around a model that carries a task forward: it supplies context, dispatches tools and decides when another model call is needed. Calling a model once is only part of that work. OpenAI’s announcement puts session management, context compaction and parallel delegation inside the managed offering. Compaction means shortening accumulated context so the agent can continue as a conversation grows. [1]

I read this as a deployment choice. If maintaining the loop is the work delaying your product, having OpenAI operate it is useful. If controlling every transition is the reason your product works, you should inspect that trade-off before migrating. A new API does not make an existing SDK application obsolete.

A Reddit discussion in r/artificial on 10 September captured both reactions: the appeal of agents becoming infrastructure, and questions about the sandbox boundary. That is a better starting point than asking whether another agent framework is fashionable. The practical question is which responsibilities you want to hand over. [8]

Does a persistent session keep all the agent’s files?

A persistent session keeps the conversation and saved work associated with an agent, but the execution environment has its own lifetime. OpenAI separates the application, the hosted harness and the environment in its architecture. Treating all three as one permanent computer would be a mistake. [2] [3]

The environment is where tools can execute code and access a workspace. It can be OpenAI-hosted or supplied by the developer. An agent can also run without that environment: the documented none option has no built-in Bash, apply-patch tool or workspace filesystem, while remote HTTP MCP tools remain possible. MCP is the protocol used to connect the agent to external tools. [2]

OpenAI’s session documentation says to reuse the session identifier for follow-up work. It also distinguishes saved session items from live events: a disconnected stream does not replay everything you missed, so applications need to retrieve saved items when reconnecting. That is an implementation detail with a direct product consequence. A reconnecting interface must recover the actual task state rather than assume silence means nothing happened. [3]

For files, I would define the handoff explicitly: what the agent must produce, where the application will copy it and which result means the task is complete. That requirement belongs in the product design even when the vendor manages the session. A successful conversation is not yet a reliably delivered artifact.

Do parallel subagents have separate permissions?

The documented subagents share the coordinator’s filesystem and environment and inherit configured tool access. I would treat them as workers sharing one security boundary. OpenAI also documents a specific beta limitation: subagents do not support function tools. [4]

That distinction matters for application design. A function tool is custom functionality supplied by your application; remote MCP tools are a different integration route. If a worker’s task depends on a custom function, do not assume delegating the task gives that worker the same capabilities as the coordinator. Check the supported tool path before making the worker responsible for the whole result.

I would start with independent tasks that have clear outputs, such as inspecting different modules, and keep final integration with the coordinator. Shared files make cooperation possible, but they also create the possibility of overlapping edits. Parallelism is useful when the tasks fit together without having to undo each other’s work.

It also changes the cost model. OpenAI warns that additional subagents can increase token usage. A shorter wall-clock run can involve more total work, so “finished sooner” and “cost less” should be measured separately. [4]

What security and data decisions remain yours?

The environment’s permissions still matter because code executed by the agent can reach the files, credentials and network resources available there. OpenAI’s sandbox guidance tells developers to restrict outbound access and keep the application’s API key outside the execution environment. Hosting the loop does not decide which business systems the agent should be allowed to change. [5]

For a code-review assistant, I would begin with access to the repository and a place to return findings. Permission to deploy or change customer records would need a separate product decision. The important boundary is the action your application enables, not whether the agent describes itself as cautious in its response.

A stateful service can be a useful fit for a returning user or an ongoing task. It also means the application needs a deliberate lifecycle for that state. I would decide when sessions should be kept or deleted as part of the feature, before letting them accumulate indefinitely.

What does the Agents API cost?

OpenAI says the Agents API adds no separate fee: developers pay for the tokens and tools their agents use. That makes the relevant budget the whole task, including repeated model calls and delegated work. It does not make a long-running agent free to keep working. [1]

The pricing page separates model token charges from tool charges. Hosted execution containers are metered by resources and time, while tools such as web search can add per-call charges. A cost estimate should include the chosen execution environment, not just the model’s output tokens. [10]

The observability documentation adds an important limit to the counters an application sees. Session and turn usage can be incomplete or change, and OpenAI explicitly says those counts are not a final bill. Use them to understand a run, while reconciling actual spending through the billing records. [7]

My first evaluation would therefore be a small, repeatable workload with a clear completion condition. I would record whether the result passed review, what external actions occurred and what the completed task cost. Then I would compare that with the application I already have, including the work required to maintain it.

The Agents API is worth considering when running the agent infrastructure has become a product burden. The first question to settle is concrete: which loop, state and execution responsibilities can OpenAI take over without removing control your application actually needs?