Accessibility API for AI agents: diff the tree, don't re-read it.

Two things a vision model has to reconstruct from pixels. First, the role of every element (Button, ComboBox, Edit, MenuItem, ListItem) as the OS itself classifies it, not as a CNN guesses. Second, a stable selector grammar (role + name + window + AutomationId) that the agent can call back to in the next step without re-finding the element by visual coordinates. On Windows that comes from UIAutomation. On macOS it's AXUIElement. On Linux it's AT-SPI2. The agent's job changes from 'where is the Save button at this DPI' to 'invoke the element whose role is Button and whose name is Save.'

Because they re-read the full tree after every action. A medium-complexity desktop window (Outlook compose, a Salesforce browser tab, a Jira backlog) renders 800 to 4,000 elements in its UIA tree. Serialized as YAML that's roughly 30,000 to 120,000 input tokens. If the agent calls 20 tools to finish a task, the model has now seen the same tree 20 times, with most attributes identical. The token bill scales with steps, the latency scales with steps, and the model gets confused by what changed because nothing is highlighted. The fix is not 'use a smaller tree,' it's 'send a diff.'

crates/terminator/src/ui_tree_diff.rs. The function `simple_ui_tree_diff` at line 58 takes the before-tree and after-tree as strings, detects whether they're JSON or compact YAML, and runs them through `remove_ids_and_bounds_from_compact_yaml` (lines 40-50) or `preprocess_tree` (lines 26-35). The YAML path uses two regexes: ` #[\w\-]+` to strip indices like `#12345` and `#abc-def`, and `bounds: \[[^\]]+\],?\s*` to strip bounding-rectangle blocks. The JSON path walks the value tree and drops `id` and `element_id` keys recursively. Then it calls `TextDiff::from_lines` from the `similar` crate (line 81) and emits only `+` (insert) and `-` (delete) lines. Equal lines are skipped. If nothing changed, it returns `Ok(None)` and the model sees no tree at all that turn.

Twenty of them, including click_element, type_into_element, press_key, press_key_global, mouse_drag, scroll_element, select_option, set_selected, set_value, invoke_element, navigate_browser, open_application, activate_element, validate_element, wait_for_element, execute_browser_script, capture_screenshot, run_command, and the meta-tool execute_sequence. Every action tool that mutates UI state takes the parameter. The tool captures a tree snapshot before it fires the action, performs the action, captures another snapshot, runs `simple_ui_tree_diff`, and includes the diff in the tool result. That removes a whole class of agent calls (the explicit get_window_tree after every action) and is exactly what the description on get_window_tree itself warns about: 'Do NOT call after action tools - use their ui_diff_before_after/include_tree_after_action params instead.'

Compact YAML, not raw UIA serialization. crates/terminator/src/tree_formatter.rs::format_tree_as_compact_yaml emits one element per line in the form `#1 [ROLE] name (bounds: [x,y,w,h], focusable, focused, selected, value: ...)`. Children are indented two spaces. Elements with bounds get a 1-based clickable index; elements without bounds get a `- [ROLE]` dash prefix. State flags are only included when true (`focused`, `selected`, `toggled`, `disabled`). This format is denser than UIA's native XML by an order of magnitude, and the regex-based strip in ui_tree_diff.rs is designed to operate on exactly this shape.

Because both are volatile across a single application's run. `AutomationId` is generated per-instance for many WinUI, WPF, and Electron controls; the same Save button gets a new id every render pass. `bounds` shifts whenever the window is resized, scrolled, or DPI-changed, even when nothing semantically changed. If you don't strip these, every action looks like a 200-line diff because the layout reflowed. After the strip, the diff is exactly the elements that appeared, disappeared, or had a name, role, or state change. That's what the agent actually needs to reason about.

Take a 20-step automation that opens Outlook, drafts a reply, attaches a file, and sends it. The Outlook compose window's UIA tree is roughly 900 elements. In compact YAML that's about 24,000 tokens. Naive loop: send the full tree before step 1 and after each of 20 actions. Total: 21 * 24,000 = 504,000 tokens of tree input. Delta loop: send the full tree once, then 20 deltas of typically 5 to 30 lines each (~200 tokens). Total: 24,000 + 20 * 200 = 28,000 tokens of tree input. The agent does the same task with about 5% of the input cost on the tree side, and the model is no longer drowning in unchanged context.

Both. UIA exposes Chrome, Edge, and Firefox windows as accessibility trees, so the same `get_window_tree(process: 'chrome')` returns a tree the diff can run on. For richer DOM data, set `include_browser_dom: true` and you get the DOM merged with the UIA tree, prefixed with `#d` for DOM elements and `#u` for UIA elements (see ElementSource in tree_formatter.rs lines 41-79). The Chrome extension Terminator ships does the bridging. The diff treats both source prefixes the same — they're just lines.

Pass `include_tree_after_action: true` instead of `ui_diff_before_after: true`. The action tools accept either. Use the full tree when the action triggered a navigation or a window switch and you genuinely want the agent to re-orient. Use the diff for incremental changes within the same window. Mixing both during a workflow is fine; both branches share the same `format_tree_as_compact_yaml` pipeline so the agent doesn't see a different schema between turns.

Different input, different loop, different cost curve. Screenshot agents send images to a vision model on every step; the model burns tokens on layout it already knows and re-derives selectors that are not stable across renders. Terminator sends a structured tree once and a delta after each action, so the model can plan with cheap, fully-described elements and call back to them by selector. Vision is still available (`include_gemini_vision: true`, `include_omniparser: true`, OCR via `include_ocr: true`) for the cases where an app has no accessible surface, but it's a fallback, not the default. The deterministic outcome that Terminator advertises (>95% success rate at CPU speed) comes from the accessibility-tree-plus-delta path being the primary route.