OpenAI adds browser control to the Agents API
OpenAI adds browser control to the Agents API. Website approvals, authentication limits and separate compute charges shape how developers should integrate it.
OpenAI added computer use to the Agents API on September 29, according to its API changelog. Developers can now build agents that navigate websites through a browser hosted by OpenAI, with their application responsible for handling access requests and sign in.
The addition extends the Agents API public beta introduced on September 10. It gives developers another way to reach software, especially when a workflow depends on a browser interface rather than a dedicated integration.
Website approval has a limited meaning
The computer use guide says each new website origin requires user approval, including public sites. Network access settings are separate. Permitting a destination through the network policy does not approve the browser’s request to visit it.
The guide also states an important boundary. Origin approval does not enforce confirmation before individual purchases, destructive changes or other consequential actions. Applications that need such guarantees should restrict the hosted browser to resources that cannot perform those actions, or use a browser runtime they control.
That is a design decision to make before exposing the feature to customers. A team testing a public website has different requirements from a team automating an account that can change records or spend money. The approval screen should accurately describe the protection the application actually provides.
Authentication and completion need their own handling
OpenAI’s guide supports email addresses, passwords and verification codes through a dedicated authentication flow outside ordinary chat. Passkeys and QR code sign in are unsupported. Only the main agent can request browser authentication.
An accepted authentication response does not establish that login succeeded. After a connection failure, developers should inspect the existing session and pending requests before retrying. Closing the event stream does not stop the task.
These details affect the application’s user experience. A disconnected progress display can leave work running. A submitted form can still lead to another login step. The interface needs to represent those states rather than treating every successful request as a finished job.
Compute and model costs remain separate
The hosted sandbox documentation says compute uses container rates, while model usage is billed separately. Each session has a separate workspace. Output artifacts can remain downloadable after the sandbox expires, but developers should retrieve required results before requesting cleanup.
This makes a completed workflow the useful budgeting unit. Our GPT 6.1 Sol pricing report covers model rates. Browser driven tasks add infrastructure and integration work, including recovery, authentication and review of the final result.
AWS offers another deployment path in preview
Amazon Bedrock Managed Agents combines OpenAI models, the Codex harness and AgentCore inside AWS. AWS says the runtime and model inference stay within its infrastructure, with identities and permissions used to control resource access.
The AWS quickstart still labels the service preview and warns that features and APIs can change. It describes an execution role controlled by the customer and an isolated machine for each Runtime session. Runtime resources, image builds and model calls can all incur charges.
This is existing deployment context. Amazon’s announcement history dates the initial Managed Agents limited preview to April 28. The newly dated OpenAI update is browser support in its Agents API. Teams should verify capabilities for their chosen deployment instead of assuming identical features across both services.
