GoModel: a Go AI gateway that speaks OpenAI and Anthropic to your providers

What GoModel actually replaces in your stack

The problem is key sprawl plus the absence of a chokepoint. If four services each hold an OpenAI key, an Anthropic key and a Groq key, you have no single place to cap spend, no single place to see which model answered, and no single place to reroute when a provider degrades. GoModel is that chokepoint. It is a Go binary that listens on port 8080 by default and presents two compatible surfaces: OpenAI-compatible at /v1 and Anthropic-compatible at /v1/messages. The README states that the official SDKs work unchanged once you point their base URLs at the gateway, so the migration cost for existing code is a base URL change rather than a rewrite.

The audience is narrow and specific. It is for platform or infrastructure engineers running self-hosted services who are willing to operate Redis, and optionally PostgreSQL or MongoDB, in exchange for owning the request path. It is not for someone who wants a hosted endpoint with no infrastructure. The feature list is aimed at that platform role: per-request cost estimates, hard spend limits per user, team or key, rate limits on requests, tokens and concurrency, and a Usage API that lets a client check its own remaining budget using the same key it already uses for inference.

Routing, sessions and failover in the request path

Two mechanisms do most of the work. The first is virtual models: stable model names that hide aliases and load balancing, with the README naming round-robin and cost-based strategies. The second is session keeping, which detects a client session and pins it to one target and one provider key. The stated reason is concrete: keeping provider prompt caches warm, and making audit logs read as threads rather than interleaved fragments. That is a real trade-off. Pinning buys cache hits and readable logs, and it costs you the ability to spread a single session across providers mid-conversation.

Failover sits alongside retries and circuit breakers, rerouting to backup providers automatically. Caching is described as exact and semantic response caching, so repeated prompts cost nothing. Semantic caching is the part to treat with suspicion until you have measured it yourself: a cache that matches on meaning rather than bytes can return a plausible answer to a question you did not ask, and the README does not describe a similarity threshold or a way to scope semantic matching per model. If your prompts are short and your tolerance for near-miss answers is low, disable semantic caching and keep exact matching.

Configuration resolves in a documented order, each source overriding those to its left: good defaults, then config.yaml, then .env, then exported environment variables. Exported variables winning is convenient in containers and surprising on a workstation where a stale export silently beats the file you just edited.

Installing GoModel and making a first call

The README gives three install paths. On macOS and Linux it is a shell script piped to sh, which then runs the gomodel binary. The OPENAI_API_KEY line is shown commented out, so the gateway starts without a provider key and you add one when you have it.

curl -fsSL https://gomodel.enterpilot.io/install.sh | sh
# OPENAI_API_KEY="your-openai-key" # (optional)
gomodel

On Windows the equivalent is a PowerShell invocation of install.ps1, with the key set as an environment variable before starting the binary.

irm https://gomodel.enterpilot.io/install.ps1 | iex
# $env:OPENAI_API_KEY = "your-openai-key" # (optional)
gomodel

The Docker route maps container port 8080 to host 8080 and passes the key as an environment variable. Note the README uses --rm here, so this container keeps no state between runs; the compose file below is the one that mounts a data volume.

docker run --rm -p 8080:8080 \
  -e OPENAI_API_KEY="your-openai-key" \
  enterpilot/gomodel

Once it is up, the dashboard is at http://localhost:8080/admin/dashboard. A first request goes to /v1/responses with a model name and an input string; the README's example uses gpt-5-chat-latest and the input "Hello!".

curl http://localhost:8080/v1/responses \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5-chat-latest",
    "input": "Hello!"
  }'

For anything beyond a smoke test, the compose file is the better starting point. Copying .env.template to .env, adding keys, then running docker compose up -d brings up Redis, PostgreSQL, MongoDB and Adminer without building the image. The app profile adds GoModel itself and Prometheus. One detail in that file matters more than it looks: the gomodel service mounts a named volume at /app/data, and the comment states this holds the SQLite database when STORAGE_TYPE is sqlite, the pid file and the install identity. Without that volume the directory lives inside the container and disappears when the container is recreated. The compose file also sets STORAGE_TYPE to mongodb by default with postgresql commented out, and enables METRICS_ENABLED.

Where GoModel is the wrong tool

The retraction in go.mod is the most important line in the repository for anyone doing due diligence. The module retracts v0.1.52 through v0.1.79, with a comment explaining that unauthenticated access to the aggregated MCP tool surface was possible via browser DNS rebinding, because the /mcp endpoint's origin check could not detect a rebind, and that this was fixed in v0.1.80. Two conclusions follow. First, if you are pinning a version, pin v0.1.80 or later, and if your dependency tooling ignores retractions you need to check this by hand. Second, the gateway exposes an MCP surface, and the project's own note says the origin check was the weak point, so treat /mcp as an administrative interface rather than a public one.

The versioning is the second limitation. Releases are at v0.1.90, v0.1.89 and v0.1.88, all within days of each other. A v0.1.x line with that cadence means interfaces can still move. The README's claim of being production ready is a positioning statement; the version number is the fact, and the two do not agree.

The third limitation is operational surface. Exact caching, semantic caching, budgets, rate limits, session pinning, audit logs and Prometheus metrics all need somewhere to live. The compose file expects Redis, PostgreSQL and MongoDB together, with MongoDB selected for audit storage. That is three stateful services in front of your LLM traffic. If you run one service with one provider key, GoModel adds more moving parts than it removes, and a plain SDK call is the better answer. The README is also silent on rollback and on schema migration between versions, so plan how you would revert a gateway upgrade before you deploy one.

GoModel against LiteLLM and Portkey

The README frames GoModel as an alternative to LiteLLM, which it says was hacked recently, and to Portkey, which it says is no longer maintained on GitHub. Those are positioning claims, and the article does not verify either one. The architectural difference is easier to state and more useful. GoModel is a single Go binary distributed with a distroless runtime image and no Python runtime in the container, and it ships its own dashboard, Redis-backed cache and audit storage rather than delegating them. LiteLLM is a Python proxy, so the deployment shape, the dependency tree and the memory profile differ, and the plugin ecosystem you inherit differs with them. If your team already runs Python services and wants to extend the proxy in Python, that is a genuine reason to prefer LiteLLM, and GoModel's plugin surface is not the same thing.

The comparison that matters most is not feature counts. It is what you have to operate. GoModel asks for Redis plus a storage backend. If that is already in your stack, the marginal cost is low. If it is not, you are adopting three services to gain a chokepoint, and you should decide whether the chokepoint is worth them.

Licence, maintenance and the cost of upgrading

GoModel is MIT licensed, which permits commercial use, modification and redistribution with the licence and copyright notice preserved. That is a permissive arrangement with no copyleft obligation on your own code, and no legal advice is implied by saying so; if you redistribute the binary or embed it, keep the notice intact.

Maintenance signals are mixed but readable. The repository is not archived and the last push was on 2026-09-09, which is recent. Releases v0.1.88, v0.1.89 and v0.1.90 landed on 2026-09-06, 2026-09-06 and 2026-09-08. The repository carries a .goreleaser.yaml, a helm/ directory, a Dockerfile, a Dockerfile.plugins, a Makefile with lint, test-race, test-e2e, test-integration and test-contract targets, and a golangci.yml, so the release and test machinery exists in the tree.

The upgrade cost is where the version number bites. A 0.1.x line moving this fast means you should read release notes between versions rather than trusting that a patch bump is inert. The go.mod comment about echo-swagger being pinned to v1.5.0 because later releases switch back to echo/v4 shows that transitive constraints can force pins. The retraction range shows that a version you may already be running can be withdrawn. Budget for reading changelogs, and pin explicitly.

Editorial conclusion

Adopt GoModel if you already have several provider keys in several services and want one self-hosted OpenAI-compatible endpoint with caching, budgets and audit storage you control. Do not adopt it if you need a long-stable release line: the module is still on v0.1.x, the go.mod retracts v0.1.52 through v0.1.79, and the README says Portkey is no longer maintained on GitHub while making the same claim about LiteLLM being hacked, which is a positioning statement rather than a technical comparison. Verify first that the provider you depend on appears in the Providers Overview matrix, that your chosen STORAGE_TYPE (mongodb, postgresql or sqlite) is one you can operate, and that the /mcp endpoint is either disabled or reachable only from trusted networks, since the retraction note ties that surface to a DNS rebinding issue fixed in v0.1.80.

Frequently asked questions

Official sources

1. ENTERPILOT/GoModel on GitHub
2. License: MIT
3. Project website
4. README
5. Releases