Mirrowel/LLM-API-Key-Proxy: an OpenAI and Anthropic compatible gateway with a separate key-rotation library

The problem is key sprawl, not model quality

Most teams end up with credentials spread across several vendors. One key for Gemini, one for OpenAI, one for Anthropic, and possibly an OpenRouter key on top. Each vendor has its own base URL, its own request shape, and its own way of reporting a rate limit. The README frames the project as solving exactly that: "One proxy. Any LLM provider. Zero code changes." The claim rests on the two endpoint families the proxy exposes, /v1/chat/completions for OpenAI-style clients and /v1/messages for Anthropic-style clients. Anything that accepts a custom base URL can be pointed at the proxy instead of at the vendor. The README lists Claude Code, Opencode, Continue, Roo/Kilo Code, Cursor, JanitorAI, SillyTavern and custom applications as targets. The second audience is narrower and more interesting: developers who want the rotation and failover logic as a library rather than as a process. The repository describes a reusable Python library for intelligent API key management, rotation and failover, which means the routing behaviour is not welded to the HTTP layer.

Routing is decided by the provider prefix in the model string

The proxy does not guess a backend from the request body. It reads the model name, which must be written as provider/model_name, and the prefix selects the upstream. The README gives five worked examples: gemini/gemini-2.5-flash, openai/gpt-4o, anthropic/claude-3-5-sonnet, openrouter/anthropic/claude-3-opus, and gemini_cli/gemini-2.5-pro. Note the last two. OpenRouter nests a second slash, so the parser has to split on the first separator only. Gemini CLI is marked in the README as an exclusive provider reached over OAuth, which is where the oauth_creds directory in the Docker invocation comes from. Translation between request formats sits between the endpoint and the upstream, which is how an Anthropic-shaped client can be served by a Gemini model. The README also links to the LiteLLM provider list, so the set of upstreams is bounded by what LiteLLM supports plus the project's own additions. That is a design worth stating plainly: the proxy is not writing a bespoke client for every vendor, it is a compatibility and rotation layer over an existing provider abstraction.

Getting it running: three paths, and the environment file is the one that matters

Windows users download a release, unzip it, and run proxy_app.exe, which opens an interactive TUI launcher. On macOS and Linux the release binary needs chmod +x proxy_app before ./proxy_app. From source the sequence is git clone, python3 -m venv venv, source venv/bin/activate, pip install -r requirements.txt, then python src/proxy_app/main.py. The README notes that passing command-line arguments such as --host 0.0.0.0 --port 8000 bypasses the TUI and starts the proxy directly, which is the form you want under a process supervisor. Docker is the path with the most moving parts. The documented run mounts .env read-only at /app/.env, mounts oauth_creds, logs and usage, and sets SKIP_OAUTH_INIT_CHECK=true. The Compose route expects you to copy .env.example to .env and create a usage directory first, and the README warns explicitly that the usage directory must exist before Compose starts or usage statistics will not persist on the host. Clients then point at http://127.0.0.1:8000/v1 with the value of PROXY_API_KEY as the API key. For OAuth-backed providers the README says to authenticate locally with the credential tool first, then mount oauth_creds or export the credentials as environment variables. That ordering is not optional, and it is the step most likely to be skipped.

The failure modes the README does not resolve

Key rotation and cooldowns are described as built in, but the README does not state the cooldown duration, the retry count, or which HTTP status codes trigger failover. Those numbers matter if you are putting this in front of production traffic, because a rotation policy that is too eager will burn through a key pool on transient errors and one that is too slow will surface 429s to the caller. The material does not say. The provider/model format is also a hard constraint rather than a convenience. Any client that hardcodes a model identifier without a provider prefix will not route, and the README does not describe a default-provider fallback. Multi-tenant use is another gap: there is a single PROXY_API_KEY in the documented configuration and no discussion of per-caller keys or quota separation, so if you need to attribute spend per team you would be building that yourself. Finally, the release tags are dated builds (dev/build-20260530-2-e1f8843, main/build-20260527-1-af40b91) rather than semantic versions, which makes it hard to reason about upgrade risk from the tag alone.

LiteLLM proxy is the obvious comparison, and the difference is packaging

LiteLLM already offers a proxy that fronts many providers behind an OpenAI-compatible endpoint, and the README here links to LiteLLM's provider documentation as the source of supported upstreams. So the honest comparison is not capability but shape. LiteLLM's proxy is a general-purpose gateway with a config file describing model lists, and it is the layer this project builds on. LLM-API-Key-Proxy narrows the scope to two things: an Anthropic-compatible /v1/messages endpoint alongside the OpenAI one, and a separately importable resilience library. If you only need OpenAI-shaped traffic and you are comfortable with LiteLLM's configuration model, adding this proxy in front is an extra process to run and monitor for little gain. If you specifically need Claude Code or an Anthropic SDK client talking to Gemini or OpenAI models, the /v1/messages endpoint is the reason to look here rather than at a plain OpenAI-compatible gateway. The Gemini CLI provider is the other differentiator the README calls out as exclusive.

Maintenance cost and the licence question

There is no Homepage field set on the repository, so the README and the linked DeepWiki, zread and Mirrobot badges are the documentation surface. That matters for maintenance: you are reading source when the README runs out, and the README does run out on rotation parameters, retry semantics and multi-key configuration syntax. The release cadence shown is frequent, with dev builds landing days apart and a main build between them, which suggests active work but also means the dev channel moves under you. Pin a specific build tag if you deploy this. On licensing, the repository metadata reports NOASSERTION, which means no standard licence identifier was detected. No licence text was available in the supplied material, so the terms under which you may use, modify or redistribute this code cannot be confirmed from what is here. Treat that as an open item to resolve before any commercial deployment, and note that the README's Ko-fi button indicates the project accepts donations, which is not the same as a stated licence. This is a factual gap, not legal advice; if the terms matter to you, read the repository's licence file directly.

Editorial conclusion

Adopt it if you already hold keys or OAuth credentials for several providers and want existing OpenAI or Anthropic clients pointed at one base URL without patching those clients. Skip it if you need a single vendor, if you cannot run a long-lived process next to your credentials, or if you require a permissive licence you can verify today, because the repository metadata reports NOASSERTION and no LICENSE file text was available to check. Before committing, confirm the Gemini CLI OAuth flow works for your account, decide whether the usage/ directory is worth mounting so stats survive a container restart, and read the source of the resilience library if you plan to import it rather than only run the proxy.

Official sources

1. Issues
2. Mirrowel/LLM-API-Key-Proxy on GitHub
3. README
4. Releases