Mecum vs Cua: 85–97% fewer estimated tokens per full read

Mecum returned 85–97% fewer estimated response tokens per full read than Cua Driver across eight paired Mac app results in our 6 October 2026 experiment. Both drivers read the same target windows using their default observation behavior.

In Safari, the estimate was 977 tokens for Mecum versus 34,002 for Cua. In TextEdit, it was 385 versus 6,185. Every paired full-read result favored Mecum on response size.

That is the first comparison we want to put in front of developers choosing a desktop driver: how much context does your agent receive each time it reads an app?

The result measures estimated tool-response context. Provider billing and complete-task performance require further measurement. This experiment ran through driver CLI paths on one Mac, rather than through the shipped Mecum app. The full dated report contains the method, observations and failures.

We build Mecum. This is our own comparison, and the table below includes every paired full-read result. Stocks was also attempted, but Mecum could not open its session; we report that failure separately.

The eight paired full-read results

The reduction is calculated for each app as 1 − Mecum estimate / Cua estimate. The headline range rounds the smallest and largest paired reductions. It is not an average across apps.

Stocks has no paired result: Mecum refused the session, while Cua returned an estimated 5,755 tokens for its full read. That attempted app is excluded from the eight-pair percentage range because there is no Mecum read to compare.

For builders, this makes response composition a concrete selection criterion. Ask for the payload from the app you actually use. A driver demo can show a successful interaction while leaving the observation size invisible.

Two ways to describe the same window

Mecum returns a structured text Scene. In this experiment, Cua returned a screenshot and the full accessibility tree as Markdown. The token estimates cover MCP content, including the image estimate.

Cua's current observation documentation describes the tree and screenshot combination, and also documents an option to omit the screenshot. Our table describes the default configuration used in the dated run. It does not measure every Cua observation setting.

Images can carry information that an accessibility tree misses. Structured text can give an agent a compact description of actionable controls. The useful comparison is whether the returned context supports the next decision in your task, and at what size.

There is also a scope difference worth inspecting. In this run, Cua's tree included the app's menu bar, including Recent Items. Mecum omitted the menu bar from the Scene and exposed menu information through a separate tool when requested. The report identifies this as one source of context outside the target window.

This leaves a clear design question for desktop tools: how much information should every read return, and what should the agent request only when it needs it?

How the token estimates were calculated

The report estimates text at four characters per token. Images use an area estimate of width × height / 750 after resizing. These are approximations, rather than measurements from a model provider's usage counter.

No complete task with a real model was run. The experiment therefore does not tell us the final number of model calls, retries or billed input tokens for a task. A smaller observation may change those downstream quantities, but measuring them requires an agent run with actual usage recorded.

Cua also returned a separate structuredContent field ranging from approximately 34 to 425 KB per read. Those bytes are excluded from the table's token estimates. The amount a model receives depends on which fields its client forwards.

The strongest supported claim remains the full-read result: under this run's default configurations and estimation method, Mecum returned less estimated response context in all eight paired apps.

An unchanged Scene returns even less context

Mecum's unchanged-Scene responses ranged from 38 to 100 estimated tokens. That is a separate observation mode from the full reads used in the headline.

For example, TextEdit's full read was 385 estimated tokens, while its unchanged response was 100. Safari's values were 977 and 38. Cua did not have a separately measured unchanged-read series in this experiment.

Keeping those series distinct matters. Comparing an unchanged response with another driver's full read answers a different question from comparing two full reads. The smaller unchanged response also does not establish faster observation: the report measured the read taking place even when the returned Scene had not changed.

The local resource tradeoff

Mecum used more driver CPU and memory in this experiment. Its median memory footprint was 132 MB, compared with 35 MB for Cua. Peak values were 241 MB and 122 MB respectively.

The report attributes additional work around Mecum actions to OCR and perception before and after the action. The action response already includes the resulting Scene.

This is a tradeoff we want to make visible. A compact response is useful, but a driver also consumes local resources. Whole-task cost needs to account for the local work and the model usage that follows it.

The report's two CPU summaries differ in some rows, so they need reconciliation against the raw aggregation before supporting another numerical headline. The memory figures above are a separate measurement. None of these values measures whole-Mac battery life.

Where the drivers refused or needed help

Mecum failed to open the Stocks session after a window-placement check. Cua accepted the tested Stocks key and scroll operations. Mecum also refused disabled menu commands in TextEdit, Chrome and Safari; Cua accepted the tested menu items.

Safari exposed a different boundary for Cua. With two windows open, its ambiguity check refused typing, keys and scrolling. Mecum avoided that ambiguity by moving both Safari windows onto its virtual display, including the person's other window. That behavior deserves attention when evaluating a multi-window workflow.

In kitty, an OCR check confirmed Mecum's inserted text in each measured repetition. Cua reported that it delivered none of the requested ten characters. Neither driver's tested Ctrl+U or Ctrl+A had an independently confirmed clearing effect.

These details matter alongside the context table. They tell you which behavior to check on your app. A reported-done tool call can include an effect the driver could not verify, so the report's completion counts are not task-success rates.

What the Resolve result actually covers

The Resolve context row is a read of the Project Manager. Its basic view controls and scrolling were tried; GPU editing-canvas work was outside the experiment.

At the time of the run, Cua's documented background scope excluded Qt/GPU viewports. Both drivers still returned successful responses for some simple Qt controls. The report retains read estimates while omitting Cua's Qt action metrics from the supported-background comparison.

The lower Resolve response estimate is part of the eight-pair result. It does not validate a complete editing workflow or every Qt app.

The machine, builds and repetition count

Mecum used its research opt-in because this OS build was outside its Driver Ledger. The experiment did not qualify that build for normal release use. It also did not test Cua's installed daemon/proxy path or the shipped Mecum app and installer.

App version numbers were not recorded. The report identifies raw measurements and a reproduction harness, but those files are absent from the linked public source revision. The Markdown report provides the published measurements and method; it is not yet a complete public replication bundle.

Put the next comparison on finished tasks

The next useful test should give both drivers the same task and model, then inspect the output. Record completed results, refusals, interventions, actual usage and elapsed time. Test background behavior while a person works, with a separate check for focus and input interference.

Our current result gives Mecum a strong starting point: less estimated context on every paired full read. The next test needs to show what that changes for the agent and the person using the Mac.

If you are evaluating desktop tools, ask them to show the returned context as well as the demo. Read the complete benchmark report, then use the Mecum documentation to define a small trial in an app you use. Inspect the output and keep the conditions visible. That is the comparison we want Mecum to compete on.