Matching an AI model to the machine in front of you
"Which model do you want?" is the wrong question to ask a user. Here's how the app answers it for them — and one UX decision I still haven't settled.
The unglamorous truth about running AI locally is that the model has to fit. A model that's excellent on a 32GB machine will swap to disk, crawl, or fail to load outright on a 16GB one. And when that happens, the user doesn't think "ah, a memory mismatch." They think the app is slow, or broken, and they're right to — it is broken, for them.
So the worst thing I could do is open with a menu of models and a cheerful "which would you like?" Most people, very reasonably, don't know how much RAM they have, let alone what a 4-bit 24-billion-parameter model needs to load. Asking the user to match a model to their hardware is asking them to do the app's job.
The app should do that job. This post is how it does — and the one part of it I genuinely haven't resolved.
Inspect the machine, then decide
On first run, before it offers anything, the app inspects the device: how much RAM, which CPU architecture, how much free disk, which platform. That produces what I think of as the machine's capability profile — the authoritative description of what this computer can actually run.
The app runs on Windows and macOS, and the same fit-the-machine logic applies on both — though the catalogue offers different models per platform: llama.cpp builds for Windows and Intel Macs, Apple's MLX builds for Apple Silicon, because what runs well genuinely differs by operating system.
Everything downstream defers to that profile. The app scores every model in its catalogue against it and recommends one that will genuinely fit:
- 8GB machine → a lighter, faster model that leaves room to actually work.
- 16GB machine → the balanced default. (This is the government standard laptop, and it's the case I optimise hardest for, because it's the one most people are actually on.)
- 24GB and up → the heavier, higher-quality option unlocks.
The user doesn't choose from a wall of options and hope. The app recommends the best fit, downloads it, verifies it, and starts it. You can change it later in Settings if you want to — but the default path is one the app is confident will work on your machine, not on mine.
That confidence matters. A recommendation you can trust is worth more than a choice you're not equipped to make.
The decision I haven't settled
Here's where I'd genuinely like other people's judgement, because I keep going back and forth.
I recently added a premium model to the catalogue — Mistral's Devstral, a 24-billion-parameter coder and one of the Apple Silicon (MLX) options, the strongest on-device choice for this kind of work. Its catalogue entry says it needs 32GB of RAM. My development Mac has 24GB.
So when I went to look at it in the model picker, it had vanished. Entirely.
That's the recommendation engine working as designed: it marks any model whose minimum RAM exceeds your machine's as incompatible, and incompatible models are filtered out before the picker even renders. No row, no mention, nothing. On a 24GB machine, Devstral simply does not exist.
And I'm no longer sure that's right. It surfaces a real product question, and it's not a technical one — it's about what you owe the user when the answer is "no":
The case for hiding it. Don't dangle something that will fail. Keep the list clean and the default obviously-correct. A model the machine can't run is noise, and noise on a first-run screen is where people bounce.
The case for showing it, greyed out, with the reason. Silence is itself a failure mode. A designer on a 16GB laptop has no idea the premium tier even exists — so they can't make an informed decision about whether to ask for a better machine, and they can't understand the ceiling they're working under. "There's nothing here" reads like a bug. "This exists, but it needs 32GB and you have 24GB" is information — it respects the user enough to tell them the truth and let them act on it.
There's a tell that the current design is unprincipled rather than deliberate: the system already treats uncertainty inconsistently. If your RAM is below a model's minimum, the model is hidden. But if your RAM is unknown, the same model is shown — as a selectable option with a caveat. So "we're not sure" gets you a visible warning, while "we're sure it won't fit" gets you silence. If a caveat is the right pattern for the uncertain case, it's hard to argue silence is right for the certain one.
Where I'm leaning: show premium models that don't fit, but disabled, with a plain-English reason — "needs 32GB RAM; this Mac has 24GB." The information is worth more than the tidiness. But I haven't shipped it, partly because every extra row on a first-run screen has a real cost, and partly because I'm wary of designing for the edge case at the expense of the common one. I'd value the argument either way.
The principle underneath
Strip out the specifics and this is an inclusion question wearing an engineering costume. Not everyone has a top-spec machine. In government especially, the hardware is standardised and deliberately modest. Designing the experience around the capable, common device — and being honest and respectful about the limits of the modest one — is the same instinct that drives the rest of this tool.
The app should do the hard work of fitting the model to the person. It should never make the person do the work of fitting themselves to the model. The only open question is how loudly to tell them about the doors their current machine can't yet open.
Prompt to Page is an independent project by Courtney Allen. It is not affiliated with, endorsed by, or connected to the Government Digital Service, the Crown, or any UK government body. "GOV.UK" and the GOV.UK Design System are referenced descriptively.