Replacing LNP Harness with OpenCode + OpenChamber: what it costs in CPU, RAM and work

🎯 TL;DR — the numbers

📏 What this machine is running right now

Collected with ps RSS and a 3-second /proc CPU sample on 27 Oct 2026. RSS counts shared pages per process, so group totals overstate real usage; treat them as upper bounds, and compare like with like.

💾 Cost per deployment shape

Derived from the measured processes, with realistic headroom. "Active" means one agent turn in flight or a dev server being previewed.

Rules of thumb you can actually plan with:

• ≈0.3 GB baseline per concurrent user for the direct web stack.
• ≈+0.4 GB per code-server you keep alongside it — the dominant variable.
• ≈1.6 GB per desktop install if your users run the Electron app.
• Reserve 30% headroom: RSS grows with transcripts and MCP servers, and this host is already swapping at 70% utilisation.

⚙️ CPU: where it actually goes

Idle agent servers are nearly free: 0.0–0.5% of a core, sampled live. The 7% reading belongs to the desktop process mid-turn — one streaming response. CPU is bursty, not steady.

Concurrency planning: a 4 vCPU box comfortably hosts 6–8 concurrent users doing normal agent work, and far fewer if several run builds or test suites simultaneously. CPU, not RAM, becomes the limit once code-server and builds enter the picture.

💽 Disk and data

Per-user disk is dominated by cloned repositories and node_modules, not by OpenChamber. Budget 2–10 GB per active workspace and put session transcripts on a retention policy.

➖ Delta vs LNP Harness

Important: your LNP workspaces already run OpenCode and OpenChamber inside. So "switching" is not adding a stack — it is removing the packaging around it.

Same agent, same UI, less packaging. The saving comes from code-server and containers, not from the agent.

What you add by going direct: nothing in RAM, but everything LNP was doing for you disappears — see the next section.

🧩 Feature parity: what you must rebuild

This is the part that decides whether the move is worth it. OpenCode + OpenChamber replace the agent and the workspace UI. They do not replace a multi-tenant product.

🔧 Customising OpenCode A-to-Z

Yes, you can carry over essentially every agent-level customisation you built in LNP — and more, because the surfaces are documented rather than internal.

What does not come across from LNP

• Per-user accounts, credits and quotas — LNP-specific, no upstream equivalent.
• Admin dashboards and platform analytics.
• Workspace snapshot/restore and S3 archive pipeline.
• Per-project secrets, API keys and Turso namespaces.
• Sandbox isolation for untrusted users — you must add containers or OS users.

🎨 Customising OpenChamber

Three layers, lowest cost first:

The boundary is hard: extensions live in sandboxed iframes and cannot touch host DOM, CSS or React state. So "add a thing beside what exists" is an extension; "change how what exists looks" is React.

If you keep a product layer

Put your accounts, credits and admin in your own service, and let OpenChamber be the workspace shell. Two clean patterns:

1. Reverse proxy in front — your auth gateway issues a session cookie, OpenChamber runs with its own password behind it, one instance per tenant.
2. Extension as the bridge — an SDK extension calls your billing/usage API, shows quota in a rail panel and a Work Status section, without forking React.

🚀 Recommended migration path

Option A — Team / self-hosted (do this if you are the main user)

• Run one OpenChamber web instance per machine or per person; one OpenCode server behind it.
• Drop code-server unless you truly need a browser IDE — it is 0.4–0.45 GB and most of the CPU bursts.
• Keep the desktop app only for people who want it; 1.6 GB each is a real cost.
• Expected footprint: 0.3 GB per concurrent user, 4 vCPU / 8 GB for a small team.

Option B — Product with accounts (do not throw LNP away)

• Keep the LNP control plane for auth, billing, admin, quotas and snapshots.
• Stop launching code-server by default; make it opt-in per workspace.
• Autosuspend idle workspaces; one OpenCode process per active tenant only.
• Reuse OpenChamber as the UI, and add your product surface as extensions.
• Expected footprint: 0.3 GB active, near-zero idle after eviction.

Option C — Replace everything (only with months of runway)

• Rebuild auth, billing, admin, isolation and backups around OpenCode's API.
• Own the UI: fork OpenChamber or write your own SPA against opencode serve.
• You will end up with a smaller, better agent stack — and a second product to maintain.

⚠️ Caveats and sources

• All RAM figures are RSS from ps at one moment; shared pages are counted per process, so group sums overstate. PSS would be lower.
• CPU figures come from a 3-second /proc sample plus lifetime averages; agent work is bursty, so single readings are indicative only.
• Measured on one 4 vCPU / 7 GB Linux host with 3 LNP workspaces, an OpenChamber desktop session and a long agent conversation. Your workload will differ.
• Scaling numbers are derived from these measurements plus 30% headroom, not from a load test.
• No OpenChamber or OpenCode build was benchmarked under synthetic concurrency; treat "25 users" as a planning estimate.

Sources

• Live process measurements on this host, 27 Oct 2026 (ps, /proc/*/stat, du).
• openchamber/openchamber — install requirements (Node ≥ 24.14), SDK, extension docs.
• anomalyco/opencode — plugin docs, config surface, server/API, web app (SolidJS).
• LNP Harness AGENTS.md and workspace runtime layout in this repository.