CCS is an MIT-licensed TypeScript CLI that switches Claude Code and compatible CLI runtimes between multiple Claude accounts, OAuth providers such as Codex and xAI/Grok, and OpenAI-compatible or local model endpoints through one stable ccs command surface, aimed at developers who hold several AI coding subscriptions or model providers at once.

What it is

CCS (Claude Codex Switch) is a multi-provider profile and runtime manager for Claude Code and compatible CLIs. It runs Claude, Codex, Droid-routed profiles, GLM, local models, and Anthropic-compatible APIs without config thrash, giving one command surface over multiple runtimes such as Claude Code, Factory Droid, and Codex CLI, over multiple Claude subscriptions and isolated account contexts, and over OAuth providers like Codex, xAI/Grok, Kiro, Claude, and Kimi with legacy Copilot compatibility.

The concrete problem it solves is config rewriting between providers. Switching providers by hand means editing config files, breaking active sessions, and repeating that work for every provider change. CCS moves that into named profiles and a local Anthropic-compatible proxy, so a provider switch is a command rather than an edit. It lives in the Node.js and Claude Code ecosystem, distributed through npm and as a container image, and it replaces the per-project config file churn that otherwise sits between a developer and each upstream model provider.

Key capabilities

• One command surface for launching runtimes: ccs, ccs codex, ccs xai (alias ccs grok), ccs --target droid glm, ccs glm, and ccs ollama.
• Multiple Claude subscriptions and isolated account contexts managed as profiles.
• OAuth provider support for Codex, xAI/Grok, Kiro, Claude, and Kimi, with legacy GitHub Copilot compatibility for existing setups.
• API and local-model profiles including GLM, Kimi, OpenRouter, OrcaRouter, Ollama, llama.cpp, Novita, Fireworks AI, and Alibaba Coding Plan.
• OpenAI-compatible routing that bridges Claude Code into non-Anthropic upstreams through a local proxy: ccs api create --preset hf, then ccs hf; manual control via ccs proxy start hf and eval "$(ccs proxy activate)", with a Fish variant ccs proxy activate --fish.
• Request-time profile:model selectors and scenario-based model routing through proxy.routing.
• A React dashboard and proxy shipped as ghcr.io/kaitranntt/ccs:latest, with the dashboard on port 3000 and CLIProxy on port 8317, plus remote proxy support and WebSearch fallback.

Who uses it and how

• Developers holding more than one Claude subscription use profile switching to keep isolated account contexts apart without editing config between sessions.
• Teams that need Claude Code to talk to OpenAI-compatible providers create a preset with ccs api create --preset hf and route through the local proxy.
• Self-hosters run the published compose file and point a sibling container at CLIProxy, with the dashboard at http://localhost:3000.
• Environments behind a corporate proxy download docker/compose.yaml directly from raw.githubusercontent.com instead of using the hosted quick-start URL.
• Local-model users add an Ollama or llama.cpp profile and launch it with ccs ollama rather than maintaining a separate client configuration.

Getting started

Install on a host with npm install -g @kaitranntt/ccs and run ccs config, or run the container path with curl -fsSL https://ccs.kaitran.ca/docker-compose.yaml -o docker-compose.yaml followed by docker compose up -d.

How it compares

Among similar tools, claude-code-router is named in the README as a standalone router for sending Claude Code requests to OpenAI-compatible providers, and CCS credits CCR's transformer architecture for informing its own local proxy and SSE transformation work. The README's stated split is to use CCR when a standalone router is enough, and CCS when the routing flow should stay integrated with CCS profiles, runtime bridges, and the existing ccs command surface, so CCS positions itself as the profile-management layer rather than a router alone.

When to use it — and when not to

A self-hoster must operate the Docker containers, the local proxy, the dashboard, and the OAuth credentials for each provider, and must keep profile and routing configuration current as providers change. Anyone wanting a single-provider client with no proxy in the path should not pick it, since the profile and proxy layers are the product. One documented gap: Qwen Code account linking is not available in the bundled CLIProxy runtime yet, so Qwen models require an API-key profile such as Alibaba Coding Plan, and the older ghcr.io/kaitranntt/ccs-dashboard:latest image is deprecated in favour of ghcr.io/kaitranntt/ccs:latest.

curl -fsSL https://ccs.kaitran.ca/docker-compose.yaml -o docker-compose.yaml
docker compose up -d

npm install -g @kaitranntt/ccs
ccs config

ccs
ccs codex
ccs xai              # Alias: ccs grok
ccs --target droid glm
ccs glm
ccs ollama

ccs api create --preset hf
ccs hf

ccs proxy start hf
eval "$(ccs proxy activate)"

# Design with default Claude
ccs "design the auth flow"

# Implement with a different provider
ccs codex "implement the user service"

# Use a cheaper API profile for routine work
ccs glm "clean up tests and docs"

# Run a local model when you need privacy or offline access
ccs ollama "summarize these logs"