How to install CLIProxyAPI, and where its OAuth tokens actually live

One local endpoint in front of five provider families, with the mapping in code

The unit of work here is translation, not inference. CLIProxyAPI takes CLI-backed accounts for Google Gemini, OpenAI GPT, Anthropic Claude, xAI Grok and Kimi, and republishes them through OpenAI compatible, Gemini compatible and Claude compatible interfaces, so an existing client or SDK can talk to all of them without knowing which provider answered. The README is explicit that you can use several CLI accounts at once, and that Kimi is reached either through OAuth or through a compatible API interface. The endpoints are not limited to the classic chat completions shape: OpenAI Responses and Gemini Interactions are named as supported too, and the examples tree carries a `translator/`, a `custom-provider/`, a `plugin/` and a `realtime-openai-go/` directory, which is where the compatibility layer lives when the shapes do not line up. What the README does not do is publish a matrix of which upstream features survive translation, so streaming quirks, tool call shapes and reasoning blocks are things you verify against your own client rather than read off a table. The layout is conventional Go: `cmd/` holds the server entry point the Dockerfile builds, `internal/` and `sdk/` hold the implementation and the client surface, `docs/` the documentation, and `config.example.yaml` sits at the root as the configuration starting point that the compose file expects to find on the host as `config.yaml`.

The auths directory is the security surface, and the compose file mounts it for you

Credentials are the asset here, so look at where they are stored before anything else. The compose file maps a host directory onto the service account home with a name that has nothing to do with credentials at a glance, which is worth noticing because the port mapping around it looks like five extra services.

    volumes:
      - ${CLI_PROXY_CONFIG_PATH:-./config.yaml}:/CLIProxyAPI/config.yaml
      - ${CLI_PROXY_AUTH_PATH:-./auths}:/root/.cli-proxy-api
      - ${CLI_PROXY_LOG_PATH:-./logs}:/CLIProxyAPI/logs
      - ${CLI_PROXY_PLUGIN_PATH:-./plugins}:/CLIProxyAPI/plugins

Whatever the OAuth flow produced for your Gemini, Codex, Claude Code or Grok Build accounts lands under that host directory, so backup, permissions and deletion are your problem, not the project's. Two defaults make this worse than it looks. The example environment file ships `MANAGEMENT_PASSWORD=change-me-to-a-strong-password` commented out, so a fast setup leaves the management surface unconfigured, and the storage variables are documented as necessary only when you use a remote backend, which encourages people to believe a local install holds nothing sensitive. It holds the tokens. The `auths/` directory is in the repository layout for that reason.

refraction-networking/utls decides what your egress fingerprint looks like

One dependency deserves attention from anyone who cares about network posture. `go.mod` requires `github.com/refraction-networking/utls v1.8.2`, a library that lets a Go client present a chosen TLS fingerprint instead of the one the standard library emits. A plain Go client is easy to fingerprint, and a proxy that has to impersonate a browser or a CLI client to reach an upstream endpoint is exactly the case the library exists for. The consequence for you is narrow but real: the handshake your network sees is the one this project chose, not the Go default, and it can change in a patch release. If you sit behind a TLS inspecting proxy or a policy that filters by client signature, that dependency is the line item to review, and pinning a release rather than tracking `latest` is how you keep it stable. Everything else in the module list is more conventional: `gin` for HTTP, `pgx` for Postgres, `minio-go` and `go-redis` for storage, `pion/webrtc` for the realtime path, and `bubbletea` and `lipgloss` for a terminal interface.

pull_policy: always sits next to a build section, so your local build can be ignored

The compose file configures both an image and a local build, then tells Docker to pull anyway.

    image: ${CLI_PROXY_IMAGE:-eceasy/cli-proxy-api:latest}
    pull_policy: always
    build:
      context: .
      dockerfile: Dockerfile

`pull_policy: always` wins over the build you just declared, so edits to the Dockerfile or the Go source in a local clone can sit there unused while a registry image runs. Anyone developing against this should set `CLI_PROXY_IMAGE` to a tag they built themselves, or drop the pull policy, and should treat the `latest` default as a moving version. The port story has the same shape: the Dockerfile exposes only 8317, while the compose file publishes 8317 alongside 8085, 1455, 54545, 51121 and 11451 on the host, which is six listening sockets for one service. The repo also ships `docker-build.sh`, `docker-build.ps1` and a separate `docker-compose.cluster.yml` with `.env.cluster.example`, so a cluster deployment is a supported shape rather than a hack. The container carries a fixed name, `cli-proxy-api`, a `restart: unless-stopped` policy and a `DEPLOY` variable passed through from the host environment, which means a crashed proxy comes back up with the same mounted credentials rather than waiting for you.

Version 8 in the module path, and three patch releases in three days

The build target is one line in a two stage Dockerfile, and it pins the toolchain expectations.

RUN CGO_ENABLED=1 GOOS=linux go build -buildvcs=false -ldflags="-s -w -X 'main.Version=${VERSION}' -X 'main.Commit=${COMMIT}' -X 'main.BuildDate=${BUILD_DATE}'" -o ./CLIProxyAPI ./cmd/server/

`go.mod` declares `go 1.26.0` and the module path carries the major version, `github.com/router-for-me/CLIProxyAPI/v8`, which is why a wrong major version fails at import time rather than at runtime. Version stamping happens through linker flags rather than a version constant, so a build with the default arguments records `dev`, `none` and `unknown`, and any release identification you rely on has to come from a real build. The release cadence is fast: v8.0.2 shipped on 2026-09-27, v8.0.3 on 2026-09-28 and v8.0.4 on 2026-09-29, with the last push on 2026-09-29. The README also recommends a separate desktop client, EasyCLIProxyAPI, with automatic updates and one-click start and stop, which means the version on your machine is often the version that client pushed, not the tag you chose.

The sponsor list is a list of API relay vendors, with their own discount claims

Read the sponsor section as what it is. PackyCode, AICodeMirror, APIKEY.FUN, FennoAI, Qiniu Cloud AI and Cubence are relay services, and each block of the README carries that vendor's own commercial terms: a `cliproxyapi` promo code for 10% off, official channels at 38% and 2% and 9% of original price, a permanent 5% top-up discount, a $1.99 purchase for $50 of credits, a 1.69 million user count for one of them. Those figures are vendor supplied and the README passes them through unedited, so treat every percentage and user number as advertising rather than measurement. The relevance to your decision is that this project is a routing layer, and a routing layer plus a reseller is a different trust model from a routing layer plus a direct provider account. If you use the proxy, choose the upstream yourself and keep the credentials you care about on a path you control. The licences and contribution paths in the repository are ordinary: MIT, `LICENSE`, `CONTRIBUTING.md`, `AGENTS.md` and `CLAUDE.md`.

Four storage backends turn a local tool into a shared service

The default is local files, and the environment file is explicit that nothing needs setting for that case. Everything else exists to let several processes share one set of accounts, and each backend moves data further from the machine. Postgres is addressed by `PGSTORE_DSN`, with `PGSTORE_SCHEMA` and `PGSTORE_LOCAL_PATH` beside it. A Git-backed config store takes `GITSTORE_GIT_URL`, `GITSTORE_GIT_USERNAME`, `GITSTORE_GIT_TOKEN` and `GITSTORE_LOCAL_PATH`, with a sample value of `ghp_your_personal_access_token`, which means your configuration and whatever it references ends up in a repository you have to protect and rotate. Object storage adds `OBJECTSTORE_ENDPOINT`, `OBJECTSTORE_BUCKET`, `OBJECTSTORE_ACCESS_KEY` and `OBJECTSTORE_SECRET_KEY`, and the module pulls in `minio-go` and `go-redis` to serve them. The consequence of moving off local files is that the management password becomes the single control in front of shared state, so set `MANAGEMENT_PASSWORD` before you point a second process at the same store. `github.com/fsnotify/fsnotify v1.9.0` is in the module list, the file watching library, and the repository does not say which paths it watches, so whether editing a mounted `config.yaml` takes effect without restarting the container is a question for `docs/` rather than an assumption to build on.

Editorial conclusion

Adopt CLIProxyAPI when you already hold CLI access to several model providers and want one local endpoint that speaks OpenAI, Gemini and Claude shapes, especially with the Postgres or Git-backed token store so several processes share accounts. Do not adopt it as a way to obtain model access, and do not run it as a shared service until MANAGEMENT_PASSWORD is set to something other than the example value, because that file is the only thing between the management UI and every stored token. Verify three things first: that the build works against the Go 1.26.0 toolchain the module declares, that the image tag you run is the tag you tested rather than the `latest` default in the compose file, and that nothing in your network policy objects to a client that sets its own TLS fingerprint through the utls dependency.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes