Tek Bir Ayar AI Kodlama Ajanımın Token Kullanımını %17 Azalttı: İşte Rakamlar

Sep 22, 2026 tarihinde Štefan Moravík tarafından yayınlandı.
AI Agents Token Optimization Claude Code Developer Tools
Bu sayfada 6 dakika okuma
  1. 1Kısa Versiyon
  2. 21M Pencere Göründüğünden Neden Daha Pahalı
  3. 3Neyi Değiştirdim
  4. 4Nasıl Ölçtüm
  5. 5İki Oturum, Aynı Ajan
  6. 6Haftalık Sayılar
  7. 7Para Nereye Gidiyordu
  8. 8Tavan Tuttu mu
  9. 9Sınır Olmasaydı Maliyeti Ne Olurdu
  10. 10Size Maliyeti Ne
  11. 11Nasıl Kurulur
  12. 12Haftalık Limitteyseniz
  13. 13Sonra Okuyun

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.

FlowHunt Logo

İşinizi büyütmeye hazır mısınız?

Bugün ücretsiz denemenizi başlatın ve günler içinde sonuçları görün.

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:

TarihAyar
14 Eylül250.000
15 Eylül300.000
18 Eylül350.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.

İki gerçek oturumda her API çağrısının taşıdığı bağlam: sınırdan önce bağlam 996k token’a tırmanıyor, bir kez sıkıştırılıyor ve 880k’ya geri tırmanıyor. Sınırdan sonra 24k ile 270k arasında testere gibi inip çıkıyor ve on beş kez sıkıştırıyor.

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.

Haftaya göre API çağrısı başına önbellek ağırlıklı giriş tokenları. Sınırdan önceki dört hafta 27,9k ile 36,1k arasında. Sınırın uygulandığı hafta 27,3k’ya, sonraki kısmi hafta 22,4k’ya düşü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İstemlerAPI çağrılarıÖnbellek ağırlıklı girişÇağrı başına
7 Eyl97111.364348,1M30,6k
14 Eyl96810.555288,5M27,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.

Çağrının bağlam boyutuna göre tüm önbellek ağırlıklı giriş harcamasının payı. Sınırdan önce harcamanın %24’ü 350k-500k bağlam taşıyan çağrılara, %15’i 500k üzeri çağrılara gitti. Sınırdan sonra bu paylar %8 ve %5.

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.

Oturum başına ulaşılan en büyük bağlam, her biri bir nokta. Sınırdan önce 260 oturum 100k’dan 996k’ya yayılıyor. Sınırdan sonra 59 oturum 320k’nın altında kümeleniyor; ilk iki günden 434k ve 561k’da iki istisna var.

İ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ırma216,8M
Sınır olmadan aynı oturumlar479,2M
Kaçınılan262,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.

Sıkça sorulan sorular

Štefan, FlowHunt'ı geliştiren bir yapay zeka ve yazılım mühendisidir. Ürünün kendisinin ötesinde, geliştirme maliyetlerini düşürürken kod kalitesini artıran geliştiriciler için agentic yazılım mühendisliği iş akışları tasarlar.

Štefan Moravík
Štefan Moravík
Yapay Zeka & Yazılım Mühendisi

Bağlamını İsraf Etmeyen AI Ajanları Kurun

FlowHunt, her adımın yalnızca ihtiyaç duyduğu bağlamı taşıdığı ajan iş akışları tasarlamanıza olanak tanır; böylece tokenları geçmişi yeniden okumaya değil, işe harcarsınız.