frabonacci

i bought this for my girlfriend as an entrypoint laptop considering she is coming from Windows - and overall satisfied. the battery though could be improved especially considering for a couple of hundred bucks more we could have gotten a used macBook air

A few examples i'm excited about:

- Closing the coding feedback loop by having agents verify their own changes in a real app

- Automating repetitive workflows across apps that don't have good APIs

- Agents recording product demos of them using software. One compelling use case here: https://x.com/trycua/status/2047383207612645426

- Creating CLI and APIs for apps by reverse implementing their GUI, e.g. see: https://github.com/HKUDS/CLI-Anything

Nothing prevents using it as a general automation library.

If you want to use it directly as an automation framework, you can take a Swift dependency on 'CuaDriverCore': https://cua.ai/docs/cua-driver/guide/getting-started/swift-i...

Thanks! We haven't gone deep on Windows yet because we're still focused on polishing the macOS release. We want to go deeper on the Mac experience before going broader across platforms, and there are still a lot of features we want to ship and use cases we want to share.

really appreciate it. macOS has powerful primitives already, but they weren’t designed as one coherent agent API so you end up stitching together and hitting roadblocks. If Apple doesn't make this more first-class, Linux/Android-style environments may move faster because they’re easier to instrument. I think the OpenAI/Jony Ive AI hardware rumors are yet another signal that people may start building agent-native CUA devices instead of retrofitting agents onto existing desktops

Thanks for trying out Lume! We definitely haven't given up on the idea of sandboxing GUI agents in local macOS VMs. Cua Driver is aimed at a different use case though, letting coding agents and general agents use the Mac you're already on, asynchronously and in the background. That also makes the economics better since multiple agents can share the same machine instead of each needing its own VM

We don't have a specific testing framework yet. cua-driver is closer to an automation interface than a test runner. that said, you could definitely build one on top of it. For reference these are some of our integration tests: https://github.com/trycua/cua/tree/main/libs/cua-driver/Test...

One useful trick is to cua-driver 'launch_app' instead of the default 'open' or other osascript, since it can start the app without raising/focusing it, and the tests don't disturb your active desktop while they run

Thanks for starting that thread, I definitely drew some inspiration from it. But ultimately the secret sauce for the background click came from discovering yabai's window_manager_focus_window_without_raise https://github.com/asmvik/yabai/blob/f17ef88116b0d988b834bb2...

Fair criticism. We took a similar approach to established dev tools like Homebrew, with an anonymous, opt-out telemetry to understand install issues, crashes, and high-level usage. For cua-driver specifically, telemetry is limited to command/tool-level events and basic environment metadata. We don’t send screenshots, recordings, app contents, prompts, typed text, file paths, or tool arguments. That said, we should make the opt-out path clearer

what's even more alarming is how exploitable GitHub Trending itself is these days. you can get the star count to fork ratio right and you land on the front page, which then pulls in real organic stars

it reminds me of https://github.com/dockur/windows with its compose-style YAML over QEMU/KVM. The difference i'm seeing is scope: dockur ships curated OS images (Windows/macOS), while holos looks more like a generic single-host VM runner. Is that a fair read? also curious any plans to support running unattended processes for OS installs?

Thanks - trajectory export was key for us since most teams want both eval and training data.

On non-determinism: we actually handle this in two ways. For our simulated environments (HTML/JS apps like the Slack/CRM clones), we control the full render state so there's no variance from animations or loading states. For native OS environments, we use explicit state verification before scoring - the reward function waits for expected elements rather than racing against UI timing. Still not perfect, but it filters out most flaky failures.

Windows Arena specifically - we're focusing on common productivity flows (file management, browser tasks, Office workflows) rather than the edge cases you mentioned. UAC prompts and driver dialogs are exactly the hard mode scenarios that break most agents today. We're not claiming to solve those yet, but that's part of why we're open-sourcing this - want to build out more adversarial tasks with the community.

Fair point - we just open-sourced this so benchmark results are coming. We're already working with labs on evals, focusing on tasks that are more realistic than OSWorld/Windows Agent Arena and curated with actual workers. If you want to run your agent on it we'd love to include your results.

Hey visarga - I'm the founder of Cua, we might have met at the CUA ICML workshop? The OS-agnostic VNC approach of your benchmark is smart and would make integration easy. We're open to collaborating - want to shoot me an email at f@trycua.com?

The author's differential testing (2.3M random battles) is great as final validation, but the real lesson here is that modular testing should happen during the port, not after.

1. Port tests first - they become your contract 2. Run unit tests per module before moving on - catches issues like the "two different move structures" early 3. Integration tests at boundaries before proceeding 4. E2e/differential testing as final validation

When you can't read the target language, your test suite is your only reliable feedback. The debugging time spent on integration issues would've been caught earlier with progressive testing.

Fair point - both use VNC for unattended setup. The difference is implementation: Tart does it via a Packer plugin (Go), we built it natively in Swift with a customizable YAML schema that's less error-prone. User-facing difference is --unattended flag vs Packer workflow.

Thanks! On API call visibility - Lume's MCP interface doesn't expose outbound network traffic directly. It's focused on VM lifecycle (create, run, stop) and command execution, not network inspection.

For agent observability, we handle this at the Cua framework level rather than the VM level:

- Agent actions and tool calls are logged via our tracing integration (Laminar, OpenTelemetry) - You can see the full decision trace - what the agent saw, what it decided, what tools it invoked - For the "what HTTP requests actually went out" question, proxying is still the right approach. You could configure the VM's network to route through a transparent proxy, or set up mitmproxy inside the VM. We haven't built that into Lume itself since network inspection feels orthogonal to VM management.

That said, it's an interesting idea - exposing a proxy config option in Lume that automatically routes VM traffic through a capture layer. Would that be useful for your workflow?

MDM platforms can skip Setup Assistant, but they require the device to be pre-enrolled in Apple Business Manager before first boot - VMs can't be enrolled in ABM, so those hooks aren't available.

defaults write only works after you have shell access, which means Setup Assistant is already done.

There are tools that modify marker files like .AppleSetupDone via Recovery Mode, but that's mainly for bypassing MDM enrollment on physical Macs - you'd still need to create a valid user account with proper Directory Services entries, keychain, etc.

The VNC + OCR approach is less elegant but works reliably without needing to reverse-engineer macOS internals or rely on undocumented behaviors that might break between versions.

Good catches, thanks! Just updated the page:

Fixed the registry description—you're right, GHCR is an OCI registry. Both tools use OCI-compatible registries, we just default to GHCR/GCS.

Added licensing to the "when to choose" sections.

Thanks for the feedback! You're right that a proper comparison page beats hunting through GitHub issues.

We just put one together (with some help from Claude Code, naturally): https://cua.ai/docs/lume/guide/getting-started/comparison

Thanks! On graphics - currently it's paravirtualized via Apple's Virtualization Framework, so basic 2D acceleration but no GPU passthrough. Fine for desktop use, web browsing, coding, productivity apps. Wouldn't recommend it for anything GPU-intensive though.

Good news is there are hints of GPU passthrough coming (_VZPCIDeviceConfiguration symbol appeared in Tahoe's Virtualization framework), so that might land in a future macOS release. We're keeping an eye on it.

Nice, thanks for sharing! It'd be interesting to integrate MIST into lume's ipsw command - right now Apple's native features in Apple Vz only provides download links for the latest supported version of the host, so grabbing older versions requires workarounds like this.

Both use Apple's Virtualization Framework, so core VM performance is similar. Main differences are around agent-first design (HTTP API, MCP server), unattended setup via VNC + OCR, and registry support for VM images.

We've also built a broader ecosystem on top - the Cua computer and agent framework for building computer-use agents: https://cua.ai/docs

We went through the comparison with Tart, Lima etc here: https://github.com/trycua/cua/issues/10

Yeah, Apple intentionally provides no unattended setup. Plus any process trying to control the UI programmatically needs explicit accessibility permissions, which defeats the purpose.

So we just click through like a human would via VNC. Version-specific but works with their security model rather than against it.

We haven't observed any networking degradation with Lume on Tahoe so far - things have been working smoothly in our testing. Give it a try and let us know if you run into any issues!

Correct, Containerization APIs are Linux VMs specific.

There's a kernel-level check in the Hypervisor framework that enforces the 2 VM limit, and bypassing it violates Apple's EULA.

Nice technical deep-dive on the how here: https://khronokernel.com/macos/2023/08/08/AS-VM.html

LoganDark is right. I've personally never tried, and don't think it'd be easy for any macOS predating Apple Virtualization Framework. For that you'd need something like UTM since they're relying on QEMU - these configs might help: https://github.com/adespoton/utmconfigs

re: unattended setup.

You're both right - Apple's official zero-touch setup requires MDM + DEP, which needs Apple Business Manager (and yes, a DUNS number).

But for VMs specifically, DEP doesn't work anyway - VMs don't have real serial numbers that can be enrolled in Device Enrollment Program.

VNC-based setup automation is the only practical option - it's what the ecosystem has converged on for macOS VMs. Lume connects to the VM's VNC server and programmatically tabs, clicks, types through Setup Assistant.

re: https://github.com/dockur/macos

A closer comparison here is Lumier, which provides a "Docker-like" interface to spin up VMs with a noVNC server: https://cua.ai/docs/lume/guide/advanced/lumier/docker

The key difference: dockur/macos uses QEMU+KVM, which only works on Linux hosts. It can't run on macOS hardware since Apple doesn't expose KVM. See: https://github.com/dockur/macos/issues/256

Docker on Mac runs Linux containers inside a Linux VM - you can't run macOS in Docker. So if you need Claude / Codex / OpenCode to interact with:

- macOS GUI apps (Xcode, Numbers, Safari, etc.) - macOS desktop automation (screenshots, mouse/keyboard input, accessibility APIs) - macOS CI/CD (building iOS/macOS apps, running XCTest)

...you need an actual macOS VM, which is what Lume provides.