Background computer use under interruption: Braus vs Cua

A background computer-use agent has two jobs: finish the task you gave it and let you continue yours. The interesting test starts when you type, switch apps or interrupt the agent halfway through a change.

Braus and Cua Driver both describe background operation on macOS. The question is how each behaves under those conditions, with the final app state and the person’s input measured independently.

Our published October 13 comparison includes foreground and cursor observations. It does not establish a winner for safe simultaneous typing or interruption recovery. This article separates those observations from the current designs and sets out the comparison we think background agents should face. It contains no new interruption benchmark results.

Compare the same kind of computer use

The scope here is Braus’s virtual desktop Driver and Cua Driver’s macOS background window control, on a person’s Mac. Cua’s wider platform includes other deployment options; those need separate comparisons. Braus’s Pro Tools integration also needs a separate test from a generic desktop driver.

An interruption benchmark should hold the task, target app, starting data, model and harness constant. It must also record the delivery route. A native app command, a browser-specific route and desktop input can all change the same field, but they exercise different mechanisms.

We covered the broader interface comparison in Braus vs Cua Driver: what your agent gets from the same Mac app. Here, the focus is what happens while the person keeps working and when the original plan stops being valid.

Both designs need evidence under real conditions

Braus: a virtual display in your Mac session

Braus’s desktop Driver moves target windows onto a virtual display. A cursor fence keeps the physical pointer out while held, and actions are bound to the observation used to choose them. The documented contract rules out an automatic fallback onto the person’s desktop or an automatic repeat of an action with an uncertain effect. These are design properties to test against, rather than a measured zero-interference result. See the Driver documentation.

The virtual display lives in the same Mac session. It is not another user account or an isolated filesystem. Work using that desktop takes turns between workers, and the physical display must stay awake. Native and web routes have their own ownership checks; they do not create another unrestricted desktop. The compatibility guide describes those boundaries.

Cua Driver: background window control

Cua’s current documentation describes window-targeted background control, including semantic and pixel routes. Foreground retry is explicit. It also distinguishes confirmed effects from uncertain outcomes. Its platform guide lists macOS limits, including some background scroll and drag cases. These documents were checked on October 22; they are separate from our historical measurements of Cua Driver 0.34.0.

That gives us a useful comparison: two background approaches, tested on the same work, with interruptions deliberately introduced. A moving cursor or a hidden window alone cannot settle it.

What the October 13 observations actually show

Our October 13 report records these operation-phase probe totals:

Those are observed changes during probe intervals. The person could use the Mac during the experiment, so the report cannot attribute every change to a driver. The denominators include calls beyond input actions, and the procedures did not contain identical call counts.

It would be easy to turn 15 versus 30 into a headline about interference. That would overstate the evidence. There was no controlled stream of human input against which to measure missing characters, leaked keystrokes or pointer displacement caused by the agent.

The report explicitly calls for a separate sentinel-window test. It also reports model-driven task outcomes in another section; those are a different measurement and cannot become an interruption ranking.

We will use the same standard for Braus that we apply to Cua: show the task result and the interruption trace before claiming the person was left undisturbed.

The comparison we want: measure the person’s work too

The following is a proposed protocol, not a completed experiment. Use disposable documents, fixed test strings and a target app with state that can be inspected independently of the agent’s final reply.

Give the agent a small task, such as filling named fields in a test form. In another app, the person types a fixed sentinel text. That separate text is the reference for checking whether the agent disturbed their work.

Record the person’s deliberate switches with timestamps. Otherwise, the experiment recreates the attribution problem in the October 13 counters. Compare actual text with the fixed expected text; a screen recording alone can miss a dropped character.

For a strict background trial, any foreground action belongs in a separate result category. Preserve an explicit foreground retry in the trace. The reader needs to know whether the task finished while background delivery was maintained.

Recovery matters as much as the first action

An interrupted task leaves a question: did the last action happen?

Suppose a test form’s first field changed just before a connection dropped. Resuming from the original plan could enter the same content twice or act against a different window. A recovery test should inspect the current app state, establish what already happened and obtain a fresh observation before deciding the next action.

For Braus, stopping a response does not undo delivered changes. Its compatibility guide tells users to inspect the app, files and last reported action before retrying. That behavior needs to remain visible in any stop-and-resume result.

Refusal and task completion also need separate scores. A driver can correctly refuse a stale target and leave the requested task unfinished. That may be the right behavior, but a contract check passing does not make the task complete. Report both, along with any intervention the person had to make.

There is an important limit in our own test setup: the Driver’s existing Live tier requires nobody to operate the Mac during the run. A row affected by a person’s input is inconclusive. That tier can check its intended conditions; a concurrent-input claim requires a separate harness that records and accounts for the person’s activity.

What a credible result should publish

Publish each condition as its own set of repeated attempts. Include task completion, exact sentinel integrity, unexpected foreground or pointer changes, recovery behavior, manual intervention and elapsed time. Keep failed and inconclusive attempts visible.

Record the Mac, macOS build, app version, driver revisions, model, harness and delivery mode. Reset the same starting data between attempts and vary driver order so one side does not always run first. Publish the check that determined success, alongside the traces needed to understand failures.

Do not compress all of that into one unexplained percentage. A task finished after taking focus away has a different outcome from a background completion. A task that refused safely has a different outcome from one that silently changed the wrong field.

The challenge for Braus and Cua

We’re building Braus around background work on the Mac you already use. That makes interruption behavior part of the product’s value, and it gives us a concrete obligation to measure it.

The existing report leaves the controlled interruption question open. The next useful comparison needs to show what the agent finished, what happened to the person’s work and how both drivers recovered when conditions changed.

If a background agent claims to give people their attention back, the benchmark should account for their attention. Show the finished task. Show the untouched sentinel. Show every interruption and recovery.

Read the published comparison report, explore Braus, or discuss a reproducible test case in the Braus Discord.