Agenți care rulează ore: bucla corectă pe Claude Fable 5.1

Un model bun într-o buclă prost construită produce o factură mare și un rezultat mediocru. Pe Claude Fable 5.1, modelul pe care Anthropic îl recomandă explicit pentru muncă agentică cu orizont lung, diferența dintre o buclă atentă și una scrisă din reflex se măsoară în ore de rulare și în sute de dolari pe sesiune. Ghidul acesta adună deciziile care contează: unde reglezi effort-ul, cum ții istoricul valid, cum grupezi apelurile de unelte, ce faci ca agentul să nu pară mort minute în șir și unde se duc, de fapt, banii.

Pornim de la ce s-a schimbat în comportamentul implicit

Fable 5.1 se comportă altfel decât Fable 5 în bucle lungi, fără să fi schimbat tu nimic. Cinci diferențe contează pentru agenți:

• poate face un singur apel de unealtă pe tur acolo unde Fable 5 grupa mai multe, când acțiunile următoare sunt implicite, nu cerute explicit;
• scrie mai puține actualizări de progres, mai ales la effort mare și în lanțuri lungi de unelte;
• la effort low, răspunde mai des din memorie în loc să apeleze o unealtă de căutare;
• rescrie fișiere întregi pentru modificări mici;
• la xhigh și max, poate gândi mult înainte de a scrie un livrabil lung.

Niciuna nu e o scădere de calitate. Toate sunt însă costuri: tururi în plus, tokeni de ieșire în plus, timp de așteptare în plus și un agent care pare blocat. Fiecare are un reglaj, iar restul articolului le ia pe rând. Dacă modelul mental de bază — ce e o buclă de agent, unde se pun granițele, cum se opresc rulările scăpate de sub control — nu e încă solid, el se construiește sistematic în AI Agents: Arhitectura și Automatizarea Sistemelor Autonome.

Effort: prima pârghie, și cea mai prost folosită

Pe Fable 5.1, effort este pârghia principală pentru compromisul dintre inteligență, latență și cost. Valoarea implicită e high, iar treptele merg de la low, prin medium, high și xhigh, până la max.

Trei lucruri de reținut, toate din documentația oficială de prompting:

Numele treptelor nu corespund aceleiași cantități de gândire de la un model la altul. O măturare de effort făcută pe Fable 5 nu se transferă pe Fable 5.1. Refă-o.

La medium, Fable 5.1 obține rezultate cam la nivelul lui Fable 5, la cost mai mic. Dacă evaluările tale arată că se ține calitatea, coborârea de la high la medium e câștig curat. La low, modelul e adesea competitiv pe cost per sarcină cu modelele Opus și Sonnet, scorând totuși mai bine — deci merită inclus în comparație oriunde ai fi rulat, altfel, un model mai mic la effort mai mare.

La xhigh și max, lasă loc. Modelul poate să își schițeze în raționament o bună parte din livrabil, apoi să îl scrie din nou ca răspuns — deci așteptare mai lungă și mai mulți tokeni de ieșire. Setează max_tokens cu spațiu pentru gândire și pentru răspuns, nu doar pentru lungimea răspunsului pe care o aștepți. Recomandarea implicită rămâne high, cu urcare doar acolo unde ai măsurat un câștig.

Effort schimbat pe parcurs, nu pe toată sesiunea

Noutatea reală pentru agenți este că, pe Fable 5.1, poți schimba effort-ul la mijlocul conversației, fără să invalidezi cache-ul de prompt. Funcția e în beta, sub antetul mid-conversation-output-config-2026-07-01, și se face cu un mesaj role: "system" care poartă output_config:

{ "role": "system", "content": [], "output_config": { "effort": "low" } }

Noul nivel intră în vigoare de la turul următor al utilizatorului. Tiparul care iese cel mai bine într-o sesiune lungă: high pentru planificare și pentru pașii cu decizii grele, coborâre la medium sau low pentru pașii de rutină — citiri, verificări, formatări — și urcare punctuală acolo unde ai nevoie de raționament sau de căutare proaspătă. Este exact contrariul obiceiului de a fixa un nivel la începutul sesiunii și de a-l uita acolo.

Un caz particular merită menționat: la low, modelul apelează mai rar uneltele de căutare. Dacă ai un tur care are nevoie de informație proaspătă, cea mai simplă soluție e să urci effort-ul doar pentru turul acela, nu pentru toată conversația.

Istoricul append-only nu mai e o preferință de stil

Pe Fable 5.1, blocurile de raționament sunt legate de conversația exactă care le-a produs. Dacă modifici ceva dinaintea unui bloc — promptul de sistem, lista de unelte sau un mesaj anterior — cererea următoare întoarce 400 cu The block is bound to a different conversation, sau blocul e eliminat, dacă ai cerut explicit comportamentul acesta. Verificarea e aplicată pentru conturile create începând cu 31 august 2026, iar documentația anunță că modelele viitoare o vor aplica pentru toate conturile.

Pentru un agent, consecința practică se rezumă la o singură regulă: adaugă la istoric, nu rescrie. Turul de asistent se adaugă exact cum l-a returnat API-ul, cu tot cu blocurile de thinking. Turul de utilizator conține doar rezultatele uneltelor. Nimic anterior nu se atinge.

Tiparele care trebuie scoase din harness sunt cele care păreau inofensive: mementourile injectate și șterse la fiecare tur, rezumarea în loc a turelor vechi, schimbarea promptului de sistem la mijlocul sesiunii. Toate rup și cache-ul de prompt, deci le plăteai deja — doar că înainte plăteai doar în bani. Lista completă, cu tabelul „ce invalidează / ce păstrează" și cu procedura de verificare în trei pași, e în ghidul de migrare Fable 5 → Fable 5.1.

Mesajele de sistem pe un singur tur rezolvă trei probleme deodată

Aceasta este, pentru agenți, cea mai utilă adăugire din Fable 5.1. Un mesaj role: "system" cu clear_at: "next_user_message" are autoritate de prompt de sistem pentru turul curent și încetează să mai fie randat odată ce apare un mesaj de utilizator mai nou. Antetul beta este mid-conversation-system-clear-at-2026-08-21.

Ce îl face special: mesajul rămâne în messages și îl trimiți înapoi neschimbat, la fiecare cerere. Nimic anterior nu se modifică. Deci cache-ul se potrivește în continuare, blocurile de raționament rămân valide, iar un mesaj deja curățat nu costă niciun token de intrare.

Regula de folosire e strictă și merită respectată litera: adaugă o copie nouă la fiecare tur și lasă copiile anterioare exact unde sunt, octet cu octet. Ștergerea sau rescrierea lor este o editare a turelor anterioare — adică fix lucrul pe care încerci să îl eviți.

Trei utilizări care se plătesc imediat: nota de grupare a apelurilor de unelte (secțiunea următoare), mementoul de stare după un pas lung și avertismentul despre ce vede efectiv utilizatorul. Ultimul arată așa:

Doar tu vezi rezultatul acelei comenzi — terminalul utilizatorului afișează
cel mult câteva rânduri din el. Dacă utilizatorul are nevoie să citească ceva
din el, pune-o în răspunsul tău.

Nota aceasta rezolvă o problemă subtilă: dacă produsul tău ascunde sau restrânge ieșirea uneltelor, modelul poate rula comenzi ca „să îi arate" utilizatorului lucruri pe care interfața ta nu le afișează niciodată.

Grupează explicit apelurile de unelte

Fable 5.1 emite de obicei apeluri paralele corect: când o cerere numește mai multe lucruri de adus, le aduce în paralel. Excepția sunt buclele de cod și de computer use — agenți de cod proprii, harness-uri de tip bash-plus-editor — unde acțiunile următoare sunt implicate de sarcină, nu cerute explicit. Acolo poate emite un apel pe tur. Calitatea răspunsului nu scade, dar fiecare tur în plus costă tokeni, un dus-întors de rețea și timp real.

Rezolvarea e o singură propoziție, adăugată la finalul cererii curente:

Enumeră mai întâi, pentru tine, ce îți trebuie mai departe; apoi cere,
în acest singur răspuns, fiecare element care nu depinde de rezultatul altuia.

Locul corect al acestei propoziții este imediat după mesajul de utilizator care poartă rezultatele uneltelor, ca mesaj de sistem valabil un singur tur. Fără beta-ul respectiv, o pui într-un bloc de text după blocurile tool_result, în același mesaj de utilizator.

Agentul care amuțește

Comportamentul implicit al lui Fable 5.1 este să scrie mai puțin text vizibil pentru utilizator în timpul tururilor lungi cu unelte. Efectul, într-un produs: agentul tace minute în șir, apoi livrează un mesaj final care acoperă doar ultimul pas.

Ordinea corectă a verificărilor este următoarea, și nu invers.

Întâi, verifică dacă primești deloc actualizările. Notele scurte dintre apelurile de unelte vin ca blocuri de thinking, iar sub valoarea implicită "omitted" a lui thinking.display ele sunt goale. Cu display: "updates", sub antetul beta thinking-display-updates-2026-08-18, le primești 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 afișabilă. Se poate întâmpla, altfel spus, ca modelul să scrie actualizări pe care clientul tău nu le cere.

Apoi, curăță promptul. Modelele mai vechi erau prea vorbărețe în timpul lucrului, așa că multe prompturi de sistem au căpătat linii de tipul „păstrează toate concluziile pentru răspunsul final". Scoate-le înainte să adaugi ceva.

Abia apoi cere explicit narațiune, dacă tot mai ai nevoie de ea — de exemplu în lucru împreună cu un om, la programare în pereche.

Termină treaba

Pe sarcini asincrone lungi, Fable 5.1 poate să descrie ce ar face în continuare în loc să facă („În continuare, voi...") sau să se oprească pentru a cere permisiunea la un pas pe care cererea inițială îl acoperea deja („Să aplic?"). Utilizatorul trebuie atunci să răspundă „continuă" — potrivit la programare în pereche, dar risipă curată într-o rulare autonomă.

Reglajul are două părți, iar documentația recomandă aplicarea amândurora; dacă trebuie să scurtezi promptul, prima parte păstrează cea mai mare parte din efect. Prima îi spune modelului să nu întrebe despre munca deja cerută și să execute pașii pe care singur i-a anunțat, iar propoziția de deschidere — cea care îi spune că utilizatorul nu se uită — cară cea mai mare parte din efect. A doua definește cererea utilizatorului drept limita livrabilului.

Legat de a doua: pe funcționalități deschise, Fable 5.1 livrează ce s-a cerut și uneori mai mult — repară cod din jur, extinde comportamente pe care sarcina nu le pomenea, comite mai multe fișiere de test decât justifică modificarea. Răspunde bine la instrucțiuni explicite despre ce să lase deoparte.

Unde se duc, de fapt, banii

Într-o sesiune agentică lungă, costul dominant nu e textul nou, ci prefixul recitit la fiecare cerere: promptul de sistem, definițiile uneltelor, contextul proiectului, turele anterioare. Aici Fable 5.1 schimbă aritmetica.

Un calcul ilustrativ, cu prețurile publicate. Presupune un prefix stabil de 60.000 de tokeni și o sesiune care face 200 de cereri:

Cifrele de mai sus sunt aritmetică pe tarifele oficiale, nu o măsurătoare — sesiunea ta va arăta altfel. Concluzia rămâne însă: prompt caching-ul nu e o optimizare opțională pe un agent de lungă durată, e diferența dintre 120 $ și 3 $ pe partea de prefix. Iar pragul minim ca un prompt să fie eligibil pentru cache rămâne 512 de tokeni.

Consecința cea mai puțin evidentă privește compactarea. Pe modelele anterioare, compactarea timpurie a conversației era o mișcare bună de cost: tăiai context ca să nu îl mai plătești la fiecare cerere. Pe Fable 5.1, contextul păstrat e ieftin de recitit, iar compactarea costă inteligență — modelul pierde detalii pe care le-ar fi folosit. Documentația spune direct că momentul optim de compactare s-ar putea să fie mai târziu decât obișnuiai. Merită re-testat, nu presupus.

Două economii mai mici, dar reale:

• Rescrierea de fișiere întregi. Dacă modelul rescrie un fișier pentru o modificare de trei rânduri, rezultatul e de obicei același, dar plătești tokeni de ieșire — cei mai scumpi din tot lanțul, la 50 $ per milion. O instrucțiune care cere editări țintite îl aduce înapoi la comportamentul lui Fable 5 pentru modificări mici și medii.
• Subagenții. Dacă agentul tău principal deleagă muncă unor subagenți, nu-l obliga să aștepte după fiecare. Pe sarcini de cod, lăsarea agentului principal să continue în timp ce subagenții rulează scade timpul mediu până la finalizare, la calitate, consum de tokeni și cost similare. Practic: unealta care pornește un subagent returnează imediat, rezultatul ajunge înapoi într-un mesaj user ulterior, iar agentul principal are o unealtă separată prin care poate alege să aștepte.

Toate deciziile astea — ce ții în context, când compactezi, ce delegi — sunt aceeași disciplină sub nume diferite, iar ea se învață mai bine sistematic decât din tatonări: Context Engineering și Memorie pentru Agenți AI.

Două detalii operaționale care economisesc tichete

Vederea. Fable 5.1 lucrează cel mai bine pe intrări vizuale complexe — grafice dense, tabele în PDF — când poate să analizeze, să decupeze și să verifice iterativ. Ideal, îi dai un container cu imaginile brute și cu biblioteci de procesare. Dacă e prea mult, o simplă unealtă de decupare, care întoarce o regiune aleasă din imagine, mărită, aduce cea mai mare parte din câștig.

Refuzurile fals-pozitive. Clasificatoarele de siguranță produc mai puține fals-pozitive decât la lansarea lui Fable 5, iar găsirea de vulnerabilități în cod sursă este permisă. Trei situații le fac totuși mai probabile: formulările de tip „compilează programul ăsta fără erori?" (întreabă în schimb „există erori în programul ăsta?"), limbajele de programare puțin cunoscute (dă-i documentația limbajului) și datele codificate base64 ajunse în context din ieșirea uneltelor (scoate-le). Un refuz vine cu HTTP 200 și stop_reason: "refusal" — deci codul tău trebuie să verifice stop_reason înainte de a citi conținutul.

Întrebări frecvente

Î: Ce nivel de effort folosesc pentru un agent care rulează ore? R: Pornește de la valoarea implicită high și măsoară. Pe Fable 5.1, medium obține rezultate cam la nivelul lui Fable 5 la cost mai mic, deci coborârea e adesea justificată. Mai bine decât un singur nivel pentru toată sesiunea: high pentru planificare și pașii grei, medium sau low pentru pașii de rutină, cu schimbare pe parcurs.

Î: De ce agentul meu face un singur apel de unealtă pe tur? R: E un comportament cunoscut al lui Fable 5.1 în buclele de cod și de computer use, unde acțiunile următoare sunt implicite. Nu afectează calitatea răspunsului, dar costă tururi. Se rezolvă cu o propoziție care îi cere să enumere întâi ce îi trebuie și să ceară, în același răspuns, tot ce nu depinde de altceva.

Î: De ce nu văd niciun text între apelurile de unelte? R: Notele de progres vin ca blocuri de thinking, iar valoarea implicită a lui thinking.display este "omitted", ceea ce le întoarce goale. Pornește display: "updates" sub antetul beta corespunzător și afișează fiecare bloc de thinking cu text nevid ca linie de stare.

Î: Mai merită să compactez devreme conversația, ca să economisesc? R: Nu automat. Citirile din cache costă acum 0,25 $ per milion de tokeni, adică un sfert față de Fable 5, deci contextul păstrat e ieftin de recitit, în timp ce compactarea costă inteligență. Documentația recomandă să experimentezi cu momente de compactare mai târzii.

Î: Cum trimit un memento care se aplică doar la turul curent? R: Cu un mesaj role: "system" care are clear_at: "next_user_message", sub antetul beta pentru mesaje de sistem valabile un singur tur. Adaugi o copie nouă la fiecare tur și le lași pe cele vechi neatinse: API-ul le curăță, modelul o vede doar pe cea nouă, iar cele curățate nu costă tokeni de intrare.

Concluzie

Pe Fable 5.1, calitatea unui agent de lungă durată se decide în patru locuri: nivelul de effort, reglat pe pas și nu pe sesiune; istoricul, care se adaugă și nu se rescrie; apelurile de unelte, grupate explicit acolo unde modelul nu le grupează singur; și cache-ul, care acum face diferența între o factură de zeci de dolari și una de câțiva.

Restul e măsurare. Fiecare reglaj din articolul acesta e o ipoteză despre bucla ta, nu un adevăr universal — iar singurul mod de a ști dacă a ajutat este un set de evaluări rulat înainte și după, pe sarcini reale. Cum se construiește, se punctează și se automatizează un asemenea set e tema cursului AI Evals pentru LLM-uri în Producție. Dacă încă evaluezi dacă modelul acesta e cel potrivit pentru tine, comparația de specificații și de preț e în prezentarea lui Claude Fable 5.1.

Articol tehnic, redactat la 1 septembrie 2026, pe baza documentației oficiale Anthropic disponibile la această dată: ghidul de prompting pentru Fable 5.1, noutățile din Fable 5.1 și prezentarea modelului. Calculele de cost sunt aritmetică pe tarifele publicate, nu măsurători; funcțiile marcate „beta" se pot modifica.