Claude'da Bağlam Yönetimi: Compaction mı Memory mi

Uzun süre çalışan bir Claude ajanı, her tool çağrısıyla birlikte bağlam penceresini biraz daha doldurur ve bu artış genelde fark edilmeden olur: dosya okumaları, arama sonuçları ve ara düşünme adımları birikir, prompt cache prefix'i kırılır, aynı görev bir öncekinden fazla token'a mal olmaya başlar. Anthropic bu sorunu tek bir araçla değil, birbirini tamamlayan üç mekanizmayla çözüyor: sunucu-taraflı context editing, memory tool ve (artık farklı bir biçimde yaşayan) SDK compaction. LLM bağlam yönetimi başlığı altında compaction ile memory tool'un nerede ayrıştığını, hangi mekanizmanın ne zaman devreye girdiğini, varsayılan değerlerini ve aralarında nasıl seçim yapacağını bu yazıda netleştiriyoruz.

💡 Pro Tip: clear_tool_uses_20250919 stratejisini eklemeden önce exclude_tools listesine, sonucu hâlâ referans verdiğin tool'ları (ör. bir dosya okuma sonucu) koy — aksi halde Claude, kendi ürettiği ama artık göremediği bir sonuca atıfta bulunmaya devam edebilir.

İçindekiler

• Bağlam neden sessizce pahalılaşır
• Üç strateji: context editing, memory tool, compaction
• clear_tool_uses_20250919: ayarlar ve varsayılanlar
• clear_thinking_20251015 ve prompt cache etkisi
• Memory tool ile kalıcı bilgi taşımak
• Client-side compaction'ın kaderi: kaldırılma mı yeniden tasarım mı
• Sunucu-taraflı on-demand compaction
• Karar ağacı: hangi strateji ne zaman
• Pratik senaryo: dosya-düzenleme ajanı için konfigürasyon
• SSS
• Uzun ajan oturumlarında bağlam nasıl yönetilir?
• Server-side compaction mı tool-result clearing mi kullanmalıyım?
• clear_tool_uses eşiği kaç token ve kaç çağrı saklar?
• Memory tool bağlam temizliğiyle nasıl birlikte çalışır?
• Eski compaction_control parametresini kullanmaya devam edebilir miyim?
• Sonuç
• Kaynaklar

Bağlam neden sessizce pahalılaşır

Bir ajan oturumu tek bir mesaj alışverişi değil, art arda gelen tool çağrılarının biriktiği bir zincirdir. Her tool sonucu, her thinking bloğu ve her ara yanıt bağlam penceresine eklenir ve konuşma büyüdükçe bu birikim iki farklı maliyet üretir: ham token sayısı artar ve prompt cache prefix'i her yeni ekleme ile birlikte taşınmak zorunda kalır. Anthropic'in resmi dokümantasyonu, sunucu-taraflı bağlam yönetimini uzun süre çalışan konuşmalarda birincil strateji olarak tanımlıyor; bunun nedeni, sorunun istemci tarafında elle özetleme koduyla değil, API'nin kendisinin bileceği bir mekanizmayla çözülmesi gerektiğidir.

Burada kritik ayrım şu: "bağlamı küçültmek" tek bir işlem değil, en az üç farklı amaca hizmet eden üç farklı işlemdir. Bir tool sonucunu silmek, bir thinking bloğunu silmek ve tüm konuşmayı özetlemek, kayıp toleransı açısından birbirinden çok farklıdır — biri yeniden üretilebilir bir sonucu atarken, diğeri geri dönüşü olmayan bir özetleme yapar. Bu farkı görmeden "compaction kullanıyorum" demek, aslında hangi bilginin kalıcı olarak kaybolduğunu bilmemek anlamına gelir.

Bu üç mekanizmanın hepsi de kendi başına yeterli değil çünkü hepsi farklı bir maliyet ekseninde optimize ediyor. Tool result clearing token sayısını düşürür ama prompt cache'i kırar; thinking clearing bağlamı hafifletir ama model sınıfına göre farklı davranır; memory tool token maliyeti eklemez ama uygulamanın dosya sistemi erişimi gerektirir. Bir ajan mimarisi kurarken bu üç ekseni aynı anda dengelemek, tek bir "en iyi" ayar bulmaktan çok, görevin kendi kayıp toleransına göre bir kombinasyon seçmek anlamına gelir.

Üç strateji: context editing, memory tool, compaction

Anthropic'in context editing dokümanı, bağlam yönetimini üç ayrı yapı taşına ayırıyor: tool result clearing, thinking block clearing ve client-side SDK compaction. İlk ikisi context_management parametresi altında sunucu tarafında çalışır ve context-management-2025-06-27 beta header'ı ile etkinleştirilir; üçüncüsü ise SDK'nın tool runner katmanında yaşar. Bunlara ek olarak, konuşmanın tamamen ayrı bir katmanı olan memory tool (memory_20250818) var — bu araç context editing'in _tersini_ yapar: bağlamdan silinen bilgiyi, silinmeden önce kalıcı dosyalara taşır. Context editing kendi içinde iki stratejiye ayrıldığı için yazının devamında bu mekanizmaları dört ayrı kalem olarak sayacağız.

Üçünü birlikte düşünmenin doğru yolu, hangi bilginin "ucuza yeniden üretilebilir" olduğuna bakmaktır: bir dosya okuma sonucu tekrar istenebilir, bu yüzden tool result clearing için iyi bir adaydır; ama bir kullanıcının verdiği kısıtlama veya bir kararın gerekçesi yeniden üretilemez — bu tür bilginin memory tool ile kalıcı hâle getirilmesi gerekir.

clear_tool_uses_20250919: ayarlar ve varsayılanlar

clear_tool_uses_20250919 stratejisi, konuşma belirli bir input token eşiğine ulaştığında devreye girer ve en eski tool kullanım/sonuç çiftlerini placeholder içerikle değiştirir. Anthropic'in doküman tablosuna göre varsayılan trigger değeri 100.000 input token; bu eşik input_tokens ya da tool_uses cinsinden özelleştirilebilir. Varsayılan keep parametresi ise 3 tool use/result çifti — yani en yakın zamanda kullanılan 3 çift her zaman bağlamda kalır, geri kalanı temizlenir.

Dört parametre pratikte fark yaratıyor:

• trigger: stratejinin ne zaman aktif olacağını belirler (varsayılan 100K input token).
• keep: en son kaç tool çiftinin korunacağını belirler (varsayılan 3).
• clear_at_least: API en az bu kadar token'ı temizleyemiyorsa, strateji hiç uygulanmaz — yani "yarım temizlik" yapılmaz.
• exclude_tools: tool use/result'ları asla temizlenmeyecek tool adlarının listesi.

Varsayılan davranış yalnızca tool _sonuçlarını_ temizler; clear_tool_inputs parametresi false olduğu sürece Claude'un orijinal tool çağrıları (hangi parametrelerle hangi tool'u çağırdığı) görünür kalır. Bu, modelin "neden bu tool'u çağırdığını" hatırlamasını sağlarken, sonucun kendisini bağlamdan çıkarır.

1{
2  "context_management": {
3    "edits": [
4      {
5        "type": "clear_tool_uses_20250919",
6        "trigger": { "type": "input_tokens", "value": 100000 },
7        "keep": { "type": "tool_uses", "value": 3 },
8        "clear_at_least": { "type": "input_tokens", "value": 5000 },
9        "exclude_tools": ["memory"]
10      }
11    ]
12  }
13}

Buradaki clear_at_least alanı özellikle prompt caching kullanan ajanlarda önemli: temizleme işlemi, cache'lenmiş prefix'i geçersiz kılar, dolayısıyla "az miktarda temizleyip cache'i boşuna kırmak" yerine ya yeterince büyük bir blok temizlenir ya da hiç temizlenmez.

clear_thinking_20251015 ve prompt cache etkisi

Thinking bloklarının temizlenmesi ayrı bir stratejidir çünkü thinking bloklarının varsayılan davranışı model sınıfına göre değişir. Anthropic'in dokümanına göre Opus 4.5 ve sonrası ile Sonnet 4.6 ve sonrası modellerde önceki tüm thinking blokları korunur; Fable ve Mythos ailesinde tüm turlar korunur; daha eski model sınıflarında ise yalnızca son tur saklanır. Bu, "extended thinking kullanıyorsam bağlamım otomatik şişer mi" sorusunun cevabının model sürümüne bağlı olduğu anlamına geliyor.

İki strateji birlikte kullanıldığında sıralama önemli: Anthropic'in dokümanı, birden fazla strateji kullanıldığında clear_thinking_20251015'in edits dizisinde ilk sırada listelenmek zorunda olduğunu söylüyor; bunun nedenini belirtmiyor, dolayısıyla kuralı olduğu gibi uygulaman gerekiyor.

Prompt cache açısından kritik olan ayrım şu: Claude Fable 5.1 ve Claude Opus 5.5'te sunucu-taraflı bağlam yönetimi thinking bloklarını geçersiz kılmaz. Buna karşılık istemci tarafında önceki turlara yapılan elle düzenlemeler, sonraki her asistan turundaki thinking bloklarını geçersiz kılabilir. Başka bir deyişle, clear_thinking_20251015 cache-dostu tasarlanmışken, kendi elinle geçmiş mesajları düzenlemek cache'i kırma riski taşır.

1response = client.beta.messages.create(
2    model="claude-fable-5-1",
3    max_tokens=4096,
4    betas=["context-management-2025-06-27"],
5    context_management={
6        "edits": [
7            {"type": "clear_thinking_20251015"},
8            {
9                "type": "clear_tool_uses_20250919",
10                "trigger": {"type": "input_tokens", "value": 100000},
11            },
12        ]
13    },
14    messages=conversation_history,
15    tools=tool_definitions,
16)

Memory tool ile kalıcı bilgi taşımak

Memory tool (memory_20250818), context editing'in tam tersi yönde çalışır: silinmeden önce önemli bilgiyi kalıcı hâle getirir. Anthropic'in memory tool dokümanına göre araç tamamen istemci taraflı çalışır — Claude dosya operasyonu istekleri üretir (oku, yaz, listele), bu istekleri gerçekten yürüten senin uygulamandır; Anthropic sunucu tarafında hiçbir dosya saklamaz. Araç tipi tüm Claude 4 ve sonrası modellerde kullanılabilir.

Context editing ile memory tool birlikte kullanıldığında ortaya çıkan asıl fayda burada: konuşma, tool result clearing'in tetikleneceği eşiğe yaklaştığında Claude otomatik bir uyarı alır ve önemli bilgiyi silinmeden önce memory dosyalarına yazma fırsatı bulur. Yani iki mekanizma rakip değil, art arda çalışan bir çift — biri bağlamı hafifletirken diğeri kaybolacak bilgiyi önceden kurtarır.

1{
2  "tools": [{ "type": "memory_20250818", "name": "memory" }],
3  "context_management": {
4    "edits": [
5      {
6        "type": "clear_tool_uses_20250919",
7        "trigger": { "type": "input_tokens", "value": 100000 }
8      }
9    ]
10  }
11}

Pratikte bu, bir kod inceleme ajanının "bu dosyadaki üç kritik bulguyu" /memories/findings.md içine yazıp, ardından o dosyaları okuduğu tool sonuçlarının bağlamdan temizlenmesine izin vermesi anlamına gelir — bulgular kaybolmaz, yalnızca ham dosya içerikleri kaybolur.

Memory tool'un istemci taraflı olması, bunu context editing'den ayıran en önemli mimari fark. Context editing tamamen Anthropic'in sunucusunda çalışır ve senin uygulamandan hiçbir ek kod istemez; memory tool ise dosya operasyonlarını gerçekten yürütecek bir katman ister — bu genelde yerel bir dosya sistemi, bir nesne deposu ya da bir veritabanı olabilir. Bu da memory tool'u context editing'e göre daha fazla mühendislik kararı gerektiren, ama karşılığında konuşma oturumları arasında bile hayatta kalabilen bir mekanizma yapıyor.

Client-side compaction'ın kaderi: kaldırılma mı yeniden tasarım mı

Burada iki ayrı gerçeği birbirine karıştırmamak gerekiyor. Anthropic'in context editing dokümanı, eski compaction_control parametresinin TypeScript ve Ruby SDK'larında deprecated olduğunu ve gelecekte kaldırılacağını, bu SDK'ların etkinleştirildiğinde bir deprecation uyarısı verdiğini belirtiyor. Python SDK'da ise durum daha kesin: compaction_control argümanı ve CompactionControl tipi, 20 Ağustos 2026'da yayınlanan v1.0.0 sürümünde tamamen kaldırıldı — Python SDK'nın migration rehberine göre bu değişikliğin gerekçesi, konuşmayı ekstra bir istemci round-trip'i ile özetlemek yerine, özetlemeyi doğrudan API içinde yapan sunucu-taraflı compaction'a geçiş.

Ama bu, "compaction SDK'lardan tamamen çıktı" anlamına gelmiyor. Python SDK'nın changelog'u, 15-22 Eylül 2026 tarihleri arasında (yani bu yazının yayınından yalnızca birkaç hafta önce) yeni bir compaction mekanizmasının SDK'ya geldiğini gösteriyor: v1.6.0 API tarafında sinyalli (signed) compaction bloklarını ve beta compaction parametresini ekledi; tool runner metodu ise v1.7.0'da geldi — bu sürüm compact_before_next_turn() metodunu ekleyip durum ve hata yönetimini düzenledi; v1.8.0 ise compaction isteğinin gövdesini düzeltti. TypeScript SDK tarafında da paralel bir gelişme var: v0.127.0 (18 Eylül 2026), tool runner'a aynı işlevi gören compactBeforeNextTurn() metodunu ekledi.

Sonuç olarak doğru çerçeve şu: eski, tamamen istemci tarafında özetleme yapan compaction_control mekanizması TS/Ruby'de kullanımdan kaldırılıyor ve Python'da zaten kaldırıldı — ama onun yerine, tool runner'ın sunucu-taraflı compaction'ı tetikleyen yeni, daha ince bir yardımcı metodu geldi. "Compaction bitti" demek yanlış; "eski compaction mekanizması sunucu-taraflı olana devrediyor" demek daha doğru bir tarif. Dokümanın gösterdiği resmi göç yolu da bu: tool runner ile sunucu-taraflı compaction kullanmak için isteğin context_management parametresine compact_20260112 edit'ini geçiyorsun (Python SDK'nın migration rehberindeki "After" örneği de betas=["compact-2026-01-12"] ile bu edit'i birlikte gösteriyor) — ve tool runner dokümanının uyardığı gibi, bir runner üzerinde ya compact_before_next_turn() helper'ını ya da context_management compaction edit'ini kullan, ikisini birden değil. Sunucu-taraflı compaction'ın iki biçimi var: eşik-tabanlı compaction (compact_20260112, context_management içinde) ve istek-üzerine compaction (compact-2026-09-04, top-level compaction parametresi); doküman ikisinin aynı istekte birleştirilemeyeceğini söylüyor.

Sunucu-taraflı on-demand compaction

Bu yeniden tasarımın altında yatan asıl API özelliği, Messages API'ye 14 Eylül 2026'da eklenen on-demand compaction. Anthropic'in API release notes'una göre bu özellik beta compact-2026-09-04 header'ı ile etkin: bir konuşmayı istek üzerine sıkıştırıyor ve imzalı bir compaction bloğu döndürüyor; bu blok sonraki isteklerde sıkıştırılan mesajların yerini alıyor. Compaction, bir konuşmanın eski turlarını Claude'un sunucuda yazdığı bir özetle değiştirir — yani özetleme mantığı client tarafında yazılan bir algoritma değil, modelin kendisinin ürettiği bir özet.

Bu, tool runner'daki compact_before_next_turn() / compactBeforeNextTurn() metotlarının neden var olduğunu açıklıyor: bu metotlar, mevcut tur bittiğinde bir sonraki compaction isteğini zamanlıyor — yani SDK artık kendi özetini yazmıyor, sunucudaki on-demand compaction'ı tetiklemek için ince bir köprü görevi görüyor.

Bu ayrım, eski mimariyle karşılaştırıldığında neyin değiştiğini netleştiriyor. Eski compaction_control yaklaşımında özetleme mantığı istemci tarafındaydı: SDK, konuşmayı özetlemek için ayrı bir API çağrısı yapar, sonucu kendi tarafında biçimlendirir ve bir sonraki isteğe eklerdi — bu da ekstra bir round-trip ve istemci tarafında bakımı gereken bir özetleme kodu anlamına geliyordu. On-demand compaction'da bu sorumluluk tamamen sunucuya taşınıyor: istek compact-2026-09-04 beta header'ı ile işaretlendiğinde, özetleme API çağrısının kendi içinde gerçekleşiyor ve dönen imzalı compaction bloğu, sonraki isteklerde doğrudan kullanılabiliyor. Tool runner'daki yeni metotlar da compaction isteğini ve geçmiş takasını senin yerine yapan, ama ne zaman sıkıştırılacağına yine senin karar verdiğin birer kolaylık katmanı.

Karar ağacı: hangi strateji ne zaman

Üç mekanizma birbirini dışlamaz; sorulması gereken soru "hangi bilginin kaybına tahammül edebilirim" sorusudur.

• Tool sonucu tekrar üretilebilir mi (dosya okuma, arama sonucu, API çağrısı)? → clear_tool_uses_20250919 ile temizle, gerekiyorsa exclude_tools ile istisna tanımla.
• Thinking süreci sadece o an için mi gerekliydi, yoksa sonraki kararları mı etkiliyor? → clear_thinking_20251015'i ilk sırada kullan; model sınıfına göre varsayılan keep davranışını kontrol et.
• Bilgi yeniden üretilemez ve konuşma reset'inden sağ çıkması gerekiyor mu (kullanıcı kararı, proje kısıtlaması, önceki hata analizi)? → memory tool ile /memories dizinine yaz.
• Konuşmanın tamamı çok uzadı ve tek tek tool sonuçlarını temizlemek yetmiyor mu? → on-demand compaction'ı compact-2026-09-04 beta header'ıyla tetikle; SDK'daysan compact_before_next_turn() / compactBeforeNextTurn() kullan, eski compaction_control'e güvenme.
• Prompt cache hit oranı kritik mi? → tool result clearing cache prefix'ini kırar; clear_at_least ile küçük, sık temizlemeler yerine daha büyük ve nadir temizlemeler tercih et.

Bu beş soruyu sırayla cevaplamak, "hangi ayarı açayım" sorusunu "hangi bilgiyi kaybetmeye razıyım" sorusuna çeviriyor — ki asıl karar da budur.

Bu sıralamanın pratikte önemli olan bir sonucu daha var: dört stratejiyi aynı anda açmak, hepsini tek tek düşünmeden açmakla aynı şey değil. clear_tool_uses_20250919 ve clear_thinking_20251015'i birlikte kullanıyorsan edits dizisindeki sıralama zorunlu; memory tool'u context editing ile birlikte kullanıyorsan exclude_tools listesini gözden geçirmen gerekiyor; on-demand compaction'ı devreye alıyorsan tool runner'ın hangi sürümde olduğunu (Python'da v1.7.0+, TypeScript'te v0.127.0+) kontrol etmen gerekiyor. Yani karar ağacı yalnızca "hangi stratejiyi açayım" sorusuna değil, "bu stratejileri hangi sırayla ve hangi versiyon gereksinimleriyle açmalıyım" sorusuna da cevap veriyor.

Pratik senaryo: dosya-düzenleme ajanı için konfigürasyon

Bir dosya-düzenleme ajanı düşün: dosya okuma sonuçları büyük ve tekrar üretilebilir, ama kullanıcının "bu dosyaya dokunma" gibi kısıtlamaları kalıcı olmalı. Aşağıdaki konfigürasyon, önceki bölümlerdeki üç stratejiyi tek bir isteğe topluyor:

1const response = await client.beta.messages.create({
2  model: "claude-opus-5",
3  max_tokens: 4096,
4  betas: ["context-management-2025-06-27"],
5  tools: [
6    { type: "memory_20250818", name: "memory" },
7    { type: "text_editor_20250728", name: "str_replace_based_edit_tool" },
8  ],
9  context_management: {
10    edits: [
11      { type: "clear_thinking_20251015" },
12      {
13        type: "clear_tool_uses_20250919",
14        trigger: { type: "input_tokens", value: 100000 },
15        keep: { type: "tool_uses", value: 3 },
16        clear_at_least: { type: "input_tokens", value: 5000 },
17        exclude_tools: ["memory"],
18      },
19    ],
20  },
21  messages: conversationHistory,
22});

exclude_tools: ["memory"] satırı burada kilit nokta: memory tool'un kendi okuma/yazma sonuçları, tool result clearing tarafından silinmiyor — çünkü memory zaten kalıcılık katmanı, onu da temizlemek amaçla çelişir.

clear_thinking_20251015'in dizinin başında durması ise bir tercih değil, zorunluluk: doküman birden fazla strateji kullanıldığında bu stratejinin edits dizisinde ilk sırada listelenmesini şart koşuyor, nedenini ise belirtmiyor. Yani bu satırın yerini değiştirmeden bırak; str_replace_based_edit_tool gibi bir düzenleme aracıyla çalışırken de sıralama aynı kalır.

SSS

Uzun ajan oturumlarında bağlam nasıl yönetilir?

Anthropic üç tamamlayıcı mekanizma sunuyor: sunucu-taraflı context editing (eski tool sonuçlarını ve thinking bloklarını otomatik temizler), memory tool (bilgiyi /memories dizininde kalıcı dosya olarak saklar, konuşma sıfırlansa da hayatta kalır) ve on-demand compaction (konuşmanın eski turlarını sunucuda yazılan bir özetle değiştirir). Üçü birlikte kullanılabilir; hangi bilginin yeniden üretilebilir, hangisinin kalıcı olması gerektiğine göre seçim yapılır.

Server-side compaction mı tool-result clearing mi kullanmalıyım?

Bu iki ayrı katman, tek bir seçim değil. Tool result clearing (clear_tool_uses_20250919) eski tool sonuçlarını placeholder ile değiştirirken konuşma akışını ve tool çağrılarını korur; on-demand compaction ise eski turları sunucuda yazılan bir özetle değiştirir — istersen son turları birebir koruyabilirsin — dolayısıyla daha agresif ve daha az token kullanır ama ayrıntı kaybı riski daha yüksektir. Anthropic'in dokümanı, sunucu-taraflı stratejileri uzun konuşmalarda genel olarak tercih edilen yaklaşım olarak konumlandırıyor.

clear_tool_uses eşiği kaç token ve kaç çağrı saklar?

Varsayılan tetikleme eşiği 100.000 input token'dır (trigger, input_tokens ya da tool_uses cinsinden özelleştirilebilir); varsayılan olarak en son 3 tool use/result çifti korunur (keep). clear_at_least parametresi minimum temizlenecek token miktarını garanti eder — bu miktar karşılanamazsa strateji hiç uygulanmaz. exclude_tools ile belirli tool'lar temizlik dışında tutulabilir.

Memory tool bağlam temizliğiyle nasıl birlikte çalışır?

İkisi birlikte kullanıldığında, konuşma tool result clearing'in tetikleneceği eşiğe yaklaşırken Claude otomatik bir uyarı alır ve önemli bilgiyi silinmeden önce memory dosyalarına yazma fırsatı bulur. Böylece ham tool sonuçları bağlamdan temizlense bile, onlardan çıkarılan kritik bilgi memory tool üzerinden erişilebilir kalır — iki mekanizma birbirini tamamlayan bir çift olarak tasarlanmıştır.

Eski compaction_control parametresini kullanmaya devam edebilir miyim?

Python SDK'da hayır: v1.0.0 (20 Ağustos 2026) ile compaction_control argümanı ve CompactionControl tipi tamamen kaldırıldı. TypeScript ve Ruby SDK'larında parametre hâlâ çalışıyor ama deprecated olarak işaretli ve gelecekte kaldırılacak; SDK etkinleştirildiğinde bir deprecation uyarısı basıyor. Her iki durumda da yeni projelerde tool runner'ın compact_before_next_turn() / compactBeforeNextTurn() metotlarına geçmek, sunucu-taraflı on-demand compaction ile uyumlu kalmanın yolu.

Sonuç

Bağlam yönetimi artık tek bir "sıkıştır" düğmesi değil, dört ayrı aracın (tool result clearing, thinking clearing, memory tool, on-demand compaction) birlikte kullanıldığı bir katman kümesi. Claude Prompt Caching yazımızda ele aldığımız cache mantığı, burada clear_at_least parametresinin neden var olduğunu açıklıyor; büyük codebase'leri tek seferde analiz eden senaryolar için Claude 1M Context Window yazısına bakabilirsin — orası tek seferlik büyük okuma senaryosunu, bu yazı ise uzun-koşan ajan oturumlarının maliyet/kalite eksenini ele alıyor. Extended thinking'in bağlamla ilişkisi için Claude Extended Thinking yazımıza, memory kavramının genel çerçevesi için Claude Projects ve Memory yazımıza göz atabilirsin. Model sürümü güncellemelerini takip etmek istiyorsan Claude Fable 5.1: Yenilikler ve Kırılan Değişiklikler yazımız güncel kalmana yardımcı olur.

Pratikte en verimli yaklaşım, dört mekanizmayı birbirinin rakibi değil, farklı kayıp toleranslarına sahip katmanlar olarak görmek: yeniden üretilebilir olanı ucuza temizle, kalıcı olması gerekeni memory'e yaz, geri kalanı sunucuya özetlet.

Kaynaklar

• Context editing — Claude Docs — clear_tool_uses_20250919, clear_thinking_20251015 parametreleri ve varsayılanları için birincil kaynak.
• Compaction — Claude Docs — sunucu-taraflı özetleme mekanizmasının resmi tanımı.
• Memory tool — Claude Docs — memory_20250818 aracının istemci-taraflı çalışma modeli.
• API release notes — Claude Docs — 14 Eylül 2026 tarihli on-demand compaction duyurusu.
• anthropic-sdk-python MIGRATION.md — GitHub — Python SDK v1.0'da compaction_control'ün kaldırılma gerekçesi.
• anthropic-sdk-typescript CHANGELOG.md — GitHub — compactBeforeNextTurn() eklenişinin sürüm kaydı.