Prompt Caching · Context Yönetimi

Prompt Caching · Context Management

Agent'ının history'sini shrink etmeli misin?

Should you shrink your agent's history?

Sezgi “context büyüyorsa kırp” der. Ama prompt caching açıkken biriken history zaten hit fiyatından geçiyordur — ve onu kırpmak cache prefix'ini bozarak aynı tokenları miss fiyatından geri getirir. Bu araç o dengeyi kendi sayılarınla turn turn hesaplar.

Intuition says “context is growing, trim it.” But with prompt caching on, accumulated history is already billing at the hit rate — and trimming it breaks the cached prefix, bringing those same tokens back at the miss rate. This tool works that tradeoff out, turn by turn, on your numbers.

Zincir birikir

The chain accumulates

Turn başına 5 tool call, her biri 20k token eklerse o turn 100k token büyür. Bir sonraki turn buranın üstüne biner.

Five tool calls per turn, 20k tokens each, and that turn alone grows the prompt by 100k. The next turn stacks on top of it.

Cache prefix'i taşır

Cache carries the prefix

Prompt'un değişmeyen kısmı hit fiyatından geçer, sadece yeni eklenen kısım miss öder. Fiyat farkı iki mertebe olabilir.

The unchanged prefix bills at the hit rate; only the newly appended slice pays miss. That gap can be two orders of magnitude.

Cevap: cold start'a bakar

The answer hinges on cold starts

Cache sıcak kalıyorsa shrink genelde zarardır. Turn'ler arası TTL doluyor ve her turn soğuk giriyorsa shrink büyük kazançtır. Belirleyici olan bu.

If the cache stays warm, shrinking usually loses. If the TTL expires between turns and every turn enters cold, shrinking wins big. That's the deciding variable.

Kararı hesapla

Run the decision

Kendi fiyatlarını ve mimarini gir. Araç taraf tutmaz — girdiler neyse sonuç odur. Shrink kazandırıyorsa onu, zarar ettiriyorsa onu gösterir.

Enter your own prices and architecture. The tool takes no side — the output is whatever the inputs imply. If shrinking wins it says so; if it loses, it says that too.

Fiyatlar ($ / 1M token)

Pricing ($ / 1M tokens)

Cache hit Cache hit

Cache miss Cache miss

Varsayılanlar DeepSeek off-peak fiyatlandırmasından. Kendi sağlayıcının rakamlarını gir.

Defaults follow DeepSeek off-peak pricing. Swap in your own provider's numbers.

Senaryo

Scenario

Başlangıç prompt (token) Starting prompt (tokens)

Tool sonuçları şuna insin (token) Compact tool results to (tokens)

Turn içinde tool sonuçları tam boyutuyla gelir; turn bitince bu boyuta indirilir. Konuşmanın kendisi silinmez — history birikmeye devam eder.

Tool results arrive at full size during the turn, then get compacted to this size once it ends. The conversation itself is kept — history still accumulates.

Yapı (ortalamalar)

Structure (averages)

Turn başına ort. tool call Avg. tool calls per turn 5

Call başına ort. eklenen token Avg. tokens appended per call 20k

Turn sayısı Number of turns 10

Bu üçü ortalama değerdir — her turn aynı kabul edilir. Gerçek agent'larda tool call sayısı turn'den turn'e oynar; sonucu tek bir fatura değil, eğilim olarak oku.

These three are averages — every turn is treated identically. Real agents vary call counts turn to turn; read the result as a trend, not a single invoice.

Output token maliyetini de hesaba kat Include output token cost

Cache durumu Cache state

Turn'ler arası cache hâlâ geçerli mi? Soğukta her turn'ün girişi baştan miss öder. Is the cache still valid between turns? When cold, each turn's entry pays a full miss.

Shrink yok

No shrink

—

Shrink var

With shrink

—

Fark

Difference

—

Son taşınan boyut

Final carried size

—

Turn turn döküm

Turn-by-turn breakdown

Eğrinin nerede ayrıldığını görmek için tabloyu oku. Fark sütunu birikimli.

Read the table to see exactly where the curves diverge. The difference column is cumulative.

Turn	Zincir zirvesiChain peak	Taşınan · shrink yokCarried · no shrink	Taşınan · shrink varCarried · with shrink	Maliyet · shrink yokCost · no shrink	Maliyet · shrink varCost · with shrink	Birikimli farkCumulative diff

Model nasıl çalışıyor

How the model works

Kapalı kutu değil. Hesap şu üç kuraldan ibaret.

No black box. The whole calculation comes down to three rules.

Zincir içi maliyetCost inside a chain

Zincirin ilk call'ı prompt'un tamamını öder — cache sıcaksa hit, değilse miss. Sonraki her call'da yalnızca yeni eklenen dilim miss, geri kalan prefix hit'tir.

The first call in a chain pays for the whole prompt — at hit rate if the cache is warm, miss if not. On every later call, only the newly appended slice is a miss; the rest of the prefix hits.

// entry = bu turn'e taşınan history prompt = entry // ilk call (call[0]) üç durum: turn 1 veya soğuk → prompt × MISS // cache boş/soğuk sıcak + shrink yok → prompt × HIT // prefix aynen korundu sıcak + shrink → (entry − fresh) × HIT + fresh × MISS // fresh = min(shrinkTo, entry): taze özet // bu turn'e ilk kez gidiyor → miss call[n>0] = (prompt − add) × HIT + add × MISS prompt += add // her call'dan sonra şişer // turn sonu: shrink yoksa şişmiş prompt olduğu // gibi taşınır; shrink varsa bu turn'ün eklentisi // shrinkTo'ya iner, entry korunur: carry = shrink ? entry + shrinkTo : prompt

// entry = history carried into this turn prompt = entry // first call (call[0]) has three cases: turn 1 or cold → prompt × MISS // cache empty/cold warm + no shrink → prompt × HIT // prefix kept intact warm + shrink → (entry − fresh) × HIT + fresh × MISS // fresh = min(shrinkTo, entry): the new summary // is sent for the first time this turn → miss call[n>0] = (prompt − add) × HIT + add × MISS prompt += add // bloats after each call // turn end: without shrink the bloated prompt // carries as-is; with shrink this turn's additions // collapse to shrinkTo, entry is kept: carry = shrink ? entry + shrinkTo : prompt

Turn'ler arası geçişBetween turns

Shrink yoksa bir sonraki turn, zincirin bıraktığı tam boyuttan devam eder ve cache durumu neyse ona göre ödenir.

Without shrink, the next turn resumes at the full size the chain ended at, billed according to the cache state.

Shrink varsa yalnızca o turn'ün tool sonuçları küçültülür; konuşma geçmişi taşınır. Yani turn sonu = giriş + küçültülmüş sonuçlar. History hâlâ birikir, sadece daha yavaş. Kırpma prefix'i değiştirdiği için bir sonraki giriş miss olarak fiyatlanır.

With shrink, only that turn's tool results get compacted; the conversation carries forward. So the turn ends at entry + compacted results. History still accumulates, just more slowly. Because trimming alters the prefix, the next entry is priced as a miss.

İlk turn her iki senaryoda da soğuk girer; henüz cache'lenecek bir şey yoktur.

The first turn enters cold in both scenarios; there's nothing cached yet.

Neden shrink ters tepebilirWhy shrink can backfire

Cache sıcakken biriken history zaten HIT fiyatından geçiyordur — yani neredeyse bedava. Onu kırpıp yerine yeni bir giriş koyduğunda o tokenları MISS fiyatından yeniden ödersin. İki fiyat arasındaki fark yüz kata varabildiği için bu kolayca zarara döner.

When the cache is warm, accumulated history is already billing at HIT — effectively free. Trim it and swap in a fresh entry, and you re-pay those tokens at MISS. With up to a hundredfold gap between the two rates, that flips into a loss quickly.

Modelin sınırlarıWhat the model ignores

Yapı değerleri ortalamadır — her turn aynı sayıda call ve aynı token artışı varsayılır. Output maliyeti opsiyoneldir ve açıldığında her iki senaryoya aynı sabiti ekler. Cache yazma ücreti, sağlayıcıya göre değişen TTL davranışı ve shrink'in kalite üzerindeki etkisi modelin dışındadır.

Structure inputs are averages — every turn assumes the same call count and the same token growth. Output cost is optional and, when enabled, adds the same constant to both scenarios. Cache write fees, provider-specific TTL behavior, and the quality impact of shrinking all sit outside the model.

Amaç kuruşu kuruşuna fatura tahmini değil — büyüklük mertebesini ve eğrinin şeklini görmek.

The goal isn't an exact invoice — it's seeing the order of magnitude and the shape of the curve.

Peki ne zaman shrink gerekir?

So when do you actually need to shrink?

Maliyet tek kriter değil. Aşağıdaki durumlarda shrink, fiyat tablosu ne derse desin gerekli olabilir.

Cost isn't the only criterion. In the cases below, shrinking can be necessary regardless of what the pricing says.

Cache soğuk giriyorsaWhen turns enter cold

Kullanıcı turn'leri arasında dakikalar geçiyorsa cache TTL'i dolar ve her turn biriken history'nin tamamını miss fiyatından öder. Shrink'in en net kazandığı senaryo budur — simülatörde “Soğuk”a bas, farkı gör.

If minutes pass between user turns, the cache TTL expires and every turn re-pays the entire accumulated history at the miss rate. This is where shrinking wins most clearly — flip the simulator to “Cold” and watch the gap.

Context limitine yaklaşıyorsanWhen you approach the context limit

Uzun zincirlerde prompt milyon token mertebesine çıkabilir. Maliyet kabul edilebilir olsa bile pencereye sığmıyorsa shrink bir tercih değil, zorunluluktur.

Long chains can push the prompt into the millions of tokens. Even when the cost is acceptable, if it no longer fits the window, shrinking stops being a choice.

Kalite bozuluyorsaWhen quality degrades

Şişmiş context'te modeller alakasız geçmiş tool çıktılarına takılabilir. Bu durumda shrink bir maliyet optimizasyonu değil, doğruluk müdahalesidir — ve bu araç onu ölçmez.

In a bloated context, models can latch onto stale, irrelevant tool output. There, shrinking is an accuracy intervention rather than a cost optimization — and this tool doesn't measure that.

Kırpmadan önce deneneceklerTry these before trimming

Cache'i sıcak tutmak çoğu zaman shrink'ten iyidir: stabil bir prefix kur (system prompt ve tool tanımları başta ve sabit), TTL uzatma seçeneği varsa kullan, turn'leri gruplayarak boşlukları azalt.

Keeping the cache warm usually beats shrinking: build a stable prefix (system prompt and tool definitions first, never reordered), use extended TTL if your provider offers it, and batch turns to shorten the gaps between them.

Kırpman gerekiyorsa prefix'i değil sonu kırp — baştaki değişiklik tüm cache'i geçersiz kılar.

If you must trim, cut the tail, not the prefix — a change at the front invalidates the entire cache.

Not: Bu bir tahmin aracıdır, fatura garantisi değil. Gerçek maliyetin sağlayıcının cache TTL'i, prefix eşleşme granülaritesi ve request paternine göre değişir. Kararı vermeden önce kendi kullanım loglarınla doğrula. Note: This is an estimation tool, not a billing guarantee. Real cost shifts with your provider's cache TTL, prefix-matching granularity, and request pattern. Validate against your own usage logs before acting on it.