Claude Fable 5.1: Cache %75 Ucuzladı, tool_choice Kırıldı

Claude Fable 5.1 nedir sorusunun kısa cevabı şu: 1 Eylül 2026'da yayınlanan claude-fable-5-1, fiyat etiketini ($10/$50 per MTok) değiştirmeden cache-read maliyetini %75 düşüren, ama üç yerde geriye dönük uyumluluğu kıran bir sürüm. Eğer production kodun tool_choice: {"type":"any"} veya {"type":"tool"} kullanıyorsa, ya da mesaj geçmişini elle inşa ediyorsan, bu yazıyı atlamadan önce okumalısın — aşağıdaki üç kırılmadan ikisi doğrudan 400 hatasıyla, biri ise sessizce kendini gösteriyor.

💡 Pro Tip: Fable 5'ten 5.1'e geçmeden önce staging'de bir "kırılma taraması" yap: kod tabanında tool_choice ve elle inşa edilmiş thinking bloklarını grep'le — resmi migration rehberinin ilk iki maddesi de tam olarak bu iki desen.

İçindekiler

• Fable 5.1 tek bakışta: fiyat, bağlam, effort
• Cache-read $0,25: gerçek fatura etkisi
• Nerede fark yaratır, nerede yaratmaz
• KIRILMA: tool_choice any/tool artık 400 dönüyor
• Neden bu kırıldı: resmi gerekçe
• Strict tool use ve structured outputs'a geçiş
• Thinking-block uyumu ve 400 tuzağı
• Filigranlı çıktı ne anlama geliyor
• Fable 5 → 5.1 göç kontrol listesi
• Adım adım migration akışı
• Python ve TypeScript'te aynı geçiş
• SSS
• Claude Fable 5.1 ne zaman çıktı ve fiyatlandırması nasıl?
• Fable 5.1'de tool_choice neden 400 hatası veriyor?
• Fable 5.1 cache-read indirimi maliyeti ne kadar düşürüyor?
• Fable 5'ten Fable 5.1'e geçerken kodumda neyi değiştirmeliyim?
• Sonuç
• Kaynaklar

Fable 5.1 tek bakışta: fiyat, bağlam, effort

Fable 5.1, Mythos 5.1 (claude-mythos-5-1, yalnızca Project Glasswing kapsamında) ile aynı gün, 1 Eylül 2026'da duyuruldu. Model kimliği claude-fable-5-1; Claude API, Amazon Bedrock, AWS, Google Cloud ve Microsoft Foundry üzerinden erişilebilir durumda.

Temel spesifikasyonlar şöyle:

• Bağlam penceresi: 1M token (varsayılan aynı zamanda maksimum)
• Çıktı limiti: 128k token
• Thinking: always-on adaptive thinking — kapatılamaz, yalnız effort parametresiyle derinliği ayarlanır
• Tokenizer: Fable 5 ile birebir aynı (Opus 4.7'den beri sabit) — Opus 4.7 öncesi modellere göre aynı metin yaklaşık %30 daha fazla token üretiyor
• Veri saklama: 30 gün zorunlu; Anthropic'in açık izni olmadan ZDR (zero data retention) yok — bu da Fable 5 ile birebir aynı

Bu, Claude 4.7 Opus yazısında ele aldığımız, her görev için doğru effort seviyesini seçme yaklaşımının doğal devamı; Fable 5'te olduğu gibi 5.1'de de effort, thinking'i açıp kapatan bir anahtar değil, thinking'in derinliğini ayarlayan bir kadran.

Fiyatlandırma tablosu (girdi/çıktı Fable 5 ile birebir aynı kaldı):

Cache-read $0,25: gerçek fatura etkisi

Buradaki asıl haber girdi/çıktı fiyatı değil, cache-read oranı. Fable 5'te cache'ten okuma, temel girdi fiyatının 0,1 katıydı ($1/MTok). Fable 5.1'de bu oran 0,025 katına indi ($0,25/MTok) — diğer modellerdeki standart 0,1x oranın dörtte biri.

Bunun somut anlamı: sistem promptu + tool tanımları + uzun konuşma geçmişini her turda cache'ten okuyan ve cache-read'in baskın maliyet kalemi olduğu (uzun sistem promptu + kısa çıktı) agent mimarilerinde, bu kalemi %75 düşürmek doğrudan faturaya yansıyor. Bu düşüş, prompt caching yazısında anlattığımız "10x'e kadar maliyet azaltma" tavanını daha da yükseltiyor — özellikle uzun sistem promptlu, çok turlu agent döngülerinde.

Nerede fark yaratır, nerede yaratmaz

• Yaratır: Uzun sistem promptlu chatbot'lar, çok araçlı agent'lar, MCP sunucularıyla konuşan pipeline'lar — bunların hepsi turdan-tura aynı büyük bağlamı cache'ten tekrar okur.
• Yaratmaz: Tek seferlik, kısa promptlu, cache kullanmayan çağrılar — burada girdi/çıktı fiyatı zaten aynı kaldığı için fatura değişmez.

KIRILMA: tool_choice any/tool artık 400 dönüyor

Bu yazının en kritik bölümü burası. Fable 5'te ve öncesinde çalışan şu istek, Fable 5.1'de doğrudan hata veriyor:

1curl https://api.anthropic.com/v1/messages \
2  -H "x-api-key: $ANTHROPIC_API_KEY" \
3  -H "anthropic-version: 2023-06-01" \
4  -H "content-type: application/json" \
5  -d '{
6    "model": "claude-fable-5-1",
7    "max_tokens": 1024,
8    "tools": [{"name": "get_weather", "input_schema": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]}}],
9    "tool_choice": {"type": "tool", "name": "get_weather"},
10    "messages": [{"role": "user", "content": "Hava nasıl?"}]
11  }'

Dönen hata birebir şu:

1{
2  "type": "error",
3  "error": {
4    "type": "invalid_request_error",
5    "message": "tool_choice: type \"tool\" and \"any\" are not supported for this model."
6  }
7}

auto ve none değerleri etkilenmedi — sorun yalnız modeli belirli bir tool'u (veya herhangi bir tool'u) çağırmaya zorlayan iki değerde. Aynı doğrulama, token-counting endpoint'inde de aynen geçerli; yani tool_choice:any ile token saymaya çalışırsan orada da 400 alırsın.

Neden bu kırıldı: resmi gerekçe

Bunun bir hata değil, bilinçli bir tasarım kararı olduğunu vurgulamak gerek. Fable 5.1'de thinking her zaman açık. Bir tool çağrısını zorunlu kılmak, modelin "working out" adımını atlatıp doğrudan tool argümanlarına yazmasına yol açıyor — sonuç, daha düşük kaliteli argüman üretimi. Anthropic bu davranışı önlemek için any/tool zorlamasını tamamen kapattı; model artık ya serbestçe düşünüp kendi kararıyla tool çağırıyor (auto) ya da hiç çağırmıyor (none).

Bu, Claude Extended Thinking yazısında değindiğimiz, thinking'in bir yan özellik değil model mimarisinin parçası olduğu fikrinin doğal sonucu — 5.1'de bu ilke artık API seviyesinde zorunlu kılınıyor.

Strict tool use ve structured outputs'a geçiş

tool_choice: any/tool kullanan kodun için resmi olarak önerilen iki yol var:

1. Strict tool use — tool_choice: "auto" ile birlikte tool tanımına strict: true ekleyerek şema uyumunu garantiliyorsun, ama modeli zorlamıyorsun:

1{
2  "tools": [
3    {
4      "name": "get_weather",
5      "strict": true,
6      "input_schema": {
7        "type": "object",
8        "properties": { "city": { "type": "string" } },
9        "required": ["city"]
10      }
11    }
12  ],
13  "tool_choice": { "type": "auto" }
14}

2. Structured outputs — şemayı doğrudan tool tanımından çıkarıp yanıt formatına taşımak; özellikle "bana her zaman bu JSON şeklini ver" senaryosunda tool çağrısı yerine daha doğal bir uyum sağlıyor.

Üçüncü, daha basit bir alternatif de resmi olarak öneriliyor: modeli tool kullanmaya prompt üzerinden açıkça yönlendirmek — örneğin "Hava durumunu cevaplamak için get_weather tool'unu kullan" gibi net bir talimat. Fable 5.1'in açık tool talimatlarını güvenilir biçimde izlediği belirtiliyor; yani zorlama olmadan da davranışı yönlendirebiliyorsun.

Ben genelde ikisini birlikte kullanmayı tercih ederim: prompt'ta net talimat + strict: true şema doğrulaması. Bu kombinasyon, eski tool_choice:tool zorlamasının verdiği "garanti çağrılır" hissini, thinking kalitesinden ödün vermeden en yakın şekilde taklit ediyor.

Thinking-block uyumu ve 400 tuzağı

İkinci kırılma daha sinsi, çünkü hemen değil, ikinci turda ortaya çıkıyor. Uyumluluk tek yönlü: Fable 5.1, Opus 5, Fable 5, Mythos 5 ve öncesi modellerin thinking bloklarını okuyabiliyor — ama hiçbir eski model, Fable 5.1'in ürettiği thinking bloklarını okuyamıyor. Model geçişinde uyumsuz blok API tarafından sessizce düşürülüyor; bu blok input_tokens'a sayılmıyor, faturalanmıyor.

Asıl tuzak burada değil. Ayrı ve daha kritik bir kural şu: bir önceki turdaki system promptu, tool tanımlarını veya mesajları değiştirirsen, o turun thinking blokları geçersiz sayılıyor — ve bir sonraki istek şu hatayla 400 dönüyor:

1{
2  "type": "error",
3  "error": {
4    "type": "invalid_request_error",
5    "message": "The block is bound to a different conversation"
6  }
7}

Bu kural, 31 Ağustos 2026 ve sonrasında açılan hesaplarda zorunlu; öncesindeki hesaplarda varsayılan olarak sessiz kalıyor ve yalnız prefix_mismatch_behavior alanı ayarlanırsa devreye giriyor. Kendi messages dizisini elle inşa eden — yani her turda system/tools/history'yi programatik olarak yeniden birleştiren — entegrasyonlar için resmi rehber özellikle şunu söylüyor: migrate etmeden önce bu kodu kontrol et, çünkü bir önceki turun prefix'ini fark etmeden değiştirmek bu hataya yol açabiliyor.

Kaçış yolu resmi olarak tanımlı: thinking-binding-controls-2026-08-01 beta header'ı ile birlikte şu alanı ekliyorsun:

1{
2  "thinking": {
3    "block_binding": {
4      "prefix_mismatch_behavior": "drop_block"
5    }
6  }
7}

Bu ayarla uyumsuz blok sessizce düşürülüyor ve düşme nedeni yanıtın input_transformations alanında reason: "prefix_binding_mismatch" olarak raporlanıyor — yani hatayı almak yerine, neyin düştüğünü görebiliyorsun.

Güvenli kalan pattern'ler şunlar: thinking bloklarını en eskiden başlayarak kaldırmak, server-side context editing/compaction kullanmak, cache_control'ü taşımak, ve turlar arası yalnızca effort değiştirmek (bu, prefix'i bozmuyor).

Filigranlı çıktı ne anlama geliyor

Fable 5.1 ve Mythos 5.1'in ürettiği tüm metin çıktısı, kullanıldığı her platformda Anthropic'in istatistiksel text watermark'ını taşıyor. Resmi güvence şu üç noktada net: anlamı, kaliteyi veya okunabilirliği değiştirmiyor; ekstra token ya da gizli karakter eklemiyor; kullanıcı veya organizasyon bilgisi taşımıyor.

Pratikte bu, kod tarafında hiçbir değişiklik gerektirmiyor — istek/yanıt işleme akışın aynı kalıyor, ekstra bir alan parse etmen ya da temizlemen gerekmiyor. Ek olarak, code execution tool ile üretilen ve desteklenen görsel/video/ses dosyaları, Files API üzerinden alındığında ayrıca imzalı C2PA Content Credentials taşıyor — bu, medya dosyalarının kaynağını doğrulamak isteyen entegrasyonlar için ayrı bir doğrulama katmanı.

Fable 5 → 5.1 göç kontrol listesi

Aşağıdaki tablo, gerçek bir migration'da kontrol etmen gereken maddeleri önceliğine göre sıralıyor:

Adım adım migration akışı

1. Kod tabanında tool_choice için grep çalıştır; "any" veya "tool" tipi bulursan işaretle.
2. İşaretlenen her çağrıyı tool_choice:auto + strict:true şablonuna taşı; gerekirse prompt'a açık tool talimatı ekle.
3. Mesaj geçmişini elle birleştiren kodda, bir önceki turun system/tools alanlarının turlar arası değişmediğini garanti eden bir test yaz.
4. Testte prefix_mismatch_behavior:"drop_block" ile bir kez çalıştır, input_transformations alanını logla — beklenmedik drop'ları burada yakalarsın.
5. Model-router veya fallback zincirin varsa (örneğin Fable 5.1 → Opus 5 → Sonnet 5), thinking bloklarının yalnız eskiden yeniye okunabildiğini unutma; 5.1 → eski model geçişinde blok sessizce elenir, bu durumu bekleyen bir varsayım koyma.
6. Staging'de bir hafta gözlemle, sonra production'a al.

Bu adımların hiçbiri zorunlu bir "büyük rewrite" gerektirmiyor — resmi migration rehberi bu geçişi "mostly drop-in" olarak nitelendiriyor. Asıl risk, taramayı hiç yapmadan geçiş yapıp kırılmayı production'da, kullanıcı raporlarından öğrenmek.

Ek olarak, üç opsiyonel/beta özellik daha var: turn-scoped system messages (mid-conversation-system-clear-at-2026-08-21), thinking.display:"updates" (thinking-display-updates-2026-08-18) ve turlar arası effort değişimini destekleyen mid-conversation-output-config-2026-07-01 header'ı. Bunların hiçbiri zorunlu geçiş adımı değil, cache-dostu iyileştirmeler — Claude 1M context window ile çalışan büyük codebase pipeline'larında denemeye değer.

Python ve TypeScript'te aynı geçiş

Aşağıda, tool_choice: {"type":"tool"} kullanan bir Python entegrasyonunun 5.1-uyumlu haline dönüşümü var:

1# ÖNCE (Fable 5'te çalışır, Fable 5.1'de 400 döner)
2response = client.messages.create(
3    model="claude-fable-5",
4    max_tokens=1024,
5    tools=[weather_tool],
6    tool_choice={"type": "tool", "name": "get_weather"},
7    messages=[{"role": "user", "content": "Hava nasıl?"}],
8)
9 
10# SONRA (strict tool use + açık prompt talimatı)
11weather_tool["strict"] = True
12response = client.messages.create(
13    model="claude-fable-5-1",
14    max_tokens=1024,
15    tools=[weather_tool],
16    tool_choice={"type": "auto"},
17    messages=[
18        {
19            "role": "user",
20            "content": "Hava durumunu cevaplamak için get_weather tool'unu kullan. Şehir: İstanbul",
21        }
22    ],
23)

Node/TypeScript tarafında model-router zincirini test eden basit bir kontrol:

1// Fallback zincirinde thinking-block yönünü doğrulayan basit kontrol
2const chain = ["claude-fable-5-1", "claude-opus-5", "claude-sonnet-5"];
3 
4function canReuseThinkingBlock(fromModel: string, toModel: string): boolean {
5  // 5.1 bloğunu yalnız 5.1 ve daha yeni modeller okuyabilir; 5.1 ise eski modellerin bloklarını okur
6  const rank = (m: string) => chain.indexOf(m);
7  return rank(fromModel) >= rank(toModel);
8}

Bu kontrolü fallback mantığına eklemek, "eski model bloğu okuyamadı" hatasını production'da değil, CI'da yakalamanı sağlıyor.

SSS

Claude Fable 5.1 ne zaman çıktı ve fiyatlandırması nasıl?

Fable 5.1, 1 Eylül 2026'da Mythos 5.1 ile birlikte yayınlandı. Girdi/çıktı fiyatı Fable 5 ile birebir aynı kaldı ($10/$50 per MTok); tek fiyat değişikliği cache-read'de: $1/MTok'tan $0,25/MTok'a, yani %75 indirim. Claude API, Amazon Bedrock, AWS, Google Cloud ve Microsoft Foundry üzerinden erişilebilir.

Fable 5.1'de tool_choice neden 400 hatası veriyor?

tool_choice: {"type":"any"} ve {"type":"tool","name":"..."} değerleri Fable 5.1'de artık desteklenmiyor ve invalid_request_error ile 400 dönüyor. Resmi gerekçe: always-on thinking, zorunlu tool çağrısıyla çakışıyor — model "working out" adımını atlayıp doğrudan tool argümanına yazıyor, bu da düşük kaliteli argüman üretimine yol açıyor. auto ve none etkilenmedi; çözüm strict tool use veya structured outputs'a geçmek.

Fable 5.1 cache-read indirimi maliyeti ne kadar düşürüyor?

Cache-read oranı, temel girdi fiyatının 0,1 katından 0,025 katına indi. Uzun sistem promptu ve tool tanımlarını her turda cache'ten okuyan ve cache-read'in baskın maliyet kalemi olduğu (uzun sistem promptu + kısa çıktı) çok turlu agent mimarilerinde, bu toplam faturada belirgin bir düşüş anlamına geliyor — özellikle prompt caching stratejisi zaten kullanılan projelerde.

Fable 5'ten Fable 5.1'e geçerken kodumda neyi değiştirmeliyim?

Üç şeyi kontrol et: (1) tool_choice:any/tool kullanan tüm çağrıları strict tool use'a taşı, (2) mesaj geçmişini elle birleştiren kodda önceki turun system/tools alanlarının değişmediğini garanti et — aksi halde "block is bound to a different conversation" hatası alırsın, (3) model-router/fallback zincirinde thinking bloklarının yalnızca eski modelden yeniye doğru taşınabildiğini hesaba kat.

Sonuç

Fable 5.1, fiyat etiketini değiştirmeden cache-read maliyetini %75 düşüren ve buna karşılık üç yerde geriye dönük uyumluluğu kıran bir sürüm: tool_choice:any/tool artık 400 dönüyor, eski modeller 5.1'in thinking bloklarını okuyamıyor, ve thinking-block prefix'i turlar arası sabit kalmak zorunda. Bunların yanında beş additive değişiklik var: cache-read fiyatındaki düşüş, turn-scoped system messages, thinking.display:"updates", turlar arası effort değişimi ve tüm metin çıktısının artık filigranlı olması — bunların hiçbiri kodda zorunlu bir değişiklik gerektirmiyor. Bunların hiçbiri sürpriz bir "regresyon" değil — hepsi resmi dokümantasyonda açıkça gerekçelendirilmiş, kasıtlı tasarım kararları.

Pratik sonuç şu: production kodunda tool_choice kullanan veya mesaj geçmişini elle inşa eden her entegrasyon, geçiş öncesi bir tarama borçlu. Bu taramayı Claude 4.6 Opus veya Claude 4.7 Opus ile çalışan mevcut agent'ların üzerinden geçirirken, Extended Thinking davranışının artık zorunlu olduğunu ve MCP tabanlı tool zincirlerinde tool_choice zorlamasının kalktığını unutma. Cache-read indirimini gerçekten cebine koymak istiyorsan, prompt caching mimarini bu yeni oranla yeniden hesapla; cache-read ağırlıklı mimarilerde kalem başına maliyet dörtte birine iniyor ($1 → $0,25/MTok).

Kaynaklar

• Claude Platform Release Notes — 1 Eylül 2026 Fable 5.1 lansman girdisi, tool_choice ve thinking-block değişikliklerinin resmi duyurusu
• What's new in Claude Fable 5.1 — sürüm-özel yenilikler, cache-read fiyatı ve filigran açıklaması
• Claude Models Overview — güncel fiyatlandırma tablosu ve model karşılaştırması
• Tool use with Claude — strict tool use ve tool_choice davranışının resmi referansı
• Preserved thinking — thinking-block'ların model ve prefix uyumluluğu, block_binding/prefix_mismatch_behavior alanları ve turlar arası kurallar