Context Mode - Claude Code'un bağlam tüketimini %98 azaltan MCP sunucusu

 (mksg.lu)
39 puan yazan GN⁺ 2026-03-02 | 1 yorum | WhatsApp'ta paylaş
  • Harici araç çağrıları sırasında oluşan büyük miktardaki ham verinin bağlam penceresini hızla tüketmesi sorununu çözer
  • Claude Code ile araç çıktıları arasına yerleşerek veriyi sıkıştırıp filtreler, 315KB'yi 5.4KB'ye indirir (%98 tasarruf)
  • Sandbox yapısı sayesinde her çalıştırmayı izole eder ve yalnızca stdout'u bağlama dahil ederek log, snapshot gibi ham verilerin sızmasını engeller
  • SQLite FTS5 tabanlı bilgi tabanı ile Markdown içeriğini indeksler, BM25 sıralaması ve Porter stemming uygulayarak doğru kod bloğu aramayı destekler
  • Aynı 200K token sınırında oturum süresi 30 dakikadan 3 saate çıkar ve yapay zeka ajanları için verimli bağlam yönetimi sağlar

Sorun

  • Claude Code'un MCP araç çağrıları, her çağrıda ham veriyi doğrudan 200K bağlam penceresine döker
    • Playwright snapshot'ı 56KB, 20 GitHub issue'su 59KB, access log'ları 45KB vb.
    • Yaklaşık 30 dakikalık kullanımda toplam bağlamın %40'ı tüketilir
  • MCP, harici araç kullanımının standardı haline geldi ancak hem girdi tanımları hem de çıktı verileri bağlamı dolduran yapısal bir sınıra sahip
  • 81'den fazla araç etkin durumdayken ilk mesajdan önce bile %72 (143K token) tüketilmiş olur

Context Mode'un yapısı

  • Claude Code ile araç çıktıları arasında konumlanan bir MCP sunucusu olarak, ham veriyi en aza indirerek iletir
    • 315KB'lik çıktı 5.4KB'ye düşer (%98 azalma)
  • Her execute çağrısı, bellek ya da durum paylaşımı olmadan bağımsız çalışan izole bir alt süreçte yürütülür
    • Yalnızca stdout bağlama dahil edilir; log'lar, API yanıtları, snapshot'lar vb. sandbox içinde tutulur
  • 10 dil çalışma zamanı desteği: JavaScript, TypeScript, Python, Shell, Ruby, Go, Rust, PHP, Perl, R
    • Otomatik Bun algılama ile JS/TS çalıştırma hızı 3 ila 5 kat artar
  • Kimlik doğrulaması yapılmış CLI'lar (gh, aws, gcloud, kubectl, docker), kimlik bilgilerini güvenli biçimde aktarmak için ortam değişkeni miras alma yöntemi kullanır

Bilgi tabanı (knowledge base)

  • index aracı, Markdown'ı başlık bazında böler ve kod bloklarını koruyarak SQLite FTS5 sanal tablosuna kaydeder
  • Arama sırasında BM25 sıralama algoritması kullanılarak kelime sıklığı, ters belge sıklığı ve belge uzunluğu normalizasyonuna göre ilgililik hesaplanır
  • Porter stemming sayesinde “running”, “runs”, “ran” aynı kök olarak eşleştirilir
  • search çağrısında özet yerine tam kod blokları ve başlık hiyerarşisi döndürülür
  • fetch_and_index, URL'yi alır, HTML'yi Markdown'a dönüştürür ve indeksler; orijinal sayfa bağlama dahil edilmez

Performans verileri

  • 11 gerçek senaryoda (test triage, TypeScript hata teşhisi, git diff incelemesi vb.) her durumda çıktı 1KB'nin altında tutuldu
    • Playwright snapshot'ı: 56KB → 299B
    • GitHub issue'ları (20 adet): 59KB → 1.1KB
    • Access log'ları (500 kayıt): 45KB → 155B
    • CSV analizi (500 satır): 85KB → 222B
    • Git log'u (153 commit): 11.6KB → 107B
    • Repository incelemesi (subagent): 986KB → 62KB (37 çağrı yerine 5 çağrı)
  • Tüm oturum bazında 315KB → 5.4KB küçülme, oturum süresi 30 dakika → 3 saat
  • 45 dakika sonra kalan bağlam: önce %60 → %99

Kurulum ve kullanım

  • Plugin Marketplace üzerinden otomatik yönlendirme hook'u ve slash command desteği
  • Yalnızca MCP için kurulum da mümkün
  • Claude Code yeniden başlatıldıktan hemen sonra kullanılabilir

Gerçek değişim

  • Kullanım biçimini değiştirmeden PreToolUse hook'u çıktıyı otomatik olarak yönlendirir
  • Subagent'lar varsayılan araç olarak batch_execute kullanır
  • Bash subagent'ı general-purpose sürümüne yükseltilerek MCP araçlarına erişebilir hale gelir
  • Sonuç olarak bağlam penceresi artık hızla dolmaz ve aynı token ile daha uzun oturumlar sürdürülebilir

Geliştirme arka planı

  • MCP Directory & Hub işletilirken tüm MCP sunucularının ham veriyi bağlama döktüğü ortak bir kalıp keşfedildi
  • Cloudflare'ın Code Mode yaklaşımının araç tanımlarını sıkıştırmasından ilham alınarak bu yaklaşım çıktı verisi sıkıştırmasına doğru genişletildi
  • Claude Code oturumlarında 6 kat daha uzun çalışılabildiği görüldükten sonra MIT lisansı ile açık kaynak olarak yayımlandı
  • GitHub: mksglu/claude-context-mode

İlgili okumalar

1 yorum

 
GN⁺ 2026-03-02
Hacker News yorumları

  • Burada önerilen FTS5 indeksleme yaklaşımı doğru, ama bence bir adım daha ileri gitmek gerekiyor
    Araç çıktısı yapılandırılmış veriyle (JSON, tablolar, ayarlar) doğal dilin (yorumlar, hata mesajları, docstring'ler) karışımından oluşuyor; bu yüzden salt BM25 iyi performans vermiyor
    Benzer bir sorunu çözmek için Model2Vec + sqlite-vec + FTS5 birleştiren hibrit bir arama sistemi yaptım. İki arama sonucunu Reciprocal Rank Fusion(RRF) ile birleştirince, hem BM25'in tam anahtar kelime eşleşmesini hem de vektör aramanın anlamsal eşleşmesini aynı anda elde edebiliyorsunuz
    Artımlı indeksleme de önemli. Benim indeksleyicim --incremental bayrağıyla yalnızca değişen parçaları yeniden embedding'den geçiriyor. Toplam 15.800 dosyayı baştan yeniden indekslemek 4 dakika sürüyor, günlük artımlı güncellemeler ise 10 saniyenin altında
    Cache tarafında da bu yaklaşım avantajlı. Aynı sorgu için sıkıştırılmış çıktı deterministic olduğu için prompt cache istikrarlı biçimde çalışıyor
    Context Mode mimarisine eklenebilecek bir şey de, aynı arama sistemini PostToolUse hook'u olarak çalıştırıp çıktının sohbete girmeden önce sıkıştırılmasını sağlamak olurdu

    • OP'nin yaklaşımında yapılandırılmış yanıtların olduğu gibi kalması sorunluydu; ben de sandbox çalıştırması yapılamayan bir MCP gateway geliştiriyorum, bu yüzden bu yöntem çok faydalı görünüyor. Bugün bunu denemeyi planlıyorum
    • Bu konuda daha derin bir yazı mutlaka okumak isterim. HN'deki titiz not tutucuların hoşuna gider gibi geliyor
    • Ben de bu Obsidian indeksleme çalışmasının arka planını ve uygulama sürecini ayrıntılı görmek isterim

  • Yazının yazarı benim. Birkaç gün önce GitHub deposunu paylaşmıştım ve güzel geri bildirimler aldım. Bu yazı da onun mimari açıklaması
    Temel fikir şu: MCP araç çağrılarının döktüğü ham veriyi 200K bağlam penceresine koymak yerine, Context Mode izole bir alt süreç oluşturuyor ve yalnızca stdout'u bağlama iletiyor. LLM çağrısı olmadan, tamamen algoritmik olarak çalışıyor; SQLite FTS5 + BM25 + Porter stemming kullanıyor
    Son dönemde 228 yıldız ve gerçek kullanım verisi elde ettim; bu sırada alt ajan yönlendirmesinin ne kadar önemli olduğunu fark ettim. Bash alt ajanını genel tipe otomatik yükseltip batch_execute kullanırsanız, bağlamı ham çıktıyla doldurmanıza gerek kalmıyor

    • Blog yazısına Cloudflare Code Mode gönderisinin bağlantısını eklemek iyi olabilir. README'de var ama metnin içinde yok
    • Çok ilginç görünüyor, ben de bizzat denemeyi düşünüyorum. Yalnız anladığım kadarıyla Context Mode, MCP bağlam kullanımının kendisini ele almıyor; doğru mu, bunu netleştirmek isterim. Birden fazla Claude ortamında MCP kullandığım için yalnızca CLI ile sınırlı kalmak yetersiz geliyor
    • Bunun Zed Agent gibi başka ajanlarla da kullanılıp kullanılamayacağını merak ediyorum
    • Codex desteği olmamasının özel bir nedeni var mı, öğrenmek isterim. Yapı gereği ajandan bağımsız görünüyor
    • Bunun cache'i bozup bozmadığını merak ediyorum

  • Neden mcp-cli modu kullanılmıyor, anlayamadım. Ben wener-mcp-cli ile klon bir sürüm hazırladım

  • Harika bir çalışma. Bağlam penceresi yönetiminde hâlâ geliştirilecek çok şey olduğunu düşünüyorum. Örneğin model birden çok denemeden sonra doğru cevabı buluyorsa, başarısız denemeleri bağlamdan çıkarmaya yönelik bir backtracking yaklaşımı faydalı olabilir

    • Ben de katılıyorum. Hata ayıklama sırasında oluşan log'lar veya başarısız deneme kayıtları, hata düzeldikten sonra kaldırılabilmeli. Mevcut IDE'lerde bunu elle yapmak zahmetli. Ajanın bağlamı kendi kendine yönetmesi ve log gibi şeyleri belli bir sayının ardından otomatik temizlemesi iyi olurdu. Bağlamı basit bir yığın değil, serbestçe düzenlenebilen bir alan olarak görmek gerekiyor
    • Başarısız denemeler sonuçta gürültü. Yeniden deneme kalıplarını otomatik tespit edip yalnızca son başarılı sürümü bırakmak gayet uygulanabilir
    • Şu an 1990'ların sonları gibi hissettiriyor. O zamanlar HTML ve SQL vardı, şimdi ise kodlama ajanları var. Biz zaten deneyimli mühendisleriz; Claude Code kullanırken optimizasyonları doğal olarak keşfediyoruz
    • Alt ajanlardan yararlanmak da bir yöntem. Sorun çıktığında bir alt ajan fork edip çözdürür, sonra sadece sonucu geri alırsınız. Modelin kendi hafızasını silip geçmiş duruma geri döndüğü fikri de ilginç
    • Ben gerçekten bunu yapıyorum. Her görev çağrısı ayrı bir alt süreçte çalıştırılıyor, böylece üst bağlam kirlenmiyor. Tamamlandıktan sonra sonuç, süreç özeti, başarısız denemeler ve öğrenilenler olmak üzere 4 başlık halinde üst sürece aktarılıyor. Araç çıktıları dosyaya kaydediliyor ve LLM yalnızca gerekli kısımları okuyor. Örneğin çıktı “Success!” ile bitiyorsa sadece son satıra bakmak yetiyor. Başarısızsa yalnızca hata mesajını okuyor. Ayrıca log'ları yerel bir modelle özetleyip bulut modeline aktarmayı da deniyorum. En yeni teknik olmayabilir ama benim ortamımda iyi çalışıyor

  • Bu yazıyı görünce Claude Code token kullanımını hiç bilmediğimi fark ettim ve bu sabah claude-trace adında bir CLI yaptım
    ~/.claude/projects/*/*.jsonl dosyalarını parse edip oturum, araç, proje ve zaman akışına göre kullanım ile maliyeti (cache okuma/oluşturma dahil) analiz ediyor
    Context Mode çıktı sıkıştırma sorununu iyi çözüyor gibi görünüyorsa, bu da ölçüm katmanı olarak değişiklik öncesi ve sonrası tüketimi görselleştiriyor

    • “/context?” sorusundaki gibi, asıl önemli olan token'ların gerçekten nereye gittiğini görünür kılmak

  • Çok fazla token kullanımı, MCP yerine CLI uygulamaları kullanılarak azaltılabilir. Örneğin GitHub CLI, MCP'ye kıyasla aynı işi çok daha az token'la yapıyor

  • Hook'lar fazla agresif geliyor. Tüm curl/wget/WebFetch çağrılarını engelleyip sandbox içinde 56KB snapshot üretmek güzel ama, basit bir curl api.example.com/health gibi yalnızca 200 bayt gereken durumlarda bu aşırı kalıyor
    153 git commit'ini 107 bayta sıkıştırırsanız, modelin veriyi görebilmesi için kusursuz bir çıkarım script'i yazması gerekiyor. Yanlış komut yazarsa ihtiyaç duyulan bilgi kayboluyor
    Benchmark'ler modelin her zaman doğru özetleme kodunu yazdığını varsayıyor ama gerçekte durum böyle değil

    • Ben de katıldığım için o özelliği kaldırdım

  • Fena değil ama doğruluk kaybı ve halüsinasyon riski var. Eksik veri veya hatalı çıkarım mantığı yüzünden Claude yanlış sonuçlara varabilir. Burada, MCP'nin hem iyi bir çıkarım script'i hem de iyi arama sorguları yazacak kadar akıllı olduğu varsayılıyor. Bilginin korunmasının pratikte büyük bir sorun olduğunu düşünüyorum

  • Sıkıştırma oranı etkileyici ama modelin sıkıştırılmış bağlamla da aynı kalitede çıktı verip vermediğini merak ediyorum. Oturumu 30 dakikadan 3 saate çıkarıyorsanız, 2. saatteki muhakeme kalitesinin de korunması gerekir ki anlamlı olsun
    esafak'ın söylediği cache ekonomisi de önemli. Prompt caching iyi çalışıyorsa, uzun bağlam aslında neredeyse bedava olabilir. Ama sıkıştırma cache sürekliliğini bozuyorsa, tam tersine maliyet artabilir
    Daha temel sorun ise çoğu MCP aracının tüm veriyi SELECT * ile çekmesi. Bu da özetleme ve drill-down destekleyen bir protokol tasarımı sorunu

    • Cache ücretsizmiş gibi görünse de gerçekte dikkat kaybına ve hız düşüşüne yol açıyor. Uzun prefix yeniden kullanılsa bile hesaplama yükü hâlâ büyük

  • 80'den fazla aracı bağlama koymak gerçekten gerekli mi, emin değilim. Bağlam altın kadar değerli; sorunla ilgisiz ne kadar çok şey koyarsanız sonuç da o kadar kötüleşir. Veri sıkıştırmaktan çok alt ajan ayrımı daha iyi bir yaklaşım gibi duruyor

    • Doğru, ama çoğu kişi görev bazında MCP sunucularını doğrudan yönetmiyor. Sadece 5-6 sunucu kurunca bile varsayılan olarak 80 araç yükleniyor. Context Mode, araç tanımlarındaki fazlalığı çözmüyor. Bunun yerine, araç çalıştıktan sonra dökülen çıktı tarafını ele alıyor. Örneğin yalnızca bir Playwright snapshot'ı veya git log bile 50 bin token tüketebiliyor; bunu sandbox içinde işliyor