CLIProxyAPI vs Lynkr
Turns your coding-CLI subscriptions (Claude Code, Codex, Antigravity, Kimi, Grok) into a local OpenAI/Gemini/Claude-compatible API — multi-account rotation in one Go proxy. — versus — Self-hosted LLM gateway wrapping Claude Code, Cursor or Codex with zero code changes — strips unused tools, compresses JSON tool results ~88%, semantic-caches, tier-routes easy work to local models.
Both self-hosted proxies between coding subscriptions and clients: lynkr optimizes (compression, caching, tier-routing); CLIProxyAPI multiplexes accounts and re-exposes them as standard APIs.
| CLIProxyAPI | Lynkr | |
|---|---|---|
| Stars | 43k | 531 |
| Forks | 6.8k | 57 |
| Language | Go | JavaScript |
| License | MIT | Apache-2.0 |
| Last activity | today | 6 days ago |
| Topics | gateway | coding, local, gateway |
| Curated connections | 2 | 8 |
CLIProxyAPI — the curator's take
The inverse of a router: 9router points CLIs at providers, CLIProxyAPI exposes your subscription OAuth accounts AS a provider — any SDK can spend your Claude Code/Codex/Kimi quota. Multi-account balancing built in. ToS gray zone: unofficial client re-use; firewall it, don't resell it.
Lynkr — the curator's take
Use it when your Claude Code/Cursor subscription limits or API bill hurt: `lynkr wrap claude` is a one-liner, and compression + routing SIMPLE-tier traffic to a free Ollama model genuinely stretches quotas. Also the escape hatch when corporate policy forces traffic through Databricks/Azure/Bedrock. NOT a model server — it only routes, so pair it with Ollama or another backend. Skip it for light usage: a proxy is one more moving part with a big config surface (tiers, budgets, cache), and semantic caching can serve stale hits on near-duplicate prompts. If you only want provider switching without the token tricks, plain LiteLLM is the boring default.