Claude Code Pro Max 5x planında, makul kullanımda bile kotanın 1,5 saatte tükenmesi sorunu

• Pro Max 5x (1M context) planında, orta düzeyde Soru-Cevap ve geliştirme çalışmasıyla bile 1,5 saat içinde token limitinin aşılması yaşanıyor
• Neden olarak, cache_read tokenlarının tam oranla (1.0x) hesaplandığı bir hata gösteriliyor; bu da önbellekleme etkisini ortadan kaldırıp hızlı tüketime yol açıyor
• Arka plan oturumlarının otomatik çağrılması, otomatik sıkıştırma (auto-compact) ve büyük context girdileri birlikte tüketim hızını artırıyor
• Topluluk, cache TTL kısalması (1 saat→5 dakika) ve cache invalidation (cache busting) olgusunu temel neden olarak analiz ediyor
• Anthropic, varsayılan context küçültme (400k), UX iyileştirmeleri ve etkin olmayan çağrıların optimizasyonu üzerinde çalışıyor ve kullanıcı geri bildirimleri topluyor

---

Pro Max 5x planında hızlı kota tükenmesi sorunu

• Pro Max 5x (claude-opus-4-6, 1M context) planında, orta düzey Soru-Cevap ve hafif geliştirme ile bile 1,5 saat içinde kotanın tükenmesi durumunun raporlandığı belirtiliyor
  • Önceki 5 saatlik yoğun geliştirmede tüketim normalken, sıfırlamanın ardından hızlı tüketim ortaya çıktı
  • Ortam: Claude Code CLI on WSL2, tek oturumda (2 kez otomatik sıkıştırma) gerçekleşti
• Başlıca neden olarak cache_read tokenlarının tam oranla (1.0x) hesaplandığı hata gösteriliyor
  • Normalde cache_read 1/10 oranında hesaplanmalı; aksi halde önbelleklemenin faydası ortadan kalkıyor
  • Token kullanımı, oturum günlüklerindeki (~/.claude/projects/.../*.jsonl) usage nesnesi üzerinden analiz edildi
• Arka plan oturumlarının otomatik çağrılması, otomatik sıkıştırmanın (auto-compact) yüksek maliyetli işlemleri ve 1M context window’un büyük girdileri birlikte etki ederek tüketim hızını artırıyor
• Topluluk analizine göre bazı kullanıcılar, cache TTL kısalmasını (1 saat→5 dakika) ve cache invalidation (cache busting) olgusunu ana neden olarak işaret ediyor
• Anthropic ekibi, varsayılan context küçültme (400k), UX iyileştirmeleri ve etkin olmayan çağrıların optimizasyonu üzerinde çalışıyor; ayrıca kullanıcı geri bildirimleriyle ek veri toplamayı istiyor

Ölçülen token tüketimi

• Pencere 1 (15:00–20:00, 5 saat, yoğun geliştirme)

  • 2.715 API çağrısı, 1.044M Cache read, 16.8M Cache create, 1.15M çıktı tokenı
  • Etkin giriş (1/10 oranı uygulandığında): 121.8M token
  • Express sunucusu + iOS uygulaması geliştirme, graphify pipeline, SPEC tabanlı çoklu ajan koordinasyonu yapıldı

• Pencere 2 (20:00–21:30, 1,5 saat, orta düzey kullanım)

  • Ana oturum (vibehq): 222 API çağrısı, 23.2M Cache read, 1.4M Cache create, 91k çıktı
  • Arka plan oturumları (token-analysis, career-ops dahil): toplam 691 çağrı, 103.9M Cache read, 387k çıktı
  • Toplam 13.1M etkin token (1/10 oranı uygulanırsa) → normalde kota aşımı olmamalı
  • Gerçekte ise 105.7M token (1.0x hesaplanırsa) → saatte 70.5M düzeyinde; bu da kota tükenmesiyle örtüşüyor

Başlıca sorunların özeti

• 1. Cache read tokenlarının ücret/kota hesabı hatası

  • Beklenen: cache_read 1/10 oranında hesaplanmalı
  • Gerçekte: tam oranla hesaplanıyor ve önbellekleme etkisi geçersiz hale geliyor
  • 1M context ortamında çağrı başına 100~960k token gönderildiğinden, 200’den fazla çağrıda dakikalar içinde tükenme görülebiliyor

• 2. Arka plan oturumlarının paylaşılan kotayı tüketmesi

  • Etkin olmayan oturumlar (token-analysis, career-ops vb.) da otomatik sıkıştırma ve son işlem çağrılarıyla paylaşılan kotayı sürekli tüketiyor

• 3. Otomatik sıkıştırmanın (auto-compact) yüksek maliyetli çağrıları

  • Sıkıştırma öncesi tüm context (~966k token) cache_creation olarak gönderiliyor; böylece en pahalı çağrı otomatik olarak oluşuyor

• 4. 1M context window’un yan etkileri

  • Büyük context, çağrı başına token sayısını keskin şekilde artırarak kota tüketim hızını hızlandırıyor

Yeniden üretme adımları

1. Pro Max 5x planında Opus modeliyle Claude Code’u çalıştırın
2. ~/.claude/rules/ içine yaklaşık 30 kural dosyası ekleyin (19k token ek yük)
3. Dosya okuma, build, test gibi araç ağırlıklı işler yapın
4. /context komutuyla context artışını doğrulayın
5. 200~300 çağrıdan sonra kotanın hızla düştüğünü doğrulayın
6. Başka terminallerde 2~3 oturum açık tutun
7. Sıfırlamadan sonra da kısa sürede kotanın tükendiğini doğrulayın

Beklenen davranış ile gerçek davranışın karşılaştırması

• Beklenen:

  • cache_read 1/10 oranında hesaplanmalı
  • Etkin olmayan oturumlar minimum düzeyde tüketmeli
  • Otomatik sıkıştırma aşırı tüketime yol açmamalı
  • Orta düzey kullanımda 2~3 saat dayanmalı

• Gerçek:

  • 1,5 saat içinde tükeniyor
  • Arka plan oturumları tüketimin %78’ini oluşturuyor
  • Toplam 105.7M token gönderimi nedeniyle cache_read’in tam oranla hesaplandığı tahmin ediliyor

İyileştirme önerileri

1. cache_read hesaplama yöntemini netleştirme — dokümantasyonda gerçek ücret/kota hesap oranını açıkça belirtme
2. Etkin token bazlı limit — cache_read için 1/10 oranının uygulanacak şekilde düzeltilmesi
3. Oturum boşta kalma tespiti — etkin olmayan oturumların otomatik çağrılarının engellenmesi veya uyarı gösterilmesi
4. Gerçek zamanlı token tüketimi görünürlüğü — cache_read, cache_create, giriş ve çıkış bazında kullanımın gösterilmesi
5. Context tabanlı maliyet tahmini — işlem öncesinde beklenen token maliyetinin gösterilmesi

Topluluk analizi ve tartışmalar

• cnighswonger

  • claude-code-cache-fix interceptor ile 24 saat boyunca 1.500 çağrı verisi topladı
  • Üç hipotezi (cache_read 0.0x, 0.1x, 1.0x) test etti; sonuçta yalnızca 0.0x modeli 5 saatlik pencerede tutarlı sonuç verdi (CV %34,4)
  • Sonuç: cache_read, pratikte kota üzerinde neredeyse etkisiz; cache normal çalışıyor
  • Ancak tek hesap verisi olduğu için ek doğrulama gerekiyor

• henu-wang

  • Cache TTL’nin 1 saatten 5 dakikaya düşürüldüğü regression sonrasında, oturum her duraklatıldığında cache_create oluşuyor ve 12,5 kat daha yüksek maliyet yaratıyor
  • Context uzadıkça maliyet doğrusal olmayan biçimde artıyor
  • Geçici çözüm olarak kısa oturumlar tutmayı, /compact komutunu aktif kullanmayı ve temel context’i CLAUDE.md içine önceden yüklemeyi öneriyor

• bcherny (Anthropic ekibi)

  • 1M context window kullanıldığında prompt cache miss’in yüksek maliyetli olduğunu kabul etti
  • UX iyileştirmeleri (uzun oturum yeniden başlatıldığında /clear yönlendirmesi) ve varsayılan context’in 400k’ye düşürülmesi seçeneklerini test ediyor
  • Çoklu ajan ve eklenti kullanımında etkin olmayan işlerin tokenları aşırı tükettiğini doğruladı; otomatik temizleme ve zamanlama iyileştirmeleri üzerinde çalışıyor

• wadabum

  • Yeni oturumlarda cache’in hiç isabet etmediği bir bug’a dikkat çekti (#47098, #47107)
  • git status tabanlı sistem prompt’u ile CLAUDE.md blokları her oturumda değiştiği için cache invalidation (cache busting) oluşuyor
  • cnighswonger, interceptor’un bazı sıralama kararlılığı düzeltmeleri yaptığını, ancak git-status sorununun ayrıca çözülmesi gerektiğini söyledi

Topluluk önerilerinin özeti

• RockyMM: Oturum limite ulaştığında otomatik özetleme sonrası devam etmeyi önersin ve TTL 10 dakikaya düşürülsün
• mikebutash: Pro planında 5 saatte yalnızca 2 prompt mümkün olduğunu bildirdi; v2.1.81 sürümüne geri dönüp cache-fix kurunca 3~4 kat iyileşme gördüğünü belirtti
• wutlu: Her iş için oturumu sıfırlayarak sorunu hafifletti
• dprkh: Debug mode skill (Skill.md) paylaşarak nedenin belirlenmesine katkı sundu

Sonuç

• Pro Max 5x planındaki hızlı kota tükenmesi sorununun; cache davranışı, TTL regression’ı, context şişmesi ve arka plan çağrılarının birleşik etkisinden kaynaklandığı görülüyor
• Topluluk, asıl nedenin cache_read hesaplama hatasından çok cache invalidation ve TTL kısalması olduğu yönünde analiz sunuyor
• Anthropic ekibi, varsayılan context’i küçültme, cache UX’ini iyileştirme ve etkin olmayan çağrıları optimize etme üzerinde çalışıyor; ayrıca kullanıcı geri bildirimleri (/feedback) ile ek veri toplamayı istiyor

[kimjoin2]

Kalite açısından bakınca bunun yerini alacak bir şey de yok.
Basit bir yamayla biraz daha kullanılabilse güzel olurdu.

[GN⁺]

Hacker News görüşleri

• Claude Code ekibinden Boris benim. Son dönemde bildirilen sorunları incelediğimizde, başlıca iki neden gördük

  1. 1M token context window kullanıldığında prompt cache miss maliyetli oluyor. Şu anda cache TTL 1 saat olduğu için, bir saatten uzun süre başından kalkarsanız oturum sona eriyor ve tüm cache’in yeniden yüklenmesi gerekiyor. Bunu iyileştirmek için UX düzenlemeleri yayımladık ve varsayılanı 400k’ye düşürme seçeneğini değerlendiriyoruz. Hemen test etmek isterseniz CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000 claude komutunu kullanabilirsiniz
  2. Aynı anda çok fazla plugin veya agent çalıştırıldığında token israfı oluşuyor. Bunu çözmek için UX iyileştirmeleri ile ikincil işlerin otomatik temizlenmesi ve zamanlanması üzerinde çalışıyoruz
     Sorun yaşayan kullanıcılar /feedback komutuyla geri bildirim gönderirse hata ayıklamaya yardımcı olur
  • Boris, toplulukta paylaşılan bu kullanıcı deneyimleri artık basit istisnalar değil. Jeff Bezos’un dediği gibi, bazen veri değil anekdotlar gerçeği söyler. Metriklerin yanlış olup olmadığını ciddi biçimde gözden geçirmeniz gerekiyor
  • Bunun neden bir anda ortaya çıktığını merak ediyordum ama araştırınca sebebin prompt cache TTL’nin 1 saatten 5 dakikaya düşmesi olduğunu gördüm. Yeni bir oturum başlatsanız bile sonunda her şeyi yeniden kurmak gerekiyor, yani verimsiz. Cache süresinin dolup dolmadığını takip etmek zorunda kalmak CC’nin felsefesiyle çelişiyor
  • Benim durumumda en ciddi gerileme, sistem promptunun her seferinde dosyaları zararlı yazılım taramasından geçirmeye çalışmasıydı. Bu yüzden tokenlar hızla tükendi ve sürekli “not a malware” yanıtı geldi. Bu tasarım kararı yanlıştı. Sonunda projeyi bırakıp Qwen’e geçtim ve oldukça iyi çıktı
  • /clear bildirimi çözüm değil. Cache’i temizleyince sonuçta yeniden kurmanız gerekiyor, yani maliyet aynı. UX ile kullanıcıyı daha küçük context’e yönlendirmek hizmet kalitesini düşürmek demek. Sorun maliyetse fiyatı ya da mimariyi düzeltmeniz gerekir
  • OpenAI sorun çıkınca kullanım limitini sıfırlıyordu, Anthropic’te ise böyle bir adım yok. Bu olay kasıtlıymış gibi bir izlenim veriyor

• Son zamanlarda Claude belirgin şekilde yavaş ve verimsiz hale geldi. Dosyaları özellikle belirtsem bile 5 dakikadan uzun süre keşif döngüsüne giriyor ve oturum sınırına hızla ulaşıyor. Günde sadece üç kez kullansam haftalık limitin %25’i gidiyor. Bu yüzden $100’lık Codex planına geçtim; doğruluk ve cömertlik açısından çok daha iyi. Yalnız Codex’in üslubu rahatsız ettiği için Agents.md’ye ayrıca talimat ekledim. Arayüz hissi olarak eski Claude Code daha iyiydi ama backend debugging ve karmaşık problem çözme tarafında Codex üstün. Şu anda Codex ile Cursor’un $20 planını karşılaştırmayı öneririm

  • Ben de benzer bir şey yaşadım. Claude birkaç gün önce durmuş gibi sadece düşünüyordu, ertesi gün ise normale dönmüştü
  • Codex Business planını (30 euro) kullanıyorum ve son dönemde kotanın azaldığını hissediyorum. Yine de şartlar hâlâ Claude Code’dan çok daha iyi
  • Şu anda Opus, Haiku ve Sonnet modellerinde confidence score davranışını karşılaştırıyorum. Opus, orta zorluktaki görevlerde verimlilik açısından en iyi sonucu veriyor
  • CC, Gemini-cli ve Codex kullandım; CC hâlâ en iyisi. Cursor veya Aider kombinasyonunun daha iyi olup olmadığını merak ediyorum
  • AI coding’de context israfı çok yüksek olduğu için, kapsamı özel sandbox ile sınırlarsanız verimlilik artıyor

• Issue’lara göz atınca Anthropic’in ticket’ları neden hızlı kapattığını anladım. Çoğu AI tarafından üretilmiş gürültü gibi görünüyor. Benim çözümüm şuydu

  1. Tüm oturumlarda max thinking açarak gereksiz yol aramalarını azalttım
  2. Oturumu sürekli aktif tuttum. Cache 5 dakikada dolarsa tokenları yeniden oluşturmak gerekiyor
  3. 200k token sonrasında hemen compact çalıştırdım
     Anthropic’in 1M modeli zorla uygulaması en büyük rahatsızlık kaynağım
  • Ben de issue’yu görünce güldüm. Muhtemelen Claude Code’a “tokenların neden bittiğini araştır” demişlerdir
  • Biri thinking’i açın diyor, biri kapatın diyor. İkisinin de token tasarrufu sağladığını söylemeleri ironik
  • Esas sorun, cache’in rastgele geçersizleşmesine yol açan bug. API istemcisi abonelerin cache’ini erken sonlandırıyor gibi görünüyor. Üstelik input token maliyetini de sessizce artırdılar
  • Ben de doğruladım. max effort yardımcı oluyor. Context’i %25’in altında tutmak önemli. Cache’in süresinin dolduğunu anlamanın bir yolu var mı merak ediyorum
  • /model opus veya /model sonnet komutlarıyla 1M modeli kapatabilirsiniz

• Artık sübvansiyon döneminin sonu yaklaşıyor gibi geliyor. Google Gemini topluluğunda da son dönemde kota daralması nedeniyle şikâyetler patlamış durumda (issue linki). Ben de sonunda Kiro IDE ile Codex CLI kombinasyonuna geçtim ve memnunum

  • Bu değişim beklenen bir şeydi. Bedava token döneminde ihtiyaç duyulan kütüphaneleri önceden oluşturmak akıllıca bir stratejiydi
  • Anthropic artık kurumsal müşterilere odaklı bir yapıya geçiyor ve OpenAI de benzer bir yol izliyor. Reddit ve Discord’da açık model ya da Çin menşeli alternatif arayışları var ama tam bir ikame henüz yok
  • antigravity pro kotayı hızlı tüketiyor ama flash mode çok daha cömert. STM32 projesi üzerinde çalışırken 3 kat daha yüksek üretkenlik elde ettim
  • Bu gidişatın sonu belki de çıktılara reklam eklenen bir dönem olacak
  • Bana eski 3 dolarlık Uber yolculuklarını hatırlatıyor

• Temel nedeni işaret eden issue’nun “Not planned” olarak kapatılmış olması tedirgin edici

  • Verilen yanıt AI yazmış gibi doğal durmuyor. “1 saatlik TTL daha pahalı” mantığı da garip. Toggle sunmama gerekçesinin maliyet olması ikna edici değil
  • O kadar korkmaya gerek yok. Kalite düşerse kullanmazsınız olur biter
  • Anthropic’in kumarhane gibi token sattığını ve kullanıcı para kaybetse de umursamadığını düşünüyorum. Bu model hoşunuza gitmiyorsa yerel LLM kullanmak daha mantıklı olabilir

• 2.1.34 sürümüne rollback yaptıktan sonra kota ve cache sorunlarının çoğu çözüldü.
  ~/.claude/settings.json dosyasına "effortLevel": "high", "CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING": 1 gibi ayarlar ekledim ve diğer sürümleri sildim.
  Adaptive thinking hâlâ tam olgunlaşmış değil ama ileride iyileşirse faydalı olabilir. Yine de Codex’e geçmeyi düşünüyorum

  • Ben de ~/.bashrc içine CLAUDE_CODE_MAX_OUTPUT_TOKENS=64000, DISABLE_AUTOUPDATER=1 gibi ayarlar ekledim

• Daha alt modellerde de benzer sorunlar vardı. Adil bir ilişki şeffaf ölçümle başlar diye düşünüyorum. Bu ay aboneliği iptal edeceğim

  • Bilgisayar uyku modundayken bile oturum başlatılıp token tüketildiği oldu. “Saat kaç?” gibi basit bir soruda bile %10 harcandı

• Bu yıl vergi beyanımı AI agent’larla denedim. Opus 4.6, Codex 5.4 ve Antigravity 3.1’i ayrı ayrı $20 planla kullandım.
  Codex bunu 12 dakikada kusursuz yaptı, Antigravity bir sayfayı atladı ama hızla düzeltildi. Claude Code ise kullanım limiti aşıldığı için durdu ve yeniden denemeden sonra da hata payı vardı. Beklentimin altında kaldı

  • Ben de benzer bir deney yaptım ama benim durumumda Claude muhasebeci düzeyinde doğruydu. Aynı görevde bile oturumdan oturuma sonuçların değişmesi ilginç. Belirlenimsiz yazılım çağında müşteri desteği gerçekten tuhaf bir deneyim

• Reddit’te paylaşılan güncelleme duyurusu sonrasında Claude, günlük kodlama için kullanılamayacak kadar değişti. Pro hesap kredisi bir saat içinde bitince Gemini ya da ChatGPT’ye geri döndüm

• Sonuç olarak Anthropic’in token ücretlendirme yapısı genel kullanıcıların aleyhine tasarlanmış gibi görünüyor. Gerçekte kullanınca ne kadar çok para istediklerini hemen hissediyorsunuz