Model decides, code renders.
Built by Brandon Church, opens in a new tab. Open source, MIT.
The idea
Dashboards are drawn once, for the questions someone expected. This one is drawn for the question you ask. Paste a public GitHub repo, ask what you want to know, and an agent picks from a fixed set of components and composes an interface around that repo's data. The model decides what to show and what matters most. Code renders it from the same finished pieces every time, so an answer nobody designed still looks designed.
How it works
Every question runs the same five steps, left to right, in the order the screen draws. The twelve common questions and three follow-ups match a template, and Haiku fills in its words. Anything else goes to Sonnet, which composes from every component. Either way the model writes only a composition. Code draws every piece of it.
On the five sample repos the twelve answers are precomputed, so they open with no model call. A fresh repo's answer finished in 6.2 s at the median in the last eval run.
GitHub API
Public REST and GraphQL reads for the repo you paste.
- Cache15 minutes per repo
- Warminga wait while GitHub counts
Model decides
Composer
Reads the question and the repo's numbers, then picks and arranges components.
RouterHaiku · 15 templates, or none
- Template pathHaikufixed layout · Haiku writes the words
- Off-template pathSonnetfree composition from the registry
JSON composition
The project's own format. Meaning only, never a color or a size.
{
"component": "Metric",
"props": {
"hot": true,
"deltaTone": "crit"
}
}- A2UI adapterthe same tree, for hosts that speak A2UI
Code renders
Renderer
Checks each piece against its schema, then draws it from the components.
- Componentsone Zod schema each, read by the model
- Design tokenstone, emphasis and density become values
Web app
Paste a repo, ask, read the screen.
Next.js on Vercel
MCP App
The same renderer inside a chat host.
compact density
The four layers
- Components
packages/ui - 40 components in one registry. Each has a Zod schema the model reads, every state it can reach, three densities, its own motion and a sample JSON.
- Renderer
packages/renderer - Validates each piece against the registry, diffs the new tree against the current one so survivors morph instead of remounting, and streams pieces in as they arrive. An A2UI adapter works both ways.
- Composer
packages/composer - Takes the question and the repo's normalized data and returns a streaming composition. Haiku picks a template and fills its words; Sonnet composes off-template. It never writes HTML.
- Eval harness
packages/evals - Scores the composer on template, components, hot metrics, schema, bindings, numbers and rules, plus latency and cost, across models.
What the decision model saved
The eval harness runs 99 cases three times per model through the composer itself and scores every answer. Production is the shipped routing: Haiku picks a template and fills it, and Sonnet composes only what no template fits. The other two runs compose every question with one model.
Production's answers used the expected components in 100% of cases, against 24.9% for Sonnet composing freely from the same catalog, at about a sixth of the cost ($0.0021 against $0.0138 per answer).
Sonnet alone was faster: 4.8 s to done at the median against 6.2 s, with its first piece at 2.6 s. A template answer streams nothing until its fill returns, and that latency is the open problem.
Haiku-only matches production on template, bindings and numbers at about a third of the cost; its misses are off-template copy-length and layout rules; Sonnet earns its cost only on off-template rule compliance.
Production against Sonnet alone
All three runs
| Check | Production | Sonnet alone | Haiku alone |
|---|---|---|---|
| Templaterouted to the expected template | 100% | not scored · no routing | 100% |
| ComponentsF1 at least 0.85 | 100% | 24.9% | 100% |
| Bindingsprops match the data | 100% | not scored · no routing | 100% |
| Schemaevery piece valid | 100% | 88.7% | 99% |
| Time to donemedian | 6.2 s | 4.8 s | 6.2 s |
| First piecemedian | 6.0 s | 2.6 s | 6.2 s |
| Costper answer | $0.0021 | $0.0138 | $0.0007 |
Production was run Oct 12 · 16:38 UTC. Sonnet alone composes every question off-template on purpose, so it skips routing, and template and bindings are not scored for it. Haiku alone and production differ only on the 10 off-template cases. Every case, run by run, is on the evals page.
The design system
The model can only choose, so every answer is as good as the pieces it chooses from: the components are the product. Every color, size and space comes from one token file, density is set once on the screen and never per card, and motion is a short list of moves in which every exit is its entrance in reverse. See every component in every state
Meaning, not values
The model sends tone, emphasis and density. Color, size and spacing come from the system, so one state always reads one way.
Nothing appears without a cause
Every piece draws, wipes, extends, slides, counts or blooms into place. Nothing fades in from nowhere.
Every enter has a reverse
A new answer runs its exits just ahead of its entrances. Pieces that survive morph in place.
Warm, light, quiet
One coral accent marks what the model chose. Everything else is warm ink on warm white.
What it does not do
- No persona toggle
- The question already says who you are. A maintainer and a first-time contributor ask different things and get different screens.
- No chatbot
- Answers are interfaces, not transcripts. The next question is a chip or one line in the tray.
- No private repos
- Public data only, read on the server with a read-only token, so there is nothing to authorize and nothing to leak.
- No accounts
- Nothing to sign up for and nothing you paste is stored. The only visitor state is a daily question count keyed on a hash.
- No writes to GitHub
- An action card drafts an action and shows it. It never writes to GitHub.