Claude Opus 4.7 desktop automation

What actually changed in Opus 4.7

Anthropic's release notes for 4.7 highlight coding and vision wins. For anyone building a desktop automation agent, three of the changes matter more than the rest, and they interact.

The pixel-side improvements (2576px input, 1:1 coordinates) make screenshot-driven clicks finally tractable. A 1080p screenshot fits without aggressive downscaling, and you no longer translate model coordinates back to your actual screen. So if you choose Path A, the screenshot loop is now smoother than it has ever been on a Claude model.

But the planning-side change is the one that flips the strategy. Lower default tool-call frequency means Opus 4.7, left to its own taste, will not happily emit thirty left_click events in sequence. It would rather think once and act once. If your tool surface is just screenshot and click(x,y), that preference works against you. If your tool surface includes a single tool that accepts a typed multi-step workflow, that preference works for you.

Path A vs Path B, in code

Both paths are real and supported. The shape of what Opus 4.7 emits is what differs.

// Opus 4.7 with Anthropic's built-in computer-use tool.
// Model sees a screenshot, picks pixels, returns this JSON.
// You implement the screenshot capture and the click.
// Opus 4.7 specific: image input ceiling is 2576px / 3.75MP
// (4.6 was 1568px / 1.15MP) and coordinates are 1:1 with
// actual pixels, no scale-factor math.

{
  "type": "tool_use",
  "name": "computer",
  "input": {
    "action": "left_click",
    "coordinate": [487, 341]
  }
}

// Cost shape: one model inference per click.
// Latency shape: roundtrip the screenshot every step.
// Failure shape: a tooltip or modal moves the pixel,
// the next click misses, you replay from scratch.

Path A asks the model to be a vision system. Every click costs one screenshot upload and one round-trip. The model has to decide where the button is in pixels, every time the layout shifts. Path B asks the model to be a planner. The selector role:Button && name:Save is resolved locally by the MCP server against the live UIA tree on Windows or AX tree on macOS, in microseconds, without the model in the loop.

Wire it up in one command

Terminator publishes its MCP server on npm as terminator-mcp-agent. The Claude Code, Cursor, and Windsurf clients all support the same registration command.

After registration, Opus 4.7 sees the 35 tools as ordinary tool definitions. There is no special prompting required. The model picks the tool whose schema matches the task; the server resolves selectors and runs the action; the result comes back as structured JSON that Opus reads on its next turn.

The execute_sequence shape

Of the 35 tools in the MCP server, one is the reason Opus 4.7's "fewer tool calls" default becomes an advantage rather than a problem. execute_sequence, defined at crates/terminator-mcp-agent/src/server.rs:7549, accepts a whole typed workflow inside a single tool call: variables, named selectors, an ordered list of steps, retries per step, fallback branches via fallback_id, conditional jumps based on prior step status, and an optional output parser written as JavaScript.

// One MCP call. The whole workflow inside.
// crates/terminator-mcp-agent/src/server.rs:7549

{
  "name": "execute_sequence",
  "input": {
    "variables": {
      "report_path": { "type": "string", "default": "report.xlsx" }
    },
    "selectors": {
      "calc_window": "role:Window && name:Calculator",
      "btn_equals":  "role:Button && name:Equals"
    },
    "steps": [
      { "tool_name": "open_application",
        "arguments": { "path": "calc.exe" }, "id": "launch" },
      { "tool_name": "type_into_element",
        "arguments": { "selector": "${{selectors.calc_window}}",
                       "text_to_type": "42" },
        "retries": 2,
        "fallback_id": "recover_focus" },
      { "tool_name": "click_element",
        "arguments": { "selector": "${{selectors.btn_equals}}" },
        "jumps": [
          { "if": "click_element_status == 'success'",
            "to_id": "capture" }
        ]},
      { "tool_name": "wait_for_element", "id": "capture",
        "arguments": { "selector": "${{selectors.calc_window}}",
                       "condition": "exists",
                       "include_tree": true } }
    ],
    "troubleshooting": [
      { "tool_name": "activate_element", "id": "recover_focus",
        "arguments": { "selector": "${{selectors.calc_window}}" } }
    ]
  }
}

// Opus 4.7 emits this once.
// The MCP server runs every step locally with no model in
// the inner loop. If a step fails, the troubleshooting
// branch fires. Output is structured JSON.

One model inference. The server walks the steps. If type_into_element fails twice, the engine jumps to recover_focus in the troubleshooting block and retries. The model only re-enters the loop when the whole sequence finishes or hits an unrecoverable state.

What that looks like as a sequence

The contrast with the per-click loop is sharpest when you draw it.

When to still use the screenshot path

Path B is not a moral position. There are real cases where Path A wins. Custom-rendered Electron surfaces, canvas-heavy editors, and games expose almost nothing useful through accessibility APIs; their entire UI is a single opaque element with no labels. Opus 4.7's higher-resolution input and 1:1 coordinates are exactly what you want there. Terminator includes capture_screenshot as one of its 35 tools precisely so Opus 4.7 can fall back to vision when the tree is empty.

The healthy split: use validate_element to check whether the accessibility tree exposes what you need. If yes, structural tools. If no, screenshot plus 1:1 click. Opus 4.7 is good enough at routing this decision that you can leave it to the model rather than hardcoding the split.

Numbers that fit on one row

A practical recipe

If you are starting today, the configuration that gets the most out of Opus 4.7 looks like this. Run the model at xhigh effort for the agentic outer loop, since Anthropic explicitly recommends xhigh for coding and agent work and you want the model to reason hard before dispatching a workflow. Register Terminator's MCP server as the single source of desktop tools. Lean on execute_sequence for any task that has more than two structural steps; reserve direct per-tool calls for short interactive sessions and recovery paths. Keep the computer tool available as an escape hatch for surfaces with no accessibility metadata.

The mental model: Opus 4.7 is the planner; Terminator is the operator. The model reasons, compiles a workflow, and steps back. The MCP server runs the workflow. Failures bounce back to the model only when the troubleshooting branch cannot recover. That is the agent shape Opus 4.7's defaults were tuned for.

FAQ