CC Switch Hits 104K Stars: One Desktop App for Seven AI Coding Tools

Every AI coding tool has its own config format. Claude Code wants JSON. Codex uses environment variables. Gemini CLI has its own schema. If you're running more than one of these in the same workflow, you're already familiar with the tax: hand-edit the file, source the env, restart the terminal, hope nothing broke.

CC Switch is a desktop app that handles the switching for you. It manages provider configurations across Claude Code, Codex, Gemini CLI, OpenCode, OpenClaw, Hermes Agent, and Claude Desktop from a single interface, with a local proxy layer on top. The project just hit 104,000 GitHub stars, which suggests this pain point is more common than most teams admit.

What Happened

CC Switch is a cross-platform desktop app built with Tauri 2, Rust, and React, released under an MIT license. The project currently sits at 104K stars, 6.9K forks, and 180 contributors. The latest release, v3.16.3, landed on June 14, 2026, and has added 59 commits since v3.16.2.

The core problem it solves: each AI coding tool uses a different config format, and switching API providers means editing JSON, TOML, or .env files by hand with no shared way to manage MCP servers and Skills across tools. CC Switch replaces that with a visual interface and a local proxy. The only official site is ccswitch.io.

59 commits in a single patch release are a fast-moving codebase. If you're integrating this into a shared team setup, track the release cadence before committing to it.

Key Features

• Seven tools, 50+ presets: Import providers with one click from presets covering AWS Bedrock, NVIDIA NIM, community relays, and more.
• Unified MCP and Skills management: One panel syncs MCP servers and Skills across Claude Code, Codex, Gemini CLI, OpenCode, and Hermes with bidirectional sync.
• Local proxy with failover: Handles format conversion, auto-failover, circuit-breaker logic, and provider health monitoring at the individual provider level.
• Usage and cost tracking: A dashboard tracks spend, requests, and tokens with custom per-model pricing. v3.16.3 added pricing import from models.dev.
• System tray quick switch: Switch providers from the tray menu without opening the full app, useful mid-session.
• SQLite with atomic writes: Config data lives in ~/.cc-switch/cc-switch.db. A temp-file-plus-rename pattern guards against corruption and includes auto-rotated backups.

Why It Matters

Most developers running AI coding tools are running more than one. A backend engineer might use Codex for one repo and Claude Code for another, each pointed at a different relay or official endpoint. Managing that by hand is error-prone, and a malformed TOML file can break a CLI mid-task at the worst possible moment.

Three things I keep coming back to:

• The dual-way sync is the key design choice: CC Switch writes to live config files when you switch providers, and backfills from those files when you edit directly. Your CLI tools stay consistent whether you use CC Switch or not.
• The "minimal intrusion" principle is what makes team adoption possible: Your tools keep working if you uninstall the app, so engineers who don't adopt CC Switch don't break anything for those who do.
• The cost dashboard is something I haven't seen handled well elsewhere: For teams running cheaper community relays alongside official endpoints, seeing token spend split by provider in one place changes how you evaluate the tradeoff.

Example Use Case

Say you run Claude Code against an official Anthropic endpoint for production work and a cheaper community relay for experiments. Without CC Switch, you're editing ANTHROPIC_BASE_URL and your API key each time, then restarting your terminal.

With CC Switch, you add both as presets and switch between them from the tray. Claude Code supports hot-switching, so the change takes effect without a restart. Any shared config data (plugin settings beyond keys and endpoints) is automatically carried over when you create the second provider. The usage dashboard then splits token spend between the two endpoints, so you can see exactly what the experiments cost.

This is the workflow I'd demo to a developer who's already burned time debugging a broken relay config at 11 pm.

Competitive Context

The tools CC Switch manages each handle their own configs, but none of them switch providers across the others. CC Switch sits above them as a config layer and local proxy. It doesn't replace any of them.

The closest alternative is editing each tool's files manually or writing shell scripts. That's what most developers did before, and the 104K stars say the manual approach wasn't working well enough. The 50+ built-in presets and cross-app MCP and Skills sync are hard to replicate by hand.

Claude Code's native hot-switching is worth noting: it supports provider changes without a terminal restart, and CC Switch builds on that. The other tools in the stack don't all have that capability, which is part of why the proxy layer exists.

One detail worth flagging: @claude appears in the contributor list. Co-authorship between humans and AI agents is appearing in more repos, and CC Switch's commit history is a visible example of this pattern.

My Take

CC Switch removes a real and recurring annoyance. The atomic writes, bidirectional sync, and tray switching are all thoughtful. For a solo developer or a small team running mixed Claude Code, Codex, and Gemini CLI setups, it saves time that would otherwise go to manual config edits.

What I'm less sure about is whether this approach holds at the team scale. CC Switch manages configs per machine, per developer. There's no shared state across teammates, no way to propagate a tested provider config to everyone at once. One developer figures out the right Bedrock relay with the right circuit breaker settings, and that knowledge stays in their ~/.cc-switch/ folder.

The tool does what it says. I'm curious whether teams using it end up rebuilding the coordination layer themselves anyway, or whether config-sharing eventually becomes a feature request.