WindowsUIA · Cua · Win32First complete vertical slice
macOSAX · Cua · QuartzAccepted VM appliance
LinuxAT-SPI · Cua · WaylandAccepted VM appliance
Virtual machines · physical devices · one agent session
Let one coding agent test every platform you ship.
Build anywhere, then let the agent install, launch, inspect, and verify the real application across Windows, macOS, Linux, ChromeOS, iOS, and Android through one target-native interface.
- Desktop · mobile · ChromeOS
- VMs and physical hardware
- Native semantics and input
- Open source
release checkVM + physical
$ mc targets
windows vm ready
macos vm ready
linux vm ready
chromeos physical ready
ios physical ready
android physical ready
$ mc --target ios ios snapshot --interactive
provider XCTest
device physical
observation semantic + screenshotThe whole test lab
VMs when isolation matters. Physical devices when hardware matters.
A virtual machine is ideal for repeatable desktop builds and clean workspaces. A real Chromebook, iPhone, Android device, headset, or handheld exposes hardware, security, drivers, and lifecycle behavior that simulation cannot prove.
ChromeOSchrome.automation · CDP · native capture/inputWorking physical reference
iOSCoreDevice · XCTest · screenshots/actionsWorking physical-device route
AndroidADB · deploy · capture · input · logsWorking handheld foundation
Quest · Steam DeckDevice-specific native operationsWorking specialized routes
Why it exists
One development session for every app we ship.
At Graehl Arts, an agent can make a code change, send the build to the right VM or physical device, exercise the real application, and bring back evidence—without the developer juggling six separate consoles and tool vocabularies.
one agent session→WinMacLinuxChromeOSiOSAndroid
Visit Graehl Arts →JSTorrentShared TypeScript product across desktop, browser, Android, ChromeOS, and iOS.RSTorrentRust engine with maintained desktop, Android, and iOS clients.AtpianoNative macOS and Windows application packaging and UI workflows.200 OK Web ServerCross-platform web-server application for desktop, Android, and ChromeOS.
One workflow, native controls
The interface is shared. The platform stays real.
Machine Control normalizes target selection, observations, actions, and results without pretending that every operating system works the same way.
CALLERCoding agentbuild · deploy · test
COMMON INTERFACEMachine Controltarget · claim · observe · act
Desktop VMsWindows · macOS · Linux
ChromeOSphysical · target-native
DevicesiOS · Android · Quest
RESULTactual route · delivery · effect · evidence · uncertainty
A release loop one agent can finish
Build once. Visit every target. Come back with evidence.
The coding session does not end when compilation succeeds. The same agent can move through the configured lab and finish the platform work on each real target.
- Choose a target
Find the right VM or physical device and inspect its real capabilities.
- Reserve and prepare it
Claim an exact shared target or acquire an isolated workspace, then prove readiness.
- Install and launch
Send the build to the target and start the application in the real operating system.
- Inspect and exercise
Use semantic UI, screenshots, keyboard, pointer, and platform-native operations.
- Verify and release
Confirm the application effect, retain useful evidence, and cleanly release the target.
Context is part of the system
Send useful state, not an endless desktop stream.
Compact semantic projections keep stable roles, labels, values, bounds, and actions while filtering provider noise. Content digests let an unchanged observation return without repeating the element tree.
These are measured response bytes from current Windows fixtures, not a claim about exact model-token savings. A cross-provider token benchmark is planned.
Read the measurements →Calculatorresponse bytes
Settingsresponse bytes
Current evidence
Broad destination. Honest status.
Desktop VMs and physical devices have different maturity, but both are part of the product—not a future category bolted onto a desktop-only design.
TargetCurrent routeStatus
WindowsCommon desktop · UIA / Cua / Win32First complete vertical slice
macOSCommon desktop · AX / Quartz / CuaAccepted VM appliance
LinuxCommon desktop · AT-SPI / WaylandAccepted VM appliance
ChromeOSDesktop accessibility · CDP · native capture/inputWorking physical reference
iOSCoreDevice lifecycle · XCTest semantics/actionsWorking physical-device route
AndroidADB administration · deploy · capture/input/logsWorking handheld foundation
OtherQuest · Steam DeckWorking specialized native routes
“Accepted” means exercised against the repository’s conformance and real-application workflows. It is not a production support SLA.Full platform status →
Choosing the rest of the stack?See how Machine Control works alongside Playwright, Appium, Cua, and BrowserStack.
Open the comparison →Field notes
Why app-development agents need a machine layer.
The first project note explains why screenshots, native automation, VM lifecycle, and effect verification belong in one development loop—but not one lowest-common-denominator implementation.
Read the note →