Terminator: a Windows-only computer use layer built around recorded workflows

The problem Terminator targets: desktop control without a screen-scraping loop

Most computer use tooling drives a machine the way a person does, by looking at pixels and deciding where to click. Terminator takes a different position. The README states that the project pre-trains workflows as deterministic code and calls AI only when recovery is needed. That single sentence explains the architecture and the cost model at once. The expensive part of a desktop automation run, in tokens and latency, is the model deciding what to do next. If a workflow has already been recorded, that decision has been made once and stored. The model becomes an exception handler rather than the driver. The audience follows from this. It is aimed at developers who want to script Windows applications from an AI assistant, and at teams that have repeatable back-office processes and do not want to maintain a fleet of Windows VMs by hand. The README lists example tasks: creating a GCP instance and connecting over CLI, reading Vercel logs to find the most common errors, testing app features based on recent commits. These are developer-adjacent chores, not consumer automation.

Element locators, the Accessibility tree, and why the browser extension matters

The feature table names three inputs: pixels, DOM and the Accessibility tree. Element locators find targets by name, role, window and similar attributes, and the core UI actions click and type operate on those located elements. This is the mechanism that separates Terminator from coordinate-based clicking. A locator survives a window moving or a layout shifting by a few pixels; a stored coordinate does not. The trade-off is direct: locator-based automation only works where an accessibility tree exists and is populated. Custom-drawn controls, canvas-rendered interfaces and older applications that expose little to Windows accessibility APIs will not offer name or role to match against, and the pixel path is the fallback. Browser automation is handled separately, through a Chrome extension that the README says enables browser control. That is a real dependency, not an implementation detail. If the extension is not installed or is blocked by policy, the browser dimension is unavailable and you are back to whatever the desktop accessibility tree exposes for the browser window itself. The README also claims a browser session is reused, so cookies and authentication carry over and no re-login is needed.

Installing the MCP agent: the actual commands and config keys

For Claude Code the README gives a single command: claude mcp add terminator "npx -y terminator-mcp-agent@latest". For Cursor, VS Code, Windsurf and other MCP clients, you add an entry to the MCP config file. The README's example uses the key mcpServers with a server named terminator-mcp-agent, command npx, args ["-y", "terminator-mcp-agent@latest"], and an env block containing LOG_LEVEL set to info and RUST_BACKTRACE set to 1. Both env keys are diagnostic rather than functional: LOG_LEVEL controls verbosity and RUST_BACKTRACE enables Rust stack traces when something panics. There are also one-click install badges for Cursor, VS Code and VS Code Insiders that point at the same npx invocation. Beyond the MCP path, the README lists two libraries: a Python package installed with pip install terminator, marked Partial for Windows, and a TypeScript package installed with npm i @mediar-ai/terminator, marked Yes for Windows. There is also a Windows binary download hosted on Crabnebula, and a separate Mediar IDE described as Cursor for Windows automation, which the README says entered public access on 01/09/26. Note the distinction: the IDE and the MCP agent are different entry points to the same underlying project.

Workflow recording is the load-bearing feature, and it is Windows-only

The README describes workflow recording as capturing human workflows for deterministic automation, and a release note from 08/25 mentions OS event recording that generates YAML through the MCP server. That is the pipeline that makes the deterministic-execution claim possible: a person performs the task once, the recorder captures the OS events, and the output becomes a workflow file rather than a prompt. The same release note mentions a NodeJS SDK in YAML workflows and the ability to run JavaScript in a browser. What the material does not describe is how a recorded workflow is versioned, reviewed or diffed when the target application changes. That gap matters more than it looks. A recorded workflow is a snapshot of a UI, and UIs change. The README's answer is the AI recovery path, but recovery quality depends on the locator still resolving or the model being able to re-plan from a screenshot. If an application ships a redesign that renames every control, the recorder output may need re-recording rather than editing. Treat recorded workflows as artifacts with a maintenance cost, not as write-once scripts.

The Windows-only constraint is the first thing to check

The README is unusually direct: Terminator currently supports Windows only, and macOS and Linux are not supported. The feature table reinforces it, marking every row No for macOS and Linux, with one exception in the other direction: Python support on Windows is Partial rather than Yes. The macOS entry point that exists is a hosted web app at app.mediar.ai, not the local project. So a team with mixed workstations cannot standardise on Terminator across the fleet. There is a second constraint hidden in the README's own framing. The pitch about running faster and more reliably than model-driven agents rests on determinism, and determinism rests on recorded workflows. If your task is genuinely one-off, or varies enough that recording it is not worth the effort, you are using the recovery path as the primary path, which is the expensive mode the project is designed to avoid. The README's own use cases are instructive here: checking Vercel logs, testing recent commits. Those recur. A task you will run once is a poor fit for a recorder.

Where Playwright is the better answer

Playwright is the natural comparison, and the README invites it by describing Terminator as playwright for windows computer use. The difference in approach is scope of control. Playwright drives a browser through its own automation protocol, with no accessibility tree dependency, no screen capture and no OS-level input. It runs headless on Linux CI, which Terminator cannot, and its selectors are DOM-native rather than resolved through Windows accessibility APIs. If your task lives entirely inside a web application and you control the codebase, Playwright is the smaller, more portable tool and it will run in your existing pipeline. Terminator's advantage appears when the task crosses application boundaries, or when the application is a native Windows program with no web equivalent. The README's GCP example is exactly that shape: create an instance, then connect over a CLI. A browser-only tool cannot do the second half. The honest framing is that these are not substitutes. Choosing Terminator for a pure web task means taking on a Windows-only runtime, a Chrome extension dependency and a recorder workflow for something Playwright does with a package install.

Licence, release cadence and what maintenance looks like

Terminator is MIT-licensed, and the README states the consequence plainly: fork it, ship it, no lock-in. That is the whole of the licence picture from the supplied material, and it is the permissive end of the spectrum, but you should read the actual LICENSE file and your own organisation's policy rather than treat a one-line summary as sufficient. On cadence, the release history shows v0.24.32 on 2026-04-05, v0.24.31 on 2026-04-02, and v0.24.30 on 2026-03-17, with the last push to the repository on 2026-06-02. The version numbers sit below 1.0, which in practice means the API surface can change between minor releases. The MCP config pins terminator-mcp-agent@latest, so every client restart can pull a different build. If you need reproducibility, replace latest with an explicit version in the args array. The crates are published separately as terminator-rs and terminator-workflow-recorder, so a Rust consumer has two dependency surfaces to track rather than one. There is also a commercial layer alongside the open source project: managed hosting and a workflow builder at mediar.ai, and the Mediar IDE download. The README does not describe how the hosted product and the MIT core diverge, so if you plan to rely on the hosted path, confirm what is covered before you build on it.

Editorial conclusion

Adopt Terminator if your automation targets Windows desktops and you already drive an MCP client such as Claude Code or Cursor, because the install is one command and the licence is MIT with no lock-in. Do not adopt it if any part of the workflow runs on macOS or Linux: the feature table marks every capability as No outside Windows, and Python support is listed as Partial. Before committing, verify two things on your own machine: that the Accessibility tree exposes the controls you need, since element locators depend on name, role and window attributes being present, and that the browser extension installs cleanly in whatever Chrome build your environment uses, because browser automation is gated on it.

Official sources

1. License: MIT
2. mediar-ai/terminator on GitHub
3. Project website
4. README
5. Releases