xcb vs Claude Code Router
Claude Code Router sends each API request from your coding agent to a provider and model you configure, usually with API keys. xcb never touches API traffic: it runs each provider’s own tool under your sign-in and routes whole tasks.
Which one to pick
Pick Claude Code Router when
- You want Claude Code, Codex, OpenCode, or pi to use models from other providers.
- You want retries, key rotation, and ordered fallback models for every request.
- You want request logs, token counts, and cost estimates in one dashboard.
- You pay per token with API keys and want one local endpoint for all your agents.
Pick xcb when
- You want the Claude, Codex, and Devin subscriptions you already pay for used through each provider’s own tool.
- You want each task held on one account until its run ends, instead of routing each request.
- You want each run sandboxed and a result that says how the run ended.
Side by side
| Aspect | Claude Code Router | xcb |
|---|---|---|
| What it routes | Each API request from your agent to a provider and model | Each coding task to one of your accounts and a model |
| Where it sits | A local endpoint between your agents and model APIs | Above the agents: it starts Claude Code, Codex, or the Devin CLI itself |
| What you bring | API keys, plus logins it can import for some subscriptions | Claude, Codex, and Devin subscriptions, signed in through each provider’s own flow |
| When a call fails | Retries, credential pools, key rotation, and ordered fallback models | A route call runs once; a managed task can switch accounts after a reported usage limit |
| Sandboxing | Your agent runs as usual; the router handles its requests | Every provider run is sandboxed, and file changes go through xcb |
| For your own code | One local endpoint that compatible API clients can call | xcb --json route takes one task and returns the result, the account and model used, and how the run ended |
| Platforms | Desktop apps for macOS, Windows, and Linux, plus a CLI and Docker | macOS ARM64 and Linux x86_64, with no Windows build; Codex and Devin need macOS, and Claude on Linux isn’t confirmed |
Subscription proxies
Some proxies go further and turn subscription logins into an API. CLIProxyAPI ↗ describes itself as a proxy that provides OpenAI-, Gemini-, Claude-, Codex-, and Grok-compatible API interfaces “for CLI”, so any compatible client can use “multiple CLI accounts”.
For Claude, Anthropic’s Claude Code legal page ↗ says OAuth sign-in with a Claude plan “is designed to support ordinary use of Claude Code and other native Anthropic applications.” It also says Anthropic does not permit third-party developers “to route requests through Free, Pro, or Max plan credentials on behalf of their users”.
xcb runs the unmodified Claude Code binary, signed in through Claude Code’s own claude setup-token flow. It passes the token only to Claude Code. The same page says its rules don’t “prevent an end user from signing in to the unmodified Claude Code binary with their own Claude subscription”.
Building on xcb
xcb --json route reads one task as JSON and returns one JSON result: the account and model xcb picked, a session you can resume, and how the run ended. The request can pin a provider, account, or model and set a deadline, and it can’t carry tools, credentials, or provider flags.
Apps can embed the TypeScript SDK’s createSubscriptionRouter instead. There, your app names the account and model, and xcb holds that account while the task runs. The SDK ships as a release archive, not on npm, and your app supplies the provider adapters.
Sources
- Claude Code Router on GitHub ↗Checked
- CLIProxyAPI on GitHub ↗Checked
- Anthropic: Claude Code legal and compliance ↗Checked
- xcb: Route tasksChecked