GoModel: a Go AI gateway that speaks OpenAI and Anthropic on the same port

The problem GoModel targets: one endpoint instead of N provider SDKs

Every provider ships its own SDK, its own auth header, its own streaming event format and its own error shape. A team that uses OpenAI for chat, Anthropic for long-context work and Ollama for local experiments ends up with three client configurations, three retry policies and no single place to see what was spent. GoModel inserts itself between the application and those providers. The README states that it accepts requests in two compatible formats: OpenAI-compatible at /v1 and Anthropic-compatible at /v1/messages. The practical consequence is that official SDKs work unchanged; the README tells you to point the OpenAI SDK at http://localhost:8080/v1 and the Anthropic SDK at http://localhost:8080, because that SDK appends /v1/messages itself. The audience is therefore platform or backend teams who want provider choice to be a configuration decision rather than a code change, and who want cost and usage visible in one place. It is not aimed at a single-provider application that never intends to switch.

Request path and the two compatibility surfaces

The architecture visible in the README is a single Go process listening on port 8080 that terminates both API dialects and forwards to upstream providers. The provider list is long: OpenAI, Anthropic, xAI, Google Gemini, Cohere, Vertex AI, DeepSeek, Groq, Fireworks AI, Meta, OpenRouter, Z.ai, Alibaba Cloud Model Studio, Kilo AI, MiniMax, Xiaomi MiMo, OpenCode Go, Azure OpenAI, Oracle, Ollama, SGLang, vLLM, llm-d, Amazon Bedrock (Runtime and Mantle), the ChatGPT Codex backend, Claude, ElevenLabs for text-to-speech and speech-to-text, plus any OpenAI-compatible provider. That breadth is the core mechanism: one ingress, many egresses. Around that forwarding path sit the operational features the README lists, including virtual models (aliases with round-robin or cost-based load balancing behind stable model names), session keeping, failover with retries and circuit breakers, exact and semantic response caching, per-request cost estimates, budgets, rate limits and a usage API. Configuration resolves in a defined order: good defaults, then config.yaml, then .env, then exported environment variables, with each source overriding the ones to its left. If you have debugged a gateway that silently ignored a config file because an environment variable won, this ordering is worth reading twice before you deploy.

Getting it running: install script, Docker and the first curl

The README gives three install paths. On macOS and Linux: curl -fsSL https://gomodel.enterpilot.io/install.sh | sh, then optionally set OPENAI_API_KEY and run gomodel. On Windows PowerShell: irm https://gomodel.enterpilot.io/install.ps1 | iex, then run gomodel. With Docker: docker run --rm -p 8080:8080 -e OPENAI_API_KEY="your-openai-key" enterpilot/gomodel. The dashboard is served at http://localhost:8080/admin/dashboard. A first request looks like this, with model set to gpt-5-chat-latest and input set to a plain string, posted to /v1/responses. Note that this example uses the Responses-style payload, not the classic chat completions shape, so check the API endpoints documentation before assuming your existing client body will be accepted verbatim. For anything beyond a smoke test the README points at Docker Compose: copying .env.template to .env and running docker compose up -d (or make infra) starts infrastructure only, meaning Redis, PostgreSQL, MongoDB and Adminer without building the app image, while docker compose --profile app up -d (or make image) adds GoModel and Prometheus. That split is a useful signal about dependencies: the gateway expects external storage services in a realistic deployment, so a single-container run is a trial configuration, not a production topology.

Where the README argues instead of documenting

Two claims in the README are asserted rather than shown. The first is speed and resource efficiency, supported by a link to self-reproducible benchmarks on the project site; the README text itself contains no numbers, so any figure you rely on has to come from that page and from your own reproduction. The second is the framing of alternatives: the README describes LiteLLM as having been hacked recently and Portkey as no longer maintained on GitHub, and calls GoModel an alternative to both. Those statements are dated and unverifiable from the repository contents supplied here. Treat them as positioning, not as an evaluation. The same applies to prod ready in the repository description: nothing in the material shows a support policy, a compatibility guarantee or a deprecation process. For a component that sits on the critical path of every model call, that absence matters more than any feature list.

Limitations: version churn, storage assumptions and caching risk

The strongest concrete limitation is release cadence. The three most recent releases are v0.1.90, v0.1.89 and v0.1.88, published on 8 September and 6 September 2026, meaning three tags in roughly three days. A project at 0.1.x shipping that often is still finding its shape; configuration keys and endpoint behaviour can move between tags. Pinning a version and reading release notes is not optional here. The second limitation is operational surface area. Caching, budgets, rate limits, session keeping and failover are features that pay off only when the backing stores are healthy; the compose file's inclusion of Redis, PostgreSQL and MongoDB implies you are now operating those alongside the gateway. The third is semantic caching specifically. The README describes it as making repeated prompts cost nothing, which is exactly the behaviour you do not want for prompts whose correct answer depends on fresh state. The material does not describe the similarity threshold or the invalidation controls, so that has to be checked in the feature documentation before enabling it. Finally, if you need only one provider and no spend controls, GoModel adds a network hop, a config file and a dashboard you will not open.

LiteLLM as the reference point, and where the approaches differ

The README positions GoModel against LiteLLM, which is the obvious comparison because both present an OpenAI-compatible surface in front of many providers. The difference the material supports is implementation language and packaging: GoModel is written in Go and distributed as a binary via an install script or as the enterpilot/gomodel image, whereas LiteLLM is a Python project. That distinction changes your deployment story more than your API story. A Go binary drops into a minimal container with no interpreter or virtual environment, and the README's emphasis on resource efficiency is consistent with that choice. A Python gateway tends to be easier to extend in-process if your team already writes Python and wants to add custom provider logic without leaving the codebase. GoModel's answer to extension is configuration: virtual models, aliases and load-balancing rules rather than plugins. Neither approach is better in the abstract, but if your reason for choosing a gateway is that you want to write custom routing code inside it, this one is the wrong shape. If your reason is that you want a small artifact with a fixed set of knobs, it fits.

Licence, upgrades and what maintenance actually costs

GoModel is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive arrangement, and it is the same licence family most teams already accept for infrastructure dependencies. It is not legal advice, and if you redistribute GoModel inside a product you should confirm notice retention with your own counsel. The maintenance cost that the material actually evidences is upgrade tracking. With tags landing days apart, the work is not patching but deciding when to move and what changed. A practical routine is to pin the image tag rather than tracking latest, keep config.yaml under version control so the precedence chain (defaults, then config.yaml, then .env, then exported variables) is visible in diffs, and read the release notes for every bump before deploying. The README also points to a Discord and to documentation at gomodel.enterpilot.io for configuration, API endpoints, admin endpoints and per-provider feature matrices; those pages, not the README, are where you will find out whether a given provider supports a given feature.

Editorial conclusion

Adopt GoModel if you already run Go services, want a single binary or container in front of several providers, and need per-key budgets and rate limits without writing that layer yourself. Do not adopt it if you require a stable configuration schema today: the release cadence (v0.1.88 through v0.1.90 within three days) and the 0.x version number both point to a moving target, so pin a tag and read the changelog before upgrading. Verify three things first: which storage backend your deployment needs (Redis, PostgreSQL and MongoDB all appear in the compose file), whether your provider appears in the per-provider feature matrix rather than just the provider list, and what the semantic caching path does to prompts you cannot afford to have answered from cache.

Official sources

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