Fable 5.1 vs Fable 5: ce se rupe și cum migrezi corect

Migrarea de la Claude Fable 5 la Claude Fable 5.1 arată, în cod, ca o singură linie schimbată. În realitate, trei comportamente ale API-ului devin incompatibile, iar unul dintre ele poate să treacă de teste și să pice în producție, pe conturi anume, la un anumit tipar de folosire. Articolul acesta e lista completă a diferențelor, în ordinea în care le vei întâlni, cu verificarea prin care afli dacă integrarea ta e afectată înainte să afle clienții.

Ce nu se schimbă deloc: prețul de bază și numărătoarea

Înainte de lista de probleme, două vești bune care simplifică decizia.

Prețul la intrare și la ieșire este identic: 10 $ și 50 $ per milion de tokeni. Singura modificare este la citirile din cache, care scad de la 1 $ la 0,25 $ per milion de tokeni — de la 10% din prețul intrării la 2,5%. Scrierile în cache și pragul minim de 512 de tokeni pentru un prompt pus în cache rămân neschimbate.

Tokenizatorul este același ca la Fable 5, cel introdus odată cu Opus 4.7. Nu trebuie să refaci estimările de tokeni și nici bugetele de context. Dacă migrezi însă de pe un model mai vechi decât Opus 4.7, refă-le: același text produce cam cu 30% mai mulți tokeni.

Cu alte cuvinte, migrarea nu îți crește factura. Riscul e strict tehnic, iar el vine din faptul că Fable 5.1 tratează istoricul conversației ca pe o structură cu integritate verificată, nu ca pe o listă pe care clientul o poate rescrie între cereri. Este exact genul de schimbare care nu apare într-un test unitar și apare într-o sesiune reală de agent — motiv pentru care disciplina de integrare a modelelor în aplicații de producție merită tratată ca disciplină separată, nu ca un apel HTTP; e subiectul cursului Integrare Avansată LLM în Aplicații de Producție.

Se rupe (1): apelul forțat de unelte nu mai este acceptat

Pe Fable 5.1, tool_choice cu {"type": "any"} sau {"type": "tool", "name": "..."} întoarce o eroare 400 invalid_request_error:

tool_choice: type "tool" and "any" are not supported for this model.

{"type": "auto"} (valoarea implicită) și {"type": "none"} funcționează neschimbat. Aceeași validare se aplică și pe endpoint-ul de numărare a tokenilor, deci dacă îl folosești pentru estimări, vei vedea eroarea și acolo.

Motivul e coerent cu arhitectura modelului: raționamentul e mereu pornit, iar un apel forțat de unealtă l-ar sări. Modelul și-ar scrie raționamentul direct în argumentele uneltei, ceea ce scade calitatea argumentelor. Anthropic a preferat să interzică tiparul, nu să livreze un rezultat mai slab în tăcere.

Ce pui în loc, în funcție de ce încercai să obții:

• Dacă voiai JSON valid conform unei scheme: păstrează tool_choice: {"type": "auto"} și adaugă strict: true pe definiția uneltei, sau mută schema în structured outputs, prin output_config.format.
• Dacă voiai să te asiguri că modelul apelează o unealtă în loc să răspundă în text: spune-i asta în prompt, explicit, cu numele uneltei — „Folosește unealta get_weather ca să răspunzi". Documentația notează că Fable 5.1 respectă instrucțiunile explicite de folosire a uneltelor în mod fiabil.

Aceasta este singura dintre cele trei schimbări care se vede imediat: apare la prima cerere, cu un mesaj de eroare clar.

Se rupe (2): blocurile de thinking sunt legate de modelul care le-a produs

Fiecare bloc de raționament înregistrează acum ce model l-a generat, iar compatibilitatea merge într-o singură direcție: Fable 5.1 poate citi blocurile produse de modele anterioare, dar niciun model anterior nu poate citi blocurile lui Fable 5.1.

În practică:

• O conversație care urcă pe Fable 5.1 — venind de la Opus 5, de la Fable 5 sau de la orice model Claude mai vechi — își păstrează raționamentul.
• O conversație care coboară de pe Fable 5.1 pe oricare dintre acele modele îl pierde, pentru tururile care rulează acolo.

Când o cerere transportă un bloc pe care modelul-țintă nu îl poate citi, API-ul îl elimină înainte ca modelul să îl vadă. Blocurile eliminate nu intră în input_tokens și nu sunt facturate. Problema e alta: implicit, eliminarea e tăcută. Un router care comută modelele la mijlocul conversației, sau un mecanism de fallback, poate degrada calitatea fără niciun semnal în loguri.

Soluția e să pornești antetul beta thinking-binding-controls-2026-08-01, care raportează fiecare eliminare într-un array input_transformations la nivelul răspunsului. Dacă ai un gateway multi-model sau o strategie de fallback, activează-l măcar în etapa de observare și pune-l pe un contor. Un fallback care pierde raționamentul fără să spună este cel mai scump tip de bug: nu cade nimic, doar scad rezultatele.

Se rupe (3): editarea turelor anterioare invalidează raționamentul

Aceasta este schimbarea cu cel mai mare potențial de surpriză. Pe Fable 5.1, modificarea a orice se află înaintea unui bloc de thinking — promptul de sistem, lista de unelte sau un mesaj anterior — face ca următoarea cerere să eșueze cu 400 și mesajul The block is bound to a different conversation.

Verificarea este aplicată pentru conturile create începând cu 31 august 2026. Pentru conturile mai vechi, API-ul înregistrează nepotrivirea, dar acționează asupra ei doar dacă cererea setează explicit thinking.block_binding.prefix_mismatch_behavior. Documentația spune limpede că modelele viitoare vor aplica verificarea pentru toate conturile — deci tiparul se adoptă acum, nu când te obligă o eroare în producție. Claude Mythos 5.1 nu rulează verificarea.

Dacă folosești Claude Code, claude.ai, Claude Managed Agents sau Claude Agent SDK, prefixul este păstrat intact pentru tine și nu ai nimic de făcut. Problema apare când codul tău construiește singur array-ul messages.

Al doilea rând din tabel merită subliniat: injectarea și ștergerea de mementouri per-tur este un tipar extrem de răspândit în harness-urile scrise de mână. Funcționa perfect pe modelele anterioare. Pe Fable 5.1 e exact tiparul interzis — și, întâmplător, exact tiparul care rupea și cache-ul de prompt, doar că înainte plăteai doar în bani, nu în erori.

Cum afli, în trei pași, dacă integrarea ta e afectată

1. Pornește o sesiune reală cu antetul beta thinking-binding-controls-2026-08-01 și thinking.block_binding.prefix_mismatch_behavior: "drop_block". În loc să eșueze, cererea continuă, iar blocul e eliminat.
2. Loghează input_transformations și caută intrări cu reason: "prefix_binding_mismatch". Fiecare apariție e un loc unde harness-ul tău editează istoricul.
3. Alternativ, sau în plus: capturează cererile brute trimise pe câteva tururi normale și confirmă că două cereri consecutive sunt identice octet cu octet până la turele nou adăugate.

Ce pui în loc

Regula generală: tratează conversația ca fiind append-only.

• Mementourile per-tur devin mesaje de sistem valabile un singur tur (vezi mai jos).
• Schimbările de instrucțiuni sau de unelte se fac prin mesaje de sistem la mijlocul conversației, nu prin rescrierea lui system sau tools.
• Reducerea contextului se face server-side, prin compactare sau prin context editing — niciuna nu contează ca editare.
• Dacă totuși compactezi pe client, cea mai simplă formă sigură este să înlocuiești tot istoricul cu un singur mesaj de rezumat plus turul nou al utilizatorului și să nu reiei nimic altceva: nu se transportă niciun bloc de thinking, deci nu are ce să eșueze.

Toate acestea sunt, de fapt, decizii de arhitectură a contextului, nu detalii de API — ce ții, ce arunci, ce rezumi și când. Tema e tratată sistematic în Context Engineering și Memorie pentru Agenți AI.

Se adaugă: cinci lucruri, dintre care trei în beta

1. Effort schimbat la mijlocul conversației (beta). Poți urca nivelul de effort pentru un pas greu și îl poți coborî pentru cei de rutină, fără să invalidezi cache-ul de prompt. Se face cu un mesaj role: "system" care poartă output_config, sub antetul beta mid-conversation-output-config-2026-07-01. Funcționează pe Fable 5.1, Mythos 5.1 și Opus 5, pe Claude API.

2. Mesaje de sistem valabile un singur tur (beta). Un mesaj role: "system" cu clear_at: "next_user_message" are autoritate de prompt de sistem pentru turul curent, apoi încetează să mai fie randat odată ce apare un mesaj de utilizator mai nou. Mesajul rămâne în messages și îl trimiți înapoi neschimbat, deci nimic anterior nu se modifică: cache-ul se potrivește în continuare, blocurile de thinking rămân valide, iar un mesaj deja curățat nu costă niciun token de intrare. Antet beta: mid-conversation-system-clear-at-2026-08-21.

{
  "role": "system",
  "clear_at": "next_user_message",
  "content": "Rezultatele au ajuns în inbox. Verifică-l înainte să rulezi alt cod."
}

Acesta este înlocuitorul direct pentru tiparul „injectez un memento și îl șterg", care acum rupe verificarea de integritate.

3. Actualizări de progres citibile între apelurile de unelte (beta). Fable 5.1 scrie note scurte între apelurile de unelte — ce a găsit și ce urmează — livrate ca blocuri de thinking. Sub valoarea implicită "omitted" a lui thinking.display, ele vin goale, așa că un tur agentic lung pare mut pentru utilizator. Cu display: "updates", sub antetul beta thinking-display-updates-2026-08-18, primești actualizările ca text, în timp ce raționamentul propriu-zis rămâne ascuns. Orice bloc de thinking cu text nevid devine o linie de stare pe care o poți afișa.

4. Citiri din cache la un sfert de preț. 0,25 $ per milion de tokeni, față de 1 $ pe Fable 5.

5. Marcarea conținutului generat. Textul poartă filigranul statistic de text al Anthropic pe toate platformele, iar imaginile și videoclipurile produse de model, luate prin Files API pe Claude API, poartă Content Credentials semnate C2PA. Nu necesită nicio modificare în cereri sau răspunsuri.

Ce rămâne exact la fel

Ca să nu pierzi timp verificând lucruri care nu s-au mișcat:

• Raționamentul adaptiv e mereu pornit; thinking: {"type": "enabled"} cu budget_tokens și {"type": "disabled"} întorc, în continuare, 400.
• thinking.display rămâne implicit "omitted", "summarized" e disponibil, iar lanțul brut de raționament nu e returnat niciodată.
• Raționamentul dintre apelurile de unelte apare în blocuri de thinking, iar thinking-ul întrețesut este automat, fără antet beta.
• Prefill-ul răspunsului de asistent întoarce 400.
• Valorile ne-implicite pentru temperature, top_p sau top_k întorc 400.
• Lungimea minimă a promptului care se poate pune în cache rămâne 512 de tokeni.
• Mesajele de sistem la mijlocul conversației și schimbările de unelte la mijlocul conversației sunt în continuare acceptate.
• Gestionarea refuzurilor, fallback-ul și creditul de fallback funcționează neschimbat. Țintele de fallback permise pentru Fable 5.1 sunt Opus 4.8 și Opus 5.

Dacă folosești Claude Managed Agents, documentația e categorică: nu e nevoie de nicio schimbare în afara numelui modelului.

Lista de verificare pentru migrare

1. Schimbă identificatorul din claude-fable-5 în claude-fable-5-1 (anthropic.claude-fable-5-1 pe Bedrock).
2. Scoate orice tool_choice de tip any sau tool. Mută garanțiile de schemă pe strict: true cu tool_choice: {"type": "auto"} sau pe structured outputs.
3. Rulează verificarea de istoric descrisă mai sus și repară tiparele care editează turele anterioare. Alege apoi un prefix_mismatch_behavior pentru producție și monitorizează input_transformations.
4. Re-calibrează effort pornind de la valoarea implicită high. Numele treptelor nu corespund aceleiași cantități de gândire de la un model la altul, deci o măturare făcută pe Fable 5 nu se transferă. La medium, Fable 5.1 obține rezultate cam la nivelul lui Fable 5, la cost mai mic — deci coborârea e adesea câștig curat. Ia în calcul și schimbarea effort-ului pe parcurs, în loc să ții un singur nivel toată sesiunea.
5. În buclele de agent, urmărește apelurile de unelte. Dacă vezi un singur apel pe tur acolo unde Fable 5 grupa mai multe, adaugă nota de grupare în promptul de sistem — detaliile, împreună cu restul reglajelor pentru sesiuni lungi, sunt în articolul despre bucla de agent pe Fable 5.1.
6. Reia evaluările. Nu pentru că s-au schimbat prețurile sau numărătoarea de tokeni — acelea sunt identice — ci pentru că se schimbă comportamentul implicit: densitatea prozei, formatarea în chat, marcarea citatelor din surse, rescrierea fișierelor întregi pentru modificări mici, declanșarea căutării la effort mic.

Pasul 6 este cel pe care echipele îl sar cel mai des, pentru că modelul „merge" imediat după schimbarea ID-ului. Un set de evaluări rulat înainte și după migrare este singurul mod de a vedea regresiile care nu aruncă erori — și e o investiție care se amortizează la fiecare model nou, nu doar la acesta. Cum se construiește un astfel de set, cu scoring reproductibil, e tema cursului AI Evals pentru LLM-uri în Producție.

Întrebări frecvente

Î: Migrarea de la Fable 5 la Fable 5.1 înseamnă doar schimbarea ID-ului modelului? R: Nu. Trei comportamente devin incompatibile: apelul forțat de unelte nu mai e acceptat, blocurile de raționament nu mai pot fi citite de modelele anterioare, iar editarea turelor anterioare invalidează raționamentul. Prima se vede imediat, printr-o eroare 400; ultimele două pot trece neobservate.

Î: De ce primesc eroarea „The block is bound to a different conversation"? R: Pentru că o cerere reia un bloc de raționament după ce prefixul lui — promptul de sistem, lista de unelte sau un mesaj anterior — s-a schimbat. Fie faci istoricul append-only, fie setezi thinking.block_binding.prefix_mismatch_behavior: "drop_block" sub antetul beta thinking-binding-controls-2026-08-01 ca să elimini blocul și să continui.

Î: Verificarea aceasta se aplică pentru contul meu? R: Este aplicată pentru conturile create începând cu 31 august 2026. Pentru conturile mai vechi, nepotrivirea e doar înregistrată, iar API-ul acționează asupra ei numai dacă o ceri explicit. Documentația precizează că modelele viitoare vor aplica verificarea pentru toate conturile.

Î: Am nevoie de apel forțat de unelte ca să primesc JSON valid. Ce fac? R: Păstrezi tool_choice: {"type": "auto"} și adaugi strict: true pe definiția uneltei, sau muți schema în structured outputs prin output_config.format. Pentru a determina modelul să folosească o unealtă anume, o numești explicit în prompt.

Î: Se schimbă costul după migrare? R: Prețurile de intrare și de ieșire sunt identice, iar tokenizatorul este același, deci numărătoarea nu se mișcă. Singura schimbare este în jos: citirile din cache costă 0,25 $ per milion de tokeni în loc de 1 $.

Concluzie

Fable 5.1 mută linia dintre „istoricul conversației e o listă pe care clientul o poate rescrie" și „istoricul e o structură cu integritate verificată". Cele trei schimbări incompatibile decurg toate de aici, iar cele cinci adăugiri sunt, în bună parte, uneltele care îți permit să lucrezi în noul regim: mesaje de sistem pe un singur tur în loc de injecții șterse, effort schimbat pe parcurs în loc de prompt de sistem rescris, compactare server-side în loc de rescriere pe client.

Ordinea de lucru care economisește cel mai mult timp: schimbă ID-ul, scoate tool_choice forțat, rulează verificarea de istoric cu drop_block, apoi re-calibrează effort-ul și reia evaluările. Restul sunt reglaje de prompt, nu rescrieri.

Articol tehnic, redactat la 1 septembrie 2026, pe baza documentației oficiale Anthropic disponibile la această dată: noutățile din Fable 5.1, ghidul de migrare și prezentarea modelului. Funcțiile marcate „beta" și antetele lor se pot modifica — verificați documentația înainte de a le duce în producție.