Braus vs Cua: from successful tool calls to finished tasks

Braus passed three of five real-model task attempts in our 13 October experiment. Cua direct passed all five. The Cua overlay configuration passed four decided attempts, with TextEdit inconclusive.

The same experiment gave Braus a clear observation-size advantage: 67.5–95.4% fewer estimated full-read tokens across ten paired Mac apps. The median was 351 versus 2,156, approximately 84% lower.

Those results belong together. A driver can return compact context and completed tool responses while the agent still fails to produce the requested output. Our next comparison needs to make the finish condition as visible as the tool calls.

We build Braus. This article follows the evidence structure in our GitHub README: observation context, independently checked effects and the limits of each measurement. It then examines the real-model phase of the 13 October report.

The five task outcomes

Each driver attempted each scenario once. Task success was decided by a separate result check, rather than the model's final message.

Cua direct completed the task set more consistently in this sample. Braus's two failures remain part of the result. Five heterogeneous tasks with one attempt each do not establish a stable success rate for either product.

The overlay's inconclusive TextEdit attempt took 241 seconds and had no reported cost. Reporting four passes without that unresolved attempt would make the comparison look cleaner than it was.

Prism also needs its scope attached. Cua's cited documentation placed the Qt background scenario outside its declared support, but both Cua variants were tried and passed this task. The observed pass should remain visible alongside that documentation boundary.

Zero tool errors can still end in a failed task

The source records zero tool errors for Braus's kitty and TextEdit task attempts. Both attempts nevertheless failed the final result check.

That is a useful distinction for anyone evaluating desktop agents. A tool-error counter describes one part of execution. It does not tell you whether the requested state or output exists.

Cua direct's kitty task passed after four recorded tool errors. Its TextEdit task passed with one recorded tool error. An agent can recover during a task, and the final checker can still find the expected result.

Use both observations. Tool failures reveal where recovery was needed; the final output shows whether that recovery reached the goal. Record the interventions and budget consumed along the way.

The README's effect checks answer another question

The operation phase runs individual calls and probes application-owned state. Its counts are useful for understanding actions, but they are a different phase from the model-driven task attempts.

The input procedures and checks differ between phases. These rows are not a conversion formula from confirmed effects to completed tasks.

An effect check also has a perimeter. The probe may lack a readable change for a scroll, key or custom control. A zero confirmed-effects row does not prove that every action in that application failed. Keep the checkable attempts and unverified effects visible.

This is why we put effect checks beside timing in the README. A quick response should lead to a question about the application state it actually changed.

Smaller observations remain a concrete advantage

The full-read result covers ten apps under the recorded configurations. Braus returned structured text; Cua returned a screenshot and a capped accessibility tree. Text tokens were estimated at four characters per token, with image estimates based on resized area divided by 750.

The median comparison is a ratio of medians before rounding. It describes the observation payload, rather than the whole conversation or the bill for finishing a task.

Cua also has compact diff reads in this experiment. Photoshop provides a counterexample to a universal response-size advantage: its Braus unchanged response was 38 estimated tokens, while Cua's diff was 10. Some Braus action responses were larger too.

The current README benchmark tables make that scope explicit. The older 6 October range describes another set of revisions and observations; it should not be reused as the current result against Cua 0.34.0.

Costs for the tasks both direct configurations completed

Calculator, the Chrome form and the Prism toggle passed with Braus and Cua direct. Looking at those matching completed attempts avoids comparing a cheap failed run with the cost of producing a result.

The CLI reported lower costs for the three Braus attempts, while Cua direct finished them sooner. Those observations describe single attempts. They do not establish a stable cost saving or a general speed advantage.

The report's usage-token totals combine input, output, cache-creation and cache-read categories. Those categories are not equally priced units. The USD values come from the CLI and are rounded here to three decimals; the supplied Markdown does not allow a full reconstruction of the usage and charging breakdown.

A failed attempt's lower cost is not the price of completing its task. Keep outcome attached to cost when reporting a benchmark, and include retries and human recovery in a larger workflow budget.

Count the calls, then inspect what they achieved

The completed Calculator attempt used eight Braus tool calls and three Cua direct calls. Chrome used six and three; Prism used three and four.

The compact full-read result does not imply that the agent will always use fewer calls. Different observations and action responses can change how the model proceeds, and the task run must measure that behavior.

Record both the sequence and its result. A call count can explain where the agent spent effort, but a shorter sequence that leaves the wrong output has not satisfied the finish condition.

What was actually measured

The experiment used an Apple M4 Mac with 16 GB RAM and macOS 27.0.1 build 26A434. Braus's measured backend revision was b737e719d36f04195c1eebfeb026946ea9c0f475. Cua Driver was version 0.34.0 at c1c2b5f.

The Braus run used its desktop worker backend through a driver server, with a research opt-in for an OS build outside the validated ledger. This was not a test of the distributed Braus installer.

Cua ran in direct MCP mode and in a separate embedded-daemon overlay configuration. CuaDriver.app was not installed. The overlay result therefore describes that tested layout.

For the task phase, the team records Claude Code with configured model identifier claude-sonnet-5-5 and medium effort. The resolved model identity, complete prompts, starting-state traces and per-category usage require the original run bundle for independent reproduction.

The report and detailed measurements provide the published tables. Raw run files and transcripts were not attached to those Markdown outputs. We have not rerun the experiment while preparing this article.

Put the finish condition into the next comparison

Our next task-completion study should give each scenario a stated output check before execution. The protocol should keep starting states, model configuration and budgets explicit, then repeat each task to expose variation.

The result package should contain:

• The requested task, initial state and criterion for success.
• Calls and observations, with recovery and human intervention recorded.
• The final output or application state the checker inspected.
• Elapsed time, usage categories and reported cost for each attempt.
• Driver revisions, app versions and all failed or inconclusive attempts.

For a document task, a saved file with the expected contents can provide a finish condition. For a form, inspect the intended values and resulting state. Those are examples of checks to define for a future trial, rather than additional results from this experiment.

The Braus failures need transcripts and starting-state evidence before we can attribute them to a particular model decision, driver operation or check. Repeating the same tasks after a change will show whether the output improved.

Make the output the headline of the next test

Braus's compact context is worth competing on. The next step is to show how that engineering translates into work that finishes under stated conditions.

Cua won the completed-task column in this sample. We are publishing that result alongside our observation-size advantage because both affect the decision to use a desktop agent.

Read the full report, then use the Braus setup guide to define a small task in an app you use. Name the finish condition, inspect the output and record what it took to get there. That is the evidence we want beside every driver demo.