Claude Opus 4.7 computer use, without the screenshots

Terminator's MCP server, registered with one command: claude mcp add terminator "npx -y terminator-mcp-agent@latest". Once registered, Opus 4.7 sees 35 typed tools (click_element, type_into_element, press_key, scroll_element, set_value, validate_element, wait_for_element, navigate_browser, capture_screenshot, execute_sequence, and others) instead of one schema-less computer tool. Each tool resolves a selector against the OS accessibility tree (Windows UIA today, macOS AX in the core but not yet on the published binary) and returns a structured JSON result. The crucial flag is ui_diff_before_after: true on every action tool, which makes the response include the changed elements as compact YAML lines. Opus 4.7 reads that and picks the next tool without ever sending a screenshot.

Through the diff response. Terminator captures the UI tree before the action runs, captures it again after, computes the diff, and returns it inline as compact YAML. The format is defined in crates/terminator-mcp-agent/src/tree_formatter.rs at format_tree_as_compact_yaml around line 56. A typical diff looks like 'added: #1 [Window] Save As (focused, bounds: [800,400,600,420]) #2 [Button] Save (focusable)' and 'removed: #7 [MenuItem] Save As... (focused)'. The model has the role, accessible name, focused state, bounds, and a stable index for every element that changed. That is enough information to decide the next click. The screenshot loop exists because the native computer tool has no other channel to report state; the MCP server has the tree, so it does not need pixels.

Yes, by two mechanisms. First, image input drops out. Anthropic charges screenshots through standard vision pricing (per their computer use docs), and a 2576px long-edge image is roughly 3.75MP, which is a substantial input on every step. The MCP path returns a few hundred bytes of YAML instead. Second, the inner loop avoids round-trips. Each native computer use action requires the model to emit a click, your code to execute it, your code to take a fresh screenshot, and the screenshot to ride back to Anthropic. The MCP path runs the click-and-diff inside one tool result; UIA's IUIAutomationElement.FindFirst and InvokePattern.Invoke calls finish in microseconds. Opus 4.7's documented preference for fewer tool calls per turn at the default effort level lines up with this shape: the model thinks once, dispatches one tool, reads the diff, thinks again.

The compact YAML formatter assigns sequential indices (#1, #2, #3, ...) to every element with bounds, and stores a server-side cache of (index → role, name, bounds, selector) for the most recent tree. That is exactly what click_element's Index mode consumes. The model can call click_element with { "index": 5 } and Terminator looks up the cached element and clicks it. No coordinates emitted, no selector authored, no screenshot rendered. The Index mode is documented in server.rs at the click_element handler around line 2486 (Mode 2 - Index) and is what makes the tree-diff loop self-contained: the model gets indices on every diff, refers to them on the next call.

Three honest cases. One: fully custom-painted surfaces. Games rendered through Direct3D, Office canvases, terminal emulators with custom GPU compositors, and many CAD tools expose one opaque accessibility node for an entire surface. The tree has nothing useful; you need vision. Two: visual interpretation tasks. If the user asks 'is this chart trending up?' or 'is the photo upside down?' the model has to look at pixels. The tree carries no semantics about images. Three: web pages where the structural DOM is hostile (Cloudflare interstitials, single-page apps that route tooltips into a portal far from the visible parent). Terminator handles these by exposing capture_screenshot as one of the 35 MCP tools and by adding a vision_type parameter on click_element with values UiTree, Ocr, Omniparser, Gemini, and Dom. The right pattern is structural by default, vision by exception, with the agent making the choice per call.

Yes. They are not mutually exclusive: one is a built-in Anthropic tool, the other is an MCP server. You can register both. The pragmatic split is to give Opus 4.7 access to Terminator's selector-and-index tools as the primary surface, and keep computer_20251124 around for the cases the accessibility tree does not cover. Opus 4.7 picks per task. The cost shape changes accordingly: structural tools cost a few hundred input tokens per call; the computer tool's first invocation per session adds roughly 735 input tokens for the schema, plus vision pricing on every screenshot. If 90 percent of the work hits the tree, 90 percent of the cost moves off image input.

Opus 4.7 supports computer_20251124 (with beta header computer-use-2025-11-24). The newer schema introduces enable_zoom and a zoom action that takes a region [x1, y1, x2, y2] and returns that region at full resolution. Zoom is useful when you genuinely need pixels and want to keep input cost down. The older computer_20250124 still works with prior models but does not give Opus 4.7 anything it does not already get from the newer schema. If you choose the screenshot path, use computer_20251124. If you choose the MCP path, the version of computer_20251124 is irrelevant because you do not enable the tool.

The MCP path is Windows-only on the published binary today. Terminator's core Rust crate has the cross-platform AccessibilityEngine trait at crates/terminator/src/platforms/mod.rs line 86 with macOS AX scaffolding, but the main branch ends with a compile_error! at lines 319-320 stating 'Terminator only supports Windows'. The npm package terminator-mcp-agent ships a Windows binary. If you need Opus 4.7 driving macOS desktops without screenshots today, this is not the right tool yet. If you need macOS with screenshots, you can still use the native Anthropic computer tool and pair it with a thin click-by-coordinate executor like cliclick. Linux uses AT-SPI2 in the Rust core but is similarly not packaged as an MCP binary.

It is not about trust, it is about what the model is good at. Pixels are a noisy substrate for clicks: tooltips reflow, scroll bars introduce subpixel offsets, DPI scaling and theme changes shift everything by a few pixels. The model has to ground every step from raw pixels each time. The accessibility tree is what the OS itself uses to route assistive technology; it has stable role names (Button, Edit, Window), localized accessible names that survive theme changes, and a fixed parent-child structure. A model handed '#3 [Button] Save (focusable)' has unambiguous targeting. A model handed a 2576x1620 PNG has to find the Save button through computer vision every single step. The first failure mode is brittle clicks. The second failure mode is none.