Automation decision guide
OpenAdapt vs AutoHotkey
AutoHotkey is hard to beat for a quick Windows macro. A short script can send keys, click controls, remap input, and remove hours of personal repetition with almost no ceremony. OpenAdapt is for the point where that macro becomes shared operational software and a wrong result matters.
The companion article traces the maintenance and failure costs in more detail. Read the comparison article.
Side by side on the dimensions that matter
Every claim below names its public source. If a vendor doesn't publish a figure, we don't invent one.
Determinism when interfaces drift
OpenAdapt
A compiled workflow resolves targets from retained evidence and halts or proposes a reviewable repair when the interface leaves its contract.
AutoHotkey
An AutoHotkey script deterministically sends the commands its author wrote. Coordinate and active-window macros can break under layout changes; control-oriented scripts can be more stable when the application exposes useful controls.
Source: AutoHotkey Send · AutoHotkey ControlClick · AutoHotkey ControlSend · OpenAdapt method
Cost per run
OpenAdapt
The MIT local runtime has no per-run license fee, and a healthy compiled run makes no model call.
AutoHotkey
AutoHotkey is free and open source. A normal local macro has no per-run license fee and makes no model call.
Source: AutoHotkey license · OpenAdapt MIT license · OpenAdapt method
Verification of business effects
OpenAdapt
A consequential run returns VERIFIED only after an independent check proves the intended change in the system of record. The check may use a read-only API, a database query, a file check, a second session, or reacquiring the persisted state.
AutoHotkey
AutoHotkey can read text from a window control. The author must build any business-level read-back, file check, database query, or other effect oracle.
Source: AutoHotkey ControlGetText · OpenAdapt effect-verifier kit
Halting behavior
OpenAdapt
Identity, target, policy, and effect checks define explicit halt conditions, and uncertain delivery is preserved for reconciliation.
AutoHotkey
The script decides when to stop. WinWait can pause until a matching window exists, but the author still defines every business stop and reconciliation rule.
Source: AutoHotkey WinWait · OpenAdapt execution outcomes
Data locality
OpenAdapt
Recordings, compiled bundles, and run evidence can stay in a customer-controlled boundary.
AutoHotkey
AutoHotkey runs on the Windows machine. Data stays local unless the script sends it to another service.
Source: AutoHotkey overview · OpenAdapt trust center
Scope: browser, desktop, RDP/Citrix
OpenAdapt
The runtime covers browser, native desktop, and customer-qualified remote-window workflows, with current scope bound to published qualification evidence.
AutoHotkey
AutoHotkey targets Windows input, windows, and controls. It can drive whatever is visible to that Windows session, but remote and browser semantics remain the script author's responsibility.
Source: AutoHotkey ControlClick · OpenAdapt qualification evidence
Published figures about AutoHotkey that we cite
- Send can simulate keystrokes and mouse clicks in the active window.
Source: AutoHotkey Send
- ControlClick can target a window control without relying only on the current pointer position.
Source: AutoHotkey ControlClick
- Small hotkey, remapping, and text-expansion scripts are quick to write and easy for one operator to run.
Source: AutoHotkey quick reference
- The runtime is free, open source, and local to Windows.
Source: AutoHotkey license
Where AutoHotkey is strong
- Fast Windows hotkeys, text expansion, remapping, and desktop macros in small scripts.
- Direct control over keys, mouse input, windows, and many native controls.
- No service dependency and no model call is required to run a normal script.
- A very good fit for personal automation where the author is also the operator and maintainer.
What OpenAdapt does differently
Recording demonstrations, visual targeting, virtual desktop awareness, and selector repair are common. OpenAdapt binds independent effect verification and explicit outcomes to the workflow contract.
Independent business-effect verification
A run is judged by an out-of-band check of the system of record, such as a read-only API call, a SQL query, or re-reading the persisted record, not by the acting session declaring itself successful.
Explicit transaction outcomes
Every consequential run ends with a typed outcome and a preserved run report. VERIFIED requires independent proof. A refusal before actuation and uncertain delivery after possible actuation remain distinct, so an unconfirmed write cannot appear as success.
Deterministic healthy runs
A compiled workflow replays deterministically with zero model calls on healthy runs. Model spend is reserved for compilation and reviewable repair.
External zero-install remote lane
For managed Citrix, RDP, and VDI estates, OpenAdapt can drive the local client window from outside the session, so nothing is installed inside the remote environment. The lane is qualified today against a deterministic stand-in and a real FreeRDP round trip; a real ICA/HDX environment is qualified per customer before consequential use.
Customer-controlled sensitive data
Recordings, screenshots, and compiled bundles can stay inside your boundary. Local, self-hosted, and customer-controlled deployments are first-class, not an enterprise afterthought.
Open MIT local runtime
The compiler and governed runtime are MIT-licensed and inspectable. You can audit exactly what runs beside your systems of record.
Published qualification evidence
Each execution surface ships with bounded, published acceptance evidence, counted effects, refusals, and halts, instead of an unbounded compatibility claim.
Per-surface acceptance results are published in the qualification evidence.
Frequently asked questions
When should a personal macro become an OpenAdapt workflow?
The change makes sense when other people depend on it, failures become hard to see, the target drifts often, or a wrong business result costs more than a visible macro error.
Source: AutoHotkey quick reference · OpenAdapt effect-verifier kit
Which should you choose?
Choose AutoHotkey when
Choose AutoHotkey for a personal Windows shortcut, a compact macro, or a stable task whose occasional failure is easy for the operator to see and correct.
Choose OpenAdapt when
Choose OpenAdapt when several people rely on the workflow, authoring must begin with a demonstration, the target can drift, or every consequential run must end with preserved evidence and a typed transaction result.
AutoHotkey is open, local, deterministic, and cheap. OpenAdapt does not improve those traits. It adds a compiler, retained visual evidence, reviewable repair, qualification, and independent effect checks.
Test the difference on one real workflow.
Bring one repeated, consequential workflow and measure authoring time, run time, intervention rate, and incorrect-success rate against your current approach. Or watch the governed-execution demo first. It shows result checks and safe stops against the retained event evidence.