Open Design is the open-source, Apache-2.0, local-first answer to Anthropic's Claude Design. It ships zero models. A local Node daemon scans PATH for a coding-agent CLI — Claude Code, Codex, Cursor Agent, Gemini, OpenCode, Qwen, Copilot — and turns whichever it finds into a design engine driven by 19 composable Skills and 71 brand-grade Design Systems. No subscription, no cloud lock-in, briefs stay on your laptop.
Anthropic shipped Claude Design on 2026-04-17 — a hosted, Pro/Max-gated design canvas built on Opus 4.7. Eleven days later, nexu-io/open-design shipped the open-source counterpart. Same job; opposite shape.
Open Design (OD) is a web app plus a local Node daemon. The daemon's only job is to find whichever coding-agent CLI you already have on PATH and route design briefs through it. Skills are folders of structured prompts (SKILL.md + example.html anchor). Design Systems are DESIGN.md files describing colour, typography, spacing, motion, voice. The daemon assembles a prompt stack from the active Skill + Design System and hands it to the CLI. The CLI emits HTML; OD renders it in a sandboxed srcdoc iframe and offers exports to PDF, PPTX, ZIP, and Markdown.
This is a thin wrapper around tools you already pay for. If you have Claude Code, OD spawns it. If you have Codex CLI, OD spawns it. If you have nothing, OD falls back to an OpenAI-compatible BYOK proxy at /api/proxy/stream — point it at DeepSeek, Groq, OpenRouter, the Anthropic API direct, or your own self-hosted vLLM / Ollama.
OD is two weeks old as of 2026-05-02. ~80 GitHub stars, 9 forks, 3 commits. The architecture is sound and end-to-end working — daemon, IPC, sandboxed preview, BYOK proxy, the 5-dimensional self-critique — but the ecosystem is moving weekly and several things you'll see on LinkedIn are inflated.
Numbers to NOT propagate:
alchaincyf/huashu-design before being quoted.The daemon's boot sequence is short. It scans PATH for one of seven supported CLIs, picks the first match in priority order, registers a typed five-field stamp (app · mode · namespace · ipc · source), and starts listening on a local Unix socket. The web UI proxies design briefs through that socket; the CLI does the work; the agent's output renders in an isolated iframe.
The auto-detect priority is fixed: Claude Code → Codex CLI → Cursor Agent → Gemini CLI → OpenCode → Qwen Code → GitHub Copilot CLI. To force a specific adapter regardless of what's on PATH, set OD_FORCE_AGENT=codex pnpm dev. If none of the seven are found, the daemon enters BYOK proxy mode and the UI surfaces an OpenAI-compatible config form (baseUrl, apiKey, model).
To boot it locally:
# Quickstart — daemon + web UI git clone https://github.com/nexu-io/open-design cd open-design pnpm install && pnpm dev # UI opens at http://localhost:5173 # Daemon binds to /tmp/open-design/ipc/<namespace>/<app>.sock # Force a specific CLI (skip auto-detect) OD_FORCE_AGENT=codex pnpm dev # Anthropic API directly (no Claude Code installed) ANTHROPIC_API_KEY=sk-ant-… pnpm dev # Allow BYOK proxy to hit a LAN-hosted vLLM (off by default) OD_PROXY_ALLOW_PRIVATE=1 pnpm dev
Before emitting an artifact, the agent runs a 5-dimensional self-check sourced from alchaincyf/huashu-design. The full prompt lives at src/prompts/discovery.ts in the OD repo. Two things matter when quoting it: the dimensions are real, but the labels and threshold popularly cited on LinkedIn ("philosophy / hierarchy / execution / specificity / restraint, scores below 3/5 regenerate") are not yet verified against the source — fetch discovery.ts directly. And it is a prompt-stack rubric, not a separate model. Performance depends entirely on the underlying CLI's instruction-following: strong with Opus 4.7 / Sonnet 4.6 / Codex; weaker with smaller open models.
When the user has no brand to load, OD shows a Direction Picker: 5 curated visual schools (Editorial Monocle, Modern Minimal, Tech Utility, Brutalist, Soft Warm). One radio click → deterministic OKLch palette + font stack, no model freestyle. This is the whole bet on consistency — the agent doesn't get to invent the colour story, it gets handed one. When the user does have a brand, the active Design System (Linear, Stripe, Tesla, Notion, Apple, …) is injected into the prompt stack instead. Either way, the visual system is data the model reads, not a vibe the model invents.
The architecture is clean. The footguns are operational — spawn behaviour on Windows, namespace collisions in SQLite, license carve-outs, and the gap between "5-dim critique runs" and "5-dim critique produces consistent output". Worth knowing before you bet a client deliverable on it.
OD doesn't error if it can't find a coding-agent CLI; it falls through to the proxy. If you expected Claude Code to be driving and the proxy is engaged instead, you're paying twice (CLI subscription + BYOK provider) and getting the wrong run. Always which claude-code before booting.
Adapters that hit the 32 KB CreateProcess argv limit (Codex, Gemini, OpenCode, Cursor Agent, Qwen) route through stdin. When stdin overflows, the daemon falls back to a temp prompt file. Don't "fix" prompt truncation by truncating the prompt — check OD_LOG_LEVEL=debug for the actual spawn path.
OD_DATA_DIR namespace collisions corrupt SQLite
Running Playwright tests, a beta channel, and your real project against the same OD_DATA_DIR will corrupt the database. Always --namespace per profile (prod, test, beta). Each gets its own session/history/exports tree.
The skills/guizang-ppt/ sub-folder is bundled verbatim from op7418/guizang-ppt-skill and retains its original MIT licence. Top level is Apache-2.0. If you fork OD, preserve the sub-folder's LICENSE and the op7418 attribution.
Don't promise customers regeneration semantics that depend on a specific underlying model. The same critique prompt produces tighter loops on Opus 4.7 than on Qwen 32B. Frame it as a quality bias, not a guarantee.
Two genuine Claude Design wins that OD doesn't yet match. Claude Design can grab elements from a live site and build a Design System by reading your codebase. OD requires manual DESIGN.md authoring (or an import from awesome-design-md). For "make this look like our actual product" workflows, OD lags.
For SA-based design teams, three first-class concerns — data protection, currency exposure, and operational continuity — all tilt the same way. Open Design is materially better fitted than Claude Design across all three. Worth being precise about why.
Condition 4 — Further Processing Limitation (s15). Briefs and brand assets uploaded to Claude Design flow to Anthropic's US infrastructure. Anthropic's terms permit data being used to improve services unless commercial-tier terms apply. That's a further-processing event the responsible party must justify. With OD on a local CLI, the brief is processed under the CLI's existing terms (the same ones you already accepted for code work). With local Ollama, nothing leaves the device.
Condition 7 — Security Safeguards (s19). OD's daemon edge blocks SSRF to loopback, link-local, and RFC1918 addresses by default. Credentials are stored at file mode 0600. The sandboxed srcdoc iframe isolates rendered artifacts. These are the kind of "appropriate, reasonable technical and organisational measures" Condition 7 contemplates — documentable in your DPIA without hand-waving.
Cross-border transfers (s72). Claude Design = automatic transfer to the US. OD with local Ollama = no transfer. OD with a US BYOK provider has the same s72 concern as Claude Design, so the advantage only materialises if you point BYOK at a SA/EU-hosted model provider.
| Tool | Per seat USD | Per seat ZAR @ R19/USD | Annual ZAR (6 seats) |
|---|---|---|---|
| Claude Pro | $20/mo | R380/mo | R27,360 |
| Claude Max 5× | $100/mo | R1,900/mo | R136,800 |
| Claude Max 20× | $200/mo | R3,800/mo | R273,600 |
| Open Design | $0 | R0 | R0 + your existing CLI spend |
Stage 4–6 = ~2.5–4.5 hours offline per cycle, sometimes back-to-back. UPS coverage on a router + laptop buys 30–90 minutes; international peering has its own resilience profile. Claude Design needs uplink + Anthropic availability, which together fail more often than either alone. OD on a local CLI needs uplink only for the model API call — tethered LTE/5G usually works through a stage-6 evening. OD with local Ollama (e.g. qwen2.5-coder:32b on a 32GB MacBook) needs zero internet. A charged laptop and four hours of stage 6 = a full design session, on the couch, no compromises.
Both are first-draft tools. Neither replaces a senior designer for production polish. Pick on workflow fit, not feature counts. The hybrid — Claude Design for the first 30 minutes of stakeholder exploration, then OD to ship from — is what most SA teams actually want.
DESIGN.md manually (or import from awesome-design-md) — OD has no codebase auto-onboarding.Use Claude Design for the first 30 minutes of stakeholder exploration — the slider UX is genuinely faster for "what if it were warmer / what if the typography were heavier" conversations with non-technical collaborators. Then export to HTML, drop into the Open Design workspace, and iterate to ship from there. That's roughly R380/mo for the design lead's Claude Pro seat plus zero for the rest of the team's OD usage. The catch: design tokens drift between the two tools, so the second iteration in OD has to re-anchor to your DESIGN.md rather than trusting Claude's first-draft output as canonical.
OD sits at the intersection of design, agent tooling, and SA-first defaults. The connections below are the ones worth holding in your head when deciding what role this tool should play in a given build.
DESIGN.md-style files (colour, typography, spacing, motion) are the runtime that consumes that shape.web-prototype, dashboard, mobile-app) implicitly assumes a component library; the Direction Picker overlays a token system on top.PATH, it's the engine. The skills system inside Claude Code and inside Open Design share the same canonical-file philosophy — a SKILL.md the agent reads to get capable.The repo is the canonical source — the README, the src/prompts/discovery.ts file, and the open-codesign sibling project all evolve weekly. Re-fetch before quoting any specific number in a client deliverable. Validation date for this leaf: 2026-05-01.