Tinggalkan cc-switch: Menguruskan Pelbagai Pembekal Claude Code Sebenarnya Hanya Perlukan Satu Skrip

Bagi seseorang yang kerap perlu menukar pembekal API model besar Claude Code, pengurusan dan pertukaran API yang mudah adalah satu keperluan asas.

Pertama, mengapa perlukan pelbagai pembekal API?

Terutamanya terdapat dua sebab:

1. Masalah panggilan serentak dan kuota, membuka pelbagai contoh Claude Code adalah perkara biasa, jika semua tugas berjalan menggunakan satu pembekal sahaja, mudah menghadapi halangan.

2. Beberapa model mempunyai kelebihan masing-masing, jika menghadapi masalah dan A tidak berkesan, boleh cuba tukar ke B. Atau A menulis, B melakukan Semakan Kod.

Untuk suatu tempoh, saya menggunakan cc-switch, iaitu perisian sumber terbuka percuma yang bagus. Bukan sahaja boleh menguruskan pelbagai pembekal, malah mempunyai fungsi mengurus kemahiran, mcp, prompt dan lain-lain. Dan ia bukan hanya menyokong Claude Code, tetapi juga codex, Gemini, OpenCode.

Namun masalahnya ialah ia menyediakan terlalu banyak fungsi, dan semakin bertambah. Saya rasa ramai pembuat produk sukar menolak memenuhi pelbagai keperluan orang yang berbeza, kemudian menjadikan produk semakin kompleks; dan pengguna alat juga sentiasa suka fungsi yang lebih banyak, mungkin tidak digunakan sekarang tetapi mungkin digunakan pada masa depan.

Falsafah yang saya percayai sentiasa adalah "Less is more". Untuk menyokong begitu banyak alat, beberapa perkara menjadi kompleks, saya hanya menggunakan CC, jadi fungsi dan kerumitan ini tidak bernilai, malah menjadi beban.

cc-switch sendiri mengekalkan fail konfigurasi, apabila pelbagai pembekal perlu berkongsi konfigurasi, ia perlu mengekalkan konfigurasi umum secara berasingan. Ia sendiri sering menulis .claude/settings.json , di sini sering timbul beberapa masalah, terutamanya apabila kerap menukar pembekal.

Satu lagi masalah ialah menggunakan pelbagai pembekal yang berbeza untuk melancarkan pelbagai contoh CC secara serentak, ia juga mempunyai masalah (sekurang-kurangnya semasa saya menggunakannya, mudah pertukaran tidak lengkap menyebabkan permintaan gagal). Jika menggunakan fungsi proksinya, maka hanya boleh ditukar bersama dan tidak boleh memilih pembekal yang berbeza dalam contoh yang berbeza.

Keperluan saya juga mudah:

• Konfigurasi diselenggara secara seragam (hanya satu salinan)

• Boleh menggunakan pembekal yang berbeza untuk contoh CC yang berbeza.

Berdasarkan matlamat ini, pelaksanaannya juga mudah, simpan konfigurasi seragam dalam settings.json pengguna. Mengubah pembekal sebenarnya hanya mengubah beberapa pembolehubah persekitaran CC itu, satu skrip shell boleh menyelesaikannya, jadi saya menggunakan CC sendiri untuk membuat roda, menulis skrip ccs, ia menyokong parameter pilihan -p untuk menentukan pembekal.

Oleh itu, saya boleh:

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

Langkah seterusnya, buat alias, terus gunakan mm、ark untuk melancarkan Claude Code dengan pembekal yang ditentukan.

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

Kemudian gabungkan dengan zellij untuk menguruskan pelbagai CC dengan pembekal yang berbeza dengan mudah.

Mudah dan mudah diselenggara, boleh juga menentukan pembekal dan membuka banyak contoh secara bebas.

Hariannya adalah seperti ini.