Claude'un 5 saatlik kayan kullanım penceresi nasıl ölçülür ve buna göre nasıl plan yapılır

dev.to'da yayımlanan bir yazı, birçok Claude kullanıcısına tanıdık gelen bir sıkıntıya — refaktörün ortasında gelen kullanım limiti mesajına — eğiliyor ve çevresindeki kafa karışıklığının büyük kısmının, beş saatlik saatin neyi ölçtüğüne dair basit bir yanlış anlamadan kaynaklandığını savunuyor.

Saatin gerçekte ölçtüğü şey

Yazıya göre limit, kayan bir pencere. Zamanlayıcı, bir kullanım oturumundaki ilk mesajınızın zaman damgasıyla başlıyor — ne gece yarısıyla ne de engellendiğiniz anla. Bunun iki sonucu var. Birincisi, aynı planı kullanan iki kişi limitlerine tamamen farklı saatlerde ulaşıyor, çünkü pencereleri farklı anlarda açılmış oluyor. İkincisi, bekleme süresi kesildiğiniz andan değil, başladığınız andan ölçülüyor: 09:00'da başlayıp 09:40'ta tavana çarpan bir kullanım dalgası yine de 14:00'te kilidi açıyor.

Yazı ayrıca, beş saatlik pencereden bağımsız olarak sıfırlanan ayrı bir haftalık tavan olduğuna dikkat çekiyor. Oturum limitine ulaşmak haftalık kotanın tükendiği anlamına gelmiyor — ve tersi de geçerli değil.

Mesaj sayısı değil, ağırlıklı kota

Yazıya göre Anthropic evrensel bir mesaj kotası yayımlamıyor. Kullanım yerine birkaç bileşik faktörle ağırlıklandırılıyor: her tur birikmiş bağlamı taşıdığı için konuşma uzunluğu; daha büyük modeller kotayı daha hızlı tükettiği için model seçimi; bağlama okunan ekler ve dosya içerikleri; ve genişletilmiş düşünme ile tekrarlanan araç çağrıları da sayıldığından araç kullanımı, efor düzeyi ve artifacts.

Yazı, Claude Pro'da beş saatlik pencere başına kabaca 45 mesaje, Max 5x'te yaklaşık 225'e ve Max 20x'te yaklaşık 900'e ilişkin yayımlanmış tahminlere yer veriyor; ancak bunların garanti değil, yukarıdaki tüm faktörlere göre değişen büyüklük mertebesi rakamları olduğu uyarısını da ekliyor.

Agent oturumları neden limiti en hızlı tüketiyor

Agent oturumlarının kotayı sohbete kıyasla neden bu kadar hızlı tükettiğinin açıklaması mekaniklere dayanıyor. Bir sohbet turu bir prompt gönderip yanıt alıyor ve bağlam kısa kalıyor. Agent döngüsü ise özyinelemeli: her adım birikmiş bağlamı — aynı dosyaları, aynı araç çıktılarını, aynı talimatları — yeniden gönderiyor; dolayısıyla elli adımlı bir görev aynı bağlamı elli kez yeniden okuyabiliyor. Tüketim, tek bir sohbet turunun hiçbir zaman yapmayacağı biçimde görev uzunluğuyla birlikte büyüyor; bir haftalık sohbeti karşılayabilecek bir kotayı tek bir uzun kodlama oturumunun tüketmesinin sebebi bu. Yazıya göre tüketimdeki iki en büyük kulp, bu sırayla, konuşma uzunluğu ve model seçimi.

Limitte yapılacak dört şey

Yazı, kabaca size maliyetlerine göre sıralanmış dört seçenek sunuyor:

1. Sıfırlanmayı bekleyin. Ücretsizdir ve görev bekleyebiliyorsa doğrudur — ama önce sıfırlanma saatini kontrol edin, çünkü saat oturumunuz başladığında başladı ve bekleme beş saatten kısa olabilir.
2. Bağlamı küçültün. En yüksek etkili çözüm olarak tanımlanıyor ve hiçbir maliyeti yok: uzun bir konuşmayı sürdürmek yerine yeni bir thread başlatın, araç çıktısını yapıştırmak yerine özetleyin ve kontrolsüz bir döngünün pencereyi tek seferde tüketememesi için tek bir agent görevinin atabileceği adım sayısını sınırlayın.
3. Kullanım kredisi kullanın. Kredilerin etkin ve uygun olduğu yerlerde oturumlar duraklamak yerine dahili limitin ötesinde devam ediyor; çalışmaya devam ediyor ve fazlasını ödüyorsunuz.
4. İş yükünü bir API anahtarına taşıyın. Bu, kısıtın boyutunu değil biçimini değiştiriyor: abonelik bir zaman dilimini sınırlarken, API token veya istek üzerinden ölçüm yapıyor.

Token ölçümü ile istek ölçümü

Dördüncü yolu düşünenler için yazı, iki ölçüm modeli arasında keskin bir ayrım çiziyor. Token ölçümü size geniş bir tavan ve öngörülemeyen bir fatura veriyor: bir görevin maliyetini ancak bittiğinde öğreniyorsunuz, dolayısıyla bütçeleme geriye dönük oluyor. İstek ölçümü maliyeti izin verdiğiniz adım sayısıyla sınırlıyor ve bütçelemeyi bir yapılandırma kararına dönüştürüyor. Uzun görevler yürüten bir kodlama agent'i için, yazının savunusuna göre, istek ölçümü genellikle daha iyi bir uyum; ara sıra sohbet ve kısa işler için ise token ölçümü çoğu zaman daha ucuz.

Bir sağlayıcıya karar vermeden önce üç kontrol öneriliyor: tavana tam olarak ulaşıldığında ne oluyor — Retry-After başlıklı temiz bir 429 mü, yoksa adımı kaybeden ve diskte yarım uygulanmış bir düzenleme bırakabilen kesilen bir stream mi; limitler anahtar başına mı yoksa hesap başına mı uygulanıyor, çünkü hesap başına limitler tek bir kontrolsüz agent'in diğer tüm işleri aç bırakmasına izin veriyor; ve her istemci veya ortam için ayrı anahtarlar çıkarıp çıkaramıyorsunuz, böylece kullanım atfı net kalıyor.

Dikkat çekilmeye değer bir uyarı: yazı, onu yayımlayan hesapla aynı adı taşıyan belirli bir istek ölçümlü gateway'i önererek kapanıyor; dolayısıyla bu son öneri tanıtım olarak okunmalı. Anlattığı mekanizmalar ise kendi başlarına ayakta duruyor.

Neden önemli

Kodlama agent'leri geliştiricilerin modellerle çalışmanın birincil yolu haline geldikçe, sohbet biçimli kullanım etrafında tasarlanmış abonelik limitleri giderek bağlayıcı kısıt haline geliyor. Beş saatlik pencerenin kayan ve bağlam ağırlıklı olduğunu — düz bir mesaj sayısı olmadığını — bilmek, limit yönetimini tahminden planlamaya dönüştürüyor: oturumları bilinçli başlatın, thread'leri kısa tutun, araç çıktısını özetleyin ve agent adımlarını sınırlayın. Agent'leri hangi ölçekte çalıştırırsa çalıştırsın ekipler için zaman pencereli abonelik, token ölçümü ve istek ölçümü arasındaki seçim, bütçelemenin geriye dönük muhasebe mi yoksa baştan verilmiş bir karar mı olacağını belirliyor.