Abandoning cc-switch: Managing Multiple Claude Code Providers Actually Only Requires One Script

For someone who frequently needs to switch Claude Code large model API providers, convenient management and switching of APIs is a necessity.

First, why are multiple API providers needed?

There are mainly two reasons:

1. Issues with call concurrency and quotas. Running multiple Claude Code instances is common, and if all tasks rely on one provider, it's easy to hit limits.

2. Different models have their own strengths. If one doesn't work for a problem, you can try another. Or use one for writing and another for code review.

For a while, I used cc-switch, which is a good free open-source software. It not only manages multiple providers but also handles skills, MCPs, prompts, and more. Moreover, it supports not just Claude Code but also Codex, Gemini, and OpenCode.

However, its problem is precisely that it offers too many features, and they keep increasing. I think many product developers find it hard to resist meeting various needs from different users, making the product more and more complex; while tool users always prefer more features, even if they don't need them now, they might in the future.

My philosophy has always been "Less is more". To support so many tools, some aspects become complicated. I only use CC, so these features and complexities add no value and instead become a burden.

cc-switch maintains its own configuration files. When multiple providers need to share configurations, it requires maintaining a separate common configuration. It often writes to .claude/settings.json, which can lead to issues, especially when switching providers frequently.

Another issue is running multiple CC instances with different providers simultaneously; this also causes problems (at least in my experience, incomplete switching can lead to request failures). If you use its proxy feature, you can only switch all together and cannot choose different providers for different instances.

My requirements are simple:

• Unified configuration maintenance (just one copy)

• Ability to use different providers for different CC instances.

Based on this goal, implementation is straightforward: store unified configurations in the user's settings.json. Changing providers essentially means modifying CC's environment variables, which a shell script can handle. So, I built my own wheel using CC and wrote a ccs script that supports an optional -p parameter to specify the provider.

Thus, I can do:

ccs -p glm 
ccs -p minimax
ccs -p kimi
ccs -p ark

Going further, create aliases so that using mm, ark directly launches Claude Code with the specified provider.

alias mm="ccs -p minimax"
alias ark="ccs -p ark"

Then, combined with zellij, easily manage multiple CC instances with different providers.

It's simple, easy to maintain, and allows随意指定 provider 多开.

This is how it looks in daily use.