Repo of the day: Astryx, Meta's design system built for agents too

🔍 What Astryx is: eight years inside Meta, now open source

Astryx (npm packages under the `@astryxdesign` scope) grew inside Meta's monorepo for eight years, becoming the company's most-used design system: it powers over 13,000 internal applications, including Facebook, Instagram and Threads. The public repository documents more than 90 React components with full TypeScript support, plus foundations (typography, color, layout, accessibility) and full-page patterns — dashboards, settings, form wizards. Meta's docs site counts over 150: the gap, openly acknowledged by the project, is components that exist internally but aren't yet documented for external use.

The styling foundation is StyleX, the compile-time CSS engine Meta open sourced at the end of 2023 and that today powers Facebook, Instagram, WhatsApp and Threads, and has also been adopted by outside companies like Figma and Snowflake. It's a Babel plugin that extracts every style declaration at build time, converts it into deduplicated atomic CSS classes, and emits a static stylesheet: the CSS bundle stops growing in proportion to the app's size. In Astryx this stays invisible to consumers — you import pre-built CSS, no Babel or PostCSS config needed — while themes are cascades of CSS custom properties: change the token values and every component restyles, with no component code changes required.

repo       facebook/astryx
language   TypeScript 74.8% · JavaScript 24.5% · license MIT
version    v0.1.6 (Jul 15, 2026) · public beta since Jun 18, 2026
what       React + StyleX design system, CLI and MCP server for agents
packages   @astryxdesign/core, /cli, /build, /theme-{neutral,butter,...}
stars      ~9,100 · 671 forks (snapshot as of July 20, 2026)

⚙️ Getting started: Next.js, one theme, no build plugin

Onboarding is deliberately frictionless: Astryx ships pre-built CSS, so in a Next.js project with Tailwind you don't need any build plugin, PostCSS, or Babel config. You install `@astryxdesign/core` plus a theme package — say `@astryxdesign/theme-neutral` — and, for the command-line side, `@astryxdesign/cli` as a dev dependency. A Tailwind bridge maps the design system's tokens onto recognizable utilities: instead of writing `bg-[var(--color-background-surface)]` you use `bg-surface`, which resolves to the same token.

The rest is a `Theme` provider wrapped around your app in `providers.tsx`, and components are ready to use: `import {Button} from '@astryxdesign/core/Button'` and you're off. The same steps apply, with slightly different imports, to a Vite setup or to plain StyleX without Tailwind — that's the project's choice, not an Astryx constraint. I also found `astryx swizzle Button` useful: it ejects a component's source into your project when the customization you need goes beyond what tokens can cover — internals are open and composable, not hidden behind a closed top-level API.

npm install @astryxdesign/core @astryxdesign/theme-neutral
npm install -D @astryxdesign/cli

# globals.css: import the reset, Astryx's CSS and the Tailwind bridge
# providers.tsx: <Theme theme={neutralTheme}>{children}</Theme>

import {Button} from '@astryxdesign/core/Button';
<Button label="Hello XDS" variant="primary" />

🤖 The part that matters: CLI, JSON manifest, and an MCP server

This is where Astryx sets itself apart from every other design system I've looked at so far. The CLI — invokable as `astryx` or the shorthand `xds` — has commands to search (`search`), document (`component`, `docs`, `hook`), scaffold (`template`, `init`), migrate (`upgrade`) and diagnose (`doctor`) your project. Every command supports `--json` and returns a typed envelope (`{type, data}`); errors carry a stable, machine-readable `code` — append-only, its meaning never changes once shipped — explicitly designed to be branched on in code instead of parsed from a human-readable message.

The command that justifies the feature on its own is `astryx manifest --json`: it returns a self-describing payload listing every command, its arguments, its flags (with types, allowed values and defaults), and the response types each command can emit — an OpenAPI spec applied, for what looks like the first time, to a frontend design system's CLI. The manifest is derived from Commander's metadata, so it can't drift from the real command definitions, and it's guarded by a drift test in CI. A separate MCP server exposes the same logic to compatible agents — Claude Code, Cursor, GitHub Copilot — over JSON-RPC 2.0: the agent scaffolds projects, browses components with the composition hints in their JSDoc, generates themes and retrieves structured documentation, using the same API a human developer would use from the terminal.

npx astryx search button          # components, hooks, templates in one shot
npx astryx component Button --props --json
npx astryx manifest --json        # the whole CLI as a machine-readable spec
npx astryx doctor                 # health check, exit code for CI

🏢 Why it matters, for developers and SMBs

For developers, the JSON manifest changes the nature of the most common failure mode when an agent writes UI: no longer a plausible but nonexistent prop, but — at worst — an `ERR_UNKNOWN_COMPONENT` error, complete with a suggested closest match. On top of that come practical details that cut everyday friction: context-aware spacing that avoids the classic "double padding" issue when nesting containers, ready-made page templates so you don't rebuild every dashboard from scratch, and `swizzle` for the cases where you genuinely need to get into a component's source.

For an SMB evaluating internal tools — admin panels, monitoring dashboards, back-office forms — Astryx lowers the cost of a polished interface without a dedicated frontend team: an agent can scaffold a `dashboard` or `settings` template, apply a company theme by changing only the CSS tokens, and produce a consistent result across several internal tools. The theme cascade (seven published packages: neutral, butter, chocolate, matcha, stone, gothic, y2k) makes even the textbook case plausible — multiple brands, the same component set — without rewriting a single component.

⚠️ The limits to know before adopting it

Astryx is openly in public beta: the CLI is at v0.1.6 (July 15, 2026), the API surface can still change, and two packages — `@astryxdesign/lab` (experimental components, used only internally for Storybook and the sandbox) and the Vega/Vega-Lite chart wrapper — have no stable npm release yet: they're published only under the `@canary` tag. Anyone who needs charting components today won't find them in a stable release. The usual principle applies: a daily pick is a starting point for an evaluation, not a finished due diligence.

An independent RepositoryRadar analysis of the repository, updated on July 16, 2026, logs a bus factor of 2: two people together account for more than half of the commits over the past six months, worth keeping in mind for anyone planning a long-term integration. There's also the declared discrepancy in component counts — 90+ in the repository, 150+ on Meta's docs site — which reflects real components not yet documented for external use, not a capability limit.

• Public beta, still young: born from an eight-year internal project, but public for less than a month; the API can still change.
• Bus factor of 2: two maintainers account for the majority of recent commits per RepositoryRadar — a concentration risk worth weighing.
• Two unstable packages: `@astryxdesign/lab` and the Vega/Vega-Lite wrapper are `@canary`-only, no stable npm release.
• Mismatched component count: 90+ in the repo, 150+ on Meta's site — real components, just not yet documented externally.

✅ Where to start

The path I'd suggest: install `@astryxdesign/core` plus a theme in a non-critical project, run `npx astryx doctor` for an at-a-glance check (Node version, version alignment, peer dependencies, theme installed), then explore with `astryx search` and `astryx component <Name>` before writing your first line of UI. If you're already working with an MCP-compatible agent, connect Astryx's MCP server and have it scaffold a `dashboard` template: it's the fastest way to see what actually changes compared to a design system without this layer.

Zooming out, Astryx is a useful case study in where agent tooling is headed: the Model Context Protocol powering its server, introduced by Anthropic in late 2024, was donated to the Linux Foundation in December 2025 and is now also adopted by OpenAI and Google DeepMind. The implication Astryx doesn't state outright, but that its architecture makes clear, is that any tool — not just a design system — can become reachable by every MCP-based agent by publishing the same kind of structured manifest.

More articles from the blog