Adaptive thinking pe Claude Fable 5 și Mythos 5: cum funcționează raționamentul always-on

Pe cele mai capabile modele ale Anthropic — Claude Fable 5 și geamănul lui cu acces limitat, Claude Mythos 5 — raționamentul nu mai este un mod pe care îl activezi. Este mereu pornit și nu poate fi oprit. Această schimbare aparent minoră are consecințe reale asupra felului în care scrii prompturi, controlezi costul și gestionezi conversații multi-turn. Acest ghid explică ce este adaptive thinking, singura pârghie pe care o ai ca să-l controlezi, ce primești de fapt înapoi din raționamentul modelului și cum se raportează Fable 5 la Mythos 5.

Dacă vrei comparația de cost și capabilitate cu modelul Opus mai ieftin, am tratat-o în Claude Fable 5 vs Opus 4.8. Aici ne concentrăm pe un singur lucru pe care nicio altă analiză nu-l detaliază: comportamentul de raționament al acestor două modele și ce înseamnă el pentru codul tău.

Ce este adaptive thinking și de ce e mereu activ

Pe Fable 5 și Mythos 5, adaptive thinking este singurul mod de raționament disponibil. Se aplică ori de câte ori parametrul thinking nu este setat — adică implicit, în orice apel obișnuit. Nu există un mod „fără raționament": modelul decide singur, adaptiv, cât efort de gândire alocă fiecărei cereri, în funcție de dificultatea ei.

Consecința tehnică directă: thinking: {"type": "disabled"} nu este suportat. Dacă vii de la un model unde dezactivai explicit raționamentul pentru sarcini simple, ca să economisești, acel apel va eșua aici. Nu mai ai butonul „off" — ai doar un buton de „cât de adânc".

De ce a mers Anthropic pe această direcție? Pentru că Fable 5 e construit pentru raționament exigent și muncă agentică de lungă durată — planificare în etape, folosirea de unelte (browser, terminal), sarcini care rulează autonom pe perioade extinse. Pentru acest profil de sarcini, raționamentul nu e un extra ocazional, ci mecanismul de bază. Modelul care „gândește mereu" e o alegere de design aliniată cu scopul lui: agenți care descompun, cercetează, creează și verifică singuri.

effort: singura pârghie de control al raționamentului

Dacă nu mai poți dezactiva gândirea, cum o controlezi? Prin parametrul effort. El reglează adâncimea raționamentului — și, implicit, latența și costul. Setezi effort mai jos pe sarcinile ușoare (unde raționamentul profund e overhead inutil) și mai sus pe sarcinile grele (unde diferența de calitate justifică tokenii suplimentari de gândire).

Mental, gândește-l ca pe un buget de raționament, nu ca pe un întrerupător:

• effort scăzut → mai puțin raționament, răspuns mai rapid și mai ieftin, potrivit pentru sarcini bine definite;
• effort ridicat → raționament mai adânc, cost și latență mai mari, potrivit pentru analize complexe și decizii cu miză.

Această pârghie se leagă direct de economia integrării tale. Pentru că adaptive thinking e mereu activ, nu ai cum să faci modelul „gratuit" pe sarcinile triviale — dar poți să-l faci proporțional. Un motiv în plus să nu trimiți la Fable 5 tot traficul: rezervă-l pentru sarcinile care chiar cer nivelul lui, reglează effort după dificultate, și lasă un model mai ieftin să facă volumul repetitiv. Cum construiești această decizie de rutare cu date, nu din intuiție, tratăm în Comparație modele AI.

Raționamentul brut nu se întoarce niciodată: summarized vs omitted

Un al doilea comportament specific, cu impact direct asupra a ce vezi în răspuns: pe Fable 5 și Mythos 5, lanțul brut de raționament (raw chain of thought) nu este returnat niciodată. Nu ai acces la gândirea „la firul ierbii" a modelului. În schimb, setarea thinking.display controlează ce conțin blocurile de thinking din răspuns:

• "summarized" — blocurile de thinking conțin un rezumat lizibil al raționamentului. Util când vrei să auditezi sau să depanezi cum a ajuns modelul la un răspuns, fără acces la lanțul complet.
• "omitted" (valoarea implicită) — blocurile de thinking vin cu câmpul thinking gol. Payload minim, potrivit când nu ai nevoie de vizibilitate în raționament și vrei latență și cost cât mai mici.

Există și o regulă esențială pentru conversații multi-turn: retrimite blocurile de thinking nemodificate, în cadrul aceleiași conversații, pe același model. Nu le rescrie, nu le trunchia și nu le muta între modele diferite — modelul se așteaptă să le primească intacte pentru a menține coerența raționamentului de-a lungul turelor.

Pentru echipele care construiesc agenți cu memorie și context persistent, acest detaliu de „ce păstrezi și cum retransmiți starea de raționament" se leagă direct de disciplina predată în Context Engineering și memorie pentru agenți.

Fable 5 vs Mythos 5: aceleași capabilități, un tier de acces diferit

Aici merită clarificată relația dintre cele două modele, pentru că sursa de confuzie e frecventă. Fable 5 și Mythos 5 împart aceleași specificații, același preț și același comportament de raționament. Diferența nu e de „putere", ci de garduri de siguranță și de acces:

• Claude Fable 5 (claude-fable-5) — cel mai capabil model lansat pe scară largă al Anthropic, general disponibil. Include clasificatori de siguranță care pot refuza anumite cereri.
• Claude Mythos 5 (claude-mythos-5) — aceleași capabilități, fără clasificatorii de siguranță. Nu este general disponibil: se oferă în acces limitat, organizațiilor aprobate, prin Project Glasswing. Este succesorul lui Claude Mythos Preview.

Cu alte cuvinte: dacă nu ai acces la Mythos 5, folosești Fable 5, care oferă aceleași capabilități și e general disponibil. Am detaliat separat ce este Mythos 5, relația cu Project Glasswing și logica de guvernanță din spate în Claude Mythos 5: puterea Fable 5 prin Project Glasswing — aici e suficient să reții că tot ce spunem despre raționament în acest articol se aplică identic ambelor modele, pentru că împart același motor.

Ambele specificații comune, pe scurt:

Ce funcții suportă la lansare

Comportamentul de raționament e doar o parte. La lansare, Fable 5 și Mythos 5 suportă un set de funcții orientate exact spre muncă agentică de durată:

• Effort — controlul adâncimii de raționament, descris mai sus.
• Task budgets (în beta, prin header-ul task-budgets-2026-03-13) — plafonarea efortului alocat unei sarcini.
• Memory tool — memorie persistentă între apeluri.
• Code execution — execuția de cod.
• Programmatic tool calling — apelarea programatică a uneltelor.
• Context editing cu curățarea rezultatelor de tool (în beta, prin header-ul context-management-2025-06-27).
• Compaction — compactarea contextului pentru sesiuni lungi.
• Vision — procesarea de imagini.

Combinația fereastră de 1M tokeni + 128K tokeni de output + memory tool + compaction + task budgets nu e întâmplătoare: e trusa exactă de care ai nevoie ca să rulezi un agent care lucrează pe un context mare, timp îndelungat, fără să piardă firul. Cum legi aceste piese într-un agent funcțional — de la buclă de raționament la orchestrare — construiești în AI Agents și automatizare.

Cum alegi nivelul de effort pe tipuri de sarcini

Pentru că effort e singura pârghie reală, merită tratată ca o decizie de design, nu ca o valoare pusă „din reflex". Un mod practic de a gândi alocarea, în funcție de profilul sarcinii:

• Extracție structurată, clasificare, formatare — sarcini cu format bine definit, unde răspunsul corect e aproape mecanic. Aici raționamentul adânc aduce puțin; un effort scăzut păstrează latența mică și costul jos.
• Redactare, sinteză, rescriere — un nivel mediu e de obicei suficient: modelul are nevoie de ceva raționament pentru coerență, dar nu de o analiză în profunzime.
• Analiză complexă, planificare în etape, debugging arhitectural, decizii cu miză — exact cazurile pentru care aceste modele au fost construite. Aici effort ridicat își merită tokenii suplimentari, pentru că diferența de calitate se vede direct în rezultat.
• Bucle agentice de lungă durată — combină effort cu task budgets (funcția în beta), ca să plafonezi efortul total pe o sarcină autonomă și să nu lași agentul să „gândească" nelimitat pe un pas care nu merită.

Ideea de fond: nu setezi effort o dată, global, ci îl potrivești cu dificultatea reală a fiecărui tip de apel din aplicația ta. Iar felul corect de a decide ce prag alegi nu e intuiția, ci măsurarea — rulezi aceeași sarcină la niveluri diferite de effort și compari calitatea cu costul, exact tipul de disciplină pe care o predăm în AI Agents și automatizare.

Ce înseamnă asta când migrezi de la un model anterior

Dacă muți o integrare de pe Claude Opus 4.8 (sau, pentru Mythos, de pe Claude Mythos Preview) pe aceste modele, trei lucruri se schimbă din comportamentul de raționament:

1. Nu mai dezactiva raționamentul. Orice apel care trimitea thinking: {"type": "disabled"} trebuie rescris — folosește effort pentru a regla adâncimea în loc să o oprești.
2. Recalibrează bugetul. Pentru că raționamentul e mereu activ, o parte din tokenii de output merg pe gândire chiar și pe sarcini simple. Măsoară costul real pe propriile prompturi în loc să extrapolezi de la un model fără thinking always-on.
3. Gestionează blocurile de thinking corect. Alege summarized sau omitted conștient și, în multi-turn, retrimite-le nemodificate pe același model.

Regula generală rămâne: un swap de model nu e doar o schimbare de preț, ci una de comportament. Rulează-ți setul de evaluări pe noul model înainte să comuți traficul de producție — disciplină pe care o tratăm pe larg în orice discuție serioasă despre calitate în producție.

Întrebări frecvente

Pot dezactiva raționamentul pe Fable 5 sau Mythos 5?

Nu. Adaptive thinking este singurul mod de raționament și este mereu activ; thinking: {"type": "disabled"} nu este suportat. Poți doar să reglezi adâncimea prin parametrul effort.

Care e diferența reală dintre Fable 5 și Mythos 5?

Împart aceleași capabilități, specificații și preț. Fable 5 include clasificatori de siguranță și este general disponibil; Mythos 5 nu are acei clasificatori și este oferit doar în acces limitat, prin Project Glasswing, organizațiilor aprobate. Comportamentul de raționament e identic la ambele.

Pot vedea „gândirea" completă a modelului?

Nu. Raționamentul brut nu este returnat niciodată. Prin thinking.display alegi între "summarized" (un rezumat lizibil) și "omitted" (câmp de thinking gol, valoarea implicită).

Trebuie să fac ceva special cu blocurile de thinking în conversații multi-turn?

Da — retrimite-le nemodificate, în cadrul aceleiași conversații, pe același model. Nu le edita și nu le muta între modele diferite.

Cum controlez costul dacă raționamentul e mereu pornit?

Prin effort: mai jos pe sarcini ușoare, mai sus pe cele grele. Și prin rutare — trimite la Fable 5 doar sarcinile care chiar cer nivelul lui și lasă un model mai ieftin să facă volumul repetitiv.

Concluzie

Adaptive thinking always-on este semnătura lui Claude Fable 5 și Mythos 5: un raționament care nu se dezactivează, se doar dozează. Practic, asta îți schimbă trei obiceiuri — nu mai oprești gândirea (folosești effort), nu mai vezi lanțul brut (alegi între summarized și omitted) și tratezi blocurile de thinking cu grijă în multi-turn. Adaugă peste asta fereastra de 1M tokeni, cei 128K de output și trusa de funcții agentice, și ai un motor construit pentru sarcini autonome de durată — nu pentru Q&A rapid și ieftin.

Ca de fiecare dată cu un model de frontieră, avantajul real nu vine din a-l activa, ci din a ști când merită nivelul lui și cum îl reglezi. Rezervă-l pentru sarcinile grele, dozează raționamentul cu effort, măsoară costul pe propriile prompturi — și lasă restul traficului pe un model mai ieftin.

Surse

1. Anthropic — Introducing Claude Fable 5 and Claude Mythos 5 (documentație oficială)
2. Anthropic — Claude Fable 5 and Claude Mythos 5

Articol cu caracter informativ, bazat pe documentația oficială Anthropic. Parametrii, funcțiile în beta și prețurile se pot schimba — consultă documentația oficială înainte de implementare în producție.