OpenAI Agents API Adds Computer Use and Subagents: Billing Guide
OpenAI's Agents API added computer use on September 29. On the same day, GPT-6.1 Sol began supporting task delegation to subagents (beta). The first lets an agent complete tasks in a browser hosted by OpenAI; the second lets the model split up work inside a single Responses API request. If you already use the Responses API, neither feature changes your existing calls automatically. To use them, you have to opt in to the Agents API or the relevant model capability. This article reflects the state as of October 2026; the OpenAI API changelog is the source of truth.
What is the timeline?
- September 10: The Agents API entered public beta. OpenAI describes it as running agents on a managed Codex harness, with session orchestration, context compaction, and failure recovery handled by OpenAI. Sessions are persistent and can continue across many turns.
- September 29: The Agents API added computer use. The agent works in a browser hosted by OpenAI, and your application is responsible for approving website access and handling logins.
- September 29: GPT-6.1 Sol was released with multi-agent orchestration (beta), which can delegate work to subagents within a single Responses API request.
The status page also recorded a few related incidents: "Overbilling for OpenAI-hosted containers in the Agent API" on September 19 (resolved) and "Computer Use Is Experiencing Issues" on October 6 (resolved). The status page list may be truncated, so open the full history yourself to confirm.
How do the Agents API and Responses API divide the work?
A rough split, based on OpenAI's descriptions:
| Dimension | Responses API | Agents API (beta) |
|---|---|---|
| State | Your app usually manages the conversation and the loop | Persistent sessions orchestrated by the platform |
| Long tasks | You handle context compaction and recovery | The platform handles compaction and recovery |
| Runtime | Your app executes tool calls | OpenAI-hosted sandbox, your own infrastructure, or a sandbox from a supported provider |
| Best for | Single turns or short, controllable loops | Long-running agents that need to resume midway |
Subagent delegation is a capability inside a Responses API request. It requires GPT-6.1 Sol and is currently in beta. The two are not mutually exclusive; check the official docs for supported combinations. If you are still weighing how to connect in the first place, see official API vs. cloud providers vs. aggregation gateways.
What are you responsible for once computer use is on?
The changelog states that website access approval and logins are handled by your application. In practice:
- Decide which sites the agent may visit. Do not open it up to arbitrary domains.
- Do not put login credentials directly in prompts. Follow the official computer use guide for how to pass them.
- For irreversible actions such as payments, deletions, or sending messages, add human confirmation in your app.
- Record the action trail of every session so you can replay it when something goes wrong.
If you already use sandboxes to restrict an agent's local commands, the idea is the same; see GitHub Copilot local sandboxing is now GA.
How is it billed, and what should you track separately?
The changelog does not list Agents API pricing separately and points to the official pricing page, so no specific amounts are given here. What can be confirmed:
- Model calls are billed per token. For example, the changelog lists GPT-6.1 Sol at $2 per million input tokens and $10 per million output tokens (prompts up to 272K input tokens), with separate prices for cached input and cache writes.
- Tools and hosted containers are billed as separate line items from model tokens. See the official pricing page for unit prices. The September 19 overbilling incident happened on hosted containers.
How to check your bill:
- Tag every agent task with your own task ID and record its start and end times.
- Use the usage breakdown in the dashboard and reconcile the two categories, model tokens and container time, separately.
- If a day looks unusually high, first check whether the status page logged a billing incident that day, then open a ticket with OpenAI.
For a line-by-line approach, see How to investigate API billing that looks wrong.
What should you monitor in production?
- Session-level failures: whether a persistent session can resume after an interruption, and whether retries re-run actions that have side effects.
- Timeouts and hangs: browser-driven tasks are usually slower than ordinary API calls, so set a separate timeout threshold.
- 429s and capacity errors: rate limiting at peak hours. See the October Codex error records.
- Cost: track token and container usage per task, and set a daily budget alert.
- Tracing: keep a trace for every subagent call. Claude agent OpenTelemetry setup shows one approach.
For an external signal, see cdnping's /en/status/openai (probes OpenAI's API entry point from the Cloudflare edge every 5 minutes) and /en/down/codex. They only show whether the entry point is reachable and are no substitute for your own monitoring of Agents API sessions. You can follow official updates at /en/changes.
Should you adopt it now?
Both capabilities are in beta, and the Agents API has already had a degradation and a billing incident. A safer path: start with non-critical tasks, limit the site scope, set a spending cap, watch your bill and error rate for a week or two, and then decide whether to move it into production workflows.
