cc-router Multi-Model Gateway
Pool model quotas locally and route coding clients with automatic failover.
Per-dimension scores and reasoning
The gateway defaults to 127.0.0.1, LAN/Web UI exposure is opt-in, and client-header forwarding is off by default. The architecture and inbound, outbound, translation, field-loss, and OAuth paths are described in unusually concrete detail, earning full data-flow transparency. The README also warns about provider terms, account suspension, quota consumption, and unauthenticated LAN administration. Deductions apply because the supplied files do not show local credential storage, encryption, log redaction, deletion controls, the shell plugin's effective permissions, or OAuth token scopes. Codex configuration writes are backed up, but confirmations and recovery for other settings, certificates, subscriptions, and exports are not fully documented. Releases use frozen dependency installation, signing, macOS notarization, and dependency overrides, but no SBOM, audit results, or dependency-update policy is supplied, and workflow actions use mutable major-version tags. The MIT notice names a copyright holder, while publisher identity remains unknown.
The documented protocols, endpoints, aliases, dispatch modes, and package matrix are broadly internally consistent, and the release workflow largely matches the advertised platforms. However, broad compatibility, failover, and interruption-free operation remain documentation claims without supplied implementation or tests. Dependency and build versions are reasonably explicit, with frozen installation, platform-specific runners, and system packages, but the lockfile, Rust manifest, and backend dependency set are absent. CI emits actionable errors for missing signing secrets, and the README distinguishes unsupported requests that return 400 from parameters that are ignored; ordinary runtime, upstream, and authentication failure messages are not shown, preventing full marks.
Audiences and scenarios are clearly segmented across Claude Code, Codex, desktop clients, and OpenAI-compatible applications, with three inbound protocols, several outbound families, virtual models, dispatch strategies, and multilingual UI. Capability boundaries are unusually explicit: unsupported Responses images and OpenAI-only tools, ignored Chat Completions parameters, translation loss, and OAuth account risk are all identified, justifying full marks there. Endpoint selection, session-affinity keys, aliases, and wildcard behavior are precise, but broad wildcard aliases and silently ignored parameters can produce non-obvious routing, so trigger precision is not complete. The macOS, Windows, Linux, multi-architecture, local HTTPS, and LAN guidance provides strong environment coverage.
The documentation has a clear progression from architecture and quick start through integrations, inbound/outbound protocols, and FAQ, with strong installation tables and configuration examples. Protocol losses, unsupported features, ignored fields, terms risks, and account risks are documented thoroughly. The complete MIT text agrees with the metadata. Product and virtual-model names are consistent, but permissive wildcard aliases normalize future or nonexistent-looking model names and reduce predictability. package.json declares 5.0.0, tags drive releases, and historical Releases are mentioned, but no changelog, migration guidance, or versioning policy is supplied. A copyright nickname and invitation for PRs appear, but there is no clear maintenance team, support commitment, security-reporting route, or ownership policy.
The GUI, generated configuration, unified endpoints, request logs, usage receipts, model mappings, and automatic failover are directly usable outputs and offer clear incremental value for users managing fragmented subscriptions and clients. Cost-benefit documentation acknowledges both potential savings and the risks of suspension, throttling, abnormal quota use, and semantic loss. Full marks are withheld because savings, failover performance, and compatibility breadth are not quantified or substantiated by the supplied static evidence.
The README ties some claims to concrete configurations, endpoints, a provider-descriptor directory, and release artifacts; package.json, LICENSE, and the release workflow corroborate the stack, version, license, platform builds, and signing practices. Core routing, credential handling, failover, and translation implementation is absent, leaving many claims traceable only to the README itself. Cross-file support exists for the name, version, license, Tauri stack, and distribution matrix, but not for runtime behavior. The documentation generally separates limitations, risks, and recommendations, yet marketing or behavioral claims such as saving money, avoiding interruptions, and passing requests through almost verbatim are not clearly labeled as unverified assertions.
- The author explicitly characterizes OAuth subscription-account routing as a grey area that may cause throttling, suspension, or cancellation; primary accounts and critical workloads should not depend on it.
- When listening on 0.0.0.0 with Web UI login disabled, any device on the same network may change configuration; retain authentication and use only on trusted networks.
- The supplied evidence does not establish how provider keys, proxy tokens, OAuth tokens, or request logs are stored, encrypted, redacted, or deleted.
- Protocol translation drops or silently ignores some fields, while broad model wildcards may route unexpected names into virtual slots; verify the actual model, billing, and feature semantics before use.
- Downloads use latest-version links and an independent China mirror. Although the release workflow generates signatures, the supplied material does not explain how users verify mirror artifacts or checksums.
What does this agent do, and when should you use it?
cc-router is a local desktop gateway built with Tauri 2, Rust, React 19, TypeScript 5, and Tailwind 4, listening on 127.0.0.1:23456 by default. It combines Token Plans, Coding Plans, and metered API quotas behind four virtual model slots—fable, opus, sonnet, and haiku—and selects upstream models using sequential, round-robin, or session-affinity scheduling. Clients connect through Anthropic Messages, OpenAI Responses, or OpenAI Chat Completions, while the gateway calls Anthropic-, OpenAI-, or Gemini-compatible providers. Its interface records requests and token usage, exports receipt-style usage summaries, and manages fallback across configured subscriptions in Chinese, English, or Japanese. It is a practical fit for developers who want the same provider pool behind Claude Code, Codex, OpenCode, OpenClaw, and related clients, provided they accept protocol-conversion gaps and the account-policy risks of proxying some subscription plans.
A client sends requests to the local /v1/messages, /v1/responses, or /v1/chat/completions endpoint. cc-router authenticates them with the token shown in its settings, normalizes supported model names and aliases to model-fable, model-opus, model-sonnet, or model-haiku, and selects a bound provider account according to quota, scheduling mode, and session affinity. Anthropic Messages can follow a near-pass-through route; OpenAI Responses, Chat Completions, Gemini generateContent, and /v1beta/interactions routes use protocol translation, including mappings for thinking or reasoning and tool calls. When a selected subscription is rate-limited or fails, the gateway can move the request to another binding and record the entry protocol, route, and token consumption in its local interface. It can also generate a self-signed CA and server certificate for HTTPS-only clients and expose an optional browser management interface at /ui/.
- A developer with several small Coding Plans wants to consume them sequentially and fail over automatically when one plan is exhausted, rate-limited, or unavailable.
- A user running both Claude Code and Codex CLI wants Anthropic Messages and OpenAI Responses clients to share one model pool and one usage view.
- A team running concurrent sessions or subagents wants session affinity so each conversation retains its upstream prompt cache while separate sessions are distributed across accounts.
- An Open WebUI, Cherry Studio, Cline, or LobeChat user needs an OpenAI Chat Completions endpoint backed by several configured providers.
- A developer with DeepSeek, GLM, Kimi, MiniMax, OpenAI, Anthropic, Gemini, or another compatible endpoint wants to maintain routes through a desktop GUI instead of repeatedly editing client configuration.
- A user who tracks model spending wants consolidated request logs and an exportable receipt-style record of token consumption.
What are this agent's strengths and limitations?
- One local service exposes Anthropic Messages, OpenAI Responses, and OpenAI Chat Completions, covering clients that use different API conventions.
- Sequential, round-robin, and session-affinity scheduling are combined with automatic switching and failover; session affinity preserves per-provider prompt-cache locality.
- Built-in provider presets coexist with custom Anthropic-, OpenAI-, and Gemini-compatible endpoints.
- The desktop GUI, optional web UI, request logs, consolidated token accounting, and receipt export provide a no-code operating path.
- Built-in self-signed CA and server-certificate generation enables integrations that require a local HTTPS endpoint.
- The OpenAI Responses ingress does not accept image input or OpenAI-specific file_search, web_search, or computer_use tools, and it ignores parallel_tool_calls.
- Protocol translation cannot preserve every field; cache_control may be lost on OpenAI or Gemini routes, so a native Anthropic endpoint is preferable when available.
- The Chat Completions ingress rejects legacy functions/function_call fields and ignores n greater than one, logprobs, and JSON Schema enforcement through response_format.
- Proxying per-seat Coding Plan or Token Plan credentials and mixing virtual models may violate or fall outside provider terms, potentially causing throttling, suspension, or subscription cancellation.
- The gateway and upstream network connection must remain available; LAN listening or disabled web-login authentication increases exposure of configuration and credentials.
- The documented OAuth routes for ChatGPT Plus/Pro through Codex and for Kiro are explicitly described as risky and unsuitable as primary capacity.
How do you install or deploy this agent?
For normal use, download the platform package from GitHub Releases. The project provides DMGs for Apple Silicon and Intel macOS, EXE and MSI packages for x64 Windows, an arm64 Windows EXE, and x64/arm64 AppImage and DEB packages for Linux; AppImage is recommended on Linux because it supports in-app updates. On first launch, choose a provider and endpoint, enter an API key or complete a supported OAuth login, fetch the available models, and bind the subscription to the four virtual model slots. Source development requires Node.js 20 or later, pnpm, and Rust 1.88 or later; macOS additionally requires Xcode Command Line Tools. Run pnpm install followed by pnpm tauri dev for development, or pnpm tauri build to create packages under src-tauri/target/release/bundle/. Windows builds require the MSVC Rust toolchain and Visual Studio Build Tools with the Desktop development with C++ workload.
How do you use this agent?
Add at least one subscription in the desktop app, bind real models to model-fable, model-opus, model-sonnet, and model-haiku, then choose sequential, round-robin, or session-affinity scheduling. For Claude Code, set ANTHROPIC_BASE_URL to http://127.0.0.1:23456, put the settings-page token in ANTHROPIC_AUTH_TOKEN, and select one of the model-* names. For Codex, define a provider with base_url = "http://127.0.0.1:23456/v1", wire_api = "responses", and env_key = "OPENAI_API_KEY"; select a virtual model in the cc-router profile, then invoke codex -p cc-router. Chat Completions clients generally use http://127.0.0.1:23456/v1, the cc-router token, and a virtual model or documented alias. Claude Desktop requires the local HTTPS certificate setup. If the optional web interface is enabled, open http://127.0.0.1:23456/ui/; changing the listener to 0.0.0.0 permits LAN access, but disabling login authentication lets devices on that network change the configuration.
How does this agent compare with similar options?
Compared with pointing Claude Code, Codex, or OpenCode directly at one provider, cc-router adds a local control layer that presents multiple quotas as virtual models and performs balancing or failover automatically. The tradeoff is an additional local service, access token, and routing configuration to maintain. Native Anthropic pass-through preserves the most request semantics, while OpenAI- and Gemini-compatible outbound routes broaden provider choice at the cost of translation and possible loss of fields such as cache_control.