Anthropic's current computer-use toolset can return several member tool calls in one model turn. Its documentation calls this a batch action. The application must run the calls in order because a later action can depend on the screen state created by an earlier one.
OpenAI's computer tool uses a similar shape. One computer_call can contain an ordered actions array. OpenAI tells the application to execute permitted actions in order, capture the updated screen, and return that observation. A call marked completed means the model finished generating it. The interface has not moved until the application executes it.
A batch is a route, not a transaction.
Failure leaves a real prefix
Suppose a batch asks the runner to focus a field, type a value, and take a screenshot. Focus succeeds. Typing fails because the window changes. The runner cannot pretend that nothing happened. The field may still hold focus, a menu may have opened, or a previous value may have been selected.
Anthropic's contract is explicit. Stop at the first failure. Return a normal result for each successful action. Return an error for the failed action. Return an error for every later action to say it was not executed. Every requested block still needs an answer.
The observation closes the loop
The next screenshot is not decoration. It is the evidence needed to plan from the state that now exists. OpenAI recommends a screenshot after a short group of actions. Anthropic notes that batches often end with one, and allows the application to attach one when they do not.
This matters because desktop state is unstable. GitHub's current computer-use documentation warns that timing and window changes can produce different results, repeat an action, or stop progress. GitHub also recommends a direct API, terminal command, filesystem tool, MCP server, or dedicated browser tool when one exists. Structured routes reduce the amount of state that pixels have to carry.