
Claude Sonnet 5.5 je hitrejši, cena žetona pa ostaja enaka

Anthropic je v objavi 28. septembra 2026 predstavil Claude Sonnet 5.5: izhod ustvarja več kot 30 % hitreje od Sonnet 5, ob enaki ceni 2 USD za milijon vhodnih in 10 USD za milijon izhodnih žetonov pa v preizkusih podjetja opravilo stane do 30 % manj. Razlika nastane predvsem zato, ker model za dokončanje dela porabi manj žetonov; odstotek ni znižanje cenika za API.
Model je na voljo v Claudu in prek API-ja. Za uporabnika je sprememba predvsem krajše čakanje na odgovor, za razvijalca pa možnost nižjega računa za uspešno končano nalogo. Oboje je odvisno od vrste dela: hitrost ustvarjanja izhoda še ni enaka trajanju celotnega postopka, prihranek v preizkusih pa ni zagotovljen pri vsakem pozivu.
Zakaj enaka cena žetona lahko pomeni nižji račun
Pri uporabi API-ja sta vhod in izhod obračunana ločeno. Vhod vključuje navodilo, priloženo gradivo in vsebino, ki jo aplikacija pošlje modelu; izhod zajema besedilo, ki ga model ustvari. Če novi model za primerljiv uporaben rezultat napiše manj izhoda ali potrebuje manj vmesnih poskusov, račun pade tudi ob nespremenjeni tarifi. Hitrejše izpisovanje samo po sebi na znesek ne vpliva, če se število obračunanih žetonov ne spremeni.
Razlika postane izrazitejša pri nalogah z orodji. Model lahko odpre datoteko, pridobi podatek, izvede ukaz in nato na podlagi rezultata nadaljuje delo. Vsak dodaten krog običajno prinese nov kontekst in nov izhod, zato manj korakov lahko zmanjša porabo žetonov ter skrajša čakanje. Klici zunanjih storitev imajo lahko tudi svoje stroške, vendar niso del Anthropicove cene žetona in jih splošna ocena prihranka ne določa.
Za primerjavo je zato pomembno, kaj šteje za končano opravilo. Kratek odgovor, ki zahteva ponovno zahtevo ali ročni popravek, lahko porabi manj žetonov v prvem poskusu, vendar stane več do uporabnega rezultata. Pri enostavnem vprašanju z enim odgovorom je prostora za odpravo odvečnih korakov manj kot pri daljšem poteku, ki vključuje orodja. Takšna razlika pojasni, zakaj se prihranek med aplikacijami lahko precej razlikuje.
Hitrejše ustvarjanje izhoda ne skrajša nujno celotnega postopka
Objavljena primerjava hitrosti meri ustvarjanje izhoda glede na prejšnji Sonnet. Pri zaporednem pisanju, popravljanju in dopolnjevanju besedila se hitrejši odziv lahko pozna pri vsakem nadaljnjem vprašanju. Pri aplikaciji, ki čaka še na spletni vir, izvajanje kode ali odgovor zunanjega orodja, pa skupni čas določa več členov. Tudi model s hitrejšim izpisovanjem lahko nalogo konča pozneje, če potrebuje dodatne poskuse.
Nastavitev napora vpliva na to razmerje. Nižja nastavitev pomeni manj časa in žetonov za sklepanje, višja pa modelu omogoča daljše preverjanje odgovora. Zato lahko primerjava istega poziva pri različnih nastavitvah ustvari napačen vtis o hitrosti in strošku: spremeni se lahko tako količina ustvarjenega izhoda kot kakovost končne rešitve.
Za vsakdanjo uporabo so posebej pomembna dobro omejena opravila: popravljanje napake v kodi, urejanje dokumenta, priprava preglednice ali predstavitve. Pri njih je končni rezultat mogoče razmeroma jasno opredeliti in presoditi. Popravljena koda se mora izvesti, preglednica mora ohraniti pravilne podatke, predstavitev pa mora slediti navodilom. Večja hitrost je dragocena šele, ko uporabnik dobi tak rezultat brez dodatnega kroga popravkov.
Prvi preizkusi pokažejo, od kod lahko pride razlika
Yashodha Bhavnani, podpredsednica za izdelke umetne inteligence pri Boxu, je v poročilu VentureBeata rezultat njihovega preizkusa opisala z besedami »2.4x faster and used 12% fewer total tokens«. Dodala je, da je model pri pregledu izvornih dokumentov odkril napake, ki jih predhodnik ni opazil. Gre za Boxovo primerjavo v njegovem delovnem toku, zato je ni mogoče neposredno prenesti na vsak pogovor v Claudu ali na vsako aplikacijo.
Primer kaže, zakaj je koristno ločiti porabo žetonov od časa. Manj žetonov zniža strošek, če veljajo iste tarife; manj ponovitev in klicev orodij lahko poleg tega skrajša celotno izvajanje. Kakovost rezultata ostaja samostojno merilo. Če model hitreje vrne nepopoln odgovor, dodatni poskusi izničijo prednost. V delovnih tokovih, kjer mora program po odgovoru še izvesti preverjanje, je število uspešno dokončanih nalog pomembnejše od same hitrosti besedila.
Kdaj Sonnet zadošča in kdaj se izplača Opus
Na preizkusu delovnih nalog GDPval-AA v2.1 je Sonnet 5.5 dosegel 1.844 točk, Opus 5.5 pa 1.846; Tom's Guide ta rezultat povezuje z uporabnostjo Sonneta za povzemanje, urejanje besedila in pripravo predstavitev. Razlika na tem preizkusu je majhna, vendar gre za določeno zbirko nalog, ne za splošno izenačenje obeh modelov. Sonnetov rezultat je bil izmerjen na predizdajni namestitvi z napako pri zahtevah za strukturiran izhod, ki je bila pozneje odpravljena.
Opus ostaja primernejši za odprte in dolgotrajne naloge, pri katerih je treba skozi več korakov ohraniti pregled nad povezanimi odločitvami. Sonnet je smiselnejša izbira, kadar je cilj natančno določen in je mogoče prepoznati, ali je odgovor uporaben. Pri odpravljanju ene napake ali urejanju znanega dokumenta lahko nižja cena obdelave pomeni prednost, če nalogo dokonča z ustrezno kakovostjo. Pri zapletenem načrtovanju lahko dodatni popravki to razliko hitro zmanjšajo.
Preberite tudi:
Sorodni članki


ChatGPT Plus ali Claude Pro: enaka cena skriva različne omejitve

GPT-6.1 Sol je izšel: milijon žetonov konteksta za nižjo ceno

Claude Code ali Gemini CLI: brezplačnih 1.000 zahtev ne zagotovi hitrejše naloge

Pravila za UI pri delu: seznam dovoljenih orodij ni dovolj

Lokalni ali oblačni LLM: predpomnjenje lahko obrne računico stroškov
Naročite se na naše e-novice
Najnovejše novice o Web3, UI in kriptovalutah neposredno v vaš e-poštni predal.