Claude Opus 5 în API: thinking implicit și breaking changes

Dacă lansarea lui Claude Opus 5 te interesează ca developer, cifrele de benchmark sunt partea mai puțin importantă. Partea importantă e că modelul se comportă altfel în API decât orice Opus de până acum: raționamentul (thinking) e pornit implicit, parametrul effort devine pârghia principală de control, iar o combinație de parametri perfect validă pe Opus 4.8 întoarce acum eroare 400. Acest ghid parcurge, punct cu punct, tot ce se schimbă la nivel de cod — din documentația oficială „What's new in Claude Opus 5", nu din impresii.

Contextul lansării — poziționare, benchmark-uri, siguranță — l-am acoperit în analiza dedicată Claude Opus 5, decizia de upgrade în Opus 5 vs Opus 4.8, iar alegerea față de vârful gamei în Opus 5 vs Fable 5 și Mythos 5. Aici rămânem strict la nivelul API: parametri, header-e, comportamente și ce trebuie să verifici în cod înainte de a muta traficul.

Notă: detaliile de mai jos reflectă documentația oficială Anthropic la data redactării (iulie 2026). API-urile evoluează — înainte de modificări în producție, confruntă totul cu pagina oficială „What's new in Claude Opus 5" din surse.

Fișa tehnică: context 1M, output 128k, aceleași tarife

Pe scurt, ce primești când schimbi identificatorul de model:

Două detalii merită subliniate, pentru că schimbă decizii de arhitectură. Primul: fereastra de 1 milion de tokeni este implicită, nu opțională — nu există o variantă de context mai mic, deci nu mai ai de ales între „modelul standard" și „modelul cu context extins". Documentația subliniază și consistența pe toată fereastra: instruction following, tool calling și raționament stabile inclusiv spre capătul contextului — exact zona în care generațiile anterioare de modele long-context degradau vizibil. Al doilea: outputul maxim de 128k tokeni face fezabile în API livrabile lungi dintr-o singură cerere (rapoarte, documente, refactorizări ample), cu mențiunea de mai jos despre relația dintre max_tokens și thinking.

Pe disponibilitate: modelul e live pe Claude API (claude-opus-5, pentru toți clienții), pe Amazon Bedrock (anthropic.claude-opus-5), pe Google Cloud (claude-opus-5) și în Microsoft Foundry. Opus 4.8 rămâne disponibil pe toate platformele, deci nu ești forțat la o migrare-fulger.

Thinking pornit implicit: ce se schimbă față de Opus 4.8

Cea mai vizibilă schimbare de comportament: pe Opus 4.8, o cerere fără câmpul thinking rula fără raționament extins — îl activai explicit cu thinking: {"type": "adaptive"}. Pe Claude Opus 5, aceeași cerere rulează cu thinking pornit: modelul decide singur când și cât să gândească la fiecare tură, iar profunzimea raționamentului o controlezi prin parametrul effort. Valoarea thinking: {"type": "adaptive"} rămâne validă și este echivalentă cu comportamentul implicit, deci codul care o trimite deja nu are nimic de schimbat.

Dacă ideea de raționament adaptiv îți sună cunoscută, ai dreptate: e aceeași direcție introdusă pe clasa Mythos, pe care am analizat-o în ghidul despre adaptive thinking pe Fable 5 și Mythos 5. Diferența importantă: pe Fable 5 raționamentul nu poate fi oprit deloc, în timp ce pe Opus 5 dezactivarea rămâne posibilă — dar condiționat, cum vezi imediat.

max_tokens devine bugetul pentru gândire + răspuns

Consecința practică imediată: max_tokens este o limită dură pe outputul total — tokenii de thinking plus textul de răspuns. Un workload care pe Opus 4.8 rula fără thinking și mergea lejer cu max_tokens: 2000 poate acum să-și consume bugetul pe raționament înainte să termine răspunsul. Documentația e explicită: revizuiește max_tokens pentru toate cererile care pe 4.8 rulau fără thinking. Regula practică din exemplele oficiale: la effort ridicat, alocă generos (exemplul din documentație folosește max_tokens: 64000 la effort max) și folosește streaming pentru cererile lungi.

Breaking change: thinking dezactivat + effort ridicat = eroare 400

Aici e schimbarea care poate rupe integrări existente, așa că merită formulată exact:

• Pe Opus 5, thinking: {"type": "disabled"} este acceptat doar când effort-ul este high sau mai jos.
• thinking: {"type": "disabled"} combinat cu effort xhigh sau max întoarce eroare 400, la fiecare cerere.
• Este comportament general disponibil (nu beta) de la Opus 5 înainte — și un breaking change față de Opus 4.8, unde dezactivarea thinking-ului era independentă de nivelul de effort.

Dacă azi rulezi cu thinking dezactivat la effort ridicat, ai două ieșiri oficiale: păstrezi thinking-ul dezactivat și cobori effort-ul la high sau mai jos, ori păstrezi effort-ul și ștergi câmpul thinking din cerere. Nu există a treia variantă.

Mai e o nuanță documentată care contează pentru fiabilitate: cu thinking-ul dezactivat, Opus 5 poate ocazional să scrie un apel de unealtă în textul răspunsului în loc să emită un bloc tool_use, sau să lase tag-uri XML interne în răspunsul vizibil. Recomandarea oficială este să ții thinking-ul pornit și să controlezi costul prin niveluri de effort mai mici; dacă integrarea ta chiar trebuie să ruleze fără thinking, documentația de prompting pentru Opus 5 are mitigări dedicate. Pentru un parser de tool calls din producție, asta nu e un detaliu — e un caz de eroare pe care trebuie să-l tratezi.

effort: pârghia principală, de la low la max

Odată ce thinking-ul e implicit, effort devine parametrul central al integrării. Scara completă pe Opus 5: low, medium, high (implicit), xhigh și max — cu max ca treaptă de vârf pentru cel mai profund raționament. Documentația face o afirmație de reținut: Opus 5 convertește effort suplimentar în rezultate mai bune mai fiabil decât orice model Opus anterior, deci nivelul ales cântărește mai mult ca înainte. La celălalt capăt, low și medium sunt evidențiate explicit pentru eficiență: calitate solidă la o fracțiune din tokenii și latența nivelurilor superioare.

O cerere cu effort la maximum arată așa:

client = anthropic.Anthropic()

with client.messages.stream(
    model="claude-opus-5",
    max_tokens=64000,
    output_config={"effort": "max"},
    messages=[{"role": "user", "content": "..."}],
) as stream:
    response = stream.get_final_message()

Observă trei lucruri: nu există câmp thinking (implicitul e cel corect), max_tokens e mare ca să lase loc de gândire și acțiune, iar cererea e stream-ată — la bugete de 64k tokeni, cererile non-streaming pot lovi limita de timp.

Strategia sănătoasă, conform documentației: pornește de la implicitul high și ajustează pe baza evals-urilor, nu a impresiilor — coboară acolo unde calitatea se menține (economisești tokeni și latență), urcă la xhigh/max pentru sarcinile cele mai grele, cu max_tokens dimensionat corespunzător. Cum construiești rapid un set de evaluare care să-ți spună pe ce nivel de effort se stabilizează calitatea pe sarcinile tale predăm în cursul de AI evals pentru LLM-uri în producție.

Noutăți de API: unelte schimbate din mers, fallback „default", cache de la 512 tokeni

Schimbarea uneltelor în mijlocul conversației (beta)

Până acum, lista de unelte era practic fixă pe durata unei sesiuni: orice modificare însemna re-trimiterea întregii liste și, de regulă, pierderea cache-ului. Pe Opus 5 poți adăuga sau elimina unelte între turele unei conversații, păstrând prompt cache-ul — cu header-ul beta mid-conversation-tool-changes-2026-07-01. Pentru agenți cu faze distincte de lucru (explorare → editare → verificare, fiecare cu alt set de unelte), asta elimină un compromis arhitectural întreg: nu mai încarci toate uneltele de la început „ca să fie", ci le montezi când devin relevante.

Modul default pentru fallbacks (beta)

Parametrul fallbacks — mecanismul prin care cererile refuzate pot fi redirecționate către alt model — primește un mod nou: "default", care aplică modelele de fallback recomandate de Anthropic, pe categorii de refuz, în locul unei liste de modele pe care o întreții singur. Practic: în loc să ghicești tu ce model e potrivit ca destinație pentru fiecare tip de cerere semnalată, delegi maparea către recomandările oficiale. Întregul parametru rămâne beta; header-ul actual este server-side-fallback-2026-07-01, care acceptă și modul "default", și liste explicite (header-ul mai vechi, server-side-fallback-2026-06-01, acceptă doar liste explicite). Mecanica refuzurilor și a fallback-ului am detaliat-o în ghidul dedicat pentru developeri.

Pragul de caching, înjumătățit

Detaliu mic, bani reali: lungimea minimă a unui prompt care poate fi pus în cache scade pe Opus 5 la 512 tokeni, de la 1.024 pe Opus 4.8. Prompturile de sistem compacte — care până acum erau pur și simplu prea scurte ca să creeze o intrare de cache — încep să se cacheze fără nicio modificare de cod. Dacă ai microservicii cu system prompt-uri de 600–900 de tokeni apelate intens, diferența se vede direct în factura de input.

Fast mode: doar pe Claude API

Fast mode (research preview) există și pentru Opus 5 — la 10 $ input / 50 $ output per milion de tokeni — dar doar pe Claude API: nu este disponibil momentan pe Amazon Bedrock, Google Cloud sau Microsoft Foundry. Dacă rulezi prin cloud provideri și contezi pe fast mode pentru fluxurile interactive, asta îți afectează planul de rutare.

Modelul se comportă altfel: prompturile care trebuie rescrise

Documentația dedică o secțiune diferențelor pe care le observi fără să schimbi o linie de cod, iar una dintre ele cere acțiune concretă în prompturi:

• Răspunsurile implicite sunt mai lungi — atât cele către utilizator, cât și livrabilele scrise. Dacă produsul tău are constrângeri stricte de lungime, impune-le explicit în prompt.
• În sesiuni agentice, modelul își narează progresul mai des — bun pentru UX-uri cu vizibilitate, de calibrat acolo unde vrei liniște.
• În framework-uri multi-agent, deleagă mai ușor către subagenți — de luat în calcul la bugetare, pentru că subagenții consumă tokeni.
• Își verifică singur munca, nespus. Aici e acțiunea concretă: instrucțiunile de verificare moștenite din prompturile pentru modelele anterioare — „include un pas final de verificare", „folosește un subagent care să verifice" — trebuie scoase, pentru că pe Opus 5 produc over-verification: muncă dublă, tokeni în plus, latență în plus.

E un tipar pe care îl repetăm la fiecare generație: prompturile sunt calibrate pe defectele modelului vechi, iar pe modelul nou aceleași instrucțiuni devin frecări. Migrarea de model fără igienizarea prompturilor e o migrare pe jumătate. Genul acesta de lucru — prompturi, unelte, verificare, totul pe repo-uri reale — e exact materia cursului de Claude Code și coding agentic.

Checklist de migrare, la nivel de cod

Planul de migrare complet (evals, trafic gradual, bugete) l-am detaliat în Opus 5 vs Opus 4.8; aici, strict lista de verificări pe cod, în ordinea în care rup lucruri:

1. Caută combinația fatală: thinking: {"type": "disabled"} împreună cu effort xhigh/max → acum e 400. Decide per integrare: scoți thinking sau cobori effort-ul.
2. Revizuiește max_tokens pe toate cererile care pe 4.8 rulau fără thinking — acum bugetul acoperă gândire + răspuns.
3. Schimbă identificatorul în claude-opus-5 (anthropic.claude-opus-5 pe Bedrock) — ideal dintr-o variabilă de configurare, nu hardcodat.
4. Șterge instrucțiunile de verificare din prompturile agentice moștenite — altfel plătești over-verification.
5. Activează streaming pe cererile cu max_tokens mare — la 64k tokeni, non-streaming poate depăși limita de timp.
6. Dacă rulezi cu thinking dezactivat, tratează în parser cazul tool call scris în text și tag-urile XML scăpate în răspuns.
7. Oportunități, nu doar riscuri: prompturile de sistem între 512 și 1.024 de tokeni încep să se cacheze singure; header-ul mid-conversation-tool-changes-2026-07-01 îți poate simplifica arhitectura de unelte; modul "default" la fallbacks îți poate elimina o listă de întreținut manual.

De la primul apel API la o arhitectură în care schimbarea de model e o modificare de configurare cu evals la fiecare release — drumul complet îl predăm în cursul de construire a aplicațiilor AI cu Python.

Întrebări frecvente

Î: Trebuie să setez ceva ca să activez thinking pe Claude Opus 5? Nu. Thinking este pornit implicit: modelul decide singur când și cât raționează, iar profunzimea o controlezi prin parametrul effort. thinking: {"type": "adaptive"} rămâne valid și este echivalent cu implicitul, deci codul existent care îl trimite nu necesită modificări.

Î: Ce combinație de parametri întoarce eroare 400 pe Opus 5? thinking: {"type": "disabled"} împreună cu effort xhigh sau max. Dezactivarea thinking-ului este acceptată doar la effort high sau mai jos — un breaking change față de Opus 4.8, unde cele două setări erau independente. Soluții: scoți câmpul thinking sau cobori effort-ul.

Î: Ce niveluri de effort are Claude Opus 5 și care e implicitul? Scara completă: low, medium, high, xhigh și max, cu high ca implicit. Recomandarea oficială: pornește de la high și ajustează pe baza evaluărilor proprii — în jos unde calitatea se menține, în sus (cu max_tokens generos și streaming) pentru sarcinile cele mai grele.

Î: Ce fereastră de context și ce output maxim are Opus 5 în API? 1 milion de tokeni fereastră de context — valoare implicită și maximă, fără variantă mai mică — și 128.000 de tokeni output maxim. Atenție: max_tokens limitează outputul total, adică tokenii de thinking plus textul de răspuns.

Î: Ce se schimbă la prompt caching pe Opus 5? Pragul minim de caching scade la 512 tokeni, de la 1.024 pe Opus 4.8. Prompturile care înainte erau prea scurte pentru cache încep să creeze intrări de cache fără nicio modificare de cod — relevant mai ales pentru system prompt-uri compacte apelate frecvent.

Î: Fast mode pentru Opus 5 e disponibil pe Bedrock sau Google Cloud? Nu — fast mode (research preview, 10 $ / 50 $ per milion de tokeni) este disponibil pentru Opus 5 doar pe Claude API. Pe Amazon Bedrock, Google Cloud și Microsoft Foundry rulează doar modul standard, la 5 $ / 25 $.

Concluzie

Claude Opus 5 nu îți cere să înveți un API nou, dar îți cere să recitești presupunerile codului existent: thinking-ul e acum implicit, effort e pârghia care contează, max_tokens acoperă și gândirea, iar o combinație validă ieri întoarce 400 azi. Vestea bună e că aproape toate schimbările au și o față de oportunitate — cache de la 512 tokeni, unelte schimbate din mers fără pierderea cache-ului, fallback-uri gestionate de platformă, output de 128k. Echipele care tratează migrarea ca pe o trecere prin checklist — nu ca pe un simplu find-and-replace pe numele modelului — ies din ea cu integrări mai ieftine și mai fiabile decât înainte. Iar disciplina asta, o dată construită, se amortizează la fiecare lansare care urmează.

Surse

• Documentația oficială Claude, „What's new in Claude Opus 5": https://platform.claude.com/docs/en/about-claude/models/whats-new-opus-5
• Anthropic, „Claude Opus 5" (anunț oficial, 24 iulie 2026): https://www.anthropic.com/news/claude-opus-5
• Documentația oficială Claude (modele și prețuri): https://platform.claude.com/docs/en/about-claude/models/overview