I put a small model between Claude and my design system. It sped up nothing.

When Claude designs a screen from a design system, it starts by reading: the list of components, the tokens, the house rules. That takes a few seconds and several thousand tokens.

One question kept nagging me: what if a small, very fast model answered the simple questions instead of Claude? Less reading for Claude should mean fewer tokens and less waiting. I wanted to measure it rather than believe it.

The idea: a fast lane between Claude and the MCP

Claude talks to Axolo through an MCP server, a set of tools it can call. I added a small decision model between the two: Laya. It weighs about 1.6 GB, runs on an ordinary computer, answers in under a second, and for a closed question returns an answer with a probability.

I exposed four fast-lane tools: find a token's value, find the closest component, pick the rules that matter for a screen, and say who a property is for (designer or developer). Each returns an answer and a confidence level. Below a threshold I set by hand, the answer becomes “uncertain” and Claude keeps control.

The test

• Two conditions. A: Claude with the MCP's raw tools (list components, read tokens, read rules). B: the same tools plus the four fast-lane tools.
• 14 requests (login, checkout, settings, onboarding, navigation, empty state…) on two design systems, a demo one and shadcn/ui. Each is run twice per condition.
• Claude models. Claude Opus 5.5 generates the screens, launched from the command line with only the MCP tools allowed. Claude Opus 5.5 also scores them as a blind judge: A and B screens are shuffled, and it applies a fixed grid. It also established, separately, the list of “right” rules for each request. In earlier screen-generation tests, Claude Sonnet 5 served as a reference.
• What I measure. Time per screen, tool calls, tokens read, the judge's score, and an automatic check (valid screen, components from the design system, one primary action).

The result

No faster, no cheaper in tokens, same quality. Laya itself adds about 0.9 seconds to each screen.

Why it doesn't work

1. Claude prefers to read for itself. In condition B it calls the rules tool on every screen, but keeps reading the full component list and the tokens. It uses the token lookup 13 times in total across 28 screens, and never the component lookup or the property-audience tool. Reading a whole design system costs it a few seconds; a summary from a small model whose reliability it doesn't know isn't worth the detour.

2. Laya is wrong too often when it says it's confident.

• Design rules: it settles 52% without hesitating, but 123 of those 325 “confident” answers are wrong (38%).
• Tokens: it always answers “uncertain”. shadcn has no spacing token, and the preselection falls back on colors. The right answer was “no token”, which a plain script gives without any model.
• Property audience: right 44 times in 100, and never confident enough to clear the threshold.

What I take away

• Measure before you plug it in. The idea looked obvious. It wasn't.
• A fast model is not a reliable model. Laya's probabilities are not calibrated: “0.95” does not mean “95% chance of being right”.
• A big model won't delegate what it reads in three seconds. The potential gain is in what it reads slowly or rarely.
• The simplest thing often wins. An answer computed by a script (a token's exact value, a keyword search for a component) delivers most of the benefit with no model.

Decision: I'm not plugging Laya into Axolo's MCP. The small model stays reserved for importing design systems, where it does real work with no external API. Next I'll test the most modest option: answers computed by script.

Limits

• Only 14 requests, two design systems, 2 passes per condition. The time gap (2 seconds) is small; the conclusion rests on the absence of any gain.
• The 24 rules Laya had to find were written by me for this test and their “right” selection was established by Claude Opus 5.5. Judge and generator are the same model: A and B were shuffled to limit bias, but it remains an automated evaluation.
• Confidence thresholds were tuned on 6 requests, then frozen.
• Laya ran natively on a Mac, not a dedicated server; 0.9 s per screen is an order of magnitude.