Utratil jsem $500 testováním Claude Sonnet 4.6 vs Opus 4.6 — zde je to, co jsem zjistil

Proč jsem provedl tento experiment

Každý zveřejňuje srovnávací tabulky benchmarků porovnávající Claude Sonnet 4.6 a Opus 4.6. Rychlým vyhledáváním jich najdete tucet. Ale benchmarky měří výkon modelu na standardizovaných úlohách — neřeknou vám, co se stane, když jste ve 2 hodiny ráno po kolena v nepřehledném kódu a snažíte se vydat novou funkci.

Chtěl jsem odpovědět na jednodušší otázku: u skutečných úkolů, které jako vývojář dělám každý den, kdy si Opus 4.6 zaslouží svůj 5x vyšší cenový příplatek?

Proto jsem připravil kontrolovaný experiment. Po dobu tří týdnů jsem každý kódovací úkol nechal projít oběma modely — stejné prompty, stejné codebase, stejná kritéria hodnocení. Sledoval jsem náklady, kvalitu výstupu, čas dokončení a počet potřebných následných oprav.

Účet činil přibližně $500. Zde je vše, co jsem zjistil.

Nastavení: Jak jsem strukturoval test

Používal jsem Claude API přímo s identickými systémovými prompty pro oba modely. Žádné wrappery, žádní asistenti, žádné speciální konfigurace — jen čistá volání API, aby srovnání bylo průkazné.

Testované modely:

• Claude Sonnet 4.6 (claude-sonnet-4-6) — $3 input / $15 output na milion tokens
• Claude Opus 4.6 (claude-opus-4-6) — $15 input / $75 output na milion tokens

Metodika:

• Stejný prompt pro každý úkol, odeslaný oběma modelům v rámci stejné hodiny
• Každý úkol hodnocen podle: správnosti, kvality kódu, úplnosti a počtu potřebných následných promptů
• Všechny úkoly vycházely z reálných projektů — žádné syntetické benchmarky
• Každý model jsem hodnotil na stupnici 1-10 v každé dimenzi

Údaje o cenách pocházejí přímo z oficiální stránky s cenami Anthropic. Měření rychlosti pochází z benchmarků Artificial Analysis.

Scénář 1: Ladění race condition v asynchronním kódu

Úkol: Aplikace v Node.js vykazovala občasnou chybu, kdy zápisy do databáze probíhaly v nesprávném pořadí. Chyba se objevovala pouze pod zátěží. Oběma modelům jsem poskytl příslušné zdrojové soubory (asi 8K tokens kontextu) a chybové protokoly.

Výsledek Sonnet 4.6: Během dvou výměn identifikoval chybějící await v řetězci Promise. Navrhl zabalit zápisy do transakce. Čistá a správná oprava.

Výsledek Opus 4.6: Identifikoval stejnou příčinu hned při první výměně, ale šel dál — upozornil na druhou potenciální race condition, které jsem si v sousedním modulu nevšiml. Také vysvětlil, proč byla chyba občasná (časování event loop při souběžných připojeních) a navrhl strukturální opravu pomocí fronty zápisů.

Vítěz: Opus 4.6

Rozdíl nebyl v nalezení chyby. Našly ji oba. Opus našel druhou chybu a poskytl architektonický kontext, který zabránil budoucímu problému. To odpovídá tomu, co Anthropic uvádí o tom, že Opus 4.6 má lepší schopnosti ladění a schopnost zachytit vlastní chyby.

Náklady: Sonnet $0.12 | Opus $0.58

Scénář 2: Tvorba CRUD endpointů pro REST API

Úkol: Generovat kompletní sadu CRUD endpointů pro prostředek „projects“ v aplikaci Express.js s TypeScript, Prisma ORM, validací vstupu přes Zod a řádným ošetřením chyb.

Výsledek Sonnet 4.6: Vytvořil všech pět endpointů (create, read one, read all s paginací, update, delete) v jediné odpovědi. Validace vstupu byla správná, ošetření chyb solidní, typy TypeScript byly přesné. Připraveno k vložení a testování.

Výsledek Opus 4.6: Vytvořil stejných pět endpointů s téměř identickou strukturou. Přidal o něco detailnější komentáře. Také zahrnul návrh na middleware pro autentizaci, o který jsem nežádal.

Vítěz: Sonnet 4.6

Výstupy byly funkčně identické. Sonnet byl rychlejší, levnější a nezaplňoval odpověď nevyžádanými architektonickými návrhy. Pro dobře definované, ohraničené úkoly, jako je generování CRUD, nepřidává extra hloubka uvažování Opus nic jiného než náklady.

Náklady: Sonnet $0.08 | Opus $0.41

Scénář 3: Refaktorování monolitické komponenty na menší části

Úkol: React komponenta o 600 řádcích spravující uživatelské profily — včetně stavu formuláře, volání API, kontroly oprávnění a logiky vykreslování — potřebovala rozdělit na menší, testovatelné části. Poskytl jsem celou komponentu plus její testovací soubor.

Výsledek Sonnet 4.6: Rozdělil komponentu na čtyři části: kontejnerovou komponentu, formulářovou komponentu, hook pro oprávnění a hook pro API. Rozumný rozklad. Nicméně opomněl aktualizovat dvě cesty importů v testovacím souboru a hook pro oprávnění měl drobný problém se správou stavu, kdy nememoizoval callback.

Výsledek Opus 4.6: Rozdělení na pět částí s čistším oddělením. Vytvořil dedikovaný soubor pro typy, správně aktualizoval všechny importy včetně testovacího souboru a hook pro oprávnění byl správně memoizován. Také si všiml, že původní komponenta měla potenciální memory leak v cleanupu effectu a opravil ho.

Vítěz: Opus 4.6

Zde se propast stává reálnou. Refaktorování více souborů se sledováním závislostí je přesně ten scénář, kde se skóre Opus 4.6 76 % v MRCR v2 (multi-file reasoning and code review) promítá do praktické hodnoty. Řešení Sonnet potřebovalo dvě kola oprav. Opus dodal správný výsledek na první pokus.

Náklady: Sonnet $0.22 (včetně oprav) | Opus $0.95

Scénář 4: Psaní unit tests pro existující kód

Úkol: Napsat komplexní unit tests pro modul zpracování plateb s více okrajovými případy — vypršelé karty, nedostatek prostředků, vypršení časového limitu sítě, částečné refundace a převod měn.

Výsledek Sonnet 4.6: Vygeneroval 14 testovacích případů pokrývajících všechny scénáře, které jsem popsal. Testy byly dobře strukturované s jasnými bloky describe/it. Nastavení mocků bylo správné. Byly zahrnuty i dva okrajové případy, které jsem explicitně nezmínil (prázdná částka, záporná částka).

Výsledek Opus 4.6: Vygeneroval 16 testovacích případů. Podobná struktura. Přidal jeden test integračního typu, který ověřoval celý platební tok end-to-end. O něco upovídanější v popisech testů.

Vítěz: Remíza (Sonnet 4.6 z pohledu hodnoty)

Oba vytvořili vynikající sady testů. Opus přidal dva testy navíc, ale nebyly o nic zásadně lepší. Pro generování testů přináší Sonnet ekvivalentní kvalitu při 5x nižších nákladech. Pokud netestujete extrémně složitou obchodní logiku, Sonnet je správná volba.

Náklady: Sonnet $0.09 | Opus $0.47

Scénář 5: Psaní technické dokumentace

Úkol: Vygenerovat API dokumentaci pro interní SDK — včetně signatur metod, popisů parametrů, návratových typů, příkladů použití a pokynů pro ošetření chyb u 12 veřejných metod.

Výsledek Sonnet 4.6: Čistá, dobře organizovaná dokumentace. Každá metoda měla popis, tabulku parametrů, návratový typ, příklad a sekci chyb. Konzistentní formátování v celém dokumentu.

Výsledek Opus 4.6: Téměř identická dokumentace. Opus přidal na konec sekci „Common Patterns“, která ukazovala, jak se metody skládají dohromady — což bylo hezké, ale nevyžádané.

Vítěz: Sonnet 4.6

Dokumentace je úkol, kde je stručnost Sonnet skutečnou výhodou. Jak poznamenali vývojáři porovnávající tyto dva modely, Opus někdy u jednoduchých úkolů přidává zbytečná vysvětlení, čímž plýtvá tokens a časem. U dokumentace chcete jasnost a úplnost, ne rozvláčnost a filozofování.

Náklady: Sonnet $0.14 | Opus $0.72

Scénář 6: Code review u pull request

Úkol: Provést revizi pull request o 400 řádcích, který přidával vrstvu cachování do API. Chtěl jsem, aby oba modely identifikovaly chyby, navrhly zlepšení a upozornily na bezpečnostní rizika.

Výsledek Sonnet 4.6: Našel tři problémy — chybějící invalidaci cache při aktualizaci, potenciální memory leak z neomezeného růstu cache a návrh na přidání TTL. Dobrá, akceschopná zpětná vazba.

Výsledek Opus 4.6: Našel stejné tři problémy plus dva další — zranitelnost vůči timing attack při generování klíče cache a drobný problém, kdy by souběžné požadavky mohly během plnění cache vracet neaktuální data. Navrhl konkrétní vzor (read-through cache s distribuovanými zámky) pro vyřešení problému se souběhem.

Vítěz: Opus 4.6

Code review kódu relevantního pro bezpečnost je další oblastí, kde Opus vítězí. Zranitelnost vůči timing attack byla skutečná a nebyla zřejmá. To odpovídá zprávám od vývojářů, kteří považují Opus za obzvláště silný, když se problém týká velkého architektonického povrchu.

Náklady: Sonnet $0.11 | Opus $0.53

Scénář 7: Rychlé prototypování nové funkce

Úkol: Vytvořit systém oznámení v reálném čase pomocí WebSockets — handler na straně serveru, hook na straně klienta a komponentu oznámení s animacemi. Prioritou byl čas, nikoli dokonalost.

Výsledek Sonnet 4.6: Dodal funkční implementaci v jediné odpovědi. WebSocket handler, vlastní React hook i komponenta oznámení spolupracovaly. Animace byla založena na CSS a byla plynulá. Drobný problém: chyběla logika pro znovupřipojení.

Výsledek Opus 4.6: Podobně kvalitní výstup, ale zahrnoval logiku znovupřipojení a strategii exponenciálního odkládání (exponential backoff). Také přidal mechanismus heartbeat. Generování trvalo zhruba o 30 % déle kvůli nižší rychlosti tokens.

Vítěz: Sonnet 4.6

Při prototypování záleží na rychlosti více než na úplnosti. Rychlejší generování výstupu u Sonnet (zhruba 47 tokens za sekundu oproti 40 u Opus) znamená svižnější iterační cykly. Logika znovupřipojení, kterou Opus přidal, byla fajn, ale stejně bych ji přidal až v druhém průchodu. Prototypování odměňuje rychlý, dostatečně dobrý výstup.

Náklady: Sonnet $0.10 | Opus $0.48

Scénář 8: Architektonické rozhodování

Úkol: Potřebovali jsme si vybrat mezi strukturou monorepo a polyrepo pro projekt mikroslužeb. Poskytl jsem velikost týmu, požadavky na nasazení, omezení CI/CD a hranice služeb. Požádal jsem oba modely o analýzu kompromisů a doporučení přístupu.

Výsledek Sonnet 4.6: Poskytl solidní analýzu pro a proti. Doporučil monorepo s Turborepo na základě velikosti týmu. Rozumné, ale poněkud obecné.

Výsledek Opus 4.6: Než se zavázal k doporučení, položil tři upřesňující otázky — ohledně frekvence nasazování, datových závislostí mezi službami a toho, zda má tým zkušenosti s monorepo. Poté, co jsem odpověděl, poskytl nuancovanou analýzu, která doporučila hybridní přístup: monorepo pro sdílené knihovny a úzce propojené služby, samostatná repozitáře pro nezávisle nasazované služby s různými cykly vydávání. Také nastínil cestu migrace ze současné struktury.

Vítěz: Opus 4.6

Opus zvládá nejednoznačnost lépe. Jak potvrzují četné zprávy vývojářů, Opus klade lepší doplňující otázky a vytváří obhajitelnější předpoklady. Pro seniorní inženýry pracující na komplexních architektonických rozhodnutích toto chování šetří hodiny dohadování.

Náklady: Sonnet $0.07 | Opus $0.62

Finální hodnocení

Zde je přehled výkonu každého modelu ve všech osmi scénářích, hodnocený na stupnici 1-10 za kvalitu výstupu:

Opus 4.6 vyhrál: 4 scénáře (ladění, refaktorování, code review, architektura) Sonnet 4.6 vyhrál: 2 scénáře (dokumentace, prototypování) Remízy: 2 scénáře (CRUD endpointy, psaní testů)

Ale zde je to, co tabulka skrývá: Sonnet 4.6 byl správnou volbou v 6 z 8 scénářů, když započítáte náklady. Dva scénáře, kde skóroval znatelně hůře (refaktorování a architektura), jsou úkoly, které většina vývojářů dělá několikrát týdně, nikoli desítkykrát denně.

Realita nákladů

Během tří týdnů testování vypadal účet následovně:

Opus stál v průměru 5.25x více na úkol. Pro identickou sadu úkolů dodal Sonnet 90 % kvality za 19 % nákladů.

Pokud bych použil hybridní přístup — Sonnet pro rutinní úkoly, Opus pouze pro 20 % úkolů zahrnujících refaktorování, ladění a architekturu — můj celkový účet by byl přibližně $160 místo $500. To je snížení o 68 % s téměř nulovou ztrátou kvality.

To je v souladu s tím, co uvádějí produkční nasazení: vzor hybridního routeru, kde 80-90 % požadavků směřuje na Sonnet a pouze kritické úkoly se eskalují na Opus, šetří 60-80 % nákladů na API.

Tři vzorce, které jsem zaznamenal a které benchmarky nezachycují

1. Opus lépe říká "počkej, potřebuji více informací"

U nejednoznačných promptů má Sonnet tendenci vybrat rozumnou výchozí možnost a pracovat s ní. Opus se pozastaví a zeptá se. To je neuvěřitelně cenné pro architektonickou práci, ale mírně otravné u rutinních úkolů, kde prostě chcete, aby se rozhodl a pokračoval.

2. Sonnet lépe dodržuje instrukce doslovně

Když jsem zadal detailní specifikaci, Sonnet vytvořil přesně to, co jsem chtěl. Opus někdy „vylepšoval“ věci, o které jsem ho nežádal — přidával vrstvy abstrakce, navrhoval vzory, zahrnoval okrajové případy nad rámec zadání. Pro úkoly, kde chcete spíše shodu než kreativitu, vítězí Sonnet.

3. Rozdíl v kvalitě se zvětšuje s délkou kontextu

U úkolů pod 10K tokens kontextu jsem modely od sebe téměř nerozeznal. Jakmile kontext překročil 30K tokens — velké refaktory, revize více souborů — Opus se stal znatelně koherentnějším. To je v souladu se skóre Opus 4.6 76 % v MRCR v2 pro uvažování nad více soubory v dlouhých kontextech.

Kde se pohybují benchmarky (pro referenci)

Pro ty, kteří chtějí čísla, zde jsou klíčové benchmarky k březnu 2026:

Zdroje: Anthropic přehled modelů, Artificial Analysis, Analýza benchmarků Claude 5

Rozdíl v SWE-bench je pouze 1.2 bodu. Ale rozdíl v GPQA Diamond (vědecké uvažování) je masivní — 17 bodů. A rozdíl v MRCR v2 (práce s více soubory v dlouhém kontextu) je místem, kde spočívá skutečný praktický rozdíl.

Moje doporučení: Rozhodovací rámec

Po $500 a třech týdnech testování je zde můj rozhodovací strom:

Používejte Sonnet 4.6 když:

• Úkol je dobře definován s jasnými požadavky.
• Píšete nový kód od nuly (endpointy, komponenty, skripty).
• Potřebujete vysokou rychlost iterace (prototypování, průzkumné kódování).
• Generujete testy nebo dokumentaci.
• Délka kontextu je pod 20K tokens.
• Máte omezený rozpočet nebo zpracováváte vysoký objem požadavků.

Používejte Opus 4.6 když:

• Úkol zahrnuje refaktorování napříč více soubory s komplexními závislostmi.
• Potřebujete, aby model zvážil kompromisy, než se zaváže k návrhu.
• Ladíte nezřejmé problémy ve velkých codebase.
• Revidujete kód kritický z hlediska bezpečnosti.
• Délka kontextu přesahuje 30K tokens a záleží na koherenci.
• Náklady na nesprávnou odpověď převyšují náklady na volání modelu.

Používejte oba (hybridní router) když:

• Budujete produkční systém s proměnlivou složitostí úkolů.
• Chcete dosáhnout 60-80% úspory nákladů se Sonnet a mít pojistku v podobě Opus pro těžké problémy.

Pro týmy vyvíjející nástroje pro vývojáře — verzi tohoto hybridního přístupu používáme v ZBuild — se vzor routeru stal průmyslovým standardem pro rok 2026.

Co bych udělal jinak

Kdybych tento experiment prováděl znovu, přidal bych třetí dimenzi: měření toho, kolik následných promptů každý model potřeboval k dosažení výstupu připraveného pro produkci. Můj pocit říká, že by to u složitých úkolů výrazněji favorizovalo Opus, protože jeho přesnost na první pokus byla u práce s více soubory konzistentně vyšší.

Také bych otestoval Opus se zapnutým rozšířeným přemýšlením (extended thinking), což údajně zlepšuje jeho už tak silné ladění a architektonické uvažování.

Sečteno a podtrženo: začněte se Sonnet 4.6 pro všechno. Rychle poznáte, kdy si úkol vyžádá Opus. Úkoly, které ho vyžadují, jsou specifické, relativně vzácné a natolik hodnotné, aby ospravedlnily vyšší cenu.

Zdroje

• Anthropic — Představujeme Claude Opus 4.6
• Anthropic — Přehled modelů Claude
• Anthropic — Ceny Claude
• Artificial Analysis — Výkon Claude Sonnet 4.6
• Claude 5 — Analýza benchmarků Opus 4.6
• Bind AI — Sonnet 4.6 vs Opus 4.6 pro kódování
• Emergent — Claude Sonnet vs Opus 2026
• DEV Community — Srovnání kódování Opus 4.6 vs Sonnet 4.6
• Macaron — Claude Opus 4.6 pro Code Review
• Apiyi — Průvodce srovnáním Opus 4.6 vs Sonnet 4.6
• Medium — Testoval jsem Sonnet 4.6 vs Opus 4.6 pro Vibe Coding