OpenAI Agents API vs Responses API agent loop: what the Codex harness takes over

The individual pieces are not new. The docs nav lists ten Responses-side core concepts you can already assemble yourself: Conversation state, Background mode, Streaming, WebSocket mode, Mid-turn steering, Multi-agent, Webhooks, File inputs, Compaction and Counting tokens. What the Agents API adds on top is a durable server-side session that holds them together and keeps running when your process is not.

The docs are built around four main concepts. An Agent is the model, instructions, tools and MCP servers available to it. An Environment is an optional sandbox or computer where the agent accesses files, loads skills and runs commands. A Session is a durable instance of an agent that works on tasks and responds to input, and events and items are the inputs sent to the agent and the output produced during that session.

The overview enumerates seven things the managed Codex harness supports. Each is a piece of a hand-rolled loop you would otherwise write and maintain yourself.

The session lifecycle is four steps: create a session, at which point OpenAI provisions its environment; give it a task, which starts a turn of work once the environment is ready; follow progress by streaming output or using webhooks to learn when the agent finishes or needs input; then continue or steer, by sending another task to the same session or guiding the agent during its current turn. For an OpenAI-hosted session the docs are explicit that your application sends input and receives events while OpenAI runs the agent and provisions and manages its sandbox. The calling pattern inverts: you stop driving a model turn by turn and start consuming an event stream.

Running the loop yourself means composing those ten Responses primitives by hand. You decide when conversation state is persisted, when compaction fires, how a failed turn is retried, and how a subagent result is folded back into the parent context. Under the Agents API those decisions move server-side, where the overview describes them as managed rather than configured - with the caveat that the docs also say to configure these capabilities when you create a session, and carry separate Configuring Agents and Architecture pages the overview does not summarise.

Two of the seven matter most for cost and correctness. Compaction, described here as summarizing previous work to manage its context window, is what decides which tokens survive into the next turn; a summariser you cannot inspect is a quality variable you cannot ablate. Delegation is the other - the overview's own example is comparing release notes with subagents and combining their findings into one answer, a fan-out whose token consumption you observe afterwards through the Observability and usage and Tracing pages rather than bounding in advance. The overview publishes no figures for compaction thresholds, subagent limits or per-session token overhead.

Environments are the part the docs leave to you. There are separate pages for OpenAI-hosted sandboxes and self-hosted sandboxes, plus sandbox lifecycle, sandbox security, and files and artifacts, and the overview points to environment options for setup and limitations. Inside a sandbox, agents can execute code, edit files, connect to MCP servers and produce artifacts. Tools attach through their own set of pages - Web search, Functions, MCP connections, Plugins and Vaults - which is where your application's code actually plugs in.

One commenter on Hacker News went straight to the environments page and quoted its network access configuration: enabled allows outbound access and is the default unless you inherit a template policy, disabled blocks outbound access, and restricted allows only the hosts listed in allowed_domains. The same thread reports trying to talk the agent around restricted mode: a curl to example.com exited with code 0 and returned the text Domain forbidden, and the agent declined to edit /etc/hosts and retry with an alternate hostname and a spoofed Host header. That is one anecdote from one commenter, not an evaluation. The sources contain no published security analysis of restricted mode; the docs list a Sandbox security page that the overview does not quote.

Pricing is stated in a single line with three components: model usage at the selected model's API rates, OpenAI tools at their standard rates, and OpenAI-hosted sandboxes at standard container rates. The orchestration is managed but not invisible on the bill - compaction summaries and subagent turns are model calls, billed at the same rates as any other. The container meter is the new line item relative to a loop you run on your own machine; the overview does not state how self-hosted sandboxes are billed.

The Responses side of the docs has a dedicated Counting tokens page. The Agents API side routes you instead to Observability and usage and Tracing. If your cost model depends on predicting spend before a run rather than attributing it after, that is the first difference to check.

Lock-in dominates the thread. Commenters read the Agents API as a more durable moat than the many agentic harnesses that run on your own machine, and one argues that the point of a locally-running agent is that the artifacts and work in progress sit on your disk to inspect, not just the final artifact. Another says this does not need to exist beyond the existing Responses or Chat Completions APIs, reporting that their company already scripts entire persistent workflows with a simple SDK. A fourth frames the whole release as an attempt to answer how OpenAI earns more money.

Metering is the second theme, and it is about Codex rather than the Agents API itself. One commenter reports that for about a week every request, no matter how small, has used at least 1% of their weekly limit and around 5% of their five-hour limit; a reply puts it at 5 to 10% of the five-hour limit whether the task is a code review over a significant code base or a single config value change. A third says a newly created account burned far less for the same work while the old account chews through 20%. Another asserts you cannot use a subscription with this at all. None of that is in the docs, which state only the three billing components.

The most concrete unanswered question in the thread is operational: does each execution of an agent session create a new environment, is that environment then billed for at least a full hour despite prices being quoted per 20 minutes, and is there a way to deliberately shut one down rather than waiting for it to expire. The overview does not answer any part of it. The docs nav lists a Sandbox lifecycle page, which is where that answer would live.

Three things the overview does not settle. First, sandbox billing granularity and explicit teardown, which is the difference between a cheap event-driven agent and an idle container you are paying for. Second, how much harness behaviour is configurable versus fixed - the retrieved page's sample block is titled Configure managed-harness capabilities and labelled Python while the code shown is the TypeScript OpenAI SDK, so read the quickstart prerequisites for API-key permissions and SDK setup rather than trusting the label. Third, the stability of the abstraction: the nav files Agent Builder, its migration guide and its Node reference under Legacy APIs, and carries a separate Assistants API migration guide.

A related release landed the next day, GPT-Live-1 in the API on 2026-09-11, but no body text was retrievable for it, so nothing here depends on what it contains. The practical test for anyone weighing the move is narrow: run the same task twice, once through an Agents API session and once through your own Responses loop, and compare total billed tokens plus container time. Until compaction and subagent behaviour are documented with numbers, that measurement is the only way to price the managed harness.