cc-switch-ის დატოვება: მრავალი Claude Code მომწოდებლის მართვა, რეალურად მხოლოდ ერთი სკრიპტია საჭირო
ადამიანისთვის, ვისაც ხშირად სჭირდება Claude Code დიდი მოდელის API მომწოდებლების გადართვა, API-ების მოხერხებული მართვა და გადართვა აუცილებელი მოთხოვნაა.
პირველ რიგში, რატომ არის საჭირო მრავალი API მომწოდებელი?
არსებობს ორი ძირითადი მიზეზი:
მოთხოვნების ერთდროულობის და ლიმიტების საკითხი, მრავალი Claude Code ინსტანციის გახსნა ჩვეულებრივი საქმეა, და თუ ყველა დავალება ერთ მომწოდებელზე მუშაობს, ადვილია შეზღუდვების წინაშე აღმოჩენა.
რამდენიმე მოდელს აქვს თავისი სპეციფიკური უპირატესობები, თუ პრობლემა A-სთან არ მუშაობს, შეიძლება B-ს ვცადოთ. ან A-სთან დაწერა, B-სთან კოდის რევიუ.
გარკვეული პერიოდის განმავლობაში მე cc-switch-ს ვიყენებდი, ეს კარგი უფასო ღია კოდის პროგრამაა. ის არა მხოლოდ მართავს მრავალ მომწოდებელს, არამედ ასევე skill-ებს, mcp-ებს, prompt-ებს და სხვა ფუნქციებს. და ის არა მხოლოდ Claude Code-ს უჭერს მხარს, არამედ codex-ს, Gemini-ს, OpenCode-ს.
მაგრამ მისი პრობლემა ზუსტად ის არის, რომ ის ძალიან ბევრ ფუნქციას სთავაზობს და ისინი სულ უფრო მატულობს. ვფიქრობ, ბევრ პროდუქტის შემქმნელს უჭირს სხვადასხვა ადამიანების მრავალფეროვანი მოთხოვნების დაკმაყოფილების უარყოფა, რის შედეგადაც პროდუქტი სულ უფრო რთული ხდება; ხოლო ინსტრუმენტების მომხმარებლებსაც უყვართ, რომ ფუნქციები რაც შეიძლება მეტი იყოს, ახლა რაც არ გამოიყენება, შეიძლება მომავალში გამოადგეს.
ჩვენი ფილოსოფია ყოველთვის იყო "ნაკლები უფრო მეტია". ამდენი ინსტრუმენტის მხარდასაჭერად მისი ზოგიერთი ასპექტი გართულდა, მე მხოლოდ CC-ს ვიყენებ, ამიტომ ეს ფუნქციები და სირთულეები ღირებულების გარეშეა და ტვირთად იქცევა.
cc-switch თავად ინარჩუნებს კონფიგურაციის ფაილებს, როდესაც მრავალ მომწოდებელს საერთო კონფიგურაცია სჭირდება, მას ცალკე უნდა შეინარჩუნოს უნივერსალური კონფიგურაცია. ის თავად ხშირად წერს .claude/settings.json -ში, რაც ხშირად იწვევს პრობლემებს, განსაკუთრებით მომწოდებლების ხშირი გადართვის დროს.
კიდევ ერთი პრობლემაა სხვადასხვა მომწოდებლის გამოყენება ერთდროულად მრავალი CC ინსტანციის გასაშვებად, ამასაც აქვს პრობლემები (ყოველ შემთხვევაში, როცა მე ვიყენებდი, ადვილი იყო არასრული გადართვის გამო მოთხოვნის წარუმატებლობა). თუ მისი proxy ფუნქცია გამოიყენება, მაშინ მხოლოდ ერთად შეიძლება გადართვა და შეუძლებელია სხვადასხვა ინსტანციაში სხვადასხვა მომწოდებლის არჩევა.
ჩემი მოთხოვნებიც მარტივია:
კონფიგურაციის ერთიანი მოვლა (მხოლოდ ერთი ასლი)
სხვადასხვა CC ინსტანციაში სხვადასხვა მომწოდებლის გამოყენების შესაძლებლობა.
ამ მიზნის მიღწევა ასევე მარტივია, მომხმარებლის settings.json -ში ინახება ერთიანი კონფიგურაცია. მომწოდებლის შეცვლა რეალურად CC-ის რამდენიმე გარემოს ცვლადის შეცვლაა, ერთი shell სკრიპტით მოგვარდება, ამიტომ მე თვითონ CC-ით შევქმენი ახალი გადაწყვეტა, დავწერე ccs სკრიპტი, რომელიც მხარს უჭერს სურვილისამებრ -p პარამეტრს მომწოდებლის მითითებისთვის.
ამრიგად, შემიძლია:
ccs -p glm
ccs -p minimax
ccs -p kimi
ccs -p arkკიდევ უფრო, alias-ების შექმნა, რათა პირდაპირ გამოვიყენო mm, ark კონკრეტული მომწოდებლის Claude Code-ის დასაწყებად.
alias mm="ccs -p minimax"
alias ark="ccs -p ark"შემდეგ კი zellij-თან ერთად მარტივად მართავ სხვადასხვა მომწოდებლის CC-ებს.
როგორც მარტივი და მარტივი მოვლა, ასევე თვითნებური მომწოდებლის მითითება და მრავალჯერადი გაშვება.
ყოველდღიური ცხოვრება ასე გამოიყურება.
