Klíčové poznatky
- Nejdříve Sonnet, Opus v případě potřeby: Každý úkol začněte se Sonnet 4.6; na Opus 4.6 přejděte pouze tehdy, když je výstup Sonnet nesprávný nebo když potřebujete hlubší architektonické uvažování -- obvykle v poměru 80/20.
- Sonnet zvládá rutinní úkoly stejně dobře: Opravy chyb, přidávání funkcí, psaní testů a code review produkují u obou modelů srovnatelné výsledky; platit 5x více za stejnou opravu nedává smysl.
- Opus vyniká v koordinaci mezi více soubory: Při migraci správy stavu napříč 15+ soubory nebo při provádění architektonických rozhodnutí s komplexními kompromisy si Opus udržuje strukturální přehled, který Sonnet ztrácí.
- Úspora $480/rok: Vývojář, který utratí $50/měsíc za Opus, by zaplatil zhruba $10/měsíc za ekvivalentní využití Sonnet u 80% úkolů, kde oba modely fungují stejně dobře.
Claude Opus nebo Sonnet pro kódování? Praktický průvodce rozhodováním (2026)
March 15, 2026 — Každý vývojář používající Claude pro kódování narazí na stejnou otázku: mám použít Opus 4.6 nebo Sonnet 4.6? Benchmarky jsou si blízké (80.8% vs 79.6% SWE-bench), ceny nikoliv ($15/$75 vs $3/$15 za milion tokens) a odpověď, kterou všichni dávají — „to záleží“ — je k ničemu.
Tento průvodce vám poskytne přímé odpovědi. Otestovali jsme oba modely na šesti reálných programátorských úkolech a řekneme vám přesně, který model pro každý z nich použít. Bez vytáček.
Skutečná otázka nezní „Který je lepší“
Přestaňte se ptát, který model je lepší pro kódování. To je špatná otázka. Správná otázka zní: který model je vhodný pro úkol, který se chystáte udělat právě teď?
Opus 4.6 dosahuje 80.8% v SWE-bench Verified. Sonnet 4.6 dosahuje 79.6%. Tento rozdíl 1.2 bodu vám o vašem každodenním zážitku neřekne téměř nic. Důležitý je typ úkolu. Některé úkoly jsou běžná práce — zvládne je jakýkoli schopný model. Jiné úkoly vyžadují hluboké uvažování napříč mnoha soubory a omezeními. Vědět, co je co, vám ušetří skutečné peníze, aniž byste obětovali kvalitu.
Zde je šest úkolů, které jsme nechali projít oběma modely. Výsledky byly jasné.
Úkol 1: Oprava chyby v komponentě React
Scénář: Rozbalovací nabídka se nezavře při kliknutí mimo ni. Chyba je v jediném souboru komponenty — event listener je připojen při mountu, ale nikdy není vyčištěn, a logika detekce kliknutí mimo má ref, který je po re-renderech neaktuální.
Sonnet 4.6: Identifikoval chybějící cleanup v useEffect, přidal návratovou funkci pro odstranění event listeneru a opravil neaktuální ref přepnutím na useCallback. Čistá, správná oprava. Trvalo to asi 8 sekund.
Opus 4.6: Vytvořil stejnou opravu s o něco podrobnějším vysvětlením, proč byl ref neaktuální. Trvalo to asi 20 sekund.
Verdikt: Použijte Sonnet. Oba modely to zvládly na jedničku. Chyba byla izolována v jednom souboru s jasným vzorcem (chybějící cleanup + stale closure). Platit 5x více za stejnou opravu nemá smysl. Toto je denní chleba asistence při kódování — a Sonnet to zvládá dokonale.
Úkol 2: Přidání funkce — API endpoint s validací
Scénář: Přidat nový REST endpoint, který přijímá JSON payload, validuje jej proti schématu, dotazuje se do dvou databázových tabulek a vrací sloučenou odpověď. Zahrnuje vytvoření nového route handleru, přidání validačního middleware, napsání databázového dotazu a aktualizaci indexu rout.
Sonnet 4.6: Vygeneroval route handler, validační schéma, databázový dotaz se správnými joiny, ošetření chyb a aktualizoval registraci rout. Všechny soubory byly konzistentní a kód fungoval na první pokus.
Opus 4.6: Stejný výstup, mírně odlišný styl kódu. Přidal několik kontrol okrajových případů navíc (například řešení případu, kdy jedna tabulka má řádek, ale druhá ne). O něco důkladnější, ale pro tento úkol ne významně lepší.
Verdikt: Použijte Sonnet. Přidávání funkcí s jasnými požadavky je plně v možnostech modelu Sonnet. Úkol zahrnuje více souborů, ale vztahy mezi nimi jsou přímočaré — nový soubor, importovat jej, zaregistrovat jej. Sonnet to dělá spolehlivě.
Úkol 3: Psaní testů pro stávající kód
Scénář: Napsat unit testy pro modul zpracování plateb, který řeší vytváření poplatků, logiku refundací, ověřování podpisu webhooku a správu klíčů idempotence.
Sonnet 4.6: Vygeneroval komplexní testy pokrývající hlavní cestu, chybové stavy, okrajové případy pro idempotenci a nastavení mocků pro API poskytovatele plateb. Dobré pokrytí hraničních podmínek.
Opus 4.6: Podobné pokrytí testy. Přidal několik jemnějších okrajových případů týkajících se replay útoků na webhooky a zaokrouhlování aritmetiky při částečných refundacích. O něco kreativnější při hledání okrajových případů.
Verdikt: Použijte Sonnet. Psaní testů je jednou z nejsilnějších stránek modelu Sonnet. Rozumí testovacím vzorcům, generuje správné mocky a pokrývá důležité větve. Pokud netestujete extrémně složitou obchodní logiku s jemnými invarianty, Sonnet je správná volba.
Úkol 4: Refaktorování napříč 15 soubory — migrace správy stavu
Scénář: Migrovat aplikaci React z Redux s thunks na Zustand. To se týká 15 souborů: definice store, 8 propojených komponent, 3 soubory middleware a 3 pomocné soubory, které dispatchují akce. Migrace musí zachovat stávající chování včetně optimistických aktualizací a funkce zpět (undo).
Sonnet 4.6: Úspěšně převedl store a většinu komponent. Nicméně narušil logiku optimistických aktualizací. Původní Redux middleware zachycoval specifické akce pro uložení snapshotů pro funkci zpět před aplikací optimistických změn. Sonnet převedl každý soubor jednotlivě, ale ztratil koordinaci mezi middlewarem a komponentami, které na něm závisely. Funkce zpět byla tiše rozbitá — testy by to zachytily, ale strukturální porozumění tam nebylo.
Opus 4.6: Zvládl celou migraci správně. Před generováním jakéhokoli kódu zmapoval řetězec závislostí: které komponenty odesílaly které akce, který middleware co zachycoval a jak snapshoty pro funkci zpět propojovaly systém dohromady. Poté restrukturalizoval Zustand store tak, aby zachoval chování middleware pomocí vestavěného vzorce middleware v Zustand, čímž udržel koordinaci undo/optimistických aktualizací nedotčenou napříč všemi 15 soubory.
Verdikt: Použijte Opus. Zde se modely rozcházejí. Když úkol refaktorování vyžaduje pochopení toho, jak více souborů spolupracuje na dosažení určitého chování (nejen co dělá každý soubor samostatně), hlubší uvažování modelu Opus se vyplatí. Rozdíl v ceně je irelevantní, když Sonnet vytvoří kód, který tiše rozbije funkcionalitu.
Úkol 5: Architektonické rozhodnutí — návrh vrstvy mezipaměti
Scénář: Backendová služba provádí nákladná volání API třetích stran. Potřebujete navrhnout vrstvu mezipaměti (caching layer). Omezení: některé odpovědi lze cachovat hodiny, jiné sekundy; invalidace mezipaměti musí nastat, když se změní upstream data prostřednictvím webhooků; systém běží na více instancích za load balancerem; a tým se chce vyhnout přidání Redis jako závislosti, pokud je to možné.
Sonnet 4.6: Doporučil přidat Redis. Poskytl čistou implementaci s cachováním založeným na TTL a invalidací spouštěnou webhooky. Dobré, standardní řešení — ale ignorovalo omezení ohledně vyhnutí se Redis. Po připomenutí navrhl in-memory cache s pub/sub mechanismem mezi instancemi, ale implementace obsahovala race conditions kolem invalidace cache napříč instancemi.
Opus 4.6: Začal analýzou kompromisů: Redis přidává provozní složitost, ale triviálně řeší konzistenci mezi instancemi. Bez Redis potřebujete buď sdílenou cache (podloženou databází, což popírá smysl), nebo gossip protokol pro invalidaci cache (komplexní, ale vyhýbá se novým závislostem). Poté navrhl vrstvený přístup: použít in-process caching pro položky s krátkým TTL (není nutná koordinace mezi instancemi, protože data se stejně rychle mění) a cachování založené na SQLite s módem WAL pro položky s dlouhým TTL s invalidací řízenou webhooky. Pragmatické, vědomé si omezení a uvažování bylo viditelné v každém kroku.
Verdikt: Použijte Opus. Architektonická rozhodnutí vyžadují zvažování kompromisů oproti omezením. Sonnet má tendenci sahat po standardním řešení. Opus analyzuje prostor omezení a nachází kreativní řešení, která skutečně odpovídají požadavkům. Když náklady na špatné architektonické rozhodnutí znamenají týdny předělávání, dodatečné náklady na tokens jsou zanedbatelné.
Úkol 6: Analýza neznámé codebase
Scénář: Nastoupili jste do nového týmu a potřebujete porozumět codebase v Python o rozsahu 50,000 řádků bez dokumentace. Musíte zjistit, kde se řeší autentizace, jak kaskádovitě procházejí oprávnění skrze middleware stack a identifikovat potenciální bezpečnostní problémy v autorizačním toku.
Sonnet 4.6: Analyzoval soubory poskytnuté v kontextu. Správně identifikoval auth middleware a dekorátory oprávnění. Přehlédl jemný problém: jeden endpoint obcházel standardní middleware použitím jiného routeru, který byl zaregistrován před auth middlewarem v sekvenci spouštění aplikace.
Opus 4.6: Díky svému 1M token context window (beta) pojal najednou podstatně větší část codebase. Identifikoval stejný auth middleware a oprávnění, ale také upozornil na problém s pořadím registrace routerů, timing vulnerability v logice obnovy tokens a poznamenal, že tři endpointy používaly zastaralou kontrolu oprávnění, která udělovala širší přístup, než bylo zamýšleno.
Verdikt: Použijte Opus. Analýza velké codebase je nejsilnější výhodou modelu Opus pro programátorské úkoly. Kombinace hlubšího uvažování a většího efektivního kontextu znamená, že zachytí průřezové problémy, které Sonnet přehlédne. Zejména u analýz citlivých na bezpečnost to není místo, kde by se mělo šetřit na nákladech.
Rozhodovací rámec
Tento vývojový diagram použijte pokaždé, když začínáte programátorský úkol:
Krok 1: Je úkol izolován v 1-3 souborech s jasnými požadavky? Použijte Sonnet.
Krok 2: Zahrnuje úkol vytváření nového kódu (nové endpointy, nové komponenty, nové testy)? Použijte Sonnet.
Krok 3: Vyžaduje úkol pochopení toho, jak se koordinuje 5+ souborů k dosažení určitého chování? Použijte Opus.
Krok 4: Zahrnuje úkol učinění designového rozhodnutí s protichůdnými omezeními? Použijte Opus.
Krok 5: Analyzujete problémy ve velké nebo neznámé codebase? Použijte Opus.
Krok 6: Pokusil se Sonnet o úkol a vytvořil neúplný nebo nesprávný výsledek? Přejděte na Opus.
Pokud si stále nejste jisti, začněte se Sonnet. Nic neztratíte — pokud to Sonnet zvládne, ušetřili jste 80% na daném úkolu. Pokud ne, přepnete na Opus s lepším kontextem o tom, co se nepovedlo.
Porovnání nákladů: Měsíční scénáře
Zde je ukázka toho, jak vypadají reálné měsíční náklady pro tři profily vývojářů:
Solo vývojář, mírné využití (zhruba 500 úkolů/měsíc):
- Pouze Opus: ~$50/měsíc
- Pouze Sonnet: ~$10/měsíc
- Strategie „nejdříve Sonnet“ (poměr 80/20): ~$18/měsíc
- Roční úspora oproti variantě pouze s Opus: $384
Tým 5 lidí, intenzivní využití (zhruba 3,000 úkolů/měsíc):
- Pouze Opus: ~$300/měsíc
- Pouze Sonnet: ~$60/měsíc
- Strategie „nejdříve Sonnet“ (poměr 80/20): ~$108/měsíc
- Roční úspora oproti variantě pouze s Opus: $2,304
Enterprise tým 20 lidí, velmi intenzivní využití (zhruba 15,000 úkolů/měsíc):
- Pouze Opus: ~$1,500/měsíc
- Pouze Sonnet: ~$300/měsíc
- Strategie „nejdříve Sonnet“ (poměr 80/20): ~$540/měsíc
- Roční úspora oproti variantě pouze s Opus: $11,520
Strategie „nejdříve Sonnet“ nešetří jen peníze — šetří správné množství peněz. Neobětujete kvalitu u složitých úkolů. Odstraňujete plýtvání u těch jednoduchých.
Strategie „nejdříve Sonnet“ v praxi
Zde je návod, jak to funguje ve vašem každodenním workflow:
Ranní standup odhalí tři úkoly: Opravit chybu v paginaci, přidat export do CSV na stránku s reporty a navrhnout architekturu systému notifikací.
Úkol 1 — Chyba v paginaci: Otevřete soubor, popište chybu modelu Sonnet. Opraví ji na jeden pokus. Cena: zlomky centu. Hotovo.
Úkol 2 — Funkce exportu do CSV: Popište požadavky modelu Sonnet. Vygeneruje exportní utilitu, přidá endpoint, aktualizuje UI o tlačítko pro stažení. Otestujete, funguje. Cena: pár centů. Hotovo.
Úkol 3 — Architektura notifikací: Začněte se Sonnet pro návrh úvodního designu. Výstup je rozumný, ale nebere v úvahu stávající nastavení message queue týmu ani fakt, že notifikace musí být deduplikovány napříč více zdroji spuštění. Přejděte na Opus. Poskytněte stejný kontext plus dodatečná omezení. Opus vytvoří návrh, který se integruje se stávající frontou, řeší deduplikaci a vysvětluje kompromisy, které učinil. Cena: vyšší, ale toto je rozhodnutí, které formuje týdny vývojové práce.
Tři úkoly. Dva využily Sonnet. Jeden využil Opus. Celkové náklady byly zhruba o 60% nižší, než kdybyste na vše použili Opus, a kvalita byla identická nebo lepší (protože jste rozpočet na Opus zaměřili tam, kde na tom skutečně záleželo).
Hlavní závěr
Používejte Sonnet 4.6 pro 80% své práce na kódování. Opravy chyb, přidávání funkcí, psaní testů, code review, dokumentace, jednoduché refaktorování — Sonnet to vše zvládá v kvalitě 79.6% SWE-bench za $3/$15 na milion tokens.
Používejte Opus 4.6 pro těch 20%, které to vyžadují. Refaktorování napříč soubory s behaviorálními závislostmi, architektonická rozhodnutí s protichůdnými omezeními, analýza velkých codebase, bezpečnostní audity a jakýkoli úkol, kde první pokus Sonnet nestačí. S 80.8% SWE-bench, hlubším uvažováním, podporou Agent Teams a 1M context beta si Opus svou prémiovou cenu u těžkých problémů zaslouží.
Nepoužívejte Opus automaticky ze zvyku. Rozdíl 1.2 bodu v SWE-bench je reálný, ale malý, a projevuje se pouze u nejtěžších problémů. U naprosté většiny programátorských úkolů platíte 5x více za identický výstup.
Nevyhýbejte se modelu Opus z šetrnosti. Když úkol skutečně vyžaduje hluboké uvažování nad více soubory nebo architektonické myšlení, náklady na Opus jsou nulové ve srovnání s náklady na ladění nenápadně špatného výstupu ze Sonnet nebo nasazení chybné architektury.
Vývojáři, kteří v roce 2026 dosahují nejlepších výsledků, nejsou věrní jednomu modelu. Postupují strategicky při výběru modelu pro každý úkol. Začněte se Sonnet. Přejděte na Opus, když je to potřeba. To je celá strategie.
