Iwanan ang cc-switch: Ang Pamamahala ng Maraming Supplier ng Claude Code, Isang Script Lang Talaga ang Kailangan

Para sa isang taong madalas magpalit ng mga supplier ng API para sa malalaking modelo ng Claude Code, ang madaling pamamahala at pagpapalit ng API ay isang pangunahing pangangailangan.

Una, bakit kailangan ng maraming supplier ng API?

May dalawang pangunahing dahilan:

1. Ang problema sa concurrent calls at quota, ang pagbubukas ng maraming instance ng Claude Code ay pangkaraniwan na, kung lahat ay tumatakbo ng mga gawain at iisa lang ang ginagamit, madaling mabigo.

2. Ang ilang modelo ay may kani-kaniyang espesyalidad, kung may problema at hindi gumana ang A, maaaring subukan ang B. O kaya naman, si A ang sumulat, at si B ang magsagawa ng Code Review.

Sa loob ng ilang panahon, ginamit ko ang cc-switch, ito ay isang magandang libre at open-source na software. Hindi lamang ito nakakapamahala ng maraming provider, mayroon din itong mga function para sa skill, mcp, prompt, at iba pa. At hindi lamang ito sumusuporta sa Claude Code, kundi pati na rin sa codex, Gemini, OpenCode.

Ngunit ang problema nito ay ang sobrang dami ng function na ibinibigay nito, at lalo pang nadadagdagan. Sa tingin ko, maraming gumagawa ng produkto ang nahihirapang tumanggi sa pagtugon sa iba't ibang pangangailangan ng mga tao, at ginagawang mas kumplikado ang produkto; at ang mga gumagamit ng tool ay laging gusto ng maraming function, kahit na hindi kailangan ngayon, baka kailanganin sa hinaharap.

Ang prinsipyo na sinusunod ko ay ang "Less is more". Para suportahan ang napakaraming tool na ito, naging kumplikado ang ilang bagay, ako ay gumagamit lang ng CC, kaya ang mga function at complexity na ito ay walang halaga, sa halip ay naging pabigat.

Ang cc-switch ay nagmamantini ng sarili nitong configuration file, kapag kailangang magbahagi ng configuration sa maraming provider, kailangan nitong magmantini ng hiwalay na pangkalahatang configuration. Madalas itong sumusulat sa .claude/settings.json , at dito madalas lumalabas ang mga problema, lalo na kapag madalas na nagpapalit ng provider.

Isa pang problema ay ang sabay-sabay na paggamit ng iba't ibang provider para magsimula ng maraming instance ng CC, may problema rin ito (sa panahon ng aking paggamit, madaling hindi kumpleto ang pagpapalit na nagdudulot ng pagkabigo ng request). Kung ginamit ang proxy function nito, magkakasama lang ang pagpapalit at hindi maaaring pumili ng iba't ibang Provider sa iba't ibang instance.

Ang aking pangangailangan ay simple lang:

• Ang configuration ay pinapanatili nang magkakaisa (isang kopya lang)

• Maaaring gumamit ng iba't ibang Provider sa iba't ibang instance ng CC.

Batay sa layuning ito, ang pagpapatupad ay simple din, sa settings.json ng user ay itinatago ang magkakaisang configuration. Ang pagbabago ng provider ay talagang pagbabago lang ng mga environment variable ng CC, isang shell script lang ang makakalutas, kaya ginamit ko ang CC mismo para gumawa ng sariling gulong, sumulat ako ng script na ccs, sumusuporta ito sa opsyonal na parameter na -p para tukuyin ang provider.

Kaya maaari ko na itong gawin:

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

Higit pa rito, gumawa ng alias, direktang gamitin ang mm, ark para direktang paganahin ang Claude Code na may tinukoy na provider.

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

At saka isabay sa zellij para madaling pamahalaan ang maraming CC na may iba't ibang provider.

Simple at madaling imantini, at maaaring magbukas ng marami na may tinukoy na provider.

Ganito ang pang-araw-araw.