Bağlamı sıkıştıran
üç adım.

Problem: çıktı büyük, pencere küçük.

Bir CI logu kolayca 50.000 token olabilir. Bir API yanıtı yüzlerce sipariş kaydı taşır. Test çıktısı, build logu, HTML, minified bundle… Hepsi agent’ın bağlam penceresine girmeden önce bir karar gerektirir.

Klasik çözüm kırpmak: ilk 200 satırı al, gerisini at. Ama hata çoğu zaman ortada olur. Ya da tüm çıktıyı olduğu gibi göndermek pencereyi doldurur; model asıl soruyu soramaz hale gelir.

Akış

Bu üç adımın hiçbiri model çağırmaz. Projeksiyon deterministiktir: aynı girdi, aynı tipli projeksiyon. Bu yüzden ctxc’nin çıktısı test edilebilir, tekrar üretilebilir ve maliyeti öngörülebilir.

1 · Pack: çıktıyı store’a al

~400 token’ı geçen bir çıktı ctx_pack ile sıkıştırılır. Çıktı çok küçükse ctxc dokunmaz; sıkıştırmanın maliyeti kazancından fazlaysa soyutlama yapmaz.

ctx_pack({
  text: rawOutput,
  query: "hangi istek 500 döndü"
})

// yanıt
tip=log
tokens=54813→343  (−%99,4)
handle=79ba5a7c5bde9a4e

query zorunlu değil; verirsen projeksiyon soruya göre kesilir. “Hangi kayıt hata verdi” gibi bir soru, hata satırlarını ve ilgili eşleşmeleri projeksiyonda tutar; alakasız tekrarları düşürür.

2 · Projeksiyon: ne olduğunu anlatan küçük şey

Projeksiyon, ham çıktının yerine geçmez; onu tarif eder. Bir log projeksiyonu satır sayısını, zaman aralığını, seviye dağılımını, şablonları ve hataları taşır:

#projection
lines 2.601 · chars 219.000
range 2026-11-14T08:00:00Z .. 2026-11-14T08:42:31Z
levels INFO=2014 WARN=155 DEBUG=390 ERROR=11
status 200=1730 500=21
templates 9
  1690× INFO api request id={id} method={} path={} status={} latency={}ms
   420× INFO worker job=reindex id={id} items={} latency={}ms
   ...
errors 11
L1423 2026-11-14T08:24:13Z ERROR worker job=reindex id=job_81f failed: timeout after 30000ms
  at Worker.process (worker/reindex.ts:117:18)

Bir JSON projeksiyonu ise şemayı ve dağılımı taşır: dizi uzunluğu, alan tipleri, sayısal min/max, düşük kardinaliteli alanların sayımı ve tek örnek kayıt. 320 siparişlik bir yanıt, birkaç düzine satıra iner.

• Log: seviye/status sayıları, zaman aralığı, şablonlar, hatalar, sorgu eşleşmeleri.
• JSON: anahtarlar, dizi boyutları, alan istatistikleri, örnek kayıt.
• CSV: satır/kolon sayısı, tip çıkarımı, min/max/ortalama, kategorik dağılım.
• Test: sonuç, dosya bazında geçen/kalan, failure ve assertion satırları.
• Transcript: hedef, kısıt, karar, hata ve sonraki adım.

3 · Handle: kaybı geri alınabilir yapan şey

Her pack çağrısı bir handle döndürür. Ham blok store’da bu handle ile durur. Projeksiyon bir satırı, bir alanı ya da bir kaydı atladıysa ctx_get ile aynen geri gelir.

ctx_get({ handle: "79ba5a7c5bde9a4e", lines: "1423:1425" })
ctx_get({ handle: "79ba5a7c5bde9a4e", grep: "timeout", context: 2 })
ctx_get({ handle: "79c98df0f1e0dd32", json_pointer: "/orders/37/total" })
ctx_get({ handle: "4d1e09...", record: 3 })

lines satır aralığı, grep metin araması, json_pointer JSON alanı, record ise yapısal bir kayıt getirir. context grep sonucuna komşu satırları ekler. Hepsi aynı store’a bakar.

Projeksiyon seçimi

Projeksiyon, içeriğin şekline göre seçilir. Aynı stratejiyi her metne uygulamak kötü sonuç verir; bu yüzden ctxc tipli projeksiyonlar kullanır.

Oranlar içeriğe ve sorguya göre değişir. Canlı demo, gerçekçi veri setlerinde ölçülen sayıları gösterir; evrensel bir “%99” iddiası değildir.

Nerede duruyor

• Küçük çıktı: ~400 token altında ctxc dokunmaz; aynen döner.
• Token sayısı: yaklaşık karakter / 4. Gerçek projeksiyon kendi sayımını raporlar; demo da bunu not eder.
• Store: ctxc yerelde çalışır; --store ile yolu sen seçersin. Demo sayfasındaki handle’lar tarayıcı oturumuna aittir.
• Model değil: ctxc çıktıyı bir modele özetletmez. Deterministik projeksiyon kullanır; aynı girdi aynı tipli projeksiyonu üretir.
• Tam metin gerekiyorsa: projeksiyonla yetinme; ctx_get ile orijinali çek. Zaten tasarımın amacı bu.

Sıradaki

Mekaniği gördün. Şimdi araçların parametrelerine, kuruluma veya canlı ölçüme geç.