The OpenAI Agents API has no separate managed-harness fee listed in OpenAI's current pricing documentation, but an agent job is not free or inherently predictable. The bill still includes model tokens on every loop, cache writes and reads, paid built-in tools, hosted or third-party compute, storage, retries, observability, and human review. A completed turn can also contain a failed tool call, so the useful unit is cost per accepted business outcome, not cost per API call.
For a small team, the Agents API is most attractive when long-running work genuinely benefits from OpenAI managing the Codex harness, session state, context compaction, orchestration, and recovery. It is a poor fit when a deterministic automation or one Responses API call can do the job. As of October 18, 2026, the API remains in beta: requests use the OpenAI-Beta: agents=v1 header and SDKs expose it under beta.agents.
This is a vendor-document-verified pricing and fit guide, not a hands-on test. Product status, public prices, billing minimums, environments, lifecycle, retention, and documented capabilities were checked against live OpenAI documentation on October 18, 2026. No Google Search Console or GA4 evidence was available, and no first-party performance claim is inferred.
The harness is only the coordinator. Tokens, tools, compute, retries, monitoring, and review determine the real cost of an accepted result.
What does OpenAI manage, and what does your business still own?
OpenAI manages the agent harness; your business still owns the workflow, risk, and economics. The managed Codex harness maintains sessions, runs the agent loop, compacts context, recovers state, supports subagents, and connects to tools and environments. OpenAI can also provision an isolated Linux sandbox when you select an OpenAI-hosted environment.
Your team still owns:
- the task definition and acceptance test;
- model, reasoning, tool, and environment choices;
- application function handlers and third-party credentials;
- approvals for consequential actions;
- retry, idempotency, and rollback logic;
- sandbox cleanup and artifact retention;
- monitoring, budget alarms, and incident response;
- human review and the decision to accept or reject an output.
That division matters. “Managed” removes infrastructure work from the inner agent loop. It does not transfer responsibility for bad instructions, excessive fan-out, duplicate side effects, weak permissions, or an employee approving nonsense because the dashboard had a green checkmark.
Agents API vs Agents SDK vs Responses API
Choose the thinnest runtime that safely completes the work. The Agents API is the highest-level managed option; the Agents SDK gives your application control of the loop; the Responses API is the direct model-and-tools layer.
| Option | Where the loop runs | State and execution | Best fit | Main cost risk |
|---|---|---|---|---|
| Agents API | OpenAI-managed Codex harness | Durable sessions; optional OpenAI-hosted, self-hosted, or no sandbox | Long-running, stateful, tool-using jobs where managed recovery and orchestration save engineering effort | Repeated model loops, subagent fan-out, sandbox time, retries, and retained sessions |
| Agents SDK | Your application | Your runtime, storage, deployment, approvals, and provider integrations | Teams that need custom control and can operate the agent service | Engineering and hosting may exceed token cost |
| Responses API | Your application, with optional hosted tools | You control history, chaining, and workflow code | Bounded tasks, deterministic workflows, and single- or few-step tool calls | Teams may rebuild orchestration badly, but usage is easier to cap |
Use the Agents API when the managed harness replaces real engineering and operational work. Use the SDK when deployment, storage, provider choice, or approval logic must stay under your control. Use Responses when the job is fundamentally a prompt, a few tools, and a validation step. Paying for a foreman to supervise one hammer swing is still paying for a foreman.
For adjacent decisions, compare the broader guide to useful and risky AI agents for small business, the GPT-6.1 Sol pricing guide, and ChatGPT Workspace Agents pricing. Those products and meters are related, but they are not interchangeable with the public API described here.
How OpenAI Agents API pricing actually works
There is no separate Agents API harness line item in the current public overview; OpenAI directs buyers to model, tool, and container pricing. Calculate the job from five meters:
- Model usage: ordinary input, cache writes, cached input reads, and output tokens for root and subagent turns.
- Built-in tools: web search calls and search-content tokens; other tool products can have separate meters.
- Environment: OpenAI container time or your self-hosted/partner compute and storage.
- Operational waste: failed attempts, retries, idle compute, duplicate work, and unnecessary fan-out.
- Acceptance: monitoring, exception handling, and human review.
Current standard model rates
OpenAI publishes the following standard rates per 1 million tokens. Short context is 272,000 input tokens or less; long context is more than 272,000 input tokens. These are useful planning models for agent workloads, but the accessible Agents API guides do not publish an exhaustive model-compatibility matrix. The official examples use gpt-6-astra; confirm the selected model is accepted by the beta endpoint before budgeting production.
| Model | Short input | Short cached read | Short cache write | Short output | Long input | Long cached read | Long cache write | Long output |
|---|---|---|---|---|---|---|---|---|
| GPT-6 Astra | $10.00 | $1.00 | $12.50 | $50.00 | $20.00 | $2.00 | $25.00 | $75.00 |
| GPT-6.1 Sol | $2.00 | $0.10 | $2.50 | $10.00 | $4.00 | $0.20 | $5.00 | $15.00 |
| GPT-6 Sol | $2.00 | $0.20 | $2.50 | $10.00 | $4.00 | $0.40 | $5.00 | $15.00 |
| GPT-6 Luna | $0.10 | $0.01 | $0.125 | $0.50 | $0.20 | $0.02 | $0.25 | $0.75 |
Long-context pricing is not a one-time surcharge. Once a request crosses the threshold, its applicable input, cache, and output rates change. Agent loops can repeatedly resend or reconstruct large working contexts, which is why a job that looked cheap in a one-call spreadsheet can become expensive after ten turns and three subagents.
Cache writes and reads change the math
For GPT-5.6 and later families, OpenAI says a cache write costs 1.25× the ordinary input rate. Most subsequent reads cost 0.1×; GPT-6.1 Sol reads cost 0.05×. A stable prefix written once and reused repeatedly can save money, but a changing prompt that keeps creating new writes can cost more than uncached input.
Track cached_tokens and cache_write_tokens separately. Put stable instructions, schemas, and reference context before changing content; set explicit breakpoints when appropriate; and measure actual hit rate. Cache entries are temporary, and available retention depends on the model and organization policy.
Current tool and container rates
| Meter | Current public rate | Practical warning |
|---|---|---|
| Web search | $10 per 1,000 calls, plus search-content tokens at model rates | One agent job can issue many searches; openings and follow-up searches also add model context |
| File search storage | $0.10 per GB per day, with 1 GB free | Persistent corpora create a daily storage meter |
| File search tool calls | $2.50 per 1,000 calls | OpenAI says this call charge applies to the Responses API; do not automatically assign it to an Agents API integration without confirming the path used |
| 1 GB container | $0.03 per 20 minutes | Equivalent list rate: $0.0015/minute |
| 4 GB container | $0.12 per 20 minutes | Equivalent list rate: $0.006/minute |
| 16 GB container | $0.48 per 20 minutes | Equivalent list rate: $0.024/minute |
| 64 GB container | $1.92 per 20 minutes | Listed for hosted container products; the Agents API hosted-sandbox guide currently documents selectable sizes only at 1, 4, and 16 GB |
Eligible container sessions are billed by the minute with a five-minute minimum. Tokens used around built-in tools are billed at the chosen model's rates. Therefore, a two-minute sandbox job is not a two-minute bill, and a $0.01 web-search tool charge does not include the model tokens used to interpret the results.
Which sandbox should a small team use?
Start with no sandbox if the job does not need commands or files; use OpenAI-hosted for the simplest isolated execution; use self-hosted or a partner when control justifies the lifecycle burden.
Environment choice changes who pays for provisioning, isolation, networking, storage, cleanup, and incident response.
No sandbox
Choose environment.type: none when the agent only needs model reasoning, remote MCP, web search, or application functions. This removes container cost and lifecycle work. It also means there is no built-in shell or local workspace.
OpenAI-hosted sandbox
OpenAI provisions a Linux workspace with Python, Node.js, command-line tools, files, packages, setup commands, and network controls. The documented Agents API sizes are small (1 vCPU/1 GB), medium (2 vCPU/4 GB, default), and large (4 vCPU/16 GB). This is the fastest path to isolated execution, but model billing remains separate.
Files persist across turns while the sandbox exists. If activity and keep-alives stop for an hour, the sandbox can be deleted. Delete the session when finished; closing the event stream does not cancel the task.
Self-hosted sandbox
OpenAI still runs the harness, while your executor runs in your laptop, container, private cloud, or remote sandbox and connects outbound over WebSocket. You control the image, network, storage, security boundary, compute bill, snapshots, and cleanup. Deleting the Agents API session does not stop provider compute; your controller must stop it separately.
Partner sandbox
OpenAI documents integration patterns for providers including AWS, Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, OCI, Runloop, Vercel, and others. These are self-hosted from the Agents API's perspective: OpenAI manages the harness, while your application and provider manage the environment. Provider pricing, cold starts, retention, regions, and shutdown behavior must be priced separately.
Session lifecycle, pre-warming, fan-out, and cleanup
Session operations can cost more than the happy-path turn if the application treats lifecycle as an afterthought. A session can outlive its environment, and a self-hosted environment can outlive the session.
- Pre-warming: OpenAI says preparation before attachment is free, including container usage. An unattached pre-warmed sandbox expires after five minutes. Standard container pricing begins after attachment.
- Keep-alive: Hosted sandboxes receive keep-alives and may remain available between turns. Delete sessions when the work is done.
- Artifacts: Files under
/workspace/outputsbecome immutable artifacts after a turn. Download what the business needs before cleanup. - Subagents: Each subagent has its own context and can run in parallel. Set
max_concurrent_subagents; do not assume delegation is a free speed button. - Retries: Check the saved session and tool results before resubmitting after a disconnect. A completed turn does not prove every tool succeeded.
- Self-hosted shutdown: Coordinate incoming work, then delete the session and stop provider compute separately. An idle event by itself is not a safe shutdown signal.
Observability, approvals, and data controls
A production agent needs an audit trail and a stop button before it needs more autonomy. OpenAI exposes dashboard logs, session events, saved history, traces, and recorded token usage for root and subagent turns. Use them to calculate cost by session, turn, tool, and accepted outcome.
Put human approval in front of payments, deletions, external messages, permission changes, customer-record updates, and other hard-to-reverse actions. Application function handlers should enforce authorization and idempotency even if the model asks confidently.
Data control is a material fit constraint. OpenAI's current data-control table says /v1/agents data is not used for training, has 30-day abuse-monitoring retention, retains application state until deleted, and is not eligible for Zero Data Retention. The Agents API overview says it currently supports data residency only in the United States. A self-hosted sandbox does not make the managed Agents API ZDR-eligible. Delete sessions when no longer needed and verify separate policies for MCP servers, provider sandboxes, logs, vector stores, and artifacts.
Worked SMB cost scenarios
These scenarios are transparent planning models, not quoted bills. Taxes, regional uplift, provider charges, staff rates, and actual token behavior can change the result.
Scenario 1: document review
A firm reviews 20 files in one long-context job using GPT-6 Sol: 300,000 ordinary input tokens, 30,000 output tokens, and two file-search calls. Assume no paid storage because the corpus stays under the free 1 GB, a 20% retry overhead, 15 minutes of review at $20/hour for every submitted job, and a 90% acceptance rate across 10 jobs.
- Model per attempt:
(0.30 × $4) + (0.03 × $15) = $1.65 - File-search calls per attempt:
2 × $0.0025 = $0.005 - Twelve attempts for 10 jobs:
12 × $1.655 = $19.86 - Human review:
10 × $5 = $50 - Accepted outcomes:
9 - Cost per accepted outcome: ($19.86 + $50) ÷ 9 = $7.76
The review time dominates. Reducing false retries or improving the acceptance rubric can matter more than switching models.
Scenario 2: browser research
A team runs 10 research jobs using GPT-6 Sol short-context pricing. Each attempt uses 180,000 ordinary input tokens, 80,000 cached-read tokens, 20,000 cache-write tokens, 20,000 output tokens, 12 web searches, and a 4 GB hosted sandbox for 25 minutes. Assume one retry across the batch, 12 minutes of review at $30/hour per submitted job, and eight accepted reports.
- Model per attempt:
$0.36 + $0.016 + $0.05 + $0.20 = $0.626 - Web search per attempt:
12 × $0.01 = $0.12 - Sandbox per attempt:
25 × $0.006 = $0.15 - Eleven attempts:
11 × $0.896 = $9.86 - Human review:
10 × $6 = $60 - Cost per accepted outcome: ($9.86 + $60) ÷ 8 = $8.73
Search-content token volume is already included in this simplified model assumption. In production, use recorded usage rather than estimating it twice.
Scenario 3: scheduled back-office operations
A small business runs 300 bounded classification-and-routing jobs per month on GPT-6 Luna with no sandbox. Each attempt uses 20,000 input and 1,000 output tokens. Add 5% retry overhead, $15/month for external scheduling and monitoring infrastructure, two hours of operator review at $40/hour, and 285 accepted outcomes.
- Model per attempt:
(0.02 × $0.10) + (0.001 × $0.50) = $0.0025 - Model with retries:
315 × $0.0025 = $0.79 - External infrastructure and review:
$15 + $80 = $95 - Cost per accepted outcome: $95.79 ÷ 285 = $0.34
The API bill is almost irrelevant here. Ownership and exception review are the product. A deterministic automation may still be better if the classification rules can be written explicitly.
Budget accepted outcomes, not calls. Cheap attempts can still produce expensive operations when rejection and review rates are high.
Buy, build, or skip: decision matrix
| Decision | Choose it when | Avoid it when |
|---|---|---|
| Buy the managed Agents API | Long-running state, tool use, recovery, compaction, and orchestration replace meaningful engineering work | The job is a bounded call or deterministic workflow |
| Build with Agents SDK | You need control over runtime, storage, approvals, model providers, and deployment | Nobody owns uptime, traces, security, and upgrades |
| Build directly on Responses API | The workflow is narrow, testable, and easy to cap | You are quietly rebuilding sessions, recovery, and orchestration from scratch |
| Use a self-hosted or partner sandbox | Private networking, custom images, regional compute, or provider controls justify lifecycle engineering | The only argument is “maybe it will be cheaper” without a measured workload |
| Skip agents | Rules can reliably decide every step, or consequences cannot tolerate probabilistic behavior | Interpretation and tool selection are genuinely required |
A capped pilot plan for a small business
Run a two-week pilot with hard limits and one workflow. Do not begin with a general autonomous employee fantasy.
- Pick one reversible task with a clear accepted-output rubric.
- Cap each job by model, maximum turns, searches, output tokens, sandbox size, wall time, and subagent concurrency.
- Require approval before external or irreversible actions.
- Log ordinary input, cache writes, cached reads, output, tools, container minutes, retries, review time, and accepted/rejected status.
- Set alarms at 50%, 75%, and 90% of the daily and monthly budget; stop new work at 100%.
- Compare against a deterministic automation and a human baseline.
- Expand only if cost per accepted outcome and error severity beat the baseline.
Failure and rollback criteria
Stop the pilot if any of these occur:
- two unauthorized or duplicate side effects;
- one material privacy or credential-handling breach;
- accepted-output rate below 80% after the first 30 representative jobs;
- cost per accepted outcome exceeds the baseline by 25% without a documented quality benefit;
- more than 15% of jobs require manual replay;
- traces or usage cannot be reconciled to the invoice;
- the workflow cannot be disabled and safely resumed from a known checkpoint.
Rollback means disabling new submissions, cancelling active turns when safe, revoking environment and tool credentials, deleting unneeded sessions, stopping self-hosted compute, preserving required audit evidence, and reverting downstream changes through deterministic records—not asking the agent to “undo whatever happened.”
Final verdict
The OpenAI Agents API is a sensible managed runtime for small teams that need durable, tool-using agent work but do not want to build the harness themselves. It is not a low-code promise of fixed-price labor. The public cost model is usage-based across tokens, caches, tools, containers, storage, retries, and people.
Start without a sandbox when possible, keep subagent concurrency low, delete sessions deliberately, and measure acceptance. If the workflow cannot be costed and rolled back at the outcome level, it is not ready for production.
FAQ
Is the OpenAI Agents API free?
No. OpenAI does not list a separate managed-harness fee, but model usage, paid tools, hosted containers, storage, provider compute, retries, monitoring, and human review still cost money.
Is the Agents API generally available?
Not yet in the current documentation. It uses the OpenAI-Beta: agents=v1 header and the SDK beta.agents namespace as of October 18, 2026.
What is the minimum hosted-container charge?
Eligible container sessions are billed by the minute with a five-minute minimum. The pricing table also shows reference prices per 20-minute session.
Does a completed turn mean the job succeeded?
No. OpenAI explicitly warns that a completed turn does not guarantee every tool succeeded. Validate tool results and the business outcome before accepting it.
Does self-hosting make the Agents API Zero Data Retention eligible?
No. OpenAI says /v1/agents is not ZDR-eligible, and using a self-hosted sandbox does not change that managed-service policy.
Can pre-warming reduce cost?
Pre-warming mainly reduces startup latency. OpenAI says unattached pre-warming is free and expires after five minutes; standard container pricing begins after attachment.