router-for-me/CLIProxyAPI

CLIProxyAPI is worth a look if you already use coding-CLI accounts and want to call them through an ordinary model API from your own tools. It is a gateway, not a model host, so the value depends on the accounts and upstreams you bring.

The problem

You have a client or SDK written for the OpenAI, Gemini or Claude API shape, but your model access sits behind CLI-oriented products such as Claude Code, Codex or Grok Build, each with its own login and account handling. Rewriting the client for every provider, or copying credentials between tools by hand, makes switching models the expensive part of an experiment.

CLIProxyAPI sits between them. You authenticate the CLI providers once, point your existing client at the proxy's compatible endpoints, and the proxy translates requests to the underlying provider. The result is that a single app or SDK can address several CLI-backed providers, including multiple accounts, without a per-provider integration.

What's different

The core mechanism is protocol translation plus OAuth-based upstream login. The README lists OpenAI (including Responses), Gemini (including Interactions) and Claude-compatible endpoints, plus OAuth flows for Codex, Claude Code, Grok Build and Gemini. It also supports streaming, non-streaming and WebSocket responses where the upstream supports them, function calling, and multimodal text-and-image input. Those are the features that decide whether existing code keeps working after the switch, rather than merely whether responses come back.

Multi-account handling is the other distinguishing piece: round-robin load balancing across Gemini, OpenAI, Claude and Grok accounts, and configuration of OpenAI-compatible upstreams such as OpenRouter. That turns several CLI subscriptions into one addressable pool, which matters for rate-limit headroom and for keeping a team's clients pointed at one gateway. The trade-off is that the proxy inherits the providers' quirks: protocol fidelity depends on the translation layer, and features present natively in one API shape may not survive the trip.

A deliberate change since v6.10.0 is the removal of built-in usage statistics. Observability now comes from separate projects such as a standalone usage keeper and several management consoles, which track request history, latency, tokens and estimated cost. If you expect a dashboard out of the box, budget for adding one; if you only need routing, the leaner core keeps the surface smaller.

Who should try it

A good fit is a developer or small team with several CLI accounts who wants one OpenAI-compatible URL for local scripts, agent frameworks or evaluation harnesses, and who is comfortable running a Go service and completing OAuth logins. The multi-account rotation and upstream configuration are the reasons to choose it over wiring each client directly.

A poor fit is someone who wants a desktop app with a graphical configuration flow; the project points those users to a separate desktop client. It is also a poor fit if you need built-in analytics without adding another component, or if your clients depend on provider-specific behaviour beyond what the translation layer exposes.

Requirements and limitations

You need accounts and OAuth access for the CLI providers you intend to use, plus either the server itself or the graphical desktop client for setup. The project is MIT-licensed and written in Go, with an embeddable SDK and a documented management API, so integration is possible beyond plain HTTP. Setup instructions and the management API are documented separately from the README.

The main ongoing constraints are operational: accounts must stay authenticated, multi-account rotation depends on valid credentials, and usage tracking is a separate service after v6.10.0. The README does not spell out terms-of-service implications for each provider or every protocol edge case, so check the provider terms and test your specific client paths before relying on the proxy for anything important.

HotRepo's take

The only dated HotRepo observation is 2026-10-27, when the repository had 56,573 stars and gained 298 that day, with one appearance on the daily board. That single snapshot is insufficient to judge whether interest is rising, fading or sustained. With 482 days of age and a large star count, the project is established enough that its documented interfaces are worth checking, but adoption should rest on whether your accounts, clients and protocol needs line up with the compatibility list in the project instructions and setup guides.