OpenAI computer use API: what GPT-6 Astra can automate

The OpenAI computer use API lets GPT-6 Astra operate a browser or desktop through screenshots, but OpenAI's own guide recommends code execution rather than the computer tool for GPT-6 Astra, and OpenAI does not host the computer: you run the environment and execute every action. That shapes cost, safety and where it beats an integration.

By the end of this post you will know how the tool loop works, what a screenshot costs at Astra's published prices, where computer use earns its place against an API integration or RPA, and which controls OpenAI expects before an agent touches a production account. Everything here reflects OpenAI's documentation as of 21 September 2026.

Key fact	What the docs say
Model	gpt-6-astra, 1,050,000-token context, $10 input / $50 output per 1M tokens
API	Responses API; Astra tool calling does not work through Chat Completions
Recommended path for Astra	Code execution (Playwright or PyAutoGUI scripts)
Alternative path	The computer tool, returning batched mouse and keyboard actions
Who runs the machine	You: an isolated browser, container or VM
Old preview model	computer-use-preview shut down on 23 July 2026

How the OpenAI computer use API works: two paths, one loop

OpenAI's computer use guide offers two ways to connect the model to an interface. With code execution, the model writes a script that uses a library such as Playwright or PyAutoGUI, and one call can combine several actions, loops and conditional logic. With the computer tool, the model returns structured mouse and keyboard actions that your application translates into input events.

The code-execution path is an ordinary function tool. OpenAI's sample defines a tool called exec_py or exec_js with a single code argument, sends the script to a sandbox you run, and returns the text and screenshots with the original call_id. The sample loop stops after 20 responses and raises an error asking you to inspect the last result, which is a sensible default for any first build.

The computer tool path returns a computer_call with an ordered actions array. The documented actions are click, double_click, drag, move, scroll, keypress, type, wait and screenshot. You execute them in order, capture the screen, and send it back as a computer_call_output using previous_response_id. The loop ends when the model stops returning calls.

One detail catches teams out. The guide states that the API conversation and the execution environment have separate state: continuing a response does not restore a browser session, a login or runtime variables. Your application owns the machine, and if it restarts the container mid-task, the model is now looking at a screen it has not seen.

Integration path	What the model returns	Best fit
Code execution (recommended for Astra)	A Playwright or PyAutoGUI script	Multi-step flows with loops, conditions and DOM access
computer tool	Batched click, type, scroll and screenshot actions	Harnesses that expect structured input events
Your own UI tools (function calling or remote MCP)	Calls to operations you define, such as a locator-based click	Teams that already expose browser operations as tools

What GPT-6 Astra adds to computer use

OpenAI describes GPT-6 Astra as having state-of-the-art performance in computer use, browsing and professional work, and lists computer_use among its supported Responses API tools. Reasoning effort runs from low to max; there is no none. The 3 September changelog also notes that Astra tool calling requires the Responses API, so a Chat Completions harness has to move before it can use the model at all. If you are still weighing Astra against a cheaper model for this work, our comparison of GPT-6 Astra vs GPT-5.6 sets out the per-token gap.

OpenAI computer use pricing: you pay for screenshots, repeatedly

OpenAI computer use pricing is token pricing. The tools table on the pricing page lists fees for web search, file search and hosted containers, but no per-call fee for computer use as of 21 September 2026, and the page states that tokens used by built-in tools are billed at the model's rates. The cost driver is therefore the screenshot, and how many times you resend it.

OpenAI's vision guide explains that images are tokenized in 32 × 32 pixel patches with a 1.2 multiplier for gpt-6-astra, and recommends detail: "original" for computer use. Take the 1440 × 900 viewport used in OpenAI's own Playwright example:

1. Patches: ceil(1440 / 32) × ceil(900 / 32) = 45 × 29 = 1,305.
2. Billable image tokens: ceil(1,305 × 1.2) = 1,566.
3. At Astra's $10 per million input tokens, one screenshot costs about $0.0157 the first time it is sent.

The multiplier that matters is the loop. OpenAI's conversation-state guide says that all previous input tokens in a previous_response_id chain are billed as input. Assume a 20-turn run with one new screenshot per turn and ignore text, reasoning and output tokens. Turn n carries n screenshots, so the run bills 1,566 × (1 + 2 + … + 20) = 1,566 × 210 = 328,860 image tokens, or about $3.29 uncached.

Prompt caching changes that sharply. Astra's cached input is $1 per million tokens. If every earlier screenshot hits the cache, only the 20 new screenshots (31,320 tokens, about $0.31) pay full price, and the 297,540 repeated tokens cost about $0.30, so roughly $0.61 for the images. Real runs land between those bounds, plus reasoning and output tokens at $50 per million, which on a long task can outweigh the screenshots. Our post on prompt caching covers how to keep that prefix stable.

Where computer use beats a real API, and where it does not

Computer use wins when there is no API to call. OpenAI's guide frames the tool around filling out forms, testing user flows and completing tasks in applications through their UI. In the builds we run, that describes three situations: an internal legacy application whose only interface is its screens, a vendor or government portal that offers no integration, and a supplier system you do not control and cannot ask to change.

It loses whenever an API exists. A documented endpoint is deterministic, returns structured data, costs a fraction of a screenshot loop per call and leaves a clean audit trail. If the system has an API, or you own the system and can add one, our API development and integrations work is almost always the cheaper route over the life of the workflow.

Computer use vs RPA

The strongest case for RPA is predictability. A recorded bot follows the same selectors every run, costs nothing per execution beyond its licence and infrastructure, and an auditor can read exactly what it will do. Computer use gives up some of that: the model decides each step from what it sees, so two runs of the same task can take different paths.

What computer use buys in return is tolerance of change. It reads the screen rather than a stored selector, so a moved button or a renamed field does not have to break the flow, and it can handle a dialog nobody scripted. The code-execution path also narrows the gap, because the model is writing Playwright or PyAutoGUI code you can log, review and, for stable steps, keep as a fixed script.

Approach	Needs an API	Per-run cost	When the UI changes	Predictability
API integration	Yes	Lowest	Unaffected	High
RPA bot	No	Low, after licensing	Selectors break until someone re-records	High
OpenAI computer use	No	Tokens per screenshot and step	The model adapts from the screenshot	Lower; verify every outcome

This is the wrong choice if the task runs thousands of times a day against a stable screen: a script or an RPA bot will be cheaper and easier to audit. It is also the wrong choice as a permanent answer for a system you own. Computer use can bridge a legacy application while you replace it, but it is a bridge, and our legacy application modernization work usually ends with an API the automation can call directly.

How safe is AI computer use? OpenAI's required controls

OpenAI's guide is direct that computer use can affect real accounts and data, and it lists four controls to apply in your application and execution environment, not just in the prompt:

• Restrict the environment. An isolated browser or VM, with an allow list of sites and actions.
• Treat screen content as untrusted. Text on a page cannot grant permission or override the user.
• Confirm consequential actions. Purchases, data transmission and destructive changes stay with the user; typing sensitive data into a form counts as transmission.
• Bound and verify the run. Step, time or cost limits, cancellation, and a check of the actual outcome rather than the model's final answer.

The integration recipes go further and grade actions. The user must take over for the final step of changing a password or for bypassing an HTTPS warning. The agent must confirm at action time before deleting data, changing permissions or API keys, solving CAPTCHAs, sending or submitting anything on the user's behalf, or confirming a financial transaction. Logging in or uploading files can proceed on pre-approval only if the initial prompt explicitly allows it.

The same page makes a point that matters for code execution: a single script can perform many actions, so permissions have to be enforced in the exposed helpers and runtime, not checked once per tool call. The model's request to act is not user permission. We treat the sandbox itself with the same suspicion; our write-up on AI agent sandbox escapes covers why the isolation layer deserves its own review.

Misalignment monitoring is a backstop, not a control

GPT-6 Astra requests are also covered by OpenAI's misalignment monitoring, which reviews reasoning and actions asynchronously in consequential contexts such as transferring sensitive data or making destructive changes. When it blocks a request, the API returns HTTP 403 with the code misalignment_policy_violation, and there is no general way to resume that conversation. Because the check is asynchronous, an action may already have completed, and a stopped request does not undo it. Build your handler for that error before go-live, and do not treat monitoring as a substitute for your own confirmations.

Before an agent touches production

If you built on the old preview, note that computer-use-preview was shut down on 23 July 2026. The general-availability tool replaces the single action per call with a batched actions array and no longer needs truncation: "auto", so the action handler needs rework, not just a model rename.

For a new build, this is the order we work in:

1. Stand up the environment first: a container or VM per run, a domain allow list, and no credentials the task does not need.
2. Put the permission layer in the runtime helpers, with the confirm-at-action-time list above encoded as rules.
3. Cap steps, wall-clock time and spend per run, and support cancellation.
4. Verify the result against the target system, not the model's summary, and log every script, action and screenshot.
5. Handle misalignment_policy_violation as a stop-and-review event with a named human owner.

The decision in front of most teams is narrower than whether computer use works. It is whether the system you want to automate will ever have an API. If it will, build the API. If it never will, a sandboxed computer use loop with hard confirmations is now a credible way to automate it, and the screenshot arithmetic above tells you what each run will cost before you commit.