Kısa Versiyon
- 1M token bağlam penceresine sahip bir model üzerinde gün boyu bir AI kodlama ajanı çalıştırıyorum. Oturumlar neredeyse pencereyi doldurana kadar büyüyordu.
- Yapılandırmasına tek bir satır ekledim: bir oturumu, kendini özetleyip devam etmeden önce 350.000 token bağlamla sınırladım.
- 1.117 oturum kaydı üzerinden ölçüm: aynı sayıda istem için %17 daha az token ve sınırın gerçekten devreye girdiği uzun oturumlarda %55 daha az.
Aşağıda yöntem, tüm grafikler ve bunun size maliyeti var; böylece kendi kurulumunuza uyup uymadığına karar verebilirsiniz.
1M Pencere Göründüğünden Neden Daha Pahalı
Bir modelle yapılan konuşma durumsuzdur. Her istek tüm geçmişi taşır: sistem istemi, her araç tanımı, ajanın okuduğu her dosya, her araç sonucu, her mesaj. Bir fark değil. Her seferinde tamamı.
Yani 900.000 token’a büyümüş bir oturum, bir sonraki çağrıda ve ondan sonraki çağrıda da 900.000 token giriş için ödeme yapar. 400. tur, 4. turdan daha fazla iş yapmaz. Sadece kat kat daha pahalıya gelir.
İstem önbellekleme bunu yumuşatır. Modelin daha önce gördüğü tokenlar normal giriş fiyatının yaklaşık onda biri olarak faturalandırılır. Bu indirim gerçek, uzun oturumları baştan mümkün kılan şey bu ve kimsenin soruna bakmamasının nedeni de bu. Verilerimde tüm giriş tokenlarının %98’i önbellek okumasıydı. Çok büyük bir sayının onda biri yine de faturadaki en büyük kalemdi.
Soru, geçmişinizin önbelleğe alınıp alınmadığı değil. Bir şey onu sıfırlamadan önce ne kadar büyümesine izin verildiğidir.
Neyi Değiştirdim
Ajan, 1M bağlam penceresinde Opus çalıştıran Claude Code. Ayar, ~/.claude/settings.json içindeki autoCompactWindow. Bir oturum bu kadar token’a ulaştığında ajan konuşmayı özetler ve özetten devam eder.
{
"autoCompactWindow": 350000
}
Hiç ayarlamamıştım, bu yüzden oturumlar tam pencereye yaklaşana kadar sürüyordu. Dört gün boyunca üç değer denedim:
| Tarih | Ayar |
|---|---|
| 14 Eylül | 250.000 |
| 15 Eylül | 300.000 |
| 18 Eylül | 350.000 |
Nasıl Ölçtüm
Claude Code her oturumu ~/.claude/projects/ altında bir JSONL kaydına yazar; buna her API çağrısının token kullanımı da dahildir. 19 Ağustos’tan 22 Eylül’e kadar beş haftayı kapsayan 1.117 kaydın tamamını ayrıştırdım, istek kimliğine göre yinelenenleri kaldırdım ve yalnızca etkileşimli oturumları tuttum. GitHub Actions’daki çalıştırmalar aynı hesabı kullanır ama dizüstü bilgisayarımdaki bir ayardan etkilenemez, bu yüzden hariç tutulmuştur.
Ham token toplamları tek başına yanıltıcıdır. Neyi değiştirirseniz değiştirin, yoğun bir hafta sakin bir haftayı yener. Bu yüzden aşağıdaki her sayı önbellek ağırlıklıdır ve sayaç gerçekte bunu okur: yeni giriş 1x, önbellek yazmaları 1,25x (5 dakikalık önbellek) veya 2x (1 saatlik önbellek), önbellek okumaları 0,1x. Ve her karşılaştırma yapılan işe göre normalize edilir: ya yazdığım istemler ya da ajanın yaptığı API çağrıları.
İki Oturum, Aynı Ajan
Mekanizma tek bir resimde. Solda, 3 Eylül’den gerçek bir oturum, sınırdan önce. Sağda, 15 Eylül’den gerçek bir oturum, sınırdan sonra.
Soldaki oturum 781 çağrı sürdü. 996.000 token bağlama tırmandı, 1M pencerenin duvarına çarptı, bir kez sıkıştırıldı ve sonra doğrudan 880.000’e geri tırmandı. O oturumun ikinci yarısında her bir çağrı yarım milyondan fazla token’ı yeniden okudu.
Sağdaki oturum 1.642 çağrı sürdü, iki katından fazla uzun ve hiç 270.000’in üzerine çıkmadı. On beş kez sıkıştırıldı. Her sıkıştırma bir nokta.
Haftalık Sayılar
Yalnızca etkileşimli oturumlar. Çubuklar API çağrısı başına önbellek ağırlıklı giriş tokenları; bu en adil tek sayı çünkü belirli bir haftada ne kadar çalıştığımı umursamıyor.
Veri kümesindeki en temiz karşılaştırma 7 Eylül haftası ile 14 Eylül haftası, çünkü onları ben seçmedim. Değişimin iki yanına denk geldiler ve her birinde neredeyse tam olarak aynı sayıda istem yazdım.
| Hafta | İstemler | API çağrıları | Önbellek ağırlıklı giriş | Çağrı başına |
|---|---|---|---|---|
| 7 Eyl | 971 | 11.364 | 348,1M | 30,6k |
| 14 Eyl | 968 | 10.555 | 288,5M | 27,3k |
971 isteme karşı 968. Etkin giriş 348,1M’den 288,5M’ye düştü. Bu, aynı miktarda istem için %17 daha az demek. Sonraki haftanın iki günü çağrı başına 22,4k ile geldi, daha da düşük.
Para Nereye Gidiyordu
Her API çağrısını taşıdığı bağlam miktarına göre ayırın, mekanizma doğrudan görünür hale gelir.
Sınırdan önce, harcadığım her şeyin %39’u arkasında 350.000 token’dan fazla geçmiş sürükleyen çağrılara gitti. O çağrılar diğerlerinden daha fazla iş yapmıyordu. Aynı işti, daha fazla yük taşıyordu. Sınırdan sonra bu pay %12.
Tavan Tuttu mu
Oturum başına bir nokta, o oturumun hiç ulaştığı en büyük bağlama yerleştirildi.
İlk iki gündeki iki oturum hâlâ sınırı aşarak 434.000 ve 561.000’e çıktı ve nedenini bulamadım. 18 Eylül’de 350.000 ayarı girdiğinden beri hiçbir oturum bunu aşmadı. İsrafın çoğunun bulunduğu 500k ile 1M arasında yaşayan oturum kuyruğu ortadan kalktı.
Sınır Olmasaydı Maliyeti Ne Olurdu
Buna bir toplam koymak için, değişiklikten sonra başlayan her oturumu, düşürülen bağlam hiç özetlenmemiş ve sonraki her çağrıda hâlâ yeniden okunuyormuş gibi, 1M penceresiyle sınırlı olarak yeniden oynattım.
| Önbellek ağırlıklı giriş | |
|---|---|
| Gerçek, 73 oturum, 9.675 çağrı, 55 sıkıştırma | 216,8M |
| Sınır olmadan aynı oturumlar | 479,2M |
| Kaçınılan | 262,5M, yani %55 |
İlk grafiğin sağındaki oturum, bunun tek başına 118,5M’sini oluşturuyor. Aksi halde son birkaç yüz çağrısını neredeyse bir milyon token’ı yeniden okuyarak geçirecek uzun bir refactor.
%55’i iyimser uç olarak alın. Sınır olmadan gerçekte bir oturumun saatlerce 900k’da öğütülmesine izin vermezdim; sonunda onu elle temizlerdim, bu da maliyeti sıfırlar. Muhafazakâr uç, gözlemlenen çağrı başına rakam: 30,6k’dan 22,4k’ya, yani kabaca %20 ile %27. Gerçek bu ikisinin arasında bir yerde.
Size Maliyeti Ne
Bu bedava değil ve bunu öneren herkes bunu söylemeli.
Bekleme. Değişiklikten bu yana 67 sıkıştırma, medyan olarak her biri yaklaşık üç dakika. Sekiz güne yayılmış, bir özetin yazılışını izleyerek geçen yaklaşık 3,4 saat.
Bir miktar yeniden iş. Sıkıştırma çok şey düşürür. 350K ayarında medyan sıkıştırma, 318.000 token’lık bir oturumu 24.000’e indirdi. Ajan ayrıntıyı kaybeder ve bazen onu yeniden inşa eder: aynı oturum içinde yeniden okunan dosyalar, ilk sıkıştırmadan önce okumaların %11,5’iyken sonrasında %20,5’i oldu. İkinci sayının arkasındaki örneklem küçük, o yüzden onu bir ölçüm değil bir yön olarak okuyun.
Eşik seçimi önemli. 250K’da uzun oturumlarımın %36’sı bir sıkıştırmaya çarptı. 350K’da %12’si çarptı, tavan yine de tuttu. Çok düşük ayarlarsanız, zaten elde ettiğiniz bir tasarruf için üç dakikayı ve yeniden işi tekrar tekrar ödersiniz.
Nasıl Kurulur
Claude Code. ~/.claude/settings.json dosyasına autoCompactWindow ekleyin. 1M bağlamlı bir modelde denediğim üç değer arasında en iyisi 350.000 oldu. 200K’lık bir modelde ölçeği küçültün ve 120.000 ile 140.000 civarından başlayın. Yeni oturumlar bunu alır; hâlihazırda çalışan bir oturum eski değeri korur.
Diğer ajanlar. Aynı fikri farklı bir ad altında arayın: bir sıkıştırma tetikleyicisi, bir bağlam sınırı, bir özetle-ve-devam-et eşiği. Hiçbiri yoksa, manuel sürüm oturumu doğal hissettirenden daha sık temizlemektir. “Projeyi biliyor” diye tek uzun oturumu gün boyu canlı tutma içgüdüsü pahalı olanıdır.
Ne kullanırsanız kullanın, iki alışkanlık herhangi bir ayardan fazlasını yapar. Kalıcı durumu konuşmada değil dosyalarda tutun; böylece ajan önceki her yanıtı sonsuza kadar taşımak yerine tek bir dosyayı ucuza yeniden okuyabilir. Ve okuma ağırlıklı işi, kendi kısa ömürlü bağlamı olan alt ajanlara itin; böylece okudukları yirmi dosya ana oturuma hiç girmez.
Haftalık Limitteyseniz
Token başına fatura yerine haftalık kullanım limiti olan bir abonelik ödüyorsanız, bu bulduğum en iyi çaba/etki oranına sahip koldur. Tek satır JSON, çalışma şeklinizde hiçbir değişiklik yok ve aynı limit ölçülebilir şekilde daha uzağa uzanıyor. Benim durumumda aynı haftalık istem hacmi %17 daha ucuza geldi ve uzun oturumlar yaklaşık yarıya indi.
Sonra Okuyun
Bağlam pencereleri kapasite olarak satılır. Oysa bir sayaç gibi davranırlar: her turda, baştan beri koyduğunuz her şey için ücret alırlar. Bunun arkasındaki mekaniği, sadece ayarı değil, eşlik eden yazı bir bağlam penceresini gerçekte neyin doldurduğunu, uzun bir oturumun neden yaptığı işten çok daha pahalıya geldiğini ve önbellekleme, temizleme ve sıkıştırmanın aritmetiği nasıl değiştirdiğini adım adım anlatıyor.

