OpenCode for design.

What OpenCode actually is

OpenCode is an open-source AI coding agent built for the terminal, maintained by the team behind SST (Anomaly Innovations). It reads your repository, runs commands, edits files, and talks to a large language model — but unlike vendor-bound agents, it does not ship its own model. You point it at whatever provider and model you want and bring your own key.

It runs as a terminal UI (TUI), with a desktop app and IDE extensions on top of the same engine. Under the hood it uses a client/server architecture, so the agent that does the work is decoupled from the surface you drive it from. Two built-in agents — build and plan — toggle with the Tab key.

• Model-agnostic: Models and providers come from models.dev, an open catalog. You configure them in opencode.json with a provider/model-id string and can disable providers you do not want loaded — so the same design workflow runs on Anthropic, OpenAI, Google, OpenRouter, local models, and more.
• Instruction file: OpenCode reads an AGENTS.md file in your project (the cross-tool standard, also compatible with CLAUDE.md) for project rules — the natural place to encode your design conventions. Run /init to generate one.
• Extensible: It supports LSP integration, MCP servers, themes, keybinds, and custom commands, plus shareable session links for collaboration.

• Maintainer: SST / Anomaly Innovations (open-source project)
• Credential: your own model-provider API key(s) — BYOK, no vendor lock-in
• License: MIT, open source

Why an open, any-model agent fits design work

OpenCode does not have a single “design model” the way a vendor agent does — and that is the point. Because it is model-agnostic and open, you can run the same design workflow on whichever model is currently best at frontend, swap it later, or fall back to a local model, all without changing your setup.

But model choice alone does not buy taste. Like every coding agent, OpenCode produces generic UI unless you give it constraints. Good design output comes from three inputs you provide.

• A design system: Real tokens, primitives, and conventions the agent reuses, so output matches a brand instead of defaulting to a generic look.
• An aesthetic skill: A curated skill that enforces real taste — restrained motion, brand-first hierarchy, at most two typefaces and one accent color — and makes the agent commit to a direction before building.
• Concrete references: Actual reference images and multiple states (desktop and mobile, hover, empty, loading), not a single hero shot.

The lesson: OpenCode gives you model freedom, but taste still comes from a curated design context. Open Design packages exactly those inputs, which is why the two fit together — both are open-source and local-first (more below).

Set up OpenCode for design work, from zero

Here is the full path from a clean machine to an OpenCode that can build and verify UI.

# 1. Install OpenCode
curl -fsSL https://opencode.ai/install | bash
# or: npm i -g opencode-ai@latest
# or: brew install sst/tap/opencode

# 2. Start the TUI in your project, then authenticate your provider
opencode          # then run /login and pick your provider + paste your key

# 3. Generate project context
opencode          # inside your project, run /init to create AGENTS.md

# 4. Pick your model (any provider, via models.dev)
#    set "provider/model-id" in opencode.json or switch in the TUI

# 5. Add an MCP server (optional, e.g. for design handoff)
#    configure it under the "mcp" key in opencode.json

• Encode your design rules: Put your tokens, primitives, and conventions in AGENTS.md (or a DESIGN.md referenced from it) so output matches a brand instead of defaulting to a generic look. The instructions option in opencode.json can point at additional rule files via globs.
• Choose a capable model: Because OpenCode is model-agnostic, pick whichever provider/model is currently strongest at frontend for the design pass — and keep the rest of your workflow unchanged.

The screenshot-to-UI workflow

The highest-leverage design loop with any agent is turning a reference image into working, responsive UI and iterating until it matches. The same five-step shape applies in OpenCode.

1. Start from the clearest visual references you have — and include multiple states (desktop and mobile, hover, empty, loading), not just one hero shot.
2. Be specific in the prompt; vague prompts produce generic UI.
3. Prepare a design system and tell OpenCode where the tokens and canonical primitives live (in AGENTS.md).
4. Run a dev server and have the agent render in a real browser, resizing to breakpoints to check the result.
5. Iterate by having OpenCode compare its implementation back to the screenshots — not merely confirm it builds.

Reference files with @ in the TUI for a fuzzy search of your working directory, run shell commands inline with a leading !, and drive actions with / commands. Then prompt with concrete constraints:

opencode
# in the TUI:
> @reference-desktop.png @reference-mobile.png
  Implement this design in React + Vite + Tailwind + TypeScript.
  Reuse my existing design-system components and tokens from AGENTS.md.
  Match spacing, layout, and hierarchy; make it responsive.
  Run the dev server, open it in a browser, and iterate until the
  UI matches the references across breakpoints.

Keep prompts small and focused, commit good iterations and revert bad ones (telling OpenCode when you revert), so each pass builds on a clean base.

AGENTS.md, MCP, and shareable sessions

Three extension points make OpenCode practical for sustained design work, and all three map cleanly onto an open design workflow.

• AGENTS.md rules: Project rules live in an AGENTS.md at the repo root (or global rules in ~/.config/opencode/AGENTS.md). It is the durable home for your design conventions, read on every run, and it is compatible with the CLAUDE.md files other agents use.
• MCP servers: OpenCode supports both local (command) and remote (URL) MCP servers, configured under the mcp key — the portable way to bring in design context and external tools that work across agents, not just OpenCode.
• Shareable sessions: The /share command creates a public link to a conversation for collaboration or review, and /unshare revokes it — useful for getting feedback on a design pass.

These are portable, multi-agent capabilities — exactly the kind of thing Open Design is built to orchestrate, rather than re-create per project.

OpenCode vs Codex vs Claude Code vs Cursor for design

There is no single winner for design work — each agent has a different strength, and experienced teams stack them. A fair summary:

The recurring community verdict is that taste comes from humans: all of them default to a generic aesthetic without skills, references, and constraints. That is the real problem to solve — and it is design-tool-shaped, not model-shaped, which is precisely why an open agent like OpenCode pairs so well with an open design layer.

Pitfalls, and how to avoid the “AI slop” look

The most common complaint about AI-generated design is that it looks generic — soft gradients, floating panels, oversized rounded corners, dramatic shadows, an Inter-and-purple vibe that “screams an AI made this.” Other reported issues include broken mobile layouts and instructions leaking into UI copy. None of these are unique to OpenCode; they are what happens when any agent runs without a curated design context.

• Add an aesthetic skill: A curated design skill forces the agent to commit to a real direction instead of the default look.
• Verify in a real browser: Render and self-check across breakpoints so layouts do not silently break on mobile.
• Supply tokens and references: Real design tokens and reference screenshots are the single biggest lever on output quality.
• Encode rules in AGENTS.md: Put “no hero cards, max two typefaces, brand-first hierarchy” style rules where the agent reads them every run.

Notice that every mitigation is about giving the agent a curated design context — regardless of which model you run. Maintaining that context by hand, per project, is the toil Open Design removes.

Designing with OpenCode inside Open Design

Open Design is the open-source design layer the workflow above keeps asking for. It treats OpenCode as a first-party adapter and wraps it in a curated skill and design-system library, a structured render pipeline, and a local desktop UI — so the design context that makes any agent good is there from the first run, not assembled by hand each time. Both projects are open-source and local-first, which makes the pairing a natural fit.

1. Install Open Design and select OpenCode as your agent.
2. Authenticate with your own model-provider API key (BYOK) — credentials stay on your machine and are never proxied through us.
3. Pick any provider and model, plus a design system and a skill, then generate decks, prototypes, and landing pages with consistent taste.
4. Every artifact and DESIGN.md file lives in your own repo, not a hosted cloud.

Same OpenCode agent, same model freedom — plus a real, portable, open-source design workflow around it. It is local-first and Apache-2.0, so nothing about your work or your credentials leaves your machine.

Frequently asked questions

1. 01 Can OpenCode really do design work? +

   Yes — with an aesthetic skill, a design system, and real reference images in context, OpenCode produces production-quality, responsive UI and can verify it in a browser. Because it is model-agnostic, you run whichever model is currently best at frontend. Without that curated context it tends to default to a generic look, which is the gap Open Design fills.

2. 02 Which model should I use with OpenCode for design? +

   Whichever you like — OpenCode is provider-agnostic via models.dev, so you can run Anthropic, OpenAI, Google, OpenRouter, or local models behind the same workflow and switch at any time. The quality of the design output depends far more on your skill, design system, and references than on the model alone.

3. 03 Is Open Design made by the OpenCode (SST) team? +

   No. Open Design is an independent open-source project that integrates OpenCode as an agent. It complements OpenCode with a local-first, open skill and design-system library.

4. 04 Do I need a special subscription to design with OpenCode? +

   No — OpenCode is BYOK. You bring your own model-provider API key, and Open Design never proxies your credentials. There is no vendor lock-in.

5. 05 OpenCode or Codex or Claude Code for frontend design? +

   All are strong, and many teams stack them. OpenCode’s edge is being fully open-source and model-agnostic; Codex excels at delegated, sandboxed builds; Claude Code is known for specific, codebase-aware design decisions. Open Design lets you switch agents without changing your design workflow.

6. 06 How do I extend OpenCode for design context? +

   Encode rules in AGENTS.md, add MCP servers under the mcp key for portable tools and design context, and use shareable sessions for review. Open Design ships a curated skill and design-system library so you skip the per-project setup.

7. 07 Is Open Design affiliated with OpenCode or SST? +

   No. OpenCode is an open-source project maintained by SST (Anomaly Innovations); Open Design is an independent open-source project that supports it as a first-party adapter.

8. 08 Are my files and credentials safe? +

   Yes — Open Design is local-first. Your files, artifacts, and DESIGN.md stay in your own repo, and your model-provider credentials are used directly by your agent, never routed through Open Design servers.