guide

OpenAI Agents API: a hosted browser with approval limits

OpenAI runs the browser and agent loop, but website approval doesn't enforce confirmation before each action. Compare your responsibilities, task costs, AWS execution, and runtime alternatives.

EiliyaOctober 1, 20267 min read

The OpenAI Agents API can run a hosted browser, but approving a website doesn't enforce approval before each action. Your app still handles website access requests and sign-in.

OpenAI runs the browser and agent loop; you connect that execution to the user's permissions and expectations. The computer use documentation makes that division worth reading closely.

DevDay added computer use to a service that entered public beta on September 10, 2026. As of September 30, your choice is how much of the agent runtime you want to operate yourself, and where the work should run.

OpenAI Agents API manages the loop; you supply the tools

OpenAI's overview describes managed access to the Codex runtime. OpenAI handles sessions, orchestration, context compaction, and recovery. You supply instructions and tools, choose an execution environment, and receive events and results.

A durable session carries the work. Create one, send a task, follow its progress, then continue or steer it. You don't have to reconstruct the whole conversation whenever a user returns with another instruction.

If you're maintaining your own loop, these capabilities are worth comparing with what you've built:

Context compaction can summarize earlier work as the session approaches its context limit.
Subagents can take independent parts of a task and bring the results back together.
Tool orchestration lets the runtime discover tools and coordinate calls without a hand-written prompt chain for every step.

I'd look hardest at this API when maintaining that machinery eats time you could spend on your app's tools and task evaluation. It saves infrastructure work, but you still need to check whether tasks finish correctly.

A self-hosted sandbox leaves the loop with OpenAI

The architecture guide treats the agent runtime, execution environment, and your application server as separate pieces.

An agent that only needs connected services or application functions can work without a sandbox. An OpenAI-hosted environment adds compute and files that OpenAI provisions; a self-hosted environment runs commands on infrastructure you manage.

Choose self-hosted execution and you own provisioning, reconnection, shutdown, and preservation of the files you need. OpenAI still runs the managed loop. You're moving command execution onto your infrastructure, rather than the whole agent service.

You also run application function tools. Your handler receives a call, runs the function, and returns the result. An unavailable handler can leave the agent waiting, the architecture docs warn, so a managed loop still depends on your integration service.

For example, a support agent might have a read-only order lookup and a separate refund function. The runtime can coordinate those calls; your backend decides which account the user may access and which operations your product permits.

Tool search doesn't defer your functions by default

Tool search can reduce the definitions in model context. Function definitions still load eagerly by default, according to the tool-search guide.

To defer a function, include tool_search in the agent's tools and mark that function with defer_loading: true. You still supply its full definition in the session request. Discovery changes when the model sees it.

For MCP tools, the runtime uses automatic discovery when the model and provider support tool search. Check the guide before copying Responses API configuration into an Agents API MCP connection.

Eager loading may be simpler for a small set of frequently used functions. Deferred loading can keep irrelevant definitions out of context when you have a large catalog, but discovery adds a step. Compare task completion, input usage, and latency on representative work before changing the default.

Website approval doesn't cover every browser action

The computer use guide explains how to enable computer_use in an OpenAI-hosted environment with desktop access. Your application creates a browser session, follows its events, and sends the task.

Your integration then needs to:

Handle requests before the browser accesses each new website origin, including public sites.
Present the requested origin and any supplied reason to the user.
Collect and submit the user's approval, denial, or cancellation.
Handle sign-in when the task needs an account, keeping credentials outside the chat.
Verify the final result and delete the session when finished.

If your product must guarantee approval before a purchase or destructive change, restrict the browser to resources that cannot perform it, or use a runtime you control. Website origin approval has the narrower scope described above. A prompt alone can't supply the action-level guarantee.

Browser activity appears as tool-call items. A completed operation doesn't mean the whole task is finished. You can include screenshots, though API output excludes them by default and they may contain sensitive account data.

I'd start with browser testing or information gathering. Prefer a direct application tool when an action already has a reliable, scoped API, and use the browser when the work needs the interface.

OpenAI Agents API pricing: no extra API fee, but runs still cost

The beta announcement says the Agents API itself has no additional fee. You pay for model usage at the chosen model's rates, OpenAI tools at standard rates, and hosted sandboxes at container rates, according to the current overview.

Several subagents, repeated tool calls, and an environment kept running can produce a different bill from a short answer using one function. There is no fixed price per completed job in that billing structure. Check the API pricing page for the components you enable.

The DevDay recap separately lists related availability in Codex and ChatGPT Work on Pro 500 and Enterprise. That product availability doesn't require you to buy Pro 500 to build through the API, and the subscription doesn't pay your application's API bill.

Measure cost per verified result. A cheap run that needs several retries or manual repair can leave you with the more expensive workflow.

Bedrock Managed Agents runs the runtime and inference in AWS

Amazon Bedrock Managed Agents, powered by OpenAI, adapts the same core approach for AWS. The agent runtime and inference run in Amazon Bedrock; commands and tools run through AgentCore Runtime or self-hosted compute, according to OpenAI's comparison guide.

You authenticate with AWS IAM credentials and SigV4 signing instead of an OpenAI project API key. The session concepts overlap, but endpoints, supported tools, and feature availability can differ. Check AWS's current contract before adapting an OpenAI example.

AWS's product page calls the service a limited preview and says data never leaves AWS. Evaluate that claim within the service's documented boundaries, including your integrations and logs.

AWS had already announced the limited preview on April 28, 2026. DevDay highlighted that route without establishing general availability for access or every capability.

Choose the loop you want to own

A September 25 r/JordanDev reply suggested Vercel's AI SDK or LangChain tooling for learning, and described the managed Agents API as quicker to start with less control. That's one developer's advice, rather than a benchmark, but control is a useful way to frame the choice.

For production, compare the options using their primary docs:

Option	Who controls the loop	Main reason to evaluate it
OpenAI Agents API	OpenAI operates the managed Codex runtime	Reduce session and orchestration work
OpenAI Agents SDK	The runner operates in your application	Choose deployment, storage, approvals, and integrations
Responses API	Your application builds the agent behavior	Work directly with responses and your own orchestration
LangGraph	You define the workflow graph and runtime setup	Mix deterministic steps with model-driven work
Claude Managed Agents	Anthropic supplies managed orchestration	Evaluate a managed service built around Claude

OpenAI explains its options in the agent runtime comparison. LangGraph's docs emphasize persistence and human oversight, while Anthropic's overview describes stateful managed sessions and hosted or self-hosted sandboxes.

Check the data requirements before building around persistent sessions. OpenAI's overview says the Agents API currently supports data residency only in the United States and isn't eligible for Zero Data Retention. A self-hosted sandbox doesn't change either restriction.

FAQ

Is the OpenAI Agents API the same as the Agents SDK?

No. The API manages the Codex runtime for you. The SDK's runner executes inside your application, where you have more control over its operation.

Does computer use control my user's desktop?

The documented flow runs an OpenAI-hosted browser. It doesn't establish access to your user's local desktop.

Does the Agents API require ChatGPT Pro 500?

The public API uses API billing. Pro 500 applies separately to related features inside Codex and ChatGPT Work.

Is Bedrock Managed Agents generally available?

AWS's current product page calls it a limited preview. Check its access requirements and supported capabilities.

Can I use Zero Data Retention with the Agents API?

No, according to the current overview. Self-hosted execution doesn't make the service ZDR-eligible.