Claude Code Kota Dolduğunda Ne Yapmalı? API Yönlendirme, Failover ve Maliyet Takibi

Claude Code kotasının dolduğunu söylediğinde, sıfırlanmayı beklemek veya daha büyük bir plan satın almak tek seçenek değildir.

Claude Code’un yanında Codex veya OpenCode gibi araçlar da kullanıyorsanız birkaç şey daha ters gidebilir: her agent’ın kendi model yapılandırması gerekir, sorun çıkaran bir hat çalışan görevi keser ve ay sonunda her görevin gerçekte kaç token tükettiğini söyleyemezsiniz.

Bu yazı üç soruyu yanıtlıyor: karşınızdaki hatanın kota sınırı mı, hız limiti mi yoksa yapılandırma hatası mı olduğunu nasıl anlarsınız; bir API geçidi üzerinden model erişimini nasıl birleştirir ve yedek hatları nasıl yapılandırırsınız; her oturumun kullanımını ve tahmini maliyetini nasıl doğrularsınız.

Kısa versiyon: tek resmî hesap ve hafif kullanımda resmî kanal genellikle daha basittir. Bir API geçidi; birden çok modele birleşik erişim, birleştirilmiş faturalandırma veya kullanmaya yetkili olduğunuz upstream hatlar arasında failover gerektiğinde değer kazanır.

1. Önce netleştirin: kota mı tükendi, hız limiti mi, yapılandırma hatası mı

“İstek başarısız” yazısını görür görmez bir relay servisine geçmek işleri genellikle daha da kötüleştirir. Farklı hatalar farklı önlemler gerektirir.

Bazı hız limitleri dakikalar içinde kendiliğinden düzelir; hatlar arasında sık sık geçiş yapmak başarısız istekleri artırabilir. Asıl önemli olan kaç kullanılabilir hattınız olduğunu, ne zaman geçiş yapacağınızı ve geçişten sonra mevcut görevin devam edip edemeyeceğini bilmektir.

2. Bir API geçidi neyi çözer, neyi çözemez

Bir API geçidi (relay servisi) agent’larınız ile model sağlayıcıları arasında durur. Agent’lar istekleri geçide gönderir, geçit de bunları yapılandırılmış upstream modellere iletir.

Genellikle dört işte iyidir:

• Birleşik erişim: tüm agent’lar tek bir Base URL, tek bir model listesi ve tek bir kullanım kaydı paylaşır.
• Failover: yeniden deneme koşulları sağlandığında trafik mevcut hattan yedeğe geçer.
• Model yönlendirme: modelleri öncelik sırasına, kota durumuna veya görev türüne göre seçin.
• Maliyet takibi: token’ları, önbellek isabetlerini, istek sayılarını ve harcamayı tek yerden görün.

Resmî kotayı havadan var edemez ve görsel, araç çağrısı ya da uzun bağlam desteği olmayan bir modele bu yetenekleri sonradan kazandıramaz. Çıktı başladıktan sonra kopan bir akış, başka bir modelde kusursuzca sürdürülemez.

Tüketici abonelik hesapları havuzlamak, çerez paylaşmak veya kaynağı belirsiz anahtarlar kullanmak hesap güvenliği ve upstream şartları açısından risk taşır. Bir servis seçmeden önce modellerin ve API erişiminin meşru olduğunu ve yetkili upstream hatlar kullandığınızı teyit edin.

3. Birden çok agent’ı tekrar eden yapılandırma olmadan yönetmek

Claude Code, Codex ve OpenCode ortak bir yapılandırma formatı paylaşmaz. Birkaç model ekleyin; Base URL’ler, API anahtarları ve model adları dosyalara dağılır.

Her şeyi bir geçide bağladıktan sonra model kaynağını merkezileştirir ve her agent’a kendi uç noktasını verirsiniz. Genel akış:

1. Geçitte kendi API anahtarınızı oluşturun ve bir kullanım üst sınırı belirleyin.
2. Servisin gerçekte hangi protokolleri, model adlarını ve Base URL’yi desteklediğini kontrol edin.
3. Agent yapılandırmasını doldurun ve geri dönüş için orijinalin bir kopyasını saklayın.
4. Gerçek görevleri çalıştırmadan önce tek bir minimal test isteği gönderin.
5. İsteğin doğru kaydedildiğini kullanım sayfasından doğrulayın.

Anthropic ortam değişkenlerini destekleyen istemcilerde yapılandırma genellikle şuna benzer:

export ANTHROPIC_BASE_URL="servisinizin gerçekte sağladığı uç nokta adresi"
export ANTHROPIC_AUTH_TOKEN="kendinizin oluşturduğu API anahtarı"

Değişken adları, protokoller ve yetkilendirme yöntemleri istemciden istemciye değişir; hem istemcinizin hem geçidin güncel dokümanlarını izleyin. Yerel bir geçit adresini üretim relay uç noktasıyla karıştırmayın ve gerçek anahtarları asla ekran görüntülerine, günlüklere veya herkese açık yazılara yapıştırmayın.

Hızlı bir deneme için değişkenleri kalıcı yapılandırma dosyalarına yazmak yerine bağımsız bir terminal oturumunda ayarlayın. Her şey çalıştıktan sonra kalıcı hale getirin.

4. Failover, “birkaç hesap daha yığmaktan” ibaret değildir

Gerçek failover bazı somut soruları yanıtlar:

• Hangi hatalar yeniden denenebilir, hangileri anında başarısız olmalı?
• Mevcut hat devre dışı kalınca yedekler hangi sırayla seçilir?
• Bir oturum, bağlam veya akıl yürütme formatı uyumsuzluğunu önlemek için modelini ve hatını korur mu?
• İçerik istemciye gönderildikten sonra akış koparsa ne olur?
• Yeniden denemeler yinelenen istekler ve ek ücretler doğurabilir mi?

Yaygın yönlendirme stratejileri:

• Birincil/yedek: birincil hattı tercih edin; failover koşulları sağlandığında geçiş yapın.
• Round-robin: istekleri kullanılabilir hatlar arasında sırayla döndürün.
• En düşük kullanım: o anki kullanımı en düşük olan hattı tercih edin.
• Kota penceresi planlaması: hatları kalan kotaya ve sıfırlanma saatlerine göre planlayın.
• Görev amacı: karmaşık kodlamayı daha güçlü modellere, küçük düzenlemeleri daha hızlı ve daha ucuz modellere gönderin.

Uzun görevlerde daha fazla hat, daha fazla istikrar demek değildir. Asıl önemli olan net hata yönetimi, protokolünüz ve araç çağrılarınız için destek ve izlenebilir bir istek geçmişidir.

5. Her görevin maliyeti nasıl hesaplanır

Maliyet takibi en azından girdi token’larını, çıktı token’larını, önbellek okumalarını, önbellek yazmalarını ve akıl yürütme token’larını ayırt etmeli ve fiyat kaynağıyla verilerin toplandığı zamanı belirtmelidir.

Bir görevin 1 milyon girdi token’ı ve 100 bin çıktı token’ı tükettiğini, girdinin milyon token başına X, çıktının milyon token başına Y fiyatlandığını varsayın. Önbellek ve diğer ücretleri yok sayarak tahmin şudur:

maliyet = (100 ÷ 100) × X + (10 ÷ 100) × Y

Gerçek bir faturayı kontrol ederken ayrıca şu noktaları doğrulayın:

• girdi ve çıktının birim fiyatlarının farklı olup olmadığı;
• önbellek okuma ve yazmalarının ayrı faturalandırılıp faturalandırılmadığı;
• akıl yürütme token’larının çıktıya sayılıp sayılmadığı;
• başarısız istekler ve otomatik yeniden denemelerin nasıl faturalandırıldığı;
• servis ücreti, kur farkı veya model çarpanı bulunup bulunmadığı;
• sayfanın gerçek tahsilatı mı yoksa liste fiyatından bir tahmin mi gösterdiği.

Abonelik planları ile API kullanıma bağlı ödeme farklı muhasebe sistemleridir. Bir relay servisinin gösterdiği “oturum maliyeti”, o görev için banka hesabınızdan çıkan nakit olmak zorunda değildir. Kayıtları dışa aktarıp satır satır kontrol edebilmek, tek bir bakiye rakamından daha işe yarar.

6. Bir relay servisi seçmeden önce bakılacak 7 nokta

1. Gerçek model ve protokol uyumluluğu. Model adlarının ötesine bakın: akış, araç çağrısı, görsel, akıl yürütme parametreleri ve bağlam uzunluğunun görevlerinizle eşleştiğini doğrulayın.

2. Hesaplayabileceğiniz fiyatlandırma. Eksiksiz bir fiyat tablosu girdi, çıktı, önbellek, çarpanlar, servis ücretleri ve iade kurallarını kapsar — yalnızca “%X’e varan indirim” değil.

3. Şeffaf hata yönetimi. Hangi hataların yeniden denendiğini, geçiş sınırının nerede olduğunu ve bakım geçmişine sahip bir durum sayfası olup olmadığını bilin.

4. İstek ve günlük saklama. Nelerin saklandığını kontrol edin — prompt’lar, yanıtlar, IP’ler, anahtarlar, istek günlükleri — ne kadar süreyle ve kimin erişebildiği.

5. Anahtar sınırları ve iptal. Bağımsız anahtarlar, kota üst sınırları, anahtar başına model izinleri ve anında iptal sunan servisleri tercih edin.

6. Doğrulanabilir kullanım. İdeali kayıtları modele, anahtara, oturuma ve isteğe göre görüp dışa aktarabilmektir.

7. Bir şey bozulduğunda ulaşacağınız biri. Hizmet şartları, işletici şirket, destek kanalları, bakım duyuruları ve iade süreçleri kolayca bulunabilmelidir.

Bunlar, “internetin en ucuzu”, “asla kapatılmaz” veya “kesinlikle stabil” iddialarından daha değerlidir. Doğrulayamayacağınız vaatler kararınızı belirlememeli.

7. Relay servisine hiç ihtiyaç duymadığınız durumlar

Tek bir agent’ı tek bir resmî hesapla kullanıyorsanız, kotanız genişse ve modeller arasında geçiş yapmıyorsanız doğrudan bağlantı bir aracı katmanı ortadan kaldırır.

Yalnızca ara sıra kısa süreli hız limitlerine takılıyorsanız, sıfırlanma saatini ve servis durumunu kontrol etmek sorunu çözebilir.

Bir API geçidinin değeri, çoklu model, çoklu araç ve çoklu hattın yönetim maliyetini düşürmektir. Değip değmediği çağrı hacminize, istikrar gereksinimlerinize, veri hassasiyetinize ve sağlayıcının fiyatlandırma ile çalışma kayıtlarını net şekilde açıklayıp açıklayamadığına bağlıdır.

Bağlanmadan önce küçük bir bakiye ve hassas olmayan bir projeyle test edin: tek bir minimal isteği geçirin, tek bir faturayı mutabık kılın ve bir birincil hat arızasını simüle edin. Üçü de anlaşılırsa gerçek işlerinizde kullanın.