BoardUI: the free tier, generated from a paid source tree, with an open chat on your key

The repository is generated and takes no pull requests

One sentence in the page settles the governance question. This repository is generated from the vendor's own source and takes no pull requests, with a pointer to a contributing file for anyone who read past it. That is the whole free tier, as source files, and the project's own pitch is that the homepage is a working chat running on your key rather than a catalogue page. Two consequences follow. Anything you want changed goes to the vendor, not to the repository, and your GitHub fork will not receive the generated updates, so refreshing component source later is a manual merge you have to own. The page does say what to do about that in its right-to-left section, telling you to preserve your own changes before refreshing source and global styles. It is a sensible arrangement for a design system with a paid tier above it, and an unusual one to meet on a code hosting site.

The provider is chosen by looking at your key

There is one environment variable, and the routing table reads it like a switch. A key beginning with one prefix routes to one provider and one default model: an Anthropic prefix gets a small Claude model, an OpenRouter prefix gets a nano GPT, a plain prefix gets OpenAI, a Google prefix gets a flash Gemini, a gateway prefix gets a nano GPT, a Groq prefix gets a 70-billion Llama, and an xAI prefix gets a fast non-reasoning Grok. Two escape hatches exist because the scheme cannot cover everything. Providers whose keys have no recognisable shape, Mistral and DeepSeek among them, are named explicitly with a provider variable, and any OpenAI-compatible server, whether Ollama, LM Studio, vLLM, LiteLLM or Together, is reached with a base URL and a model, because an arbitrary server has no default worth guessing. The usual provider variables work too.

A spending cap on the key is the only cost control

This is the sentence to read twice before you deploy the demo. The key never reaches the browser, because the request handler reads it server-side and streams the reply back, but the chat itself is open to anyone who has your URL, so the cap is what bounds the cost. The project is unusually direct about the mitigation: create the key with a spending limit where the provider offers one, and it names two that do, a credit cap on OpenRouter and per-project usage limits on OpenAI. So the security property here is not authentication, it is containment. A deployment of this starter with an uncapped key is an open relay onto someone's model account, and no amount of care about where the secret lives changes that, since the secret is not what is exposed. Put a cap on the key before the first deploy, not after the first invoice.

npx boardui add copies files instead of adding a dependency

The installation model is the interesting part of the design system. Nothing is imported from a package at runtime: the command copies the component source into your project, so you own the files and can change anything. Three forms of that one idea are offered, and the CLI is the shortest of them:

npx boardui@latest list
npx boardui@latest add data-table
npx boardui@latest add --all

A listing command prints every component one line each, a second takes a component name and installs it with its dependencies, and a third installs everything in the repository. The same catalogue is reachable from an agent, since the project ships an MCP server that any client can register, with a one-line command for Claude Code and an equivalent JSON block for everyone else, including a configuration file for another editor in the repository. Once an agent has it, the instructions are given in plain sentences: ask for every free component at once, or ask for a table and some stat cards and let it wire them in.

Direction and translation are separate, and CSS direction is not enough

The right-to-left section is the most technically careful text in the repository, and it opens with a warning that surprises people: setting the direction in CSS does not configure keyboard navigation, calendars or portalled menus, because those come from the accessibility layer underneath. The app solves it by nesting a direction provider, so a region in a different language gets its own provider rather than inheriting one, and by pairing the document attributes with the provider so they are changed together. The layout guidance is equally concrete, using logical inset and margin pairs and start and end text alignment instead of left and right, mirroring navigation arrows and drawer motion, and passing the resolved direction to custom portal roots. Then there is the rule people forget: keep email addresses, URLs, code and one-time-passcode digits in left-to-right regions, while their fields still align with the surrounding layout.

Sixty-six items, four hundred tokens, and no runtime CSS

The catalogue is described as sixty-six free items covering base components, application blocks, tokens and a type scale. The token count is given as more than four hundred semantic tokens, with light and dark produced from the same class names, and the design intent is stated as Figma first, meaning the design file is the source of truth rather than a set of exported images. Underneath sits an accessibility-first stack: a component library for accessible React primitives with a utility CSS framework layered on top, and the project is explicit that there is no runtime CSS. That combination explains the install model. If the styles are generated from tokens rather than shipped as a stylesheet dependency, copying source files into your project keeps working when the package is not there, which is exactly what the source-first pitch needs.

Chat history lives in the visitor's browser and there is no database

The application in the repository is small and its boundaries are stated. There is a chat at the root route, a dashboard with the two charts that are free, and sign-in and sign-up screens, all built from the components in the same repository rather than from somewhere else. Conversation history is kept in the visitor's own browser and the project says plainly that there is no database. That makes it a demo you can fork without provisioning anything, and it also means history is per-device and per-browser, so it is not a place to keep a transcript you care about. The one server-side piece is the chat route, which exists to read the key and stream the model reply, and that split is the reason the key can stay off the client.

The manifest ships a typecheck script and nothing that tests

The package manifest is worth reading for what it reveals. The project is named after the starter rather than the system, and it is marked private, which is consistent with a repository meant to be cloned or deployed rather than installed. The dependency list is a coherent picture of what the demo needs: three provider packages for the model SDK alongside the SDK itself, a chart library for the two free charts, an accessible React primitives library, a table library, a date library, an icon set, an animation library, a class-merging utility and a schema library, on Next 16 with React 19 and Tailwind 4. What is missing is as informative as what is there. The scripts are development, build, start and typecheck. There is no test runner, no linter and no formatter in the manifest, in a repository whose entire subject is visual consistency.

Editorial conclusion

BoardUI is worth a look if you want agent-facing components as files you own rather than as a package you depend on, and the RTL work is the part most design systems get wrong, with logical properties, nested direction providers and LTR islands for codes. Two things to be clear about. The repository is a generated export that takes no pull requests, so your route to changes runs through the vendor, not the tracker. And the demo chat behind your own key is unauthenticated and reachable by anyone with the URL, which is why a provider-side spending cap is not optional for a deployment you care about.

Frequently asked questions

Official sources

1. BoardUI/boardui on GitHub
2. Issues
3. License: MIT
4. Project website
5. README