Compare
How OpenAdapt compares
Start with the failure mode nobody in this category publishes a number for. Every self-healing replay tool — record a workflow, replay it, let it repair itself when the UI moves — can resolve the wrong on-screen target under data drift, act on it, and report success. In an EMR that is a note saved to the wrong patient's chart, with a green checkmark. The tools verify that something saved; almost none verify whose record it landed in. So we built the harness that measures it, red-teamed our own engine five times until it stopped, and pointed the same harness at shipping competitors. That measurement — not speed — is how we think this comparison should be led.
There are three common ways to automate desktop work today: traditional RPA platforms, AI agents that operate a computer with a large model, and browser recording tools. OpenAdapt takes a fourth approach. It compiles a recorded demonstration into a deterministic script that replays for free, heals itself when the UI drifts, and halts instead of guessing when it cannot verify the target's identity. Each approach wins somewhere, so here's the honest version — safety first, then cost and coverage.
The measurement
Silent wrong-action rate under UI drift
The single most dangerous thing a GUI replayer can do is the wrong write, silently. So we tried to make ours do exactly that. It reopened five times — pixel-lookalike rows, residue-blind coverage, near-name siblings (“Belford, Phil” vs “Belford, Philip”), a blind spot shared by our own test corpus and matcher, and an identifier letter/digit confusion (“A01234” vs “AO1234”). Each was fixed and pinned as a permanent test on a frozen, SHA-manifested held-out corpus (~6,900 pairs, committed before each fix).
0.000%
wrong-patient verify (false-accept) across the frozen corpus + 18 out-of-corpus probes
~26–28%
the honest cost: safe-halt rate on noisy identifier rows — a fallback or retry, never a wrong write
3/3 & 3/3
two shipping competitors silently wrote to the wrong patient under identity drift and reported success
Pointed at the category on the same task and drift, with a ground-truth check of which patient the note actually landed on: two self-healing tools whose replay path could run the task each wrote to the wrong patient in 3/3 row-identity drift modes and reported success. The gap is structural — their verification is conditioned on the goal, not on the recorded entity's identity. Total study spend: $0.94.
The honest exception, published against ourselves: on a stable browser DOM, an identity-keyed selector matches our safety (0 wrong-actions) and beats us on availability — while a positional selector wrote the wrong patient 8/8. The wrong-action vector is spec underspecification, and a demonstration captures target identity for free. That comparison exists only where a DOM does; on desktop, VDI, or Citrix there is no selector to write.
“Provably zero” is an asymptote — each of those five rounds began from a system we believed was correct. The product is not “we don't make mistakes”; it is measured, disclosed, and fail-closed, with the adversary log public. The open problems that remain — cosmetic zoom/display-scale drift is 0% replayability today, icon-only targets proceed flagged rather than verified, small sample sizes on the agent arms — are written down, not hidden.
Versus traditional RPA platforms
Platforms like UiPath, Automation Anywhere, and Blue Prism ask you to build the automation by hand. You author selectors, arrange flowcharts in a studio, and maintain both. Large enterprises run a lot of automation this way and it works, until the UI changes. A vendor ships an update, the selectors stop matching, and someone has to open the studio and repair the flow. Licensing is typically per robot or per seat, and the platforms are proprietary.
OpenAdapt skips the authoring step entirely. You record yourself doing the task once, and the compiler turns that demonstration into a script. When the UI drifts, OpenAdapt heals the script and proposes the fix as a reviewable diff, not a broken bot and a support ticket. It runs on your own machines and it's MIT-licensed open source.
Versus AI computer-use agents
Cloud agents in the OpenAI Operator and Claude computer-use family re-reason through your task with a large model on every single run. On tasks nobody has seen before, they're genuinely impressive. For repetitive work, though, re-reasoning is the wrong shape. Every run is slow. Every run can take a different path than the last. Every run is billed. And most of these services work by sending screenshots of your screen to the cloud.
OpenAdapt uses a model at compile time and at heal time, never on a healthy run. A healthy run is a deterministic local replay: same steps, same order, no model calls, no per-run bill. Your screen stays on your machines.
The support act: what repetition costs
We also measured it on a real EMR
With the safety story established above, here is the efficiency case. An 18-step add-patient-note workflow on the official OpenEMR public demo, run both ways and judged by one arm-independent OCR check, with a distinct parameterized note per run. Both arms succeeded every time: 20/20 compiled, 10/10 for a Claude computer-use agent. The agent doesn't fail here — the difference is what each run costs.
1.8× faster
median run: 39.2s compiled vs 70.4s agent
$0 vs $0.55
model cost per run, at list price
0 vs ~24
model calls per run
Run the task 500 times and the ratios compound: about $275 and ten hours of wall clock through the agent, versus $0 and about five and a half hours compiled, with every action auditable against the demonstrated script. The compiled arm's price of entry is a one-minute human demonstration; the agent needs only a prompt.
Caveats, disclosed up front: the OpenEMR demo is a shared public instance that anyone can modify and that resets daily, so this is a field result, not a CI-reproducible one. The agent arm is N=10 (agent runs cost real money and real load on a shared service), so its 100% carries wide error bars. One compiled run self-flagged postcondition drift on the final step and was verified saved by OCR; success is judged by the arm-independent check for both arms, never self-report. Results are pinned to claude-sonnet-5 with the computer_20251124 tool on 2026-07-08; newer models will differ. The OCR success check errs conservative on dense EMR text and is identical for both arms.
OpenEMR methodology and raw dataThe reproducible anchor
Because the OpenEMR numbers depend on a live shared instance, we keep the same head-to-head on MockMed, the demo clinic app that ships with openadapt-flow, as the benchmark anyone can rerun deterministically: 100 compiled replays against 20 agent runs, both arms 100%, 4.9s vs 37.5s median, $0 vs $0.27 per run at list price. Same orchestrator, same agent harness, same style of OCR check.
On the same harness under injected UI drift, a hybrid mode — compiled replay first, agent fallback only on a detected halt — matched agent reliability (20/20) at roughly one-eighth the agent's cost per successful run. Details and caveats (synthetic detected-halt drift, assumed drift mix) in the repo.
Versus browser recording tools
Tools like Skyvern and browser-use record or drive workflows inside the browser, using DOM selectors or model inference. If your whole workflow lives in a browser tab, they're worth a look. The limit is structural: browser-only tools can't reach the desktop EMR, the Windows loan origination system, or anything delivered over Citrix.
OpenAdapt works from pixels and inputs rather than the DOM, so the same approach extends past the browser to desktop applications and VDI/RDP sessions (adapters for these are in progress). Recording, compiling, and replaying all happen on your infrastructure.
Side by side
| OpenAdapt | Traditional RPA | Computer-use agents | Browser recorders | |
|---|---|---|---|---|
| How automations are built | Recorded demonstration, compiled into a script | Hand-authored selectors and flowcharts | A model re-reasons through the task on every run | Browser recording or a prompt |
| Cost per run | None on healthy runs (deterministic local replay) | Licensed per robot or per seat | Metered model calls on every run | Varies; cloud inference is metered |
| When the UI changes | Heals the script; fix arrives as a reviewable diff | Selectors break; someone repairs the flow by hand | The model may adapt, or may take a different path | DOM selectors break, or the model re-infers |
| Where it runs | Your machines | Your infrastructure or vendor cloud | Vendor cloud, with screenshots of your screen | The browser; often with a cloud backend |
| App coverage | Desktop, web, and VDI/RDP (vision-based; adapters in progress) | Desktop and web via connectors | Anything on screen | Browser only |
| License | MIT open source | Proprietary | Proprietary services | Varies; some open source |
Where agents beat us
We'd rather tell you this than have you find out mid-pilot. Computer-use agents are the better tool for novel one-off tasks, since compiling a demonstration is overhead when there's no second run. They win on tasks you can't demonstrate yourself, and on exploratory work like researching something across a dozen unfamiliar sites. OpenAdapt is built for the opposite case: work your team does the same way, over and over, where determinism and cost matter more than improvisation.
See it on your workflow
The fastest way to compare is to bring a real task. Book 15 minutes, or read the code first.