Viktige poenger
- Sonnet-først, Opus-ved-behov: Start hver oppgave med Sonnet 4.6; eskaler til Opus 4.6 bare når Sonnets utdata er feil eller du trenger dypere arkitektonisk resonnement -- typisk en 80/20-fordeling.
- Sonnet håndterer rutineoppgaver like bra: Feilrettinger, nye funksjoner, testskriving og kodegjennomgang gir sammenlignbare resultater på begge modeller; å betale 5x mer for den samme rettingen gir ingen mening.
- Opus utmerker seg ved koordinering på tvers av filer: Ved migrering av tilstandshåndtering på tvers av 15+ filer eller når du tar arkitektoniske beslutninger med komplekse avveininger, opprettholder Opus en strukturell forståelse som Sonnet mister.
- $480/år i besparelser: En utvikler som bruker $50/måned på Opus, ville betalt omtrent $10/måned for tilsvarende Sonnet-bruk på de 80% av oppgavene hvor begge modellene yter like bra.
Claude Opus eller Sonnet for koding? En praktisk beslutningsguide (2026)
March 15, 2026 — Enhver utvikler som bruker Claude til koding møter det samme spørsmålet: bør jeg bruke Opus 4.6 eller Sonnet 4.6? Ytelsestestene er tette (80.8% vs 79.6% SWE-bench), prissettingen er det ikke ($15/$75 vs $3/$15 per million tokens), og svaret alle gir — "det kommer an på" — er ubrukelig.
Denne guiden gir deg direkte svar. Vi testet begge modellene på seks ekte kodingsoppgaver og vil fortelle deg nøyaktig hvilken modell du skal bruke til hver av dem. Ingen unnaviking.
Det egentlige spørsmålet er ikke "hvilken er best"
Slutt å spørre hvilken modell som er best for koding. Det er feil spørsmål. Det riktige spørsmålet er: hvilken modell er riktig for oppgaven du skal gjøre akkurat nå?
Opus 4.6 skårer 80.8% på SWE-bench Verified. Sonnet 4.6 skårer 79.6%. Det gapet på 1.2 poeng forteller deg nesten ingenting om din daglige opplevelse. Det som betyr noe er typen oppgave. Noen oppgaver er standardarbeid — enhver kompetent modell håndterer dem. Andre oppgaver krever dype resonnementer på tvers av mange filer og begrensninger. Ved å vite hva som er hva, sparer du ekte penger uten å ofre kvalitet.
Her er seks oppgaver vi kjørte gjennom begge modellene. Resultatene var klare.
Oppgave 1: Rett en feil i en React-komponent
Scenario: En nedtrekksmeny lukkes ikke når man klikker utenfor den. Feilen ligger i en enkelt komponentfil — en event listener er festet ved mount, men blir aldri ryddet opp, og logikken for å detektere klikk-utenfor har en ref som er utdatert etter re-renderinger.
Sonnet 4.6: Identifiserte den manglende oppryddingen i useEffect, la til retur-funksjonen for å fjerne event listener, og rettet den utdaterte ref-en ved å bytte til useCallback. Ren, korrekt retting. Tok omtrent 8 sekunder.
Opus 4.6: Produserte den samme rettingen med en litt mer detaljert forklaring på hvorfor ref-en var utdatert. Tok omtrent 20 sekunder.
Dom: Bruk Sonnet. Begge modellene klarte det. Feilen var begrenset til én fil med et tydelig mønster (manglende opprydding + utdatert closure). Å betale 5x mer for den samme rettingen gir ingen mening. Dette er hverdagskosten for kodeassistanse — og Sonnet håndterer det perfekt.
Oppgave 2: Legg til en funksjon — API-endepunkt med validering
Scenario: Legg til et nytt REST endpoint som tar imot en JSON payload, validerer den mot et skjema, gjør spørringer mot to databasetabeller, og returnerer et sammenslått svar. Innebærer å lage en ny route handler, legge til validerings-middleware, skrive databasespørringen og oppdatere route-indeksen.
Sonnet 4.6: Genererte route handler, valideringsskjema, databasespørring med riktige joins, feilhåndtering og oppdaterte rute-registreringen. Alle filer var konsistente og koden fungerte på første forsøk.
Opus 4.6: Samme resultat, litt ulik kodestil. La til noen ekstra sjekker for kanttilfeller (som å håndtere tilfeller der én tabell har en rad, men den andre ikke har det). Marginelt mer grundig, men ikke betydelig bedre for denne oppgaven.
Dom: Bruk Sonnet. Nye funksjoner med klare krav er godt innenfor Sonnets kapasiteter. Oppgaven involverer flere filer, men forholdet mellom dem er rett frem — ny fil, importer den, registrer den. Sonnet gjør dette pålitelig.
Oppgave 3: Skriv tester for eksisterende kode
Scenario: Skriv enhetstester for en modul for betalingsbehandling som håndterer opprettelse av belastninger, refusjonslogikk, verifisering av webhook-signatur og håndtering av idempotensnøkler.
Sonnet 4.6: Genererte omfattende tester som dekket happy path, feiltilfeller, kanttilfeller for idempotens og mock-oppsett for API-et til betalingsleverandøren. God dekning av grensebetingelser.
Opus 4.6: Lignende testdekning. La til noen flere nyanserte kanttilfeller rundt webhook-replay-angrep og avrunding ved delvis refusjon. Litt mer kreativ når det gjaldt å finne kanttilfeller.
Dom: Bruk Sonnet. Testskriving er et av Sonnets sterkeste områder. Den forstår testmønstre, genererer riktige mocks og dekker de viktige grenene. Med mindre du tester ekstremt kompleks forretningslogikk med subtile invarianter, er Sonnet det riktige valget.
Oppgave 4: Refaktorer på tvers av 15 filer — Migrer tilstandshåndtering
Scenario: Migrer en React-applikasjon fra Redux med thunks til Zustand. Dette berører 15 filer: store-definisjonen, 8 tilkoblede komponenter, 3 middleware-filer og 3 utility-filer som dispatcher handlinger. Migreringen må bevare eksisterende oppførsel, inkludert optimistiske oppdateringer og angrefunksjonalitet.
Sonnet 4.6: Konverterte store og de fleste komponentene med suksess. Imidlertid ødela den logikken for optimistiske oppdateringer. Den opprinnelige Redux middleware fanget opp spesifikke handlinger for å lagre angre-snapshots før optimistiske endringer ble utført. Sonnet konverterte hver fil individuelt, men mistet koordineringen mellom middleware og komponentene som var avhengige av den. Angrefunksjonaliteten ble stille ødelagt — tester ville fanget det opp, men den strukturelle forståelsen var ikke til stede.
Opus 4.6: Håndterte hele migreringen korrekt. Før den genererte noe kode, kartla den avhengighetskjeden: hvilke komponenter som dispatchet hvilke handlinger, hva middleware fanget opp, og hvordan angre-snapshots holdt systemet sammen. Deretter restrukturerte den Zustand-store for å bevare oppførselen til middleware ved å bruke Zustands innebygde middleware-mønster, slik at koordineringen mellom angre/optimistiske oppdateringer forble intakt på tvers av alle 15 filer.
Dom: Bruk Opus. Det er her modellene skiller lag. Når en refaktorerings-oppgave krever forståelse for hvordan flere filer koordinerer for å oppnå en bestemt oppførsel (ikke bare hva hver fil gjør individuelt), lønner Opus' dypere resonnering seg. Kostnadsforskjellen er irrelevant når Sonnet produserer kode som i stillhet ødelegger funksjonalitet.
Oppgave 5: Arkitekturbeslutning — Design et cache-lag
Scenario: En backend-tjeneste gjør dyre tredjeparts API-kall. Du må designe et cache-lag. Begrensningene: noen svar kan caches i timer, andre i sekunder; cache-invalidering må skje når data endres via webhooks; systemet kjører på flere instanser bak en lastbalanserer; og teamet ønsker å unngå å legge til Redis som en avhengighet hvis mulig.
Sonnet 4.6: Anbefalte å legge til Redis. Ga en ren implementering med TTL-basert caching og webhook-trigget invalidering. God, standard løsning — men den ignorerte begrensningen om å unngå Redis. Da den ble minnet på det, foreslo den en in-memory cache med en pub/sub-mekanisme mellom instanser, men implementeringen hadde race conditions rundt cache-invalidering på tvers av instanser.
Opus 4.6: Startet med å analysere avveiningene: Redis gir operasjonell kompleksitet, men løser konsistens på tvers av instanser enkelt. Uten Redis trenger du enten en delt cache (database-basert, som motvirker formålet) eller en gossip-protokoll for cache-invalidering (komplekst, men unngår nye avhengigheter). Den foreslo deretter en lagdelt tilnærming: bruk in-process caching for elementer med kort TTL (ingen koordinering mellom instanser nødvendig siden dataene uansett endres raskt) og SQLite-basert caching med WAL-modus for elementer med lang TTL og webhook-drevet invalidering. Pragmatisk, bevisst på begrensningene, og resonnementet var synlig i hvert steg.
Dom: Bruk Opus. Arkitekturbeslutninger krever at man veier avveininger mot begrensninger. Sonnet har en tendens til å velge standardløsningen. Opus resonnerer gjennom rommet av begrensninger og finner kreative løsninger som faktisk passer til kravene. Når kostnaden for en dårlig arkitekturbeslutning er uker med omarbeid, er den ekstra token-kostnaden ubetydelig.
Oppgave 6: Analyser en ukjent kodebase
Scenario: Du har begynt i et nytt team og må forstå en Python-kodebase på 50,000 linjer uten dokumentasjon. Du må finne ut hvor autentisering håndteres, hvordan tillatelser forplanter seg gjennom middleware-stacken, og identifisere potensielle sikkerhetsproblemer i autorisasjonsflyten.
Sonnet 4.6: Analyserte filene som ble gitt i kontekst. Identifiserte korrekt auth-middleware og dekoratører for tillatelser. Gikk glipp av et subtilt problem: ett endepunkt gikk utenom standard middleware ved å bruke en annen router som ble registrert før auth-middleware i applikasjonens oppstartssekvens.
Opus 4.6: Med sitt context window på 1M tokens (beta), tok den inn betydelig mer av kodebasen samtidig. Den identifiserte de samme auth-middleware og tillatelsene, men flagget også problemet med rekkefølgen på router-registreringen, en timing-sårbarhet i logikken for token-oppdatering, og bemerket at tre endepunkter brukte en utdatert sjekk av tillatelser som ga bredere tilgang enn tiltenkt.
Dom: Bruk Opus. Analyse av store kodebaser er Opus' sterkeste fordel for kodingsoppgaver. Kombinasjonen av dypere resonnering og større effektiv kontekst betyr at den fanger opp tverrgående problemer som Sonnet overser. Spesielt for sikkerhetskritisk analyse er ikke dette stedet å optimalisere for kostnad.
Beslutningsrammeverket
Bruk dette flytskjemaet hver gang du starter en kodingsoppgave:
Trinn 1: Er oppgaven begrenset til 1-3 filer med klare krav? Bruk Sonnet.
Trinn 2: Innebærer oppgaven å lage ny kode (nye endepunkter, nye komponenter, nye tester)? Bruk Sonnet.
Trinn 3: Krever oppgaven forståelse for hvordan 5+ filer koordinerer for å oppnå en bestemt oppførsel? Bruk Opus.
Trinn 4: Innebærer oppgaven å ta en designbeslutning med motstridende begrensninger? Bruk Opus.
Trinn 5: Analyserer du en stor eller ukjent kodebase for å finne feil? Bruk Opus.
Trinn 6: Prøvde Sonnet på oppgaven og ga et ufullstendig eller feilaktig resultat? Eskaler til Opus.
Hvis du fortsatt er usikker, start med Sonnet. Du taper ingenting — hvis Sonnet håndterer det, har du spart 80% på den oppgaven. Hvis den ikke gjør det, bytter du til Opus med bedre kontekst om hva som gikk galt.
Kostnadssammenligning: Månedlige scenarioer
Her er hvordan ekte månedlige kostnader ser ut for tre ulike utviklerprofiler:
Solo-utvikler, moderat bruk (omtrent 500 oppgaver/måned):
- Kun Opus: ~$50/måned
- Kun Sonnet: ~$10/måned
- Sonnet-først strategi (80/20-fordeling): ~$18/måned
- Årlige besparelser mot kun-Opus: $384
Team på 5, tung bruk (omtrent 3,000 oppgaver/måned):
- Kun Opus: ~$300/måned
- Kun Sonnet: ~$60/måned
- Sonnet-først strategi (80/20-fordeling): ~$108/måned
- Årlige besparelser mot kun-Opus: $2,304
Enterprise-team på 20, svært tung bruk (omtrent 15,000 oppgaver/måned):
- Kun Opus: ~$1,500/måned
- Kun Sonnet: ~$300/måned
- Sonnet-først strategi (80/20-fordeling): ~$540/måned
- Årlige besparelser mot kun-Opus: $11,520
Sonnet-først-strategien sparer ikke bare penger — den sparer riktig mengde penger. Du ofrer ikke kvalitet på komplekse oppgaver. Du eliminerer sløsing på de enkle.
Sonnet-først-strategien i praksis
Her er hvordan dette fungerer i din daglige arbeidsflyt:
Morgen-standup avslører tre oppgaver: Rett en pagineringsfeil, legg til CSV-eksport på rapportsiden, og redesign arkitekturen for varslingssystemet.
Oppgave 1 — Pagineringsfeil: Åpne filen, beskriv feilen til Sonnet. Den retter det på ett forsøk. Kostnad: brøkdeler av en cent. Ferdig.
Oppgave 2 — CSV-eksport: Beskriv kravene til Sonnet. Den genererer eksport-verktøyet, legger til endepunktet, oppdaterer brukergrensesnittet med en nedlastingsknapp. Test det, fungerer. Kostnad: noen få cent. Ferdig.
Oppgave 3 — Varslingsarkitektur: Start med Sonnet for å lage et utkast til et innledende design. Utdataene er rimelige, men tar ikke hensyn til teamets eksisterende oppsett for meldingskø eller det faktum at varsler må dedupliseres på tvers av flere utløserkilder. Eskaler til Opus. Gi samme kontekst pluss de ekstra begrensningene. Opus produserer et design som integreres med den eksisterende køen, håndterer deduplisering og forklarer avveiningene den gjorde. Kostnad: høyere, men dette er en beslutning som former uker med utviklingsarbeid.
Tre oppgaver. To brukte Sonnet. Én brukte Opus. Total kostnad var omtrent 60% lavere enn å bruke Opus til alt, og kvaliteten var identisk eller bedre (fordi du fokuserte Opus-budsjettet der det faktisk betydde noe).
Bunnlinjen
Bruk Sonnet 4.6 for 80% av kodingen din. Feilrettinger, nye funksjoner, testskriving, kodegjennomgang, dokumentasjon, enkel refaktorering — Sonnet håndterer alt dette med 79.6% SWE-bench-kvalitet for $3/$15 per million tokens.
Bruk Opus 4.6 for de 20% som krever det. Refaktorering på tvers av filer med atferdsmessige avhengigheter, arkitekturbeslutninger med motstridende begrensninger, analyse av store kodebaser, sikkerhetsrevisjoner og enhver oppgave der Sonnets første forsøk ikke strekker til. Med 80.8% SWE-bench med dypere resonnering, Agent Teams-støtte og 1M kontekst beta, fortjener Opus sin premiumpris på vanskelige problemer.
Ikke velg Opus som standard av vane. Gapet på 1.2 poeng i SWE-bench er reelt, men smalt, og det viser seg bare på de vanskeligste problemene. For det store flertallet av kodingsoppgaver betaler du 5x mer for identiske resultater.
Ikke unngå Opus av gjerrighet. Når en oppgave genuint trenger dyp resonnering over flere filer eller arkitektonisk tenkning, er kostnaden for Opus ingenting sammenlignet med kostnaden ved å feilsøke Sonnets subtilt feilaktige utdata eller å levere en mangelfull arkitektur.
Utviklerne som får de beste resultatene i 2026 er ikke lojale mot én modell. De er strategiske med hvilken modell de bruker til hver oppgave. Start med Sonnet. Eskaler til Opus når du må. Det er hele strategien.
