OpenAI is asking developers to hand over the part of an agent stack that tends to create the most operational work: the loop that preserves state, compacts context, resumes after a disconnect, and keeps a sandbox attached to a task. In MrKeyoor's live brief, the launch drew 184 Hacker News points and 113 comments within hours. Those figures measure developer attention, not product quality. The substance is in OpenAI's Agents API documentation, which describes the product as an OpenAI-managed Codex harness. The service sits above individual model calls.
That distinction changes the build decision. An application can create a durable session, send it work, follow an event stream, and return later without reconstructing the whole conversation. OpenAI manages orchestration, context compaction, and recovery. The developer still chooses the model, instructions, tools, and execution environment. That puts the new boundary much higher in the stack than the Responses API.
The product is the agent loop
OpenAI's runtime comparison sets out three different levels of control. The Responses API leaves the application responsible for the agent design and history. The Agents SDK runs the loop inside the developer's application. The Agents API runs a managed Codex harness and saves session configuration, turns, and items between tasks. That choice sets the operating model for an application and changes much more than its inference URL.
The managed harness can execute commands, edit files, load skills, call application functions, connect to MCP servers, and delegate work to subagents. OpenAI's overview divides the system into four resources: an agent definition, an optional environment, a durable session, and the events or items created during that session. That vocabulary matters because each resource has its own lifetime. A saved agent holds reusable settings; a session holds one continuing body of work.
The SDK puts those resources into one call:
const session = await client.beta.agents.sessions.create({
agent: {
model: "gpt-6-astra",
instructions: "Write clean code and report the actual output."
},
environment: { type: "openai_hosted" },
input: "Create tree.py, run it, and show me the result.",
stream: true
});
This is adapted from the official quickstart. One request creates the session, provisions the environment, starts the first turn, and opens a stream of progress events. Direct cURL requests need the OpenAI-Beta: agents=v1 header, while current OpenAI SDKs add it automatically. Project keys also need the api.agents.read, api.agents.write, and api.responses.write permissions.
State crosses the vendor boundary
Durable sessions remove a familiar piece of plumbing. A client saves the session ID and sends later input to the same session, so the agent can continue from its earlier files and conversation. If a stream drops, OpenAI tells developers to retrieve the saved session and items before retrying. Deleting a session is an explicit cleanup step, and the quickstart warns users to save any needed files first.
Applications cannot treat agent.session.turn.completed as a success flag. It reports that a turn ended, but the quickstart says this does not prove that every tool call succeeded. An agent.session.idle event does not establish success either. Applications have to watch for turn, session, and environment failures and inspect the agent's reported execution result. A green HTTP response is therefore insufficient as a job-completion check.
OpenAI provides session logs in its dashboard and a public event stream for live activity. Developers can list saved items and retrieve turns, including a subagent_id that ties delegated work to a particular turn. The observability guide says detailed trace retrieval remains dashboard-only, and command-output truncation is not reported. Teams that need their own audit trail will still have to capture the events and application-side approvals they care about.
Sandboxes become a configuration choice
The API supports none, openai_hosted, and self_hosted environments. With no sandbox, the agent can still use configured service tools and application handlers. An OpenAI-hosted environment can receive initial files and packages, and its network access can be configured. A self-hosted environment keeps command execution on infrastructure the developer prepares, connected through an executor. These options let one session behave like a research assistant while another works against a controlled repository.
The hosted option has a permissive network default. Outbound access is enabled unless a reused template supplies another policy, according to the hosted sandbox guide. Developers can disable networking or restrict it to an allowlist, and a session cannot broaden the network rules inherited from a template. Each session receives a separate /workspace; files persist between turns while that sandbox exists. Files written under /workspace/outputs become immutable artifacts after a completed turn, so they can be downloaded after the sandbox expires. Closing the event stream does not cancel the task.
Compute location is only one part of credential isolation. The configuration guide says credentials live in vaults apart from saved agent configuration, and the quickstart tells developers to keep the application API key outside the sandbox. That is a useful minimum. Production systems also need narrow tool permissions, explicit approval for irreversible actions, and logs at the boundary where an agent asks the application to act. Those policies remain the application's responsibility.
Cost accrues across the full execution because a long agent job can contain many billable inferences. OpenAI's usage documentation says one task may trigger several model calls. Input history, tool definitions, tool results, generated arguments, reasoning, retries, and subagent turns all contribute. Tool fees, sandbox compute, and third-party services sit on top of model tokens.
OpenAI's pricing table lists hosted shell and Code Interpreter containers at $0.03 for 1 GB and $1.92 for 64 GB per 20-minute session at the published rates. Its pricing note says eligible container sessions are billed by the minute with a five-minute minimum. Recorded token usage on a session or turn is described as best effort: it can be null, can change as accounting arrives, and is not the final bill. Cost tests will need to measure complete tasks, especially when delegation is enabled.
The data terms narrow the first use cases
Persistent state is useful precisely because OpenAI stores it. The Agents API overview says sessions and published artifacts can be deleted, but the service currently supports data residency only in the United States and does not support Zero Data Retention. Selecting a self-hosted sandbox does not make the Agents API eligible for Zero Data Retention because orchestration and session state still pass through the managed service.
OpenAI's data controls table is more explicit: /v1/agents application state is retained until deletion, abuse-monitoring retention is listed as 30 days, and the endpoint is ineligible for Zero Data Retention. The table also says API data is not used for training. Regulated workloads and organizations with regional storage rules will need to clear those terms before treating a self-hosted environment as sufficient isolation.
The launch gives developers a shorter path to a stateful coding or operations agent, but the trade is concrete. OpenAI now owns more of the runtime, while the customer owns less of the state machinery and sees less of the underlying trace through the public API. Watch whether the beta endpoints stay stable and whether regional or retention options expand. Cost predictability can be tested against the usage records teams receive. Until then, the best first deployments are bounded jobs with recoverable side effects and an application that checks the work instead of trusting the final event.