Introduction

Most UI kits ask you to install a package, import a black box, and hope the escape hatches cover your design system. That works until a product need falls outside the package: a different interaction model, a custom layout, or a control that simply is not in the kit.

Cubix takes the opposite path. Components ship as TypeScript source in your repository. You theme them with CSS variables, compose them with a consistent API, and change anything without wrapping someone else's abstraction.

What you get out of the box:

• Owned source - every control lives under components/cubix, ready to edit.
• One visual API - install against Base UI, React Aria, or Radix UI without redesigning your app.
• Token-first theming - oklch colors, radius, and typography as CSS variables you can restyle in one place.
• AI surfaces included - conversation, prompt input, tool call, thinking, and related blocks for agent UIs.
• CLI + registry - add components with npx cubix@latest from a flat-file registry.

Source you own

Cubix is not a compiled dependency you fight with overrides. The CLI copies real files into your project. That means full visibility into markup, variants, and accessibility wiring - and the freedom to delete, rename, or extend anything.

Need a button that behaves differently for your product? Open components/cubix/button.tsx. No wrapper layer. No waiting on an upstream release for a one-line change.

Three bases, one Cubix API

Accessibility backends are not one-size-fits-all. Teams standardize on Base UI, React Aria, or Radix UI for different reasons. Cubix keeps the product-facing API aligned across all three so you can pick a primitive stack without rewriting screens.

• Base UI - default base for new projects.
• React Aria - when your stack already centers on Adobe's accessibility primitives.
• Radix UI - when you prefer Radix primitives under the same Cubix surface.

Switch with --base aria or --base radix when you add components. Visual variants, tokens, and data-slot structure stay consistent.

Design tokens, not one-off styles

Cubix components speak a small set of semantic tokens: background, foreground, muted, accent, primary, destructive, border, input, and ring. Light and dark palettes live in globals.css as oklch values.

Restyle the product by editing variables. Dig into component files only when structure or behavior must change. See Theming for the full token map.

Built for agent interfaces

Modern products need more than forms and dialogs. Cubix includes first-class pieces for AI chat and agent workflows: conversation shells, prompt input, streaming text, thinking states, tool calls, code blocks, and related patterns - plus ready-made blocks you can drop into an app shell.

Same ownership model as every other component: copy the source, wire your backend, ship.

Registry and CLI

Components are published as registry items - JSON that lists files and dependencies - and installed with the Cubix CLI. That keeps distribution predictable for humans and for tooling that generates or updates UI from the same schema.

Start a project with Installation, then add what you need with the CLI. When you are ready to publish your own set, use the Registry docs.

Framework support

Because Cubix is React source plus Tailwind - not a closed runtime - it runs anywhere you can render React. The docs site itself is a Next.js App Router app.