# Claude Haiku 5.5 în producție: când modelul ieftin e suficient Anthropic a lansat Claude Haiku 5.5 pe 7 octombrie 2026, iar linia de preț e genul pe care o citești de două ori: 0,10 dolari pe milionul de tokeni de intrare și 0,50 dolari pe milionul de ieșire. Haiku 4.5 costa 1 și 5 dolari. Pe hârtie e o ieftinire de zece ori, plus o fereastră de context care a crescut de la 200K la 1M de tokeni și o limită de output dublată, la 128K. Pe hârtie. În practică reducerea e mai mică, există un prag de preț la jumătatea ferestrei de 1M, iar un flux de clasificare care mergea fără probleme pe Haiku 4.5 poate începe să întoarcă erori 400 din ziua în care schimbi ID-ul modelului. Am scris articolul pentru echipele care rulează volume mari de AI (triere, extragere de date, rutare, sub-agenți) și vor să știe unde modelul ieftin e suficient și unde nu. Toate prețurile și comportamentul API de mai jos vin din documentația oficială Anthropic de la lansare. Unde facem presupuneri, o spunem. ## Cifrele care contează | | Haiku 5.5 | Haiku 4.5 | Sonnet 5.5 | Opus 5.5 | |---|---|---|---|---| | Context / output maxim | 1M / 128K | 200K / 64K | 1M / 128K | 1M / 128K | | Intrare / ieșire ($ per MTok) | **0,10 / 0,50** (prompt ≤ 100K) | 1 / 5 | 2 / 10 | 4 / 20 | | Intrare / ieșire peste 100K de prompt | 0,50 / 2,50 | preț fix | preț fix | preț fix | | Citire din cache ($ per MTok) | 0,01 | 0,10 | 0,10 | 0,20 | | Thinking | adaptiv, pornit implicit | buget manual, oprit implicit | adaptiv, pornit implicit | mereu pornit | | Effort implicit | medium | n/a | high | medium | | `temperature` / `top_p` / `top_k` | doar valorile implicite | permise | doar valorile implicite | eliminate | | Prefill de asistent | 400 | permis | 400 | 400 | Modelul e disponibil în Claude API ca `claude-haiku-5-5`, pe Amazon Bedrock ca `anthropic.claude-haiku-5-5`, iar pe Google Cloud, Microsoft Foundry și Claude Platform on AWS sub ID-ul simplu. Citirile din cache costă 0,1× din prețul de intrare, scrierile în cache pe cinci minute 1,25×, iar cele pe o oră 2×, aceiași multiplicatori ca la restul familiei. ## De ce „de zece ori” înseamnă de fapt 7,7 Primul lucru pe care ți-l spune ghidul de migrare, după câteva paragrafe, e că Haiku 5.5 folosește un tokenizer nou și **același text se numără în aproximativ 30% mai mulți tokeni** decât pe Haiku 4.5. Prețul pe token a scăzut de zece ori, dar acum plătești 1,3 tokeni acolo unde înainte plăteai unul. Zece împărțit la 1,3 dă cam 7,7. E în continuare o reducere foarte mare, dar asta e cifra pe care o pui în buget, nu 10×. Al doilea lucru care mișcă factura e thinking-ul. Haiku 4.5 raționa doar când i-o cereai, cu un buget manual de tokeni. Haiku 5.5 rulează thinking adaptiv implicit, la effort `medium`, pe orice cerere care nu spune altceva. Tokenii de thinking se facturează ca tokeni de ieșire. Pe un prompt de clasificare care întorcea un singur cuvânt, s-ar putea să plătești acum câteva sute de tokeni de raționament înaintea acelui cuvânt. Soluția e ieftină: pui `output_config.effort` pe `low` pe fluxurile simple, unde modelul gândește mai puțin și poate sări complet peste thinking la inputurile ușoare. Dar trebuie făcut intenționat, pentru că valoarea implicită n-o face pentru tine. ## Pragul de preț de la 100K tokeni Ăsta e detaliul pe care am vrea să-l vadă fiecare echipă înainte să proiecteze ceva în jurul contextului de 1M. Haiku 5.5 are **două grile de preț, alese după lungimea promptului**. Până la 100K tokeni de prompt plătești 0,10 / 0,50 dolari. Peste 100K plătești 0,50 / 2,50, de cinci ori mai mult, iar documentația o descrie ca tarif pentru toată cererea, nu doar pentru tokenii de peste prag.

Un prompt de 99K tokeni costă cam un cent. Unul de 101K costă cam cinci. Pentru o singură cerere nu contează. Pentru un pipeline care trimite un milion pe lună, e diferența dintre 10.000 și 50.000 de dolari, doar la intrare. N-am văzut pragul explicat în detaliu pentru prompturi care sunt în mare parte citiri din cache, așa că tratează partea din cache ca intrând în cei 100K până când factura îți arată altceva. Ce înseamnă în practică: **fereastra de 1M e reală, dar e prețuită pentru folosire ocazională**. Pe un flux de volum mare, proiectează-l să rămână sub 100K. Retrieval care aduce cele cinci fragmente relevante în loc de tot manualul, istoric de conversație compactat, rezultate de tool-uri tăiate înainte să ajungă înapoi la model. Dacă un flux chiar are nevoie de 300K tokeni de context la fiecare apel, ca preț nu mai e un flux de Haiku, iar Sonnet 5.5 la 2 dolari fix poate ieși aproape. ## La ce e bun Haiku 5.5 Anthropic îl poziționează pentru „volume mari, sensibile la latență, cum ar fi clasificarea, rutarea, extragerea de date și sarcinile de sub-agent” și spune că e substanțial mai bun decât Haiku 4.5 la urmat instrucțiuni și la rulat ca sub-agent. Din proiectele pe care le facem pentru clienți, astea sunt fluxurile pe care l-am încerca primele: - **Trierea tichetelor și emailurilor.** Categorie, prioritate, limbă, dacă trebuie să-l vadă un om. Input scurt, răspuns structurat, milioane de apeluri. - **Extragere într-o schemă.** Facturi, CV-uri, contracte, formulare. Cu structured outputs modelul nu poate întoarce JSON invalid, iar aici asta contează mai mult decât inteligența brută. - **Rutare în fața unui model mai mare.** Haiku decide dacă o întrebare e un răspuns din FAQ, o căutare în baza de date sau ceva ce are nevoie de Sonnet sau Opus. - **Sub-agenți care citesc mult.** Într-un agent care trebuie să parcurgă cincizeci de fișiere sau o sută de pagini web, modelul scump nu trebuie să citească tot. Un worker Haiku citește și rezumă, modelul principal decide. - **Rezumarea logurilor și evenimentelor.** Să transformi o noapte de zgomot din CloudWatch în cinci rânduri pe care un om chiar le citește. - **Moderare și verificări de date personale** înainte ca textul să fie stocat sau trimis mai departe. Unde nu l-am folosi: sesiuni lungi de coding agentic, refactorizări mari, cercetare în mai mulți pași unde următoarea căutare depinde de judecata asupra celei anterioare, și orice loc unde un răspuns greșit e scump și greu de detectat. Pentru asta există Sonnet 5.5 și Opus 5.5, iar granița asta o discutăm în comparația [Opus 5.5 vs Fable 5.1](/ro/blog/claude-opus-5-5-vs-fable-5-1). ## O comparație reală de cost Să punem preț pe un flux concret: trierea tichetelor, la un milion de cereri pe lună. Fiecare cerere are un prefix de 3.000 de tokeni identic de fiecare dată (prompt de sistem, definițiile categoriilor, câteva exemple), deci servit din cache. Apoi 1.000 de tokeni de input nou, tichetul în sine, și 300 de tokeni de ieșire, inclusiv thinking-ul la effort `low`. Presupunem același număr de tokeni pentru modelele 5.5 și împărțim la 1,3 pentru Haiku 4.5, cum spune nota despre tokenizer. Scrierile în cache le lăsăm deoparte, pentru că la volumul ăsta prefixul rămâne cald.

Per cerere asta înseamnă 0,00028 dolari pe Haiku 5.5, 0,0053 pe Sonnet 5.5 și 0,0106 pe Opus 5.5. Pe profilul ăsta Haiku 5.5 e de aproximativ 19 ori mai ieftin decât Sonnet și de 38 de ori mai ieftin decât Opus. Uită-te unde se duc banii: pe Haiku 5.5 mai mult de jumătate din cost e ieșirea, deci setarea de effort mișcă factura mai mult decât lungimea promptului. Dublezi thinking-ul și aproape dublezi costul. O precauție înainte ca cineva să construiască o cascadă pe trei niveluri pe baza unui grafic ca ăsta. Chiar ghidul de costuri al Anthropic spune să măsori întâi varianta mai simplă: modelul mai puternic, la effort mai mic, pe aceleași sarcini. O cascadă are costuri ascunse. Cache-ul e separat pe fiecare model, deci fiecare escaladare plătește din nou prefixul. Un răspuns greșit al modelului ieftin, prins mai târziu, costă o reîncercare pe cel scump, iar unul care nu e prins costă mai mult decât orice token. Judecă costul pe sarcină terminată, nu pe cerere. La triere și extragere Haiku câștigă de obicei la ambele. Pentru orice are nevoie de judecată, verifică pe evaluările tale. ## Ce se strică dacă vii de pe Haiku 4.5 Prompturile existente pentru Haiku 4.5 ar trebui să meargă în mare parte, spune Anthropic. Codul din jurul lor s-ar putea să nu meargă. Astea sunt schimbările care întorc erori sau schimbă rezultatul fără să te anunțe: 1. **`budget_tokens` întoarce 400.** Thinking-ul e doar adaptiv. Înlocuiește bugetul cu `output_config.effort`. 2. **`temperature: 0` întoarce 400.** Parametrii de sampling trebuie lăsați la valorile implicite, iar `top_k` e respins complet. Fluxurile de clasificare setează aproape mereu `temperature: 0`, deci asta e prima care se strică. Constrânge ieșirea cu structured outputs sau cu un enum într-o schemă de tool. 3. **Prefill-ul de asistent întoarce 400**, chiar și cu thinking-ul oprit. Dacă îl foloseai ca să forțezi JSON, folosește structured outputs. Dacă îl foloseai ca să sari peste o introducere, spune asta în promptul de sistem. 4. **Thinking-ul intră în `max_tokens`.** Un `max_tokens: 50` dimensionat pentru o etichetă de un cuvânt poate fi consumat de thinking, iar tu primești `stop_reason: "max_tokens"` fără niciun text. Lasă loc, în jur de 1.000 de tokeni pe un flux scurt, sau coboară effort-ul. 5. **Primul bloc de conținut poate fi `thinking`.** Codul care citește `response.content[0].text` se strică. Citește blocurile după tip. 6. **Clasificatorii de siguranță pot refuza o cerere**, iar pe Haiku 5.5 nu există fallback pe server către alt model. Tratează `stop_reason: "refusal"` în codul tău. 7. **Blocurile de thinking sunt legate de cont și de conversație.** Trimite-le înapoi neschimbate împreună cu rezultatele tool-urilor și nu edita turele anterioare. Thinking-ul se mai poate opri cu `thinking: {type: "disabled"}`, dar doar la effort `low`, `medium` sau `high`, iar documentația spune destul de clar că scăderea effort-ului e pârghia mai bună. ## Cum arată în cod Cam asta punem în fața unei căsuțe de suport, în TypeScript, cu o schemă Zod ca răspunsul să nu poată veni malformat: ```typescript import Anthropic from "@anthropic-ai/sdk"; import { z } from "zod"; import { zodOutputFormat } from "@anthropic-ai/sdk/helpers/zod"; const Triage = z.object({ category: z.enum(["billing", "bug", "how-to", "account", "other"]), priority: z.enum(["low", "normal", "urgent"]), needs_human: z.boolean(), }); const client = new Anthropic(); export async function triage(ticket: string) { const response = await client.messages.parse({ model: "claude-haiku-5-5", max_tokens: 1024, // room for thinking plus the answer output_config: { effort: "low", format: zodOutputFormat(Triage), }, system: [ { type: "text", text: TRIAGE_RULES, cache_control: { type: "ephemeral" } }, ], messages: [{ role: "user", content: ticket }], }); if (response.stop_reason === "refusal") return null; // no server-side fallback on Haiku return response.parsed_output; } ``` Trei detalii aduc cea mai mare parte din valoare. Regulile stau într-un bloc de sistem pus în cache, deci prefixul de 3.000 de tokeni costă o zecime din prețul de intrare. Effort-ul e setat explicit pe `low`, pentru că valoarea implicită e `medium`. Și nu există niciun `temperature`, pentru că trimiterea lui e acum o eroare. ## Recomandarea noastră Dacă ai un flux de volum mare pe Haiku 4.5, migrează-l. Chiar și după tokenizer, prețul scade de aproximativ 7,7 ori, modelul urmează mai bine instrucțiunile, iar schimbările de cod durează o după-amiază dacă treci prin lista de mai sus. Dacă ai un flux pe Sonnet care doar clasifică sau extrage, rulează-l pe Haiku 5.5 cu evaluările tale. În exemplul nostru economia e de 95%, iar la genul ăsta de muncă diferența de calitate e adesea mai mică decât se așteaptă lumea. Două reguli ca să rămână ieftin: stai sub 100K tokeni pe prompt și setează effort-ul explicit pe fiecare flux. Iar dacă vrei pe cineva care să se uite unde se duce de fapt factura ta de AI, e genul de muncă pe care [o facem pentru clienți](/contact).