Claude Code cache hit oranları, cron job'ların günde 20 milyon boşa harcanan tokenını gizleyebilir

Bir dev.to yazısı, Claude Code panelindeki cache hit oranının ciddi bir israfı gizlerken sağlıklı görünebileceğini savunuyor; çünkü tek bir hesap düzeyindeki sayı, aralarında hiçbir şey paylaşmayan çağırıcıların üzerinde ortlama alıyor. Açılış örneği: bir deployment genel olarak %77 cache hit oranı raporlarken, aynı hesaptaki cron görevleri yaklaşık %0'da çalışıyordu; çünkü her zamanlanmış çalıştırma yeni bir session açıyor ve yaklaşık 30.000 tokenlık aynı statik prefix'i yeniden yazıyor. Günde 672 çalıştırmayla bu, hiçbir zaman cache'e dokunmayan kabaca günde 20 milyon input token demek — bir operatörün açık bir issue'ya gönderdiği ve yazarın alıntıladığı rakamlar.

Prompt caching nasıl fiyatlanır

Anthropic, caching'i sabit bir indirim yerine çarpanlarla fiyatlandırıyor ve yazı hesabı ortaya döküyor. 5 dakikalık TTL'li bir yazma işlemi taban input fiyatının 1,25 katına, 1 saatlik yazma 2 katına mal oluyor; okumalar çoğu modelde 0,1 kat (örnek tablo Opus 5.5'te 0,05, Fable 5.1'de 0,025 kat listeliyor). Bundan üç sonuç çıkıyor: tek bir okuma 5 dakikalık yazmayı kazançlı yapar (toplam 1,25 kat, iki cache'siz geçişte ise 2 kat), TTL çağrılar arasındaki boşluğa denk gelmeli ve kimsenin yeniden kullanmadığı bir breakpoint hiç kazanç sağlamak yerine %25 ila %100 ekstra maliyet demektir. Her hit TTL'i okuma fiyatından yeniler, bu yüzden yoğun bir cache süresiz olarak yaşar; keepalive kesişim noktası ise bir model özelliği değil oran olduğu için her modelde 62,5 dakikaya denk gelir.

Tek hesap, birkaç cache davranışı

Yazıda alıntılanan Anthropic dokümantasyonuna göre, plan kullanımı içinde abonelik faturalamasıyla Claude Code ana konuşmaya 1 saatlik TTL verir, geri kalan her şeye 5 dakika; API anahtarıyla, bir cloud sağlayıcı üzerinden veya plan limitlerini aşınca her şey 5 dakika alır. Subagent'ler, workflow'lar, fork'lar, compaction çağrıları ve session başlıklarının tümü bu ikinci kovaya girer; 2.1.242 sürümünden itibaren override'lar mevcuttur.

Yapısal ayrıntı şu: bir subagent'in ilk isteği ebeveynin cache'ini okuyamaz; çünkü farklı bir prompt ve araç seti, prefix'leri ilk tokenda birbirinden ayırır. Bir fork ise tersine, ebeveynin prefix'ini birebir devralır ve ilk isteğinde hit alır.

Yazı ayrıca bir tutarsızlığa dikkat çekiyor: dokümanlar subagent'lerin 5 dakika aldığını söylerken, bir kullanıcının transcript'leri her subagent yazımının 1 saatlik kovada faturalandığını gösteriyordu ve bir maintainer, etkin TTL'in hattın daha aşağısında belirlendiğini, dokümanların ise düzeltildiğini söyledi. Yazarın tavsiyesi, herhangi bir özet tabloya değil, ephemeral_5m_input_tokens ve ephemeral_1h_input_tokens ham response alanlarına güvenmek.

Neden genel geçer 1 saatlik TTL ters teper

Yazının ölçtüğü başarısızlık modu, bir subagent görevlendirip sonra bekleyen bir ebeveyne dayanıyor. Hiçbir istek gitmediği için ebeveynin cache'ini yenileyen bir şey olmuyor. Medyan child runtime yaklaşık 9 dakikaydı — süresi dolmadan hemen sonra — ve bu bekleyişlerin %96'sı cache gerçekten süresi dolmuşken sona erdi: ebeveyn devam ettiğinde, cache'lenmiş prefix'in en az yarısının tam fiyatla yeniden yazılması gerekiyordu.

Sezgilere aykırı sonuç şu: genel geçer 1 saatlik TTL faturayı %8,6 daha kötü hale getirdi. Yeniden kullanım neredeyse hiçbir zaman uzun pencereye ihtiyaç duymuyor: cache hit'lerinin %98'i yazmadan sonra yaklaşık 34 saniye içinde gerçekleşti, medyan boşluk 7 saniyeydi. Hedefli değişiklikler işe yaradı — görevlendirme sırasında 1 saatlik yazma faturayı %6,0, tür başına kalıcı statik prefix %1,0 ve dinamik içeriği stabil prefix'in arkasına taşımak %7,6 düşürdü; toplamda %13,6.

Caching'in sessizce başarısız olduğu yerler

Birkaç başarısızlık modu hiç hata üretmiyor. Token tabanları: güncel nesil modeller minimum 512 token'da cache'liyor; Opus 4.6/4.5 ve Haiku 4.5 ise 4.096 gerektiriyor ve tabanın altında cache-creation alanı düpedüz sıfır okuyor. Lookback limitleri: bir breakpoint önceki bir yazma için en fazla 20 blok geriye tarıyor ve bir geliştirici 23 blokta miss gördü. Farklı bir system prompt üzerinden çalışan compaction, ebeveynin prefix'ini tamamen kaçırıyor; böylece en büyük transcript tam fiyatla faturalanıyor. Zamanlanmış çalıştırmalar her çağrıda yepyeni bir session başlatıyor, bu yüzden statik prefix her seferinde sıfırdan yazılıyor; yazı, sıfıra yakın cron hit oranını, daha uzun bir TTL'in düzeltebileceği bir bug değil, mimarinin bir sonucu olarak ele alıyor.

Yazı ayrıca bir okuyucunun hikâyesini aktarıyor: logları kusursuz görünen bir ajan, üç günlük hafta sonu tatilinden sonra fatura bir anlam ifade etmeyene kadar. Nedeni, bir context-retrieval adımının chunk yerine bütün belgeleri çekmesiydi — çağrı başına 40.000 token, görev başına yedi-sekiz çağrı ve her response teknik olarak başarılıydı.

Neden önemli

Ajan iş yüklerini input token'lar domine ediyor; yazı bir ajan çalıştırmasını 271.000 output'a karşı 3,5 milyon input token olarak ölçüyor. Bu oranda, caching bütçenin input tarafında kazanılıp kaybedildiği yerdir ve satıcı düzeyindeki paneller, tam da sızıntı yapan çağırıcıları ortalamalarda yok ediyor. Öneriler somut: hit oranını TTL katmanının yanında çağırıcı başına loglayın, ham cache kovalarını özetlerden değil response usage'dan okuyun, stabil içeriği cache_control'ün önünde, tarih, çalışma dizini ve branch gibi değişken verileri arkasında tutun, 1 saatlik yazmaları yalnızca görevlendirme sıralarında ve paylaşılan statik prefix'lere uygulayın ve yazılan ama hiç okunmayan breakpoint'leri denetleyin. Çıkarım taşınabilir: OpenAI ve Google caching'i farklı ele alıyor, ama prefix'lerin konuşmalara ait olduğu her yerde, faturayı açıklanabilir kılan şey çağırıcı başına muhasebedir.