Anthropic leagă prețurile Claude Opus 5.5 de sesiuni de codare mai lungi

Anthropic a raportat pe 24 septembrie 2026 că sesiunile Claude Code au devenit mai lungi și cu mai mult context în ultimele șase luni, detaliind într-o postare pe blogul Claude modul în care prețurile și mecanismele de cache ale Claude Opus 5.5 răspund la această schimbare. Compania estimează că costul de funcționare al Opus 5.5 este cu aproximativ 40 % mai mic decât al Opus 5 pentru o sarcină tipică facturată pe token.

Șase luni de date de utilizare Claude Code

Postarea, scrisă de Michael Segner, se bazează pe date agregate de utilizare care acoperă perioada martie‑septembrie 2026. Numărul de prompturi per sesiune a rămas constant, potrivit postării, în timp ce munca din fiecare prompt a crescut: modelul lucrează acum de 3,3 ori mai mult pe fiecare prompt și efectuează cu peste 40 % mai multe apeluri de model pe fiecare, iar întreruperile au scăzut cu 68 %. Dezvoltatorii conectează acum un server de instrumente sau folosesc o abilitate de aproximativ două ori mai des și lipesc text în prompturi cu o treime mai rar.

Cantitatea de context din fiecare cerere a crescut de 2,6 ori în această perioadă, iar raportul dintre token‑urile de intrare și cele de ieșire s-a modificat de la 189:1 la 324:1. Anthropic interpretează aceste cifre ca indicând că dezvoltatorii folosesc un model care lucrează mai mult timp și este mai bine informat pentru sarcini mai mari și mai deschise, și afirmă că economiile oferite de Opus 5.5 sunt maxime pentru acele sesiuni mai lungi și cu context ridicat, când utilizarea este facturată pe token.

Analiza se bazează pe lansarea Claude Opus 5.5 de către Anthropic, care a venit cu prețuri mai mici decât Opus 5. În timp ce lansarea a stabilit prețurile, postarea din 24 septembrie și o analiză însoțitoare publicată pe 22 septembrie 2026 de Addy Osmani examinează ce înseamnă aceste prețuri pentru sarcini reale Claude Code.

Prețurile token‑urilor și reducerea citirii din cache

Pentru utilizarea facturată pe token, Anthropic a redus prețurile token‑urilor de intrare și ieșire cu 20 % și a scăzut prețul citirii unui token în cache cu 60 %. Compania afirmă că reducerea citirii din cache are cel mai mare impact, deoarece citirile din cache reprezintă cea mai mare parte a costului lucrărilor agentice și de codare, și precizează că, la data publicării, un token în cache pe Opus 5.5 costă o cincime din costul modelelor concurente și le depășește în performanță.

Analiza însoțitoare a lui Osmani enumeră prețurile de listă ale API‑ului Opus 5.5 la 4 $ pentru un milion de token‑uri de intrare, 20 $ pentru un milion de token‑uri de ieșire și 0,20 $ pentru un milion de citiri din cache. La aceste prețuri, o citire din cache costă 5 % din prețul unui token de intrare proaspăt, în timp ce scrierea în cache costă de 1,25 ori prețul de intrare pentru un cache de cinci minute și de două ori prețul de intrare pentru un cache de o oră, fiecare acces reușit la cache reînnoind durata gratuit. În planurile Pro, Max sau Team, prețul mai mic al Opus 5.5 este transmis limitelor planului, astfel că acestea merg cu aproximativ 25 % mai departe decât pe Opus 5; reducerea suplimentară pentru citirile din cache se aplică doar la prețurile API.

Modificări ale cadrului de execuție care protejează cache‑ul

Chiar și pe măsură ce contextul per cerere a ajuns la aproximativ 2,6 ori nivelul anterior, ponderea intrărilor care nu sunt găsite în cache a scăzut cu peste 50 % în perioada de șase luni, potrivit postării. Postarea atribuie acest lucru unei serii de modificări Claude Code care reduc întreruperile accidentale ale cache‑ului, acoperind perturbări mici, cum ar fi reîmprospătarea autentificării, și altele mai mari, cum ar fi adăugarea de instrucțiuni în mijlocul conversației sau încărcarea instrumentelor la cerere. Pe Opus 5.5 și Fable 5.1, dezvoltatorii pot, de asemenea, să schimbe nivelurile de efort în timpul sesiunii fără a reseta cache‑ul.

Documentația oficială privind stocarea în cache a prompturilor specifică că comportamentul nivelului de efort se aplică cu o cheie API sau cu un abonament Claude și nu pe Amazon Bedrock, pe Platforma Agent a Google Cloud sau pe un gateway de aplicații Claude, nici când indicatorul CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS este activat sau o organizație are o configurație HIPAA.

Dezvoltatorii cu chei API și furnizori de cloud pot acum să seteze o durată de viață a cache‑ului de o oră, pe care abonații o aveau deja. Documentația arată valorile implicite: o oră pentru conversația principală pe un abonament Claude în cadrul utilizării planului și cinci minute pentru creditele de utilizare, cheile API sau furnizorii de cloud. Setarea promptCacheTtl sau variabila de mediu CLAUDE_CODE_PROMPT_CACHE_TTL selectează durata mai lungă, iar ambele controale necesită Claude Code v2.1.242 sau o versiune ulterioară.

Subagenții bifurcați încep acum din cache‑ul sesiunii părinte, în loc să plătească pentru reprocesarea aceluiași context. Documentația explică că o bifurcare preia promptul de sistem al părintelui, setul de instrumente și istoricul complet al conversației, astfel încât cererea inițială citește direct din cache‑ul părintelui.

Mai puține runde pe sarcină

Anthropic raportează că Opus 5.5 poate finaliza o sarcină în mai puține runde decât alte modele. Conform postării, Zeta Labs a înregistrat mai puține runde și apeluri de instrumente pe sarcină decât pe Opus 5, la aproape jumătate din cost, și a finalizat de două ori mai multe dintre cele mai dificile sarcini ale sale.

Postarea avertizează că acest tipar nu se va menține pentru fiecare sarcină, citând analiza lui Osmani: „Într-o sarcină bine delimitată, ambele modele finalizează sarcina în aproximativ același număr de runde, iar reducerea de preț este tot ce obții. Diferența ar trebui să fie cea mai mare la sarcini deschise, unde un model poate petrece multe runde pe o idee greșită.”

Anthropic raportează, de asemenea, că Opus 5.5 generează rezultate cu peste 30 % mai repede decât Opus 5. Câștigul nu modifică utilizarea token‑urilor și rata de hit a cache‑ului; postarea observă că scurtează timpul de așteptare la execuții lungi, deoarece Claude petrece mai mult timp lucrând fără intervenție.

Articolul se încheie cu practici pentru protejarea lecturilor din cache: rulați /usage în Claude Code pentru a vedea ce proporție a unei sesiuni este servită din cache, alegeți modelul la începutul sesiunii în loc să schimbați pe parcurs, rulați compactarea înainte de a vă îndepărta de lucru, nu după, și, pe o cheie API sau la un furnizor de cloud, activați durata de viață a cache-ului de o oră pentru sesiuni lungi.