OpenCode vs OpenChamber — which web UI can you actually make yours?

🎯 TL;DR — the honest answer

There is no Next.js, no Vue, no PHP and no hand-written HTML app in either project. Both interfaces are TypeScript single-page applications built with Vite. The real difference is the UI library and the amount of product surface you inherit:

🧱 Stack comparison — what is actually inside

Two things surprise most people:

• Neither web UI is server-rendered. Both are SPAs talking to a local API over HTTP + Server-Sent Events. There is no Next.js, no SSR framework, no PHP, no templating engine. If you know React or Solid and Vite, you already know the build.
• The Astro site in the OpenCode repo is not the app. packages/web is the opencode.ai documentation website (Astro + Starlight). The actual product UI is packages/app. Do not confuse them when planning edits.

🗺️ Architecture: who serves what

This is the single most important structural difference for customisation, because it decides what you have to rebuild and redeploy.

OpenCode ships one artifact that is both UI host and API. OpenChamber is a separate application server that talks to OpenCode from outside.

Practical consequence: in OpenCode, changing the UI means rebuilding the app and repackaging it into the binary (or running the Vite dev server against a live server). In OpenChamber, the UI is a static bundle served by a normal Node process — you can drop a rebuilt dist/ in, run it behind Nginx or Cloudflare, restart the process, and you are done. That is a big operational difference if you intend to run this for more than one machine.

🔵 OpenCode web in depth

What the web surface is made of

The honest scale note: the average file is small (7.2 MB over 680 files), the biggest frontend files are translation dictionaries, and the component library is mostly icons. That makes the app less intimidating than the numbers suggest — but it is still SolidJS, which many developers have never written.

How you run and edit it

# use it
opencode web --port 4096                 # UI + API on one origin
OPENCODE_SERVER_PASSWORD=secret opencode web --hostname 0.0.0.0
opencode serve --cors https://my-ui.example   # API only, for your own frontend

# develop it (two terminals, from the repo root)
bun install
bun dev serve --port 4096                # backend
bun run dev:web                          # Vite dev server for packages/app
bun run dev:desktop                      # Electron shell
bun run dev:www                          # docs site

Theming reality

Colours are not hard-coded into components. The app imports @opencode/ui/styles/tokens and styles everything from semantic variables such as --v2-background-bg-base, --v2-text-text-base, --v2-border-border-base and --v2-icon-icon-accent. A compact theme preload script (packages/app/public/oc-theme-preload.js, inlined at build time) applies the saved theme before first paint, so a rebrand does not flash.

This means a visual rebrand is genuinely a small job: edit packages/ui/src/styles/tokens/theme.css (or override the variables), swap the logo and fonts in packages/app/src/index.css, rebuild. No component surgery required.

Extensibility without forking

• @opencode/plugin is a published server/TUI plugin API, with an Effect-based variant and an RPC contract.
• Plugins can add tools, providers, commands and TUI behaviour, and are loaded from config.
• The browser plugin host (gui-plugins) exists, but the package is marked private — it is the maintainers' internal surface, not a stable public contract for your own web panels.

So: you can extend the engine cleanly without touching its UI, but you cannot plug arbitrary new UI panels into the stock web client without forking packages/app.

🟢 OpenChamber web in depth

Monorepo map

How you run and edit it

# install / run
bunx @openchamber/web serve --port 3001     # or: openchamber serve
# it connects to your local OpenCode server, then proxies sessions to the browser

# develop it (from the repo root)
bun install
bun run dev            # HMR: UI on :5180, API on :3902
bun run build:web      # production UI bundle
node ./scripts/dev-web-hmr.mjs

Theming is a first-class product feature

This is where OpenChamber clearly wins. Themes are data, not code:

• ~40 built-in palettes as JSON (packages/ui/src/lib/theme/themes/*.json), each with light and dark variants.
• Drop your own file in ~/.config/openchamber/themes/my-theme-dark.json, press Settings → Appearance → Reload themes, and it appears in the dropdown. No rebuild.
• Import any VS Code theme from Open VSX, or a local .json/.jsonc file — the importer maps surfaces, syntax tokens and diff colours onto OpenChamber's roles.
• A validation layer rejects unsafe CSS values and ignores broken themes instead of breaking the UI.

{
  "metadata": { "id": "my-theme", "name": "My theme", "variant": "dark" },
  "colors": {
    "primary": { "base": "#da7c47" },
    "surface": {
      "background": "#120f0e",
      "foreground": "#c9c5ba",
      "muted": "#0e0c0b",
      "mutedForeground": "#8f8b81",
      "elevated": "#181715"
    },
    "interactive": { "border": "#242323" },
    "status": { "error": "#da5b4a", "warning": "#c67f13", "success": "#76ad4f", "info": "#479fe6" }
  }
}

Extensibility and hosting

• Extensions are built against @openchamber/sdk (browser IIFE panels + Node services). The built-in registry is empty today, so this is a real but young surface.
• Hosting is designed in: WebAuthn login, PWA install, Web Push, reverse-proxy documentation, Cloudflare/Ngrok tunnel support, and an end-to-end encrypted private relay for remote devices.
• Feature density is much higher than OpenCode's web client: multi-run comparison, session goals, changes walkthrough, integrated preview inspector, GitHub issue-to-PR flow, scheduling, project folders, notes and todos.

📊 Editability scorecard

Scores are my assessment from source structure, build configuration and dependency weight — 1 is painful, 5 is easy. They are opinion, not upstream data.

A third option beats both on control and is often overlooked: your own frontend on top of opencode serve. You write exactly the screens you want in whatever framework you like, and you inherit zero UI debt. It scores ~34/40 on these criteria but costs more upfront than a theme change.

🧩 Where to touch for your changes

Two editing rules that will save you days on either repo:

1. Never start by editing components. Change tokens first and screenshot. Half of "customisation" ends there.
2. Never let your fork drift on main/dev. Keep your changes in a small set of theme files and a handful of components, so upstream pulls stay trivial. The moment you rewrite the session layer, you have adopted the project.

🧭 Decision guide by goal

🚀 Recommended plan

Step 1 — Decide what "customise" means (30 minutes)

Write down which of these you actually need: colours/logo, layout changes, new screens, different agent behaviour, multi-user hosting. The answer selects the path; mixing them is how projects stall.

Step 2 — Theme-only spike (half a day)

• Install OpenChamber, add one custom JSON theme in ~/.config/openchamber/themes/, reload, screenshot.
• Run OpenCode with opencode web, override the --v2-* tokens, screenshot.
• Whichever feels like your product is the base you fork.

Step 3 — Build the fork properly

• Fork, pin the exact release tag, and keep a custom/ branch with only theme + component changes.
• Wire a CI build that publishes the UI bundle (OpenChamber) or a patched binary (OpenCode).
• Put it behind Cloudflare with auth if it leaves your machine.

Step 4 — Only then consider your own frontend

If, after two weeks of forking, you keep fighting the original layout, stop and build the thin client. The API is stable enough, the streaming model is documented, and you keep the agent while owning the interface.

• Both projects are MIT — commercial use and rebranding are permitted, keep the licence notice.
• Both are TypeScript SPAs on Vite — no hidden server-rendering migration ahead.
• OpenCode wins on engine control; OpenChamber wins on UI ownership and hosting.
• Your own frontend on the OpenCode API wins on total control if you accept the build cost.

⚠️ Risks, limits, what I did not verify

📚 Sources

• github.com/anomalyco/opencode — repository metadata, package.json, packages/app/package.json, packages/web/package.json, packages/desktop/package.json, packages/app/vite.config.ts, packages/ui/src/styles/tokens/theme.css, tree counts via the GitHub API.
• github.com/openchamber/openchamber — package.json, packages/web/package.json, packages/ui/package.json, packages/ui/src/index.css, docs/CUSTOM_THEMES.md, packages/ui/src/lib/theme/DOCUMENTATION.md, packages/extensions/README.md.
• OpenCode docs — packages/web/src/content/docs/web.mdx (web flags, CORS, auth, terminal attach) and themes.mdx.
• OpenCode CONTRIBUTING.md — package map and the documented web dev workflow (bun dev serve --port 4096 + bun run dev:web).