Comparisons

Braus vs Cua Driver: what your agent gets from the same Mac app

Braus returns a compact text Scene; Cua combines accessibility and screenshots. Compare the current read results, tradeoffs and real-model task outcomes.

Back to Blog

Braus and Cua Driver give an agent different views of a Mac app. Braus returns a structured text Scene. In our 13 October comparison, Cua Driver 0.34.0 returned a screenshot and a capped accessibility tree for a full read, with a compact diff path for subsequent observations.

Braus returned less estimated context in every paired full-read app result. Cua direct completed more of the five real-model task attempts. Those findings give you two concrete things to evaluate: what your model receives, and whether the workflow finishes.

We build Braus. This comparison uses our 13 October report, the tables in our README and Cua's documentation, checked on 14 October. Measurements refer to the recorded driver configurations and source revisions.

The practical verdict

Choose Braus as a candidate when your task lives in Mac apps and you want structured text observations, an app-based worker workflow and local app knowledge. The compact full-read results give you a reason to test that approach on your own workflow.

Consider Cua Driver when you need its documented cross-platform routes or want to integrate a driver into an existing harness. On the five task attempts in our experiment, its direct configuration completed every scenario, including the two Braus did not complete.

For a task that matters to you, inspect the output and record the resources and interventions needed to obtain it. The context table can guide the trial, but it cannot decide that task's outcome in advance.

Compare the driver with the driver

Braus packages desktop work into a Mac app with workers, Perception, Brain and Memory. It also exposes the engine's desktop tools to local MCP clients. The driver provides the observation and action route used by those agents.

Cua Driver is a UI layer used by an agent harness. Cua's driver documentation separates the model loop from the driver. Cua also offers other products; the measurements here do not rank its entire platform against the Braus app.

DimensionBrausCua Driver
Full-read shape in this runStructured text SceneScreenshot plus capped accessibility tree
Subsequent readsCompact unchanged Scene responseCompact diff path
Agent connectionApp workers and local MCP clientsDriver interfaces used by a harness
Platform scopeMac desktop workDocumented macOS, Windows and Linux routes
Result to evaluateCorrect output from the complete workflowCorrect output from the complete workflow

Cua's platform support page describes its proven routes and boundaries. Braus's compatibility guide describes the current Mac scope. A platform label should lead to a test of your required operation.

The full-read result across ten apps

The current README reports 67.5–95.4% fewer estimated full-read tokens for Braus across paired apps. The median is 351 versus 2,156, approximately 84% lower, calculated as a ratio of medians before rounding.

AppBraus full readCua direct full readFewer estimated tokens
TextEdit3421,73680.3%
Chrome3993,19587.5%
Obsidian6522,86677.3%
Stocks6213,64983.0%
kitty801,74195.4%
DaVinci Resolve3602,16083.3%
Prism Launcher3262,15184.8%
Calculator19073074.0%
Safari4323,10786.1%
Photoshop3401,04767.5%

Text was estimated at four characters per token; images by resized area divided by 750. These are estimates of returned context. They do not measure equally priced provider tokens, final task cost or whether each response contains equivalent useful information.

For a builder, the advantage is specific and worth testing: Braus gives the model a smaller full-read payload on every paired app in this run. Check whether that payload identifies the controls and state your task needs.

Cua's compact reads change the comparison

The old 6 October result used different driver revisions and observations. Cua's 13 October configuration has capped full reads, compact diffs and a different action-and-observe loop. The older 85–97% article remains a dated result.

For unchanged or diff reads, the newer report records median estimates of 38 for Braus and 67 for Cua. The per-app comparison also contains a counterexample: Photoshop was 38 for Braus versus 10 for Cua.

Cua's current observation documentation also includes an option to omit the screenshot. Choosing a different observation setting changes what you need to test. The full-read range applies to the configuration recorded in our experiment.

An agent can receive full reads, diffs and action results in the same conversation. Braus's action response is larger in some rows. Apply each number to the operation it measures.

An action result needs an effect check

Our README places independently confirmed effects beside the step timing. That makes the boundary between a tool response and an observed application change visible.

AppBraus effect checksCua effect checksBraus step, msCua step, ms
TextEdit18/2412/243931,234
Chrome12/2111/181,1741,535
ObsidianUnverifiedUnverified8441,256
Stocks0/90/99551,767
kitty0/60/99781,259
DaVinci Resolve3/93/93841,635
Prism Launcher3/63/64121,172
Calculator6/66/64121,227
Safari12/189/188641,267
Photoshop6/80/181,1511,168

Effect checks are confirmed effects divided by checkable attempts. A zero or an unverified row does not prove that every requested action failed: the probe could lack a readable effect. Denominators differ, so these counts are not a framework-support percentage.

The timings use weighted medians of per-operation medians on the shared subset with completed responses. There were three measured repetitions after one warm-up. They do not describe complete successful tasks or robust tail latency.

The Qt rows retain the attempted measurements shown in the README, although Cua's cited documentation placed those scenarios outside declared background support. They cover the tested controls. Resolve's editing canvas and general Qt workflows were not qualified by these measurements.

The model task result favors Cua direct

The experiment also attempted five tasks once per driver, through a real model. Braus passed Calculator, the Chrome form and the Prism toggle. It failed the kitty and TextEdit tasks. Cua direct passed all five attempts.

The overlay configuration passed four decided attempts, with TextEdit inconclusive. Keep that inconclusive attempt in the result instead of presenting four passes as a completed five-task set.

This is a small sample, but its direction is clear. The smaller Braus observations did not guarantee completion. An operation can also fail during one test procedure while a different model-driven procedure eventually succeeds.

Use the real-model results to see the recorded outcomes, elapsed time and reported costs. The next trial should repeat the tasks and inspect the actual outputs.

Local resource use depends on the runtime path

The report records median driver footprints of 87.0 MB for Braus, 12.7 MB for Cua direct and 173.1 MB for the embedded-overlay layout. Braus's driver CPU also exceeded Cua direct in the recorded summaries.

The overlay used an embedded daemon and proxy, with CuaDriver.app not installed. Its resource measurements describe that embedding layout. They are not a measurement of the installed app's ordinary runtime.

These figures concern driver processes. Whole-workflow resource use also includes the model connection, target app and other system work. Keep that scope when deciding which configuration to run on your machine.

Background is a condition to test

Both projects document background operation routes. Braus uses a virtual display in the current Mac session. Cua provides background delivery for supported targets and refuses some ambiguous or unavailable routes.

The experiment's focus and cursor counters describe observed changes during probe windows. They do not establish that every change was caused by a driver, or prove safe simultaneous typing. A person occasionally used the Mac during the experiment.

If your requirement is to continue working while a task runs, put that condition into the trial. Check the result, window placement, interruptions and any input interference under a controlled setup.

Where app knowledge enters the choice

The Braus app keeps local knowledge of controls, relationships, interactions and procedures. Workers, local MCP clients and the CLI share the user's archive, with task streams scoped separately. Recall can suggest steps that still need resolving against the live interface.

That is a capability of the Braus stack. The driver comparison did not measure learning efficacy or memory-related savings, and it does not establish which memory features exist elsewhere in Cua's products.

Treat that context as another question for your workflow: can relevant earlier work help the next task, and does the agent verify what it reuses? The Braus documentation defines the present scope.

Give both drivers the same task

Choose a small output you can check. Match the app state, task, model configuration and execution budget, then record the observation, calls, interventions and final result. Repeat the trial to expose variation.

The 13 October report measured one M4 Mac with 16 GB RAM on macOS 27.0.1, using a Braus backend candidate and Cua 0.34.0. It is separate from a test of the shipped Braus installer. Full prompts, transcripts and raw run files are needed for independent reproduction.

Our recommendation is concrete: try Braus for compact structured context and Mac app work; include Cua direct as a serious comparison when the finish condition matters. Use the Braus setup guide and Cua's quickstart to prepare the same bounded task. Then choose from the output you can inspect.

All posts