A small gateway keeps the upstream service in charge
opencode2api puts familiar API endpoints in front of OpenCode Zen and Zen Go, letting clients use Chat Completions, Responses, or Anthropic Messages. The executable also serves its management interface, so operating it doesn't require a separate Node runtime or database. The original WebUI is Simplified Chinese, with English and Vietnamese translations available. There is an English README, though the linked detailed management guide remains Chinese.
Our checkout occupied 0.7 MB and contained 77 files, about 15,688 source lines. That modest footprint makes a personal gateway plausible without assembling a larger platform. I'd consider it for an operator already using Zen or Zen Go who needs client compatibility and key routing. The model still runs upstream. Owning this gateway gives you control of routing and configuration, not control over upstream access or availability.
What happened when we ran it
Our run installed 6 packages in 2 seconds and built opencode2api in 34 seconds. We cloned commit a6601da on October 16, 2026, into an unprivileged Debian container using golang:1.24-bookworm, with 3 CPUs and 8 GB of RAM. Both steps succeeded without secrets. The result supports the claim that this revision is straightforward to compile in that environment, without establishing whether any upstream model accepts requests.
The test command succeeded in 4 seconds, reporting 0 passed and 0 failed out of 0. That's a successful command with no executed tests in the supplied result. The lab found 2 CI workflow files, a Dockerfile, and a Compose file, but no tests directory. It supplied no vulnerability audit result. None of those observations demonstrates streaming correctness or faithful conversion of a client's full request.
The 34-second build is useful evidence for source adoption because compilation is often the first obstacle. It is a much smaller claim than saying the gateway is production-ready. Before relying on it, send representative requests through the exact client and upstream you intend to use. Include a tool call and its returned result if the application depends on tools. Our sandbox record does not include that exercise.
Protocol translation has named losses
The compatibility section says that native-protocol requests retain provider-specific fields, while conversions use a common representation. Some options have no equivalent: Chat JSON output constraints and seed are not forwarded to Anthropic Messages. The bridge source reflects that distinction. This is a useful adapter when your client stays within the supported overlap, but a risky default when every request option must survive unchanged.
Our 0-test result leaves that overlap unverified by the lab. The gateway also omits embeddings, file uploads, image generation, and Responses retrieval or cancellation. A client that uses one supported chat route may work while another feature immediately fails. List the endpoints your application actually calls before changing its base URL. If you need those absent routes, a broader gateway is a better starting point.
Management needs writable state and a private listener
The example configuration separates local client keys from upstream credentials and enables an administrator interface. Replace its example keys and password before use. The management listener binds broadly by default, while the API example binds to loopback. That separation is useful, but it requires deliberate exposure rules rather than assuming the interface inherits the API's local-only address.
A 6-package install doesn't remove the need to manage state. The configuration directory must remain writable for saved settings, password migration, and model caches. Compose supplies a state volume and a read-only root filesystem. The README explains that the host configuration seeds that volume only on first startup. Editing the host file later is insufficient unless you explicitly import it again or use the management interface.
Anonymous access can still fail upstream
The README offers an anonymous route for eligible models, but explicitly says upstream rejection and rate limiting still apply. Open PR 102 describes a title-generation request rejected after the gateway attached agent tools. That proposal concerns a specific request-shaping path and remains a proposed fix. It illustrates why a gateway can accept your client's format while the upstream refuses the resulting request.
Our sandbox used 3 CPUs and no secrets, so it supplies no authenticated or anonymous inference result. Model discovery and a healthy local process aren't substitutes for a completed response either. The documented health check measures discovery and available routing resources, not whether a key will accept the next request. For unattended work, observe completed streams and application outcomes instead of treating readiness as an upstream service guarantee.
Recent fixes show maintenance, not compatibility proof
The repository was pushed on October 16, 2026, and release v1.4.1 shipped that day. GitHub showed 7 open issues and PRs. The release notes include better errors when all proxies are down, interface translations, and console navigation work. Alongside current protocol discussions, those changes show active maintenance. They also mean the moving default branch and our measured commit should not be treated as interchangeable revisions.
LiteLLM deserves a look when you need a gateway across many providers rather than one centered on Zen. Ollama serves a different need when you want models running locally. Choose opencode2api for the narrower Zen adapter job, pin the revision you validate, and keep the application responsible for conversation history. The README explicitly says the gateway does not store it.