Відмова від cc-switch: для керування кількома постачальниками Claude Code достатньо лише одного скрипта

Для тих, хто часто перемикається між різними постачальниками API великої моделі Claude Code, зручне керування та перемикання API є нагальною потребою.

По-перше, навіщо потрібно кілька постачальників API?

Є дві основні причини:

1. Проблеми з паралельними викликами та лімітами: запуск кількох екземплярів Claude Code — це звична справа, і якщо всі завдання виконуються через одного постачальника, легко натрапити на обмеження.

2. Різні моделі мають свої особливості; якщо одна не справляється з проблемою, можна спробувати іншу. Або ж одна може писати код, а інша — проводити Code Review.

Якийсь час я використовував cc-switch — це хороше безкоштовне програмне забезпечення з відкритим кодом. Воно не лише дозволяє керувати кількома постачальниками, але також має функції для керування навичками, MCP, промптами. Крім того, воно підтримує не лише Claude Code, а й Codex, Gemini, OpenCode.

Але його проблема саме в тому, що він надає занадто багато функцій, і їх стає все більше. Я думаю, багато розробників продуктів не можуть відмовитися від задоволення різних потреб користувачів, що робить продукт все складнішим; а користувачі інструментів завжди люблять, щоб функцій було якомога більше, навіть якщо зараз вони не потрібні, можливо, знадобляться в майбутньому.

Моя філософія завжди була «Менше — це більше». Щоб підтримувати стільки інструментів, деякі речі стають складними. Я використовую лише CC, тому ці функції та складність не мають цінності, а навпаки, стають тягарем.

cc-switch самостійно керує файлами конфігурації, і коли кілька постачальників потребують спільної конфігурації, йому потрібно окремо підтримувати загальні налаштування. Він часто записує .claude/settings.json , і тут часто виникають проблеми, особливо при частому перемиканні постачальників.

Ще одна проблема — одночасний запуск кількох екземплярів CC з різними постачальниками, з цим також виникають проблеми (принаймні, коли я використовував, це часто призводило до неповного перемикання та помилок запитів). Якщо використовувати його проксі-функцію, то можна перемикати лише всі разом, не вибираючи різних постачальників для різних екземплярів.

Мої потреби також прості:

• Уніфіковане керування конфігурацією (лише один файл)

• Можливість використовувати різних постачальників для різних екземплярів CC.

Виходячи з цієї мети, реалізація також проста: зберігати уніфіковану конфігурацію в файлі користувача settings.json . Зміна постачальника фактично означає зміну кількох змінних середовища CC, що можна вирішити за допомогою shell-скрипта. Тому я створив власне рішення, написавши скрипт ccs, який підтримує необов'язковий параметр -p для вказівки постачальника.

Таким чином, я можу:

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

Йдемо далі: створюємо псевдоніми, щоб безпосередньо запускати Claude Code з вказаним постачальником за допомогою mm, ark .

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

Потім, разом із zellij, легко керувати кількома CC з різними постачальниками.

Це просто, легко підтримувати та дозволяє вільно вказувати постачальників для кількох запусків.

Щоденна робота виглядає так.