cc-switch'ten Vazgeçmek: Birden Fazla Claude Code Sağlayıcısını Yönetmek İçin Aslında Sadece Bir Betik Yeterli

Claude Code büyük model API sağlayıcıları arasında sık sık geçiş yapması gereken biri için, API'leri kolayca yönetmek ve değiştirmek temel bir ihtiyaçtır.

Öncelikle, neden birden fazla API sağlayıcısına ihtiyaç duyulur?

Başlıca iki nedeni vardır:

1. Eşzamanlı çağrı ve kota sorunları, birden fazla Claude Code örneği açmak sıradan bir durumdur; eğer tüm görevler tek bir sağlayıcı üzerinden çalıştırılıyorsa sınırlara çarpmak kolaydır.

2. Birkaç modelin kendine özgü güçlü yanları vardır, bir sorunla karşılaşıldığında A işe yaramazsa, B denenebilir. Veya A yazarken, B kod incelemesi yapabilir.

Bir süre boyunca cc-switch kullandım, bu harika bir ücretsiz açık kaynak yazılımdır. Sadece birden fazla sağlayıcıyı yönetmekle kalmaz, aynı zamanda skill, mcp, prompt gibi özellikleri de yönetir. Üstelik sadece Claude Code'u değil, codex, Gemini, OpenCode'u da destekler.

Ancak sorunu tam da sağladığı çok fazla işlevsellikte yatıyor ve giderek daha da artıyor. Birçok ürün geliştiricisinin farklı insanların çeşitli ihtiyaçlarını karşılama dürtüsüne direnmenin zor olduğunu ve ürünü giderek daha karmaşık hale getirdiklerini düşünüyorum; araç kullananlar da her zaman daha fazla özelliği tercih eder, şu anda kullanılmasa bile gelecekte kullanılabilir.

Benim inandığım felsefe her zaman "Az çoktur" olmuştur. Bu kadar çok aracı desteklemek için bazı şeyler karmaşıklaşıyor, ben sadece CC kullanıyorum, bu nedenle bu işlevler ve karmaşıklık değer katmıyor, aksine yük haline geliyor.

cc-switch kendi yapılandırma dosyalarını yönetir, birden fazla sağlayıcı arasında yapılandırma paylaşımı gerektiğinde, ayrı bir genel yapılandırma dosyası tutması gerekir. Kendisi sık sık .claude/settings.json dosyasını yazar ve burada, özellikle sağlayıcılar arasında sık geçiş yapıldığında, sıklıkla sorunlar ortaya çıkar.

Bir diğer sorun da, farklı sağlayıcılar kullanarak aynı anda birden fazla CC örneği başlatıldığında yaşanır (en azından ben kullanırken böyleydi, geçişlerin tam olmaması nedeniyle istekler başarısız olabiliyordu). Eğer proxy özelliği kullanılıyorsa, tüm örnekler birlikte değiştirilmek zorunda kalır ve farklı örneklerde farklı Sağlayıcılar seçilemez.

Benim ihtiyaçlarım da basit:

• Yapılandırmanın tek bir yerde tutulması (sadece bir kopya)

• Farklı CC örneklerinde farklı Sağlayıcıların kullanılabilmesi.

Bu hedefe dayanarak uygulama da basittir, kullanıcının settings.json dosyasında birleşik yapılandırma saklanır. Sağlayıcıyı değiştirmek aslında CC'nin o birkaç ortam değişkenini değiştirmekten ibarettir, bir kabuk betiği bunu çözebilir. Böylece ben de CC'yi kullanarak kendi tekerleğimi yaptım ve ccs adında bir betik yazdım; bu betik, sağlayıcıyı belirtmek için isteğe bağlı bir -p parametresi destekler.

Böylece şunları yapabilirim:

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

Bir adım daha ileri giderek, alias'lar oluşturup doğrudan mm, ark komutlarıyla belirli bir sağlayıcıya sahip Claude Code'u başlatabilirim.

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

Ardından, zellij ile birlikte kullanarak farklı sağlayıcılara sahip birden fazla CC'yi kolayca yönetebilirim.

Hem basit hem bakımı kolay, aynı zamanda sağlayıcı belirterek birden fazla örnek açılabilir.

Günlük kullanım şu şekildedir.