Claude Sonnet 5.5: levnější pracovní model, ale pozor na API migraci

U AI workflow se účet často nerozbije na jednom těžkém úkolu. Roste na stovkách běžných požadavků, opakovaných čteních a zbytečných pokusech. Sonnet 5.5 bych proto testoval jako hlavního pracovníka pro ohraničené úlohy: support, dokumenty a menší změny kódu.

Anthropic model vydal 28. září 2026. Uvádí přes 30 % rychlejší generování a až 30 % nižší náklady na úkol proti Sonnetu 5. Jde o výsledky dodavatele, nikoli slíbenou úsporu vašeho workflow. Sazby za token zůstaly stejné. Oznámení.

Poloviční sazba není poloviční účet

Podle specifikace modelu stojí milion vstupních tokenů 2 USD, výstupních 10 USD a čtení cache 0,20 USD. Zápis pětiminutové cache stojí 2,50 USD. Model má 1M kontext a maximálně 128k výstupních tokenů.

Vstup a výstup tedy stojí polovinu sazeb Opusu 5.5, čtení cache ale stojí stejně. To je důležitá korekce titulku videa Marka Bartoše. U agenta s dlouhou cachovanou historií nemusí účet klesnout o polovinu.

Ilustrační výpočet: 100 tisíc necachovaných vstupních tokenů a 10 tisíc výstupních vyjde u Sonnetu na 0,30 USD, u Opusu na 0,60 USD. Přidejte milion tokenů přečtených z cache a je to 0,50 proti 0,80 USD. Úspora je 37,5 %. Nejde o benchmark; počet tokenů, nástroje, retry a lidské opravy mohou poměr změnit.

Kam bych ho nasadil jako první

V n8n nebo Make bych začal na frontě zákaznických e-mailů. Jednoduchá pravidla odfiltrují spam a duplicity. Sonnet dostane relevantní část konverzace a ověřený výňatek z firemní dokumentace. Vrátí návrh odpovědi, podklady a informaci, co chybí.

Zápis do CRM pak provede samostatný krok po kontrole schématu a identity zákazníka. Kompenzace, rušení služby nebo změna platebních údajů zůstanou ke schválení. Nejasný případ dostane specialistu nebo člověka; dražší model se nemusí volat u každého ticketu.

U vývoje bych vybral opravu malé chyby s reprodukcí a testem. Agent navrhne patch, test ověří chování a reviewer posoudí rozsah změny. Kvalitu nepočítám podle toho, zda agent řekl „hotovo“.

Migrace může selhat ještě před prvním výsledkem

Průvodce migrací upozorňuje na změny Messages API:

• Místo vypnutého thinkingu použijte between_tools, s effort nejvýše high.
• Vynucené tool_choice typu any nebo tool vrací chybu. Přechod na auto nezaručuje zavolání nástroje.
• Odpověď čtěte podle typu bloků a thinking bloky vracejte nezměněné.

Prakticky: workflow musí zvládnout i platnou odpověď bez očekávané akce. Neberte HTTP 200 jako důkaz, že záznam v CRM vznikl. Ověřte výsledek operace a chybějící krok pošlete do kontrolní větve.

Dokumentace změn navíc popisuje vazbu thinking bloků na historii a účet, nový computer-use toolset na Claude API a Google Cloud a změnu průběžných zpráv mezi nástroji. U dlouhých agentů proto otestujte i pokračování uložené relace, změnu modelu a zobrazování postupu.

Rozhodne malý eval, ne pořadí v tabulce

Na stejné sadě bych porovnal dosavadní model a Sonnet 5.5 při dvou úrovních effort. Uložil bych cenu správně dokončeného případu, p95 latenci, počet retry, chybné zápisy a čas review. Součástí sady musí být chybějící data, rozporné dokumenty a selhání nástroje.

Tohle je návrh pilotu, nikoli můj provedený benchmark. Sonnet 5.5 má smysl převzít do běžné práce teprve tehdy, když úspora přežije validaci, eskalace a opravy. Pro otevřenou architekturu nebo obtížný úsudek bych dál ponechal silnějšího specialistu.