OpenAI Launches Agents API: One Call to Run Codex-Grade Agents in the Cloud

OpenAI has officially launched the Agents API in Public Beta. For teams building or planning to deploy AI agents, it provides an officially managed harness and execution environment, allowing developers to build and run cloud-based agents capable of long-running execution in production with a single API call.

From Chatbots to Long-Horizon Tasks: What Did OpenAI Release?

When building agents, getting a model to troubleshoot production incidents, work across multi-file codebases, or invoke external systems like a real engineer has historically required developers to write substantial connective tissue: handcrafting prompt chains, managing tool invocations manually, handling context window overflows, and maintaining code execution containers and permissions on their own.

In scaling Codex and ChatGPT for Work to millions of users worldwide, OpenAI learned firsthand what long-running agents require in practice: practical agents need a harness capable of managing context, using tools efficiently, and coordinating subagents, as well as infrastructure that can reliably run continuously for days, allowing agents to read and write files, execute code, and persist intermediate results.

Through the Agents API, OpenAI makes the same harness and infrastructure powering Codex available to developers. Workflows that previously required writing custom prompt chains and managing tool invocations can now be consolidated into a single standard API call: developers specify the task, model, tools, and environment, while complex logic such as session management, orchestration, context compaction, and resumption is handled by OpenAI's managed Codex harness.

Regarding pricing, the Agents API itself incurs no additional platform management fees; developers pay only for model tokens and built-in tools based on actual consumption. If using the OpenAI-hosted sandbox, container compute is billed at standard container rates.

Building a Cloud Agent with a Single API Call

In the Agents API, creating and running an agent equipped with multi-task collaborative capabilities requires only a single session creation request. The official launch page provides the following JavaScript example:

import OpenAI from "openai";

const client = new OpenAI();

const session = await client.beta.agents.sessions.create({
  agent: {
    model: "gpt-6-astra",
    tools: [
      {\n        type: "mcp",
        server_label: "observability",
        transport: {
          type: "http",
          server_url: "https://observability.example.com/mcp",
        },
      },
    ],
    multi_agent: { enabled: true, max_concurrent_subagents: 3 },
  },
  vault_ids: ["vault_YOUR_VAULT_ID"],
  environment: {
    type: "openai_hosted",
    capability_directories: ["/workspace/capabilities/skills"],
  },
  input:
    "Investigate service-api’s elevated 5xx rate over the last 30 minutes. " +
    "Delegate deployment, error, and dependency analysis to subagents. " +
    "Save findings, evidence, and recommended mitigation in /workspace/outputs.",
});

This snippet clearly illustrates how the core elements collaborate:

• agent.model: Specifies the underlying model, here gpt-6-astra.
• agent.tools: Declares the tools the agent can invoke. The example configures an mcp tool connecting to an external observability service, observability, via HTTP transport.
• agent.multi_agent: Enables multi-agent delegation support and sets max_concurrent_subagents: 3, allowing the primary agent to dispatch up to 3 subagents in parallel.
• vault_ids: The official example includes ["vault_YOUR_VAULT_ID"], though neither the announcement page nor the attached developer documentation explains the purpose of this parameter.
• environment: Specifies the compute sandbox. Here openai_hosted (OpenAI-hosted sandbox) is used, with the /workspace/capabilities/skills directory specified via capability_directories (the developer documentation notes that skills, plugins, and capability_directories can all be used to inject pre-configured capabilities into agents in a hosted sandbox).
• input: The initial task instructions passed to the agent. This task instructs it to investigate the elevated 5xx rate on service-api over the past 30 minutes, delegate deployment, error, and dependency analyses to subagents, and save findings, evidence, and recommended mitigations to the /workspace/outputs directory.

In this workflow, the managed Codex harness drives the model, manages the session, and orchestrates subagents; tools interact with external systems via MCP; code and analytical tasks run inside the sandbox; and final outputs are saved to /workspace/outputs, where they are automatically published as immutable artifacts at the end of the turn.

Core Architecture Breakdown: Division of Labor Between Framework and Environment

To understand the Agents API, one must first look at the separation of responsibilities across the system architecture. OpenAI's official architecture illustrates the division among three roles:

Under this architecture, responsibilities are clearly divided into three parts:

1. Your Application: Submits tasks to the Agents API and receives returned event streams and output results.
2. Managed Codex Harness: Hosted and maintained by OpenAI; responsible for running models, coordinating tool calls, maintaining session state, scheduling context, and managing subagents.
3. Compute Sandbox: Provided by OpenAI or your provider; where the agent reads and writes files, executes shell commands, and runs code.

Four Core Concepts and Lifecycle

In the official Agents API overview, the entire system centers around four core concepts:

• Agent: Contains the model, instructions, tools, and MCP server configurations assigned to the agent.
• Environment: An optional sandbox or compute environment where the agent accesses files, loads skills, and executes commands.
• Session: A persistent agent instance responsible for executing specific tasks and responding to subsequent inputs.
• Events and items: The inputs sent to the agent throughout the session, along with the sequence of events and output items generated during execution.

A complete session lifecycle consists of four steps:

1. Create a session: The application submits the agent configuration, and OpenAI provisions the environment (this applies when using an OpenAI-hosted sandbox; with a self-hosted sandbox, the execution environment is started by you and connects back).
2. Give it a task: Once the environment is ready, passing in task input initiates a work turn.
3. Follow progress: Monitor output in real time via the event stream, or use webhooks to know when the agent finishes work or requires human input.
4. Continue or steer: Continue assigning follow-up tasks within the same session, or steer the agent mid-turn.

Choosing a Sandbox Environment Tailored to Your Workload

Different workloads have varying demands for compute, storage, and deployment topologies. In the Agents API, developers can select an appropriate sandbox based on their scenario:

• OpenAI-hosted (OpenAI-hosted): Suited for quick onboarding and efficient scaling. This sandbox reuses the same sandbox infrastructure powering Codex and ChatGPT. OpenAI provisions and manages the environment, providing the agent with a Linux workspace (working directory /workspace) pre-equipped with Python, Node.js, and command-line tools.
• Sandbox Partners: OpenAI has established first-class integrations with multiple ecosystem providers (see the Self-hosted & Partner Sandbox Guide), including Modal, Cloudflare, Daytona, Blaxel, Runloop, Vercel, Oracle, E2B, and DigitalOcean.
• Self-hosted (Self-hosted): If you prefer using compute resources under your own control, you can run the execution environment on a local machine, self-built container, or cloud server.

Partner sandboxes primarily address three needs:

1. Fully managed environments or deployments inside enterprise VPCs;
2. Specialized file and secret storage mechanisms;
3. Diverse CPU, GPU, and memory configurations to match specific workflow requirements for performance, cold start times, and cost.

It should be noted that partner sandboxes rely on the same connection mechanism as self-hosted sandboxes; the partner provider simply supplies the host machine.

Self-Hosted Sandbox Connection Mechanism and Security Boundaries

Self-hosted sandboxes allow code and files to run on machines you trust, with all network connections initiated outbound. However, their compliance boundaries require special attention: session state and orchestration logic remain maintained in the OpenAI cloud. The Agents API currently only supports US data residency and does not support Zero Data Retention (ZDR); choosing a self-hosted sandbox does not make a session ZDR-compliant.

Specific setup and runtime procedures for self-hosted sandboxes are as follows. First, install the Codex CLI inside an internal container or machine:

mkdir -p /workspace
npm install -g @openai/codex@alpha

The execution-side component is the Codex CLI's built-in daemon codex exec-server (the executor), started via:

codex exec-server \
  --remote "<session.environment.remote_url>" \
  --environment-id "<session.environment.id>"

Its network and credential design incorporates the following security features:

• Strictly outbound network connections: The environment registers via HTTPS (https://api.openai.com), then establishes a persistent WebSocket connection (wss://codex-cloud-environments.chatgpt.com) with OpenAI to receive commands and stream back results. No inbound ports need to be exposed on the internal network.
• Restricted credential isolation: Environment variables injected into the self-hosted sandbox should use a dedicated, restricted environment key, CODEX_API_KEY (with all other permissions set to None during creation in the platform Dashboard). This key can only connect the environment and cannot perform any other API operations. Code generated by the agent can read this key, so never write it into source code, container images, or logs; rotate or revoke it promptly as needed.
• Workload isolation: Because agents within the same sandbox environment can access the same files and credentials, different runtime environments must be strictly isolated by user or specific workload.

Core Harness Capabilities: Key Mechanisms of the Codex Harness

Through the process of scaling Codex, OpenAI determined what long-running agents require in practice and crystallized these capabilities into the harness.

Harness Versioned Alongside Model Upgrades

Unlocking the full potential of a new model often means modifying your own orchestration framework (harness), taking away time that should be spent improving the application. With every model release, the Agents API provides matching capabilities tied to specific versions. OpenAI co-maintains and continuously improves the harness alongside models, helping agents gain better performance with each upgrade.

OpenAI's launch page highlights representative examples of recent harness improvements (this is not an exhaustive feature list, but highlights areas of recent focus): automatic context compaction, more efficient tool use (tool search and programmatic tool calling), and multi-agent coordination.

Automatic Context Compaction: Advancing Tasks Across Multiple Windows

When agents run continuously and invoke tools frequently, conversation history easily approaches a model's single context window limit.

To support models working continuously for hours, the Agents API provides native context management capabilities (see the Context Compaction Guide). As a session approaches its context limit, the system automatically compacts earlier context, preserving the information needed to continue work. Developers can build workflows spanning multiple context windows without implementing custom compaction logic.

Note: The linked compaction guide illustrates the compaction mechanism using the Responses API; the announcement page does not elaborate on the specific compaction format within the Agents API.

Tool Search: Loading Tool Definitions on Demand

Loading complete definitions for all tools into model context upfront not only consumes valuable context space with unused definitions, but modifying tool definitions can also invalidate previously cached prefixes.

The Tool Search Guide notes that this mechanism allows models to dynamically search for and load tool definitions on demand. Newly discovered tools are appended to the end of the context, keeping preceding cached content intact.

In the Agents API, tool search configuration rules are as follows:

• MCP tools: When supported by the model and provider, the Agents API automatically applies lazy loading to MCP tools and enables tool search by default, requiring no extra configuration from developers.
• Custom function tools: Loaded eagerly in full by default. To enable on-demand discovery, declare {"type": "tool_search"} in the agent.tools array and mark defer_loading: true on individual functions requiring lazy loading.
• Scope of lazy loading: For individual functions marked with lazy loading, the model can still initially see their name and functional description; loading of their specific parameter schema is what is deferred. (This detail originates from the Responses API section of the tool search guide.)
• (Note: The recommendation to "keep the number of tools under 10 per namespace" is a performance recommendation provided in the Responses API documentation).

Programmatic Tool Calling: Filtering and Aggregating in an Isolated Runtime

Under traditional invocation patterns, every time an agent invokes a tool, all raw data returned must be written directly into context. If a tool returns substantial amounts of unneeded data, the context quickly fills up.

The Programmatic Tool Calling Guide describes a new paradigm: models can write JavaScript code to orchestrate their own tools. In the Agents API, programmatic tool calling is enabled by default (to disable it, explicitly set enabled: false).

Its runtime environment enforces strict boundaries:

• Code executes in an independent, isolated V8 runtime supporting top-level await;
• The runtime has no direct network access, no Node.js, cannot install third-party packages, lacks a general filesystem, and preserves no state between program executions;
• Code can interact with external systems solely through tools enabled on the current request, outputting results via text(...) or image(...).

With this mechanism, models can run loops, conditional logic, or call multiple enabled tools concurrently inside the isolated environment. Suppose an investigation task requires analyzing 100 log entries and computing frequency distributions: in traditional mode, the full JSON payload containing 100 log entries must be placed entirely into context; with programmatic calling, code can perform filtering, deduplication, and aggregation inside the V8 runtime, returning only concise summary statistics to model context. This approach reduces intermediate data entering context; the exact token savings depend on task characteristics.

In engineering implementation, direct invocation or programmatic invocation should be chosen based on task characteristics:

• Single queries or individual actions: Direct tool calling is recommended
• Multiple results requiring code filtering, concatenation, sorting, deduplication, aggregation, or validation: Programmatic tool calling is recommended, allowing code to return streamlined structured results
• Dependent calls with predictable data flows: Programmatic tool calling is recommended, letting code derive downstream parameters with explicit boundaries and failure handling
• Adaptive search or semantic evaluation (where intermediate steps require model re-evaluation): Direct tool calling is recommended, so each result influences the model's next decision in real time
• Write operations or high-sensitivity actions requiring approval: Direct tool calling is recommended by default to maintain clear permission and confirmation boundaries
• Final citation verification or raw artifact validation: Direct tool calling is recommended, unless the program can completely preserve raw output and validate every required item

The launch page highlights that the Agents API supports MCP, custom functions, and built-in tools such as web search. For instance, the MCP service for OpenAI's official documentation can be mounted with the following configuration:

"agent": {
  "tools": [
    {
      "type": "mcp",
      "server_label": "openai_docs",
      "transport": {
        "type": "http",
        "server_url": "https://developers.openai.com/mcp"
      }
    },
  ]
}

Multi-Agent Parallel Collaboration: Division of Labor and Parallel Delegation

For complex analysis or comparison tasks, the Agents API provides native multi-agent support (see the Multi-Agent Documentation):

"agent": {
  "model": "gpt-6-astra",
  "multi_agent": {
    "enabled": true,
    "max_concurrent_subagents": 3,
  }
}

Under the multi-agent mechanism:

• The primary agent (orchestrator) decomposes tasks and delegates them to subagents to work in parallel.
• The concurrency limit parameter, max_concurrent_subagents, defaults to 6 (excluding the orchestrator) and can be customized to any positive integer as needed.
• The harness automatically provides built-in tools to create, message, wait for, and interrupt subagents; developers do not need to declare these tools manually.
• Applicable scenarios: Suited for mutually independent tasks (such as independently reviewing different documents or troubleshooting separate incident root causes), where each subtask has a well-defined question and expected output. Short tasks or sequential, interdependent steps should remain with the primary agent.
• File collaboration considerations: Each subagent has its own independent context window to maintain focus; however, when connected to a sandbox, all agents share the same sandbox filesystem. If multiple agents must modify the same set of files, an explicit coordination mechanism must be established in the workflow.

Limitation (from Multi-Agent Documentation): Subagents inherit MCP tools configured on the primary session (including credentials and allowed tool lists) as well as web search configurations, and can use files and CLI tools within the sandbox environment; however, subagents do not currently support Function Tools.

Editorial note: If your business logic requires custom logic delegated to subagents, packaging it as an MCP service or a command-line script inside the sandbox is recommended.

Open-Source Foundation: Codex Harness

Powering the Agents API is the open-source Codex harness. The core scheduling logic coordinating model calls, tool use, and context management is available for inspection and study in the public repository openai/codex. Through the Agents API, OpenAI operates and maintains this harness in the cloud, allowing developers to use it directly without building and maintaining the harness infrastructure themselves.

Official Minimal Example (Quickstart)

In the official Quickstart Guide, spinning up a session capable of code execution and file operations using the Python SDK (beta.agents namespace) looks as follows:

from openai import OpenAI

with OpenAI() as client:
    with client.beta.agents.sessions.create(
        agent={
            "model": "gpt-6-astra",
            "instructions": "Write clean code, run it, and report the actual output.",
        },
        environment={"type": "openai_hosted"},
        input="Create tree.py, a Python script that prints a readable tree of the files in the current directory. Run it and show me the output.",
        stream=True,
    ) as events:
        for event in events:
            print(event.to_json(indent=None), flush=True)

During execution of this code, the system performs the following sequence:

1. Environment provisioning: OpenAI provisions an openai_hosted sandbox environment in the cloud for the session, with /workspace as the working directory.
2. Code generation and execution: The agent creates the tree.py file within the workspace and runs the script in the sandbox terminal to retrieve the directory tree output.
3. Event stream monitoring and state confirmation: The client listens to progress via the event stream. When the turn concludes, the system emits an agent.session.turn.completed event, though this does not guarantee every tool call executed successfully; actual execution results reported by the agent must still be inspected. Receiving turn.failed, turn.cancelled, or session.failed indicates that the turn failed or was canceled; an agent.session.idle status alone does not signify task success. If the stream disconnects unexpectedly, retrieve the session and saved items before deciding whether to retry.
4. Artifact archiving and retention: If the task generates reports or data visualizations, writing them to the /workspace/outputs directory ensures they are published as immutable artifacts upon turn completion. Even if the sandbox is subsequently torn down due to inactivity, copies of these artifacts remain available for download. Required files should be downloaded before cleaning up and deleting the session.

Hosted Sandbox Environment Configuration and Network Controls

According to the OpenAI-Hosted Sandbox Configuration Guide, the sandbox offers fine-grained environment customization:

• Pre-installed configurations: Install Python, system, or npm dependencies via packages; run preparatory shell commands sequentially before the agent starts via setup_commands (if a setup command returns a non-zero exit code, the agent will not start); upload initial files via files; set environment variables via env (though reserved system names such as PATH, CODEX_*, OPENAI_API_KEY, etc. will be rejected); and load pre-configured capabilities via skills, plugins, and capability_directories.
• Outbound network controls: If network is not declared in the configuration, the sandbox defaults to allowing outbound network access (enabled). To restrict network permissions, network.access can be set to disabled (blocking outbound connections entirely) or restricted (restricted outbound). Under restricted mode, allowed_domains must be configured with 1 to 100 exact hostnames (e.g., api.example.com; wildcards, protocol schemes, paths, or ports are not supported, and every subdomain and redirect destination must be listed individually). Note that hosted stdio MCP servers currently require the network mode to be set to enabled.
• Background execution behavior: Closing the client's event stream connection does not cancel tasks currently executing inside the sandbox.

What Customers Are Saying (Quotes from the Launch Page)

On the announcement page, OpenAI shared testimonials from 8 early adopters. Ciridae, Hypha, and SafetyKit provided quantitative metrics before and after migration, while the remaining teams shared their engineering experiences across various scenarios:

• Ciridae (Jack Weissenberger, CTO) · Subagent Workflows (specific business unstated): Benchmark score increased from 0.71 to 0.85, while latency dropped to 1/4 of its previous level. Subagent streaming worked out of the box, significantly simplifying the heavy burden of previously orchestrating and observing subagents themselves.
• Hypha (Serhii Shchoholiev, Lead Engineer) · Financial Services: Earning customer trust in financial services is critical. By decoupling the harness from the sandbox, failed agent responses dropped by 86%, giving customers greater confidence in production use.
• SafetyKit (Bhavyansh Sabharwal, Member of Technical Staff) · Case Review: Migrating case review workflows to the Agents API reduced cost per case by 60%, lowered latency, and significantly improved token efficiency, all while maintaining quality.
• WithCoverage (Cole Striler, Director of Engineering) · Complex Multi-Step Workflows: Previously requiring custom prompt chains and self-managed tool calling, agents can now be used directly in code just as Codex runs on a laptop, resolving multiple issues that would have otherwise required building dedicated agent infrastructure.
• Dwelly (Dmitry Khanukov, Co-founder & CTO) · Burst Workloads: The most prominent takeaway during testing was the ability to handle bursty workloads. Work can be dispatched across hundreds of agents to run asynchronously and collected later, eliminating the need to keep infrastructure idling between business peaks.
• deepsense.ai (Maks Operlejn, Senior ML Engineer) · Engineering Tasks in Real Codebases: The agent completed feature implementations, independent reviews, bug fixes, and real browser validations within a live, active codebase, demonstrating strong overall engineering quality.
• Nash.ai (Aziz Alghunaim, Co-founder & CTO) · Global Logistics Delivery Dispatch: Deploying thousands of long-running agents managing hundreds of millions of deliveries. The Agents API provides persistent sessions and the orchestration layer (responsible for context management, recovery, and multi-step execution), while Nash supplies the tools and execution environments connecting to the physical world, allowing agents to coordinate and recover across hours or days.
• Long Lake (Rasmus Wissmann, CTO) · Cross-Industry AI Platform (Nexus): The Agents API provides the harness, while environment, context, and interaction experiences remain controlled by the enterprise. With the Nexus platform, agents can be stood up in hours across diverse industries ranging from residential services to architectural design.

Pricing Structure and Technical Limitations

Before integrating the Agents API into production workloads, it is important to clearly understand its pricing structure and current technical constraints.

Pricing Structure

The launch page states that the Agents API itself carries no additional fees; users pay only for tokens and tools consumed by the agent. Unit pricing details are listed on the Pricing Page:

• Model Token Fees: Billed at standard API rates for the selected base model. Taking gpt-6-astra from the example (short-context pricing): uncached input is $10.00 / 1M tokens, cached input is $1.00, cache write is $12.50, and output is $50.00; long-context pricing is higher (input $20.00, cached input $2.00, cache write $25.00, output $75.00). (Note: Regarding gpt-5.6-sol listed on the pricing sheet, input is $4.00 / 1M and output is $20.00 / 1M, but this is a promotional rate lasting at least through November 21, 2026, and current official materials have not confirmed whether the Agents API supports this model).
• Built-in Tool Call Fees: Built-in web search costs $10.00 per 1,000 calls; tokens introduced by search content are billed separately at the selected model's input token rate. (Note: The File search tool fee listed on the pricing sheet applies only to the Responses API, not the Agents API).
• Container Compute Fees (OpenAI-hosted sandbox only):
  • 1 GB tier: $0.03 / 20 min
  • 4 GB tier: $0.12 / 20 min
  • 16 GB tier: $0.48 / 20 min
  • 64 GB tier: $1.92 / 20 min The pricing page does not specify what resource "GB" measures, nor which tier the hosted sandbox uses by default. Eligible container sessions are billed by the minute, with a minimum billing duration of 5 minutes per session. OpenAI container fees apply only to hosted sandboxes; with self-hosted or partner sandboxes, compute is borne by you or your provider.

Technical and Compliance Limitations

According to official developer documentation, the current release has clear boundaries and constraints:

• Data Residency and Zero Data Retention (ZDR) Restrictions: Developer documentation explicitly states that the Agents API currently only supports US data residency and does not support Zero Data Retention (ZDR); choosing a self-hosted sandbox does not make a session ZDR-compliant. Editorial interpretation: This is because session state management, orchestration, and harness scheduling remain centralized in OpenAI's cloud. If your business requires ZDR, documentation notes that certain Responses API capabilities (such as server-side compaction paired with store=false and programmatic tool calling) support ZDR workflows, but ZDR must first be enabled for your organization or project; if data residency outside the United States is required, the materials offer no alternative for the Agents API.
• Sandbox Lifecycle and 1-Hour Inactivity Teardown: OpenAI-hosted sandbox documentation indicates that connected sandboxes automatically receive keep-alive signals (including between turns). If sandbox activity and keep-alive signals both cease for 1 hour, the sandbox may be deleted (this timeout is non-configurable). Consequently, files requiring persistence must be saved to the /workspace/outputs directory, where files are published as immutable artifacts upon turn completion and remain downloadable after the sandbox expires.
• HTTP 409 Conflicts During Session Deletion: Calling client.beta.agents.sessions.delete via the SDK while a sandbox is initializing or executing commands may return an HTTP 409 Conflict. Production code should include retry mechanisms with capped maximum retry attempts. Furthermore, closing the event stream connection does not cancel background tasks.

Implementation Selection and Practical Checklist

Environment Selection Guidance (Editorial compilation based on developer documentation)

When choosing an execution environment for an agent, evaluate against the following criteria:

1. Hard Compliance Barrier Evaluation: If your use case strictly mandates Zero Data Retention (ZDR) or requires data to reside outside the United States, you cannot currently use the Agents API. Those requiring ZDR can evaluate ZDR-supported workflows in the Responses API (which must first be enabled for the organization or project); for data residency outside the US, the materials offer no alternative.
2. Seeking Fast Verification and Low Maintenance Overhead: Prioritize the OpenAI-hosted sandbox (OpenAI-hosted). The Linux environment is provisioned automatically, with support for tightening outbound network policies via restricted or disabled. Enforcing controlled network policies does not require building your own sandbox.
3. Requiring Dedicated Compute, Custom Images, or Internal Network Access: Choose Self-hosted sandboxes (Self-hosted) or Sandbox Partners. Suitable for scenarios requiring custom system dependencies, dedicated GPU compute, private storage mounts, or placement inside your own VPC.

Production Readiness Checklist

Before deploying the Agents API to production, review each item against official specifications:

• [ ] Key Permissions and Environment Isolation:
  • Primary application API key (requiring api.agents.read/write and api.responses.write permissions) is stored outside the sandbox environment.
  • The self-hosted sandbox holds only the restricted environment key CODEX_API_KEY, with all other permissions set to None during platform creation, retaining only environment connection privileges.
  • Strictly isolate runtime environments across different users or distinct workloads to avoid file and credential leakage within shared environments.
• [ ] Outbound Network Policy Containment:
  • When using the OpenAI-hosted sandbox, if network is not explicitly configured, the system defaults to allowing outbound access. To restrict access, actively configure it to disabled or restricted.
  • Under restricted mode, configure exact hostnames individually in allowed_domains (1–100 hostnames; wildcards not supported, redirect destinations must be explicitly listed).
  • Note: Hosted stdio MCP servers currently require the network setting to be enabled.
• [ ] Artifact Persistence:
  • Ensure core data, reports, and code generated by tasks are explicitly directed to the /workspace/outputs directory. Contents of this directory freeze into immutable artifacts upon turn completion, avoiding loss after sandbox idle teardown. Download necessary files before invoking session deletion endpoints.
• [ ] Multi-Agent Mechanism Adaptation:
  • Confirm task decomposition into mutually independent subtasks; if multiple subagents share a sandbox and modify the same files, design an explicit coordination sequence.
  • Subagents inherit MCP tools and web search, but do not support standard function tools.
• [ ] Exception and Disconnection Fault Tolerance:
  • Listen to turn.completed, turn.failed, turn.cancelled, and session.failed in the event stream. Note that turn.completed does not guarantee every tool call succeeded—actual execution results reported by the agent must be verified; receiving agent.session.idle alone does not indicate task success.
  • If an event stream disconnects unexpectedly, follow documentation guidance to "retrieve the session and saved items" to restore state rather than blindly recreating duplicate sessions.

Public Beta and Getting Started

The Agents API is now available in Public Beta to all developers. During the public beta period, OpenAI will iterate rapidly based on developer feedback toward General Availability (GA), during which API interfaces may undergo adjustments.

Using the Agents API incurs no additional platform fees; developers pay only for model tokens, built-in tools used, and hosted sandbox container compute.

Developers can consult the official documentation to explore further and get started:

• Read the Agents API Overview to understand the complete architecture and core concepts;
• Follow the Quickstart Guide to run your first agent session. When making requests via cURL, explicitly add the OpenAI-Beta: agents=v1 header (the official SDK includes this header automatically); the primary application API key must possess api.agents.read/write and api.responses.write permissions.