Picking the model for the job, step by step

Quiny does not run on one model. Every step of a build is routed to whichever of four models is best for that kind of work at that moment, and this post explains how the routing decides.

The four

• Claude from Anthropic does the careful work: laying out screens and writing the code behind them. It is the most expensive per token and the least likely to produce something that compiles but is subtly wrong.
• GPT from OpenAI does fast drafting: the eight questions, the copy on your screens, quick edits. It is quick and cheap and very good at sounding like a person.
• Gemini from Google reads what you give us: links, product photos and price lists. It is strong at turning an image of a menu into a list of products with prices.
• Kimi K2 from Moonshot handles very long context: the whole app pass before submission, where all five screens and the full conversation need to be in view at once.

We say this on the landing page and people sometimes assume it is marketing. It is an engineering decision that saves our customers money and gets better answers, and the rules are written down.

What the router looks at

Each step that arrives carries a type: screen, code, copy, read, review, or question. For that type we keep a ranking of the four models on three measures.

Fit for the task. Measured offline against a test set of real builds that we re run when a provider ships a new version. A model that scores worse than another on checkout screens will not be picked for checkout screens, regardless of price.

Reliability right now. Measured live. Every call records latency, error rate and whether the output passed our checks. If a provider is having a bad hour, its score drops and traffic moves without anyone doing anything.

Cost. Only considered between models that are within a small margin of each other on fit. We will not send your checkout to a cheaper model to save eight cents. We will send a copy edit to one.

Why it is not just "use the best model"

Because there is no single best model. On our test set Claude is clearly strongest on screen and code steps. Gemini is clearly strongest at reading a photographed price list. GPT is faster and cheaper at copy with no measurable drop in quality. Kimi is the only one of the four that comfortably holds a whole app in context without truncation. Using one model for everything would be worse at three of the four jobs.

What you see

Not much, by design. The console shows each step and, if you look, a small tag such as "high effort" or "long context". Pro and Max plans can pin a model for a workspace, which some developers who hand a Quiny build to their team like to do. Almost nobody else touches it.

What happens when a step fails

The output of every step is checked before it reaches you: code has to compile, screens have to render, prices have to match the knowledge tree. If a check fails the step is retried once on the same model, then once on the next best. If it still fails it is marked as failed, its credits are returned, and a person looks at it. This happens on a small fraction of steps, and the retry catches most of those.

What changes next

Providers ship new versions often. When one does, we run the test set, and if the ranking changes the router changes. You do not need to know. That is the point.