Why VoidMCP is its own project

VoidLLM has an MCP gateway. VoidMCP is also an MCP gateway. People sometimes ask whether VoidMCP is a fork, or whether it was extracted from VoidLLM, or whether the two share code under the hood. None of those are quite right.

VoidMCP is a new project - started from scratch in April 2026 - that solves a different problem for a different audience. The overlap in features is real, but so is the reason the two exist separately.

The Code Mode threshold problem

Code Mode is the feature that gets people interested. The idea - write JavaScript in a WASM sandbox, call multiple MCP tools in one execution, get back a composed result - is useful on its own. It doesn’t care whether there’s an LLM proxy behind it or not.

But to use Code Mode via VoidLLM, you need to actually run VoidLLM. That means standing up a server, initializing a database, creating an org, creating a team, creating an API key, configuring your model registry. That’s the right amount of setup if you’re deploying an LLM proxy for a company. It’s a lot of overhead if you’re a developer who just wants their Claude Code or Cursor installation to call three MCP tools in sequence.

VoidMCP removes that threshold. Single binary. Point your IDE at it, register your servers, done. No database, no org hierarchy, no LLM proxying involved.

Distribution model is different

VoidLLM is a server you run somewhere - a VM, a container, a Kubernetes cluster. It listens on HTTP. Your tools talk to it over the network. That’s intentional: the whole point is centralising LLM access, tracking usage across a team, enforcing limits.

VoidMCP has a stdio transport. That means Claude Code or Cursor can launch it as a local process and talk to it directly - no network, no HTTP listener, no server to deploy anywhere. The IDE spawns the binary, pipes JSON over stdin/stdout, and gets MCP responses back. For personal use, that’s a much simpler operational model.

graph TD
  subgraph CLOUD["Server / datacenter"]
      VL["VoidLLM"]
      DB[(SQLite / Postgres)]
      VL --- DB
  end

  subgraph DEV["Developer machine"]
      IDE["Claude Code / Cursor"]
      VM["VoidMCP (stdio)"]
      IDE -->|"spawns"| VM
  end

  IDE -->|"HTTP"| VL

  style CLOUD fill:#12121a,stroke:#333,color:#e2e8f0
  style DEV fill:#12121a,stroke:#6366f1,color:#e2e8f0
  style VL fill:#1a1a24,stroke:#8b5cf6,color:#e2e8f0
  style DB fill:#1a1a24,stroke:#333,color:#e2e8f0
  style IDE fill:#1a1a24,stroke:#6366f1,color:#e2e8f0
  style VM fill:#1a1a24,stroke:#6366f1,color:#e2e8f0

VoidLLM also has Streamable HTTP transport for its MCP gateway - useful when you want org-scoped access control and want to run VoidMCP-equivalent features inside the proxy. But it has no stdio transport. The distribution models point in different directions.

What lives where

Both projects implement the MCP gateway and Code Mode. The implementations are separate - each project has its own internal packages, different package boundaries, different file layouts. There is no shared Go module between them. Code is similar in places (it solves the same protocol), but maintained separately.

A few things worth calling out explicitly:

• stdio transport exists only in VoidMCP. VoidLLM is HTTP-only.
• Hot-reload registry (polling SQLite every N seconds, picking up server changes without a restart) is in VoidMCP but not VoidLLM yet.
• Org-scoped MCP access - restricting which teams can reach which servers - is in VoidLLM but not VoidMCP, which has no concept of teams or orgs at all.

The honest trade-off

Separate implementations mean features drift. When something improves in one project, it has to be ported to the other separately. That’s a real cost.

Right now VoidMCP’s hot-reload registry isn’t in VoidLLM. And VoidLLM’s org-scoped access control won’t make sense in VoidMCP, because there are no orgs. The two projects are diverging in directions that fit their audiences - and that divergence is easier to manage when they’re not coupled.

The alternative - a single codebase that serves both the individual developer and the company proxy use case - would mean one audience always swallowing features they don’t want. VoidLLM users don’t need stdio transport. VoidMCP users don’t need a key management system. Keeping them separate keeps each project readable and focused.

Which one to use

If you’re setting up an LLM proxy for a team or company - you need billing allocation, RBAC, per-team rate limits, a model registry - use VoidLLM. The MCP gateway and Code Mode are included and integrate with the rest of the access control machinery.

If you’re an individual developer who wants Claude Code, Cursor, or Windsurf to talk to multiple MCP servers through a single front door, without any of the proxy infrastructure, VoidMCP is the simpler path. Grab the binary, register your servers, and you’re done.

Both are Go, both are BSL 1.1, both are self-hosted. The difference is who they’re for.