OpenAI adds computer use to Agents API; developers still control website access

OpenAI's [September 29 DevDay recap](https://openai.com/index/devday‑2026‑recap/) says the Agents API now supports computer use: developers can give agents work that involves interacting with software through a browser. The company also highlights Codex‑style multi‑agent coordination, tool search, tool calling and context compaction as part of the application platform. For a developer evaluating today's announcement, the useful question is whether a workflow needs a browser, rather than whether OpenAI has released an agent API for the first time. The [Agents API entered public beta on September 10](https://openai.com/index/introducing‑the‑agents‑api/). That earlier introduction already described a managed Codex harness, selectable execution environments, subagents, tool search and programmatic tool calling. DevDay's browser support is an additional way for an agent to perform tasks in web interfaces. It does not turn every existing API session into a browser session or make a separate computer‑use implementation unnecessary. OpenAI's [current guide](https://developers.openai.com/api/docs/guides/agents‑api/tools/computer‑use) tells developers to add a computer‑use tool and enable a desktop in an OpenAI‑hosted environment before creating one.

The [computer‑use guide](https://developers.openai.com/api/docs/guides/agents‑api/tools/computer‑use) describes a concrete sequence: create a browser session and retain its ID, follow the session's events, send the task, then handle website‑access requests as they arise. If the site needs an account, the application must handle sign‑in. After the agent finishes, the developer is expected to verify the result, review the saved browser activity and delete the session when finished. The browser runs in an OpenAI‑hosted environment; the application follows its events instead of silently treating a successful task prompt as proof of an acceptable outcome. That division matters for teams automating real work. Browser access introduces third‑party pages, account boundaries and possible state changes that a plain text‑response workflow never reaches. A practical first integration would choose a narrow task with a known final state, decide which site requests the application will permit, and define what evidence proves completion. This is an implementation implication from OpenAI's documented access and verification steps, not a claim that OpenTools tested the browser tool or that the API guarantees a particular task success rate.

The [DevDay recap](https://openai.com/index/devday‑2026‑recap/) says the capability is available through the API and also references Codex and ChatGPT Work on Pro 500 and Enterprise. Those product‑plan labels should not be read as an API rate card or proof that every developer account has the same configuration. OpenAI's [API guide](https://developers.openai.com/api/docs/guides/agents‑api/tools/computer‑use) is the source for the developer setup; the recap is the source for the launch announcement and product availability statement. The distinction between a platform and a model is also useful. Computer use here is a tool and hosted‑browser workflow associated with the Agents API, not a newly named foundation model or a measured improvement to one. For the developer platform behind the announcement, see the [OpenAI organization](https://opentools.ai/organizations/openai).