Claude Fable 5.1 Korunan Düşünce: Blok Farklı Bir Sohbete Bağlıdır Hatası Düzeltmesi

Claude Fable 5.1: “Farklı bir konuşmaya bağlı” 400 Hatasını Giderme

Ajan altyapınızı Claude Fable 5.1'e taşıdıktan sonra thinking bloğunun “farklı bir konuşmaya bağlı” olduğunu belirten bir 400 hatası görüyorsanız, kodunuz istekler arasındaki konuşma geçmişini değiştiriyor demektir. Fable 5.1 bu durumu zorunlu olarak denetleyen ilk Claude modelidir. Bu kılavuzda denetimin nasıl çalıştığını, kimleri etkilediğini, hatayı neyin tetiklediğini, acil çözümü ve istem önbelleğini sıcak tutan yalnızca eklemeli tasarımı ele alacağız.

Apidog'u bugün deneyin

Bu denetim, korunmuş düşünce ve Claude Fable 5.1'deki Yenilikler belgelerinde açıklanmıştır. Fable 5.1'deki üç bozucu değişiklikten üçüncüsüdür ve bir ajan altyapısını sessizce bozabilecek tek değişikliktir. Diğer iki değişiklik için geçiş kılavuzuna bakabilirsiniz.

Hata

messages.5.content.0: Invalid `signature` in `thinking` block. The block is bound to a different conversation. Remove the block, or set `thinking.block_binding.prefix_mismatch_behavior` to "drop_block". That setting requires the `thinking-binding-controls-2026-08-01` value in the `anthropic-beta` header.

Bu hata, model herhangi bir çıktı üretmeden önce verilen bir 400 invalid_request_error yanıtıdır. Aynı istek gövdesini yeniden göndermek yine başarısız olur.

messages.5.content.0 yolu, artık eşleşmeyen ilk düşünme bloğunu gösterir. Yanıt, değişen ilk mesajı belirten ek bir cümle de içerebilir. Bu, sorunun kaynağını bulmak için beklenen tanıdır. Token sayma uç noktası da aynı denetimi çalıştırır.

Şu hata benzer görünür ancak farklıdır:

Invalid `signature` in `thinking` block

“Farklı bir konuşmaya bağlı” ifadesi yoksa imzanın bozulmuş veya çözülemiyor olması söz konusudur. Bu durumda prefix_mismatch_behavior uygulanmaz.

Denetim neyi doğrular?

Her Fable 5.1 düşünme bloğu, iki bilgiyi içeren bir imzaya sahiptir:

1. Bloğu hangi modelin ürettiği
2. Bloğun önündeki tam konuşma öneki

Bu önek şunları kapsar:

• Üst düzey system istemi
• tools dizisi
• İlgili bloktan önceki tüm mesajlar

Düşünme blokları ayrıca birbirine zincirlenir. Transkripti yeniden gönderdiğinizde API, önekin bloğu üreten sürümle bayt düzeyinde aynı olup olmadığını doğrular.

Anthropic bu davranış için iki gerekçe sunuyor:

• Anti-damıtma: Lansman gönderisine göre yeni API hesapları, önceki düşünme transkriptini korurken çok turlu konuşmadaki Claude bağlamını manuel olarak değiştiremiyor. Böylece belgelenmiş bir damıtma tekniği devre dışı kalıyor.
• Önbellek tutarlılığı: Bu denetimi bozan değişiklikler aynı zamanda istem önbelleğini de yeniden başlatıyor. Denetimden geçen kod, her turda milyon token başına 0,25 ABD doları olan önbellek okumalarından yararlanabiliyor.

Kimler etkileniyor?

Varsayılan olarak zorunlu

31 Ağustos 2026 veya sonrasında oluşturulan hesaplarda denetim varsayılan olarak zorunludur. Buna şunlar dahildir:

• Claude API organizasyonları
• Amazon Bedrock hesapları
• Google Cloud projeleri
• Microsoft Foundry kaynakları

Kaydedilen ancak henüz zorunlu olmayan hesaplar

Daha eski hesaplarda API uyumsuzluğu kaydeder; ancak istek içinde thinking.block_binding.prefix_mismatch_behavior açıkça ayarlanmadıkça isteği reddetmez. Bu alan "error" dahil herhangi bir değere ayarlandığında denetim etkinleşir.

Anthropic, gelecekteki modellerde bu davranışı herkes için zorunlu hale getireceğini belirtiyor.

Etkilenmeyen yüzeyler

Aşağıdaki ürünler konuşma önekini sizin yerinize korur:

• Claude Code
• claude.ai
• Claude Yönetilen Aracılar
• Claude Aracı SDK'sı

Claude Mythos 5.1 bu denetimi hiç çalıştırmaz. Ancak geçmişi değiştirmek yine de istem önbelleğini yeniden başlatır.

Etkilenen uygulamalar

messages dizisini kendi oluşturan tüm kodlar etkilenir. Örneğin:

• Özel ajan döngüleri
• Sohbet arka uçları
• Messages API sarmalayan çerçeveler
• İstemci tarafı geçmiş ve sıkıştırma katmanları

Araç yazarları için önemli bir tuzak vardır: Ürününüzü kullanıcılar kendi API anahtarlarıyla çalıştırıyorsa, sizin hesabınız eski olabilir ancak onların hesabı yeni ve zorunlu denetime tabi olabilir. Bu nedenle testleri zorunlu alan etkinmiş gibi çalıştırın.

Hesabınızın denetimi zorunlu kılıp kılmadığını kontrol etmek için beta başlığı olmadan geçmişi değiştiren bir istek gönderin. Yanıt, thinking-binding-controls-2026-08-01 başlığını gerektiren bir 400 hatasıysa hesap denetime tabidir.

Hangi değişiklikler sonraki düşünme bloklarını geçersiz kılar?

Aşağıdaki değişikliklerden biri, değişiklikten sonra gelen düşünme bloklarının önek bağını bozar:

• Önceki bir turu düzenlemek, yeniden sıralamak veya kaldırmak
  • Eski araç sonuçlarını silmek
  • Transkriptin ortasındaki turları kesmek
  • Son turları özetin arkasında kelimesi kelimesine tutan istemci tarafı sıkıştırma
• Kalıcı olmayan içerik eklemek
  • Araç sonuçlarından sonra eklenen, sonraki istekte silinen tur-bazlı hatırlatmalar
  • Durum satırları
  • Her turda değişen kalan token sayısı
• İstekler arasında system veya tools öğesini yeniden oluşturmak
  • Sistem istemindeki geçerli tarihi güncellemek
  • Oturum ortasında araç eklemek veya kaldırmak
• Sonraki isteklerde farklı baytlar üreten bir görüntü veya belge URL'si kullanmak
  • Bağlanan şey URL metni değil dosyanın baytlarıdır.
  • Aynı dosya için değişen imzalı URL'ler sorun oluşturmaz.
• Bir düşünme bloğunu çalışmanın başlangıcı dışında bir yerden kaldırmak
  • En eski düşünme blokları sırayla kaldırılabilir.
  • Ortadaki tek bir blok kaldırılamaz.

Hangi değişiklikler güvenlidir?

Şunlar düşünme bloklarını geçersiz kılmaz:

• Yalnızca eklemeli geçmiş kullanmak
• Yeni role: "system" mesajları eklemek
• Temizlenmiş tur-bazlı mesajları yerinde bırakmak
• Düşünme bloklarını en eskiden başlayarak kaldırmak
• system, tools ve messages dışındaki parametreleri değiştirmek:
  • max_tokens
  • output_config, effort dahil
  • tool_choice
  • metadata
• cache_control işaretçilerini eklemek, taşımak veya kaldırmak
• Sunucu tarafı sıkıştırma ve bağlam düzenlemesi kullanmak

Sunucu tarafı sıkıştırma, gönderdiğiniz konuşmayı karşılaştıran denetimden sonra gerçekleştiği için düzenleme sayılmaz. Sıkıştırma sonrasında denetlenen önek, sıkıştırma bloğundan başlar.

Acil çözüm: drop_block

Hatanın üretimi durdurmasını önlemek için beta başlığını gönderin ve davranışı açıkça ayarlayın:

response = client.beta.messages.create(
    model="claude-fable-5-1",
    max_tokens=16000,
    thinking={"type": "adaptive", "block_binding": {"prefix_mismatch_behavior": "drop_block"}},
    betas=["thinking-binding-controls-2026-08-01"],
    messages=history,
)
for t in response.input_transformations or []:
    print(t.type, t.path, t.reason)

drop_block, ilk eşleşmeyen bloğu ve ondan sonraki tüm düşünme bloklarını kaldırır. İstek kalan içerikle devam eder ve her kaldırmayı üst düzey input_transformations dizisinde raporlar:

{
  "input_transformations": [
    {
      "type": "thinking_dropped",
      "path": "messages.1.content.0",
      "reason": "prefix_binding_mismatch"
    }
  ]
}

drop_block kullanırken dikkat edilmesi gerekenler

1. Yalnızca mevcut isteğe uygulanır. Sonraki isteklerde de beta başlığını göndermeye devam edin.
2. Varsayılanlara güvenmeyin.
   • Zorunlu bir hesapta başlık olmadan istek hata verir.
   • Yalnızca başlığı göndermek beta özelliğinin varsayılanı olan drop_block davranışına geçebilir.
   • Davranışı her zaman açıkça ayarlayın.
3. Başlık olmadan block_binding kullanılamaz. Aksi durumda şu hatayı alırsınız:

   block_binding: Additional properties are not allowed

reason alanı iki durumu ayırır:

• prefix_binding_mismatch: Konuşma geçmişi değişmiştir.
• model_binding_mismatch: Konuşma farklı modeller arasında geçiş yapmıştır. Örneğin bir yönlendirici, yeniden deneme veya geri dönüş mekanizması Fable 5.1 dışındaki bir modele geçmiştir. Bu, uygulama kodunuzda hata olduğu anlamına gelmez.

Beta başlığıyla dönen her yanıt input_transformations dizisini içerir. Hiçbir blok kaldırılmadığında dizi boştur.

Sıkıştırma sınırında bir kez blok kaldırmak genellikle kabul edilebilir bir maliyettir. Ancak her istekte geçmişi geçersiz kılan bir altyapı:

• Modelin önceki muhakemesini her turda kaybettirir
• İstem önbelleğini her turda yeniden başlatır
• Görev maliyetini artırır

Bu nedenle drop_block kalıcı çözüm değil, teşhis mekanizması ve güvenlik ağı olarak kullanılmalıdır.

Beta desteği olmayan platformlarda kurtarma

Kontrolün bulunmadığı bir platformda:

1. Geçmişteki tüm thinking ve redacted_thinking bloklarını çıkarın.
2. Her turun text ve tool_use bloklarını koruyun.
3. İsteği yalnızca bir kez yeniden deneyin.

Model, çıkarılan blokların taşıdığı muhakeme olmadan o tura yanıt verir. Bu yöntem tek seferlik kurtarmadır; kalıcı bir tasarım olarak kullanılmamalıdır.

Lansman sırasında Microsoft Foundry bu kontrolleri sunmuyordu. Bedrock ve Google Cloud ise kontrolleri model başına ekliyordu.

Üç adımlı denetim

Trafiği değiştirmeden önce aşağıdaki testi çalıştırın.

1. Tam istek gövdelerini yakalayın

Ürününüzdeki ajan altyapısının birkaç normal tur boyunca gönderdiği tam istek gövdelerini kaydedin. Sıkıştırma veya araç değişikliği gibi senaryoları da dahil edin.

Ardışık her istek çifti için şunları karşılaştırın:

• system istemi
• tools dizisi
• messages dizisinin ortak öneki

Yeni eklenen turlara kadar bu alanlar bayt düzeyinde aynı olmalıdır.

2. Normal çok turlu oturum çalıştırın

claude-fable-5-1 için beta başlığını ve prefix_mismatch_behavior: "drop_block" ayarını kullanın. Her yanıtta input_transformations değerini günlüğe kaydedin.

• Boş dizi: Geçmiş sağlamdır.
• prefix_binding_mismatch: İlgili path değerindeki bloktan önceki bir şey değişmiştir.

Bu test herhangi bir hesaptan çalışır; çünkü alanı ayarlamak denetimi isteğe dahil eder. CI ortamında düzenlemelerin testi başarısız kılması için "error" kullanın.

3. Üretim davranışını açıkça seçin

• Uyumsuzluk her zaman hata anlamına geliyorsa "error" kullanın.
• İstek başarısız olmak yerine düşünme bloklarını atlayarak devam etsin istiyorsanız "drop_block" kullanın.

Her iki durumda da şunları izleyin:

• 400 hataları
• input_transformations kayıtları

Eski bir hesapta alanı ayarlamadan bırakmayın. Aksi halde denetim yalnızca sunucu tarafında kaydedilir ve uygulamanızın izleyeceği bir sinyal oluşmaz.

Apidog içinde ikinci adım iki istekli bir testtir:

1. İlk turu gönderin.
2. Sistem istemini değiştirin.
3. Beta başlığıyla sonraki turu gönderin.
4. input_transformations içindeki thinking_dropped kaydını doğrulayın.

Bu testi koleksiyonunuza ekleyin ve her ajan altyapısı değişikliğinde yeniden çalıştırın. Apidog'u indirin.

Ajan altyapısını yalnızca eklemeli hale getirme

Aşağıdaki tablo, her geçmiş düzenlemesini öneki koruyan ve önbelleği sıcak tutan bir yaklaşımla değiştirir.

Yapmakta olduğunuz şey	Bunun yerine bunu yapın
Oturum ortasında sistem istemini değiştirmek; örneğin tarihi veya modu güncellemek	Oturum başlangıcındaki system öğesini dondurun. Değişikliğin gerçekleştiği noktaya {"role": "system", "content": "Mevcut tarih 2026-09-14."} ekleyin. Bu konuşma ortası sistem mesajı, beta başlığı olmadan da sistem istemi yetkisine sahiptir ve sonraki blokların bağlı olduğu önekin parçası olur.
Oturum ortasında tools dizisini değiştirmek	Tüm araç setini oturum başlangıcında bildirin. Başlangıçta gizli olması gereken araçlar için defer_loading: true kullanın. Daha sonra role: "system" mesajında tool_addition ve tool_removal blokları gönderin; bunun için mid-conversation-tool-changes-2026-07-01 beta'sını kullanın.
Her tura özel bir hatırlatmayı ekleyip sonraki istekte silmek	Araç sonuç mesajından sonra, önceki kopyaları yerinde bırakarak şu biçimde tur-bazlı sistem mesajı gönderin: {"role": "system", "clear_at": "next_user_message", "content": "..."}. Bunun için mid-conversation-system-clear-at-2026-08-21 beta'sını kullanın. Temizlenen kopyalar sonraki istekte görünmez ve maliyet oluşturmaz. Beta olmadan hatırlatmayı aynı kullanıcı mesajındaki tool_result bloklarından sonra bir metin bloğu olarak ekleyin; önceki kopyaları silmeyin.
Eski araç sonuçlarını istemci tarafında silmek	Araç sonuçlarını temizleme özelliğiyle sunucu tarafı bağlam düzenlemesini kullanın.
İstemcide sıkıştırma yapmak	Sunucu tarafı sıkıştırmayı tercih edin. compact-2026-01-12 beta'sı, kendi özetleme isteminizi alabilen instructions parametresini destekler. İstemci tarafında kalmanız gerekiyorsa tüm geçmişi tek bir özet mesajı ve yeni kullanıcı turuyla değiştirin; başka bir şeyi yeniden oynatmayın.
Turlar arasında URL ile görüntü veya belge göndermek	Dosyayı Files API'ye bir kez yükleyip file_id gönderin veya base64 kullanın.

İstemci tarafı sıkıştırma neden sorunludur?

İki yaygın istemci tarafı sıkıştırma yaklaşımı bu kontrol altında bozulur:

• Kuyrukta tutma sıkıştırması: Eski turları özetleyip son turu kelimesi kelimesine korumak, düşünceler tam geçmişe göre üretildiği için başarısız olur.
• Arka plan sıkıştırması: Kritik yoldan bir özet üretip daha sonra geçmişi değiştirmek, özetin başlangıcı ile değiştirme arasındaki her turda başarısız olabilir.

Transkriptin ortasından tek tek turları kesmek, sonraki tüm düşünme bloklarını geçersiz kılar. İstemci tarafında hiçbir veri şekli bunu önleyemez.

Talimat değişiklikleri için konuşma ortası sistem mesajlarını, seçici silme için sunucu tarafı bağlam düzenlemesini kullanın.

Önbellek okumaları artık milyon token başına 0,25 ABD doları olduğundan, Fable 5.1'de tasarruf amacıyla erken sıkıştırma yapmak her zaman doğru uzlaşma olmayabilir. Anthropic daha geç sıkıştırma noktalarını denemenizi öneriyor.

Bu neden aynı zamanda önbellek konusudur?

Yukarıdaki tabloda yer alan her değişiklik, aynı zamanda istem önbelleğini yeniden başlatan değişikliklerdir.

Fable 5.1, önbellek isabetlerini Fable 5'e göre dört kat daha ucuz hale getirdi. Bu da önbellek kaçırmalarını orantılı olarak daha maliyetli yapıyor. Yalnızca eklemeli bir ajan altyapısı iki avantaj sağlar:

• Önceki muhakeme korunur.
• Önek her turda 12,50 ABD dolarına yeniden yazılmak yerine 0,25 ABD dolarına okunur.

Daha fazla bilgi için:

• Fable 5.1 fiyatlandırma dökümü
• API rehberi
• İstem rehberi
• Claude Code rehberi

API rehberi, bağlam içi tur-bazlı ve mesaj başına çaba istek biçimlerini gösterir. İstem rehberi, hangi tur-bazlı talimatların bu yöntemle gönderilmeye değer olduğunu açıklar. Claude Code rehberi ise Claude Code kullanıcılarının bu hatayı neden görmediğini anlatır.

Sıkça Sorulan Sorular

“Blok farklı bir konuşmaya bağlı” ne anlama geliyor?

Bir Claude Fable 5.1 düşünme bloğu, kendisinden önceki bir şey değiştikten sonra yeniden oynatılmıştır. Değişen öğe sistem istemi, araç dizisi veya önceki bir mesaj olabilir. API, zorunlu hesaplarda isteği 400 hatasıyla reddeder.

Hangi hesaplarda geçmiş kontrolü zorunludur?

Her platformda 31 Ağustos 2026 veya sonrasında oluşturulan hesaplarda kontrol zorunludur. Daha eski hesaplarda bir istek thinking.block_binding.prefix_mismatch_behavior alanını ayarladığında etkinleşir. Anthropic gelecekteki modellerde bunu herkes için zorunlu hale getirmeyi planlıyor.

Hatayı hızlıca nasıl gideririm?

thinking-binding-controls-2026-08-01 beta başlığını ve prefix_mismatch_behavior: "drop_block" ayarını gönderin. API etkilenen blokları kaldırıp devam eder.

Ardından geçmişi değiştiren kodu düzeltin. Her turda blok kaldırmak muhakeme maliyetini artırır ve istem önbelleğini yeniden başlatır.

effort veya max_tokens değiştirmek düşünme bloklarını geçersiz kılar mı?

Hayır. system, tools ve messages dışındaki parametreler serbestçe değiştirilebilir. cache_control işaretçileri de değiştirilebilir.

Sunucu tarafı sıkıştırma kontrolü bozar mı?

Hayır. Sıkıştırma ve bağlam düzenlemesi, gönderdiğiniz konuşmayı karşılaştıran denetimden sonra gerçekleşir.

Son turları kelimesi kelimesine koruyan istemci tarafı sıkıştırma ise kontrolü bozar.

Claude Mythos 5.1'de de aynı kontrol var mı?

Hayır. Mythos 5.1 konuşma kontrolünü çalıştırmaz. Ancak düşünme bloklarını onları üreten modele bağlar ve geçmiş düzenlemeleri yine istem önbelleğini yeniden başlatır.