We tested A2UI Express on our own catalog, and it's a banger

On Sonnet 5.5, Express wrote 928 output tokens per reply against 1,985 for Direct JSON (2.14x fewer) and took 7.6 s against 15.1 s (2.00x). All 18 Express replies compiled (six briefs, three repeats); 15 of 18 Direct JSON replies did.

Caveats that belong next to these numbers:

• Haiku 4.5, the seventh model and not in the table, gave the biggest ratio (2.7x), but I am not leading with it. It compiled only 3 of its 6 briefs unaided, so most of its replies produced nothing to render. I have not diagnosed why.
• Across the models I tested, the token saving holds; the time saving depends on the model. Express used fewer output tokens on every one: 2.1x on Sonnet 5.5, 1.7x on Gemini 3.5 Flash, 1.55x (median paired ratio) on Gemini 3.8 Flash. Time: 2.0x, 1.24x, and no reliable gain on 3.8 Flash. That is below Google's "up to 3x" on time for every model I tested.
• Gemini 3.5 Flash, thinking off (my setting; re-run 29 October): a modest gain, less reliable. Three repeats of six briefs in each format, interleaved order, request-only timing. Median reply 3.8 s for Express against 5.1 s for JSON. On the 15 briefs valid in both formats, the median per-pair time ratio is 1.24x (range 0.91x to 1.67x; Express faster in 12 of 15). Express compiled 15 of 18 replies and JSON 18 of 18.
• Gemini 3.8 Flash, thinking off: fewer tokens, no time gain I can claim. Median paired time ratio 1.06x on 10 briefs, range 0.22x to 7.08x, Express faster in 6 of 10, with latency spikes in both formats. Express compiled 16 of 18 and JSON 10 of 18 (seven JSON failures were components unreachable from the root). An earlier run with thinking on gave 1.19x with truncated JSON replies and is superseded.
• The Direct JSON side is handicapped. Our catalogue build typed 18 list and boolean fields as strings, so models that obeyed the schema sent strings. I can't fix that without re-running them, so I make no claim about JSON against Express quality.
• For reference, sourced: Google says up to 3x fewer tokens and up to 3x lower latency.

Google describes a decision model that answers about 30 typed layout questions per screen while code builds the components and a small model writes only the text. I built a small version: three fixed layouts, three questions, Jev to choose, Gemini 3.5 Flash-Lite to write the text. Eighteen screens, all compiled.

A complete screen took 1.57 seconds (Jev 0.18 s, writer 1.39 s). Google reports 0.8 to 1.7 seconds for complete screens, so we are in the same range. Against the same writer model producing the whole screen, mine was 1.4x faster than Express and 1.9x faster than Direct JSON. Ratios of 12x to 96x appear only if you measure time to layout (before any text exists) against whole-screen replies: 12x to 16x against Gemini Flash-Lite, and 59x to 96x against the larger models (Opus 5.5 whole-screen Direct JSON at 17.6 s divided by about 0.18 s).

The cost was quality: in this six-brief sample the pipeline scored F1 0.31 against 0.67 for the plain whole-screen reply, because three fixed layouts cannot express five of the six briefs. Google does not say what its 80x is measured against, so my test neither confirms nor refutes it.

Sourced, from Google's post: "up to 3x" fewer tokens for Express against Direct JSON, and latency "by up to 3x, and up-to 80x using decision models like Jev". The 80x is a latency claim for decision models, not a token claim.

• On the payload, 54 of 72 cells were good or minor. No factual errors were found in the lessons or definitions, and the numbers I checked were right.
• On the rendered page, far fewer were: 34 of 72 good or minor. Of the 54 rendered cells that fell short of "good", the main cause was the model in 23, the renderer in 17 and my test harness in 14.
• A second reviewer, from a different model family and blind to the first reviewer's grades, agreed on good-or-minor against not for 64 of 67 comparable cells.
• Reviewer independence is limited. The first reviewer saw labels naming the model that wrote each cell, and graded cells that include replies from its own model family. The second saw no model labels, but also graded cells that include replies from its own family. I did not test whether either grades its own family differently.

What this does not support: any ranking of models or formats, anything about interactivity (no filter or control is wired), anything about wide screens, or anything about stability across repeats (repeats 2 and 3 were not reviewed). It is one pass on one sample.

Three cells look clearly better. The chart brief now shows a chart, the flashcard deck that was missing on the old snapshot is there, and the filterable list renders as cards (a filter strip overlaps in both versions). Two cells, the lesson and the marketing page, look the same, so not every cell improved. The model output is identical in each pair, so the difference is the renderer. One model, one repeat.

It also worked the other way. Our own catalogue build typed 18 fields wrongly and documented the pricing atom's tiers only as "array", so models followed the schema or guessed field names the renderer ignored, and every model looked worse for it. The same payload can look better or worse depending on which renderer version shows it. The catalogue's first commit was 5 July 2026, under four months ago.

A small worked case is the fourth brief, a list of eight items you can filter by status. Sourced from our earlier plain-agent test: no atom could filter a list, so I added filterable_list on 25 September. Where a model's slice contained it, models chose it. The gain came from adding the atom to the catalogue.

Of the 54 weak rendered cells above, 31 had a renderer or harness cause. And a direction we are exploring, not a result: capability tags now exist for all 557 atoms (a first, coarse pass), and the tag-only routing test in section 7 shows why tags alone are not enough.

The whole catalogue is about 108,000 tokens. A rule-based slice of 207 atoms is about 35,000. On Haiku 5.5 with Express, the cost per brief fell from $0.0576 to $0.0044, about 13x. Most of that 13x is a price tier: Haiku 5.5 charges more per token above 100,000 tokens, and the whole catalogue crosses the line. At a flat price the saving is 2.6x.

The F1 went up (0.50 to 0.59 on answer key v2), but the gain comes mostly from one brief and is not statistically significant. So the claim is "no significant change in atom choice", not "better".

A slice also acts as a guard. In one offline case, a reply written for a marketing slice was rejected by the learning slice at compile time ("Unknown component 'feature_grid' not defined in catalog"). One case, offline. I did not test how an agent would be identified, or whether the guard holds against a model that tries to get round it. This is a direction we are exploring, not a deployed control and not enterprise adoption.

Level 1, the slice alone (4 atoms, 48 calls). On the three briefs that match a block (robot, rocket, spaceship), the agent picked the right block 9 of 9 times in both formats. Express wrote 66 to 113 output tokens in 1.2 to 2.6 s; Direct JSON wrote 266 to 591 in 2.8 to 5.0 s. Express compiled 24 of 24 replies and JSON 21 of 24 (three invented-field failures). On the dashboard brief, which no block fits, the agent was forced to pick a brick atom and refused 0 of 3 times.

Briefs B1 to B7 have an expected block, so they get an F1 score. The eighth, the dashboard, has none, so it is scored pass or fail instead (above). I found an error in my own answer key after this run (the house and cat briefs accepted only one atom, and a second one also fits). I kept the pinned-key scores and show the re-score beside them, labelled as after the fact:

Level 2, the slice plus a profile (3 atoms, 24 Express calls). All 24 compiled. The matching briefs scored F1 1.0. The agent refused the real-parts table and the dashboard 6 of 6 times. These refusals were instructed: without the instruction it refused 0 of 3.

Guardrail round (24 calls, the same profile and slice as level 2). Clearly out-of-scope requests were refused 6 of 6 and prompt-injection attempts 6 of 6; control briefs were answered correctly 6 of 6. Two borderline briefs (a toy-brick bar chart, a toy-brick dashboard) were built with bricks 6 of 6 times. That is a judgement call and I did not score it.

Counting level 2 (6) and the guardrail round (12), that is 18 of 18 refusals, all instructed. Without the profile, the one out-of-scope brief I tried was refused 0 of 3.

Level 3, the full catalogue (2 calls only). 122,832 input tokens per request, and it still picked the right block 2 of 2. I did not run the other 22 planned calls.

Details behind the table:

• The vendor says Jev is 40x to 200x faster than frontier models on this kind of query and answers in 70 to 500 ms (sourced, announcement, a vendor claim I did not test). My 9x is lower. My 0.19 s sits inside their range; I compared against a fast Sonnet router, which I guess explains the gap (assumed).
• Sonnet returned an empty reply on 6 of 72 calls because its thinking used up the 256-token cap I set. That is a flaw in my setup, and I left the counts as they came out.
• On the 16 easy briefs (48 replies) Sonnet was right on all 48, 42 of them clear cases. Jev was right on 39 of the 42 clear cases: 15 of 18 on the block briefs (the spaceship brief went to "none" three times), 21 of 21 cross-catalogue and 3 of 3 where nothing fits, plus all 6 judgement replies. On the hard set the toy plane went to "none" three times with Jev.
• Keyword and tag routers (BM25, tags, a hybrid) got 7 to 8 of 12 on the clear hard briefs, and the tag routers cannot say "none". The tag file also had a gap: it tagged none of the four brick atoms. Keyword or tag routing alone is not enough for this catalogue. I did not test an embedding router.
• This is one comparison on briefs I wrote. It does not say a decision model is better than a general model.

The writer prompt is 122,832 input tokens with the full catalogue and about 3,600 behind a router with a three-atom slice (34x fewer on the writer alone). Adding the router's own input (about 1,460 tokens for Jev, 1,770 for Sonnet) gives about 5,060 and 5,370 input tokens per request: 24.3x and 22.9x fewer. Router and writer were counted in separate runs on different briefs, so the 24x is computed from measured means, like the latency. The full-catalogue prompt is the 573-atom catalogue plus the Express rules, counted by Sonnet. The 108,000 in section 5 is an earlier round counted by Haiku on 557 atoms, so the two are not the same text and I do not equate them. Summed latency, with the router and the writer measured as separate calls: 3.35 s with a Sonnet router and about 1.9 s with Jev, against 4.5 s without routing (1.35x and 2.4x). The 4.5 s comes from the two full-catalogue calls only.

Cost per request, output tokens included, Sonnet 5.5 as the writer. Sourced prices: Sonnet 5.5 at 2 and 10 USD per million input and output tokens, 0.10 per million on a cache hit (pricing page, read 29 October 2026); Jev at 42 USD per billion input tokens with output tokens free (Jev announcement, read 30 October 2026), which is its own price, not Sonnet's. The Jev figures below count its output as free. The 5,060 above is a token count. The Jev router's tokens are priced at Jev's rate, so the bill is not 5,060 times the Sonnet price. I built each figure from measured mean tokens:

• No routing: 122,832 input and about 68 output tokens, 0.2463 USD.
• Writer behind a router: 3,602 input and about 52 output tokens, 0.0077 USD.
• Sonnet router: 1,769 input and 43 output tokens, 0.0040 USD.
• Jev router: 1,456 input and 216 output tokens, 0.00006 USD (output is free).

Cost per 1,000 requests ("cached" assumes a 100% cache hit on both sides, which is a steady-state assumption):

That is 31.7x cheaper uncached and 13.8x cached with the Jev router, and 21.1x and 8.7x with the Sonnet router. The router step alone is 65x cheaper with Jev uncached (0.06 against 3.96 USD per 1,000 routes, 10x cached). That 65x comes from Jev's price per token, not from fewer tokens.

The 24x is computed from measured token counts (router and writer counted in separate calls and added), so it does not depend on timing or on the price list; the cost multiples apply list prices to those counts. Caveats: I never ran the routed path end to end, so each total is the router and the writer measured separately and added together. Cache writes cost 1.25x and the cache lasts five minutes, so a quiet service will not reach the cached column. The full-catalogue agent also picked the right block on its 2 of 2 briefs: the saving is prompt size and cost, not accuracy. I am not claiming that routing improves accuracy.

Clef is a second decision model, which I ran through Cloudflare's API. Given slices built from the answer key (a best case no real system gets), both reach a mean F1 of 0.79.

Two cautions. An oracle slice is built from the answer key, so 0.79 is a ceiling and not an end-to-end result. End to end, the cascade I built (rule-based slice, Jev, a hint file, one repair attempt) scored F1 0.64 at $0.0144 a brief. The hint file was written after I had seen failures on these same briefs, so that figure is generous.

It scores 0.774 on answer key v2, level with the Express setups (0.64 to 0.79), at $0.022 a brief against $0.007 to $0.014 (all at Haiku 5.5 list prices, so not comparable with the Sonnet costs in section 7).

There is a second answer key that scores it 0.941. It differs only by also accepting filterable_list on one brief. That atom was built to close a gap the brief exposed, and my oracle slices do not contain it, so Express could not choose it. The higher figure shows what the new atom added, not the agent. Never compare a version 3 figure with a version 2 figure.

Elemental works with our catalogue only with capitalised component names and a children property on parents. With those, Sonnet 5.5 and Haiku 5.5 compiled 18 of 18 and Flash-Lite 16 of 18 (17 after one repair). A compile pass did not prove the page was right: my first render of every Elemental reply was blank because parent-child links were silently dropped. This ran on an offline copy of the catalogue and scores atom choice only.