Jeg brukte $500 på å teste Claude Sonnet 4.6 vs Opus 4.6 — Her er det jeg fant

Hvorfor jeg gjennomførte dette eksperimentet

Alle publiserer benchmark-tabeller som sammenligner Claude Sonnet 4.6 og Opus 4.6. Du kan finne dusinvis av dem med et raskt søk. Men benchmarks måler modellprestasjon på standardiserte oppgaver — de forteller deg ikke hva som skjer når du sitter til knærne i en rotete kodebase klokken 2 om natten og prøver å rulle ut en funksjon.

Jeg ønsket å svare på et enklere spørsmål: på tvers av de faktiske oppgavene jeg gjør hver dag som utvikler, når gjør Opus 4.6 seg fortjent til sin 5x prispremium?

Så jeg satte opp et kontrollert eksperiment. Over tre uker kjørte jeg hver kodeoppgave gjennom begge modellene — samme prompts, samme kodebaser, samme evalueringskriterier. Jeg sporet kostnad, kvalitet på output, tid til ferdigstillelse og antall nødvendige oppfølgingsrettinger.

Regningen kom på omtrent $500. Her er alt jeg lærte.

Oppsettet: Hvordan jeg strukturerte testen

Jeg brukte Claude API direkte med identiske system prompts for begge modellene. Ingen wrappers, ingen assistenter, ingen spesielle konfigurasjoner — bare rå API-kall slik at sammenligningen skulle bli ren.

Modeller testet:

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

Metodikk:

• Samme prompt for hver oppgave, sendt til begge modellene innenfor samme time
• Hver oppgave ble scoret på: korrekthet, kodekvalitet, fullstendighet og antall nødvendige oppfølgings-prompts
• Alle oppgaver hentet fra virkelige prosjekter — ingen syntetiske benchmarks
• Jeg scoret hver modell på en skala fra 1-10 for hver dimensjon

Prisdataene kommer direkte fra Anthropic's official pricing page. Hastighetsmålinger kommer fra Artificial Analysis benchmarks.

Scenario 1: Feilsøking av en race condition i asynkron kode

Oppgaven: En Node.js-applikasjon hadde en periodisk feil der database-skrivinger ble fullført i feil rekkefølge. Feilen dukket bare opp under belastning. Jeg ga begge modellene de relevante kildefilene (omtrent 8K tokens med kontekst) og feilloggene.

Sonnet 4.6 resultat: Identifiserte manglende await i en Promise-kjede i løpet av to runder. Foreslo å pakke skrivingen inn i en transaksjon. Ren, korrekt fiks.

Opus 4.6 resultat: Identifiserte samme rotårsak i første runde, men gikk lenger — den flagget en potensiell race condition nummer to som jeg ikke hadde lagt merke til i en tilstøtende modul. Den forklarte også hvorfor feilen var periodisk (event loop timing under samtidige tilkoblinger) og foreslo en strukturell fiks ved bruk av en skrive-kø.

Vinner: Opus 4.6

Forskjellen lå ikke i å finne feilen. Begge fant den. Opus fant den andre feilen og ga arkitektonisk kontekst som forhindret et fremtidig problem. Dette samsvarer med det Anthropic reports about Opus 4.6 having better debugging skills og evnen til å oppdage egne feil.

Kostnad: Sonnet $0.12 | Opus $0.58

Scenario 2: Bygge CRUD-endepunkter for et REST API

Oppgaven: Generere et komplett sett med CRUD-endepunkter for en "projects"-ressurs i en Express.js-applikasjon med TypeScript, Prisma ORM, input-validering via Zod, og riktig feilhåndtering.

Sonnet 4.6 resultat: Produserte alle fem endepunktene (create, read one, read all med paginering, update, delete) i ett enkelt svar. Input-validering var korrekt, feilhåndtering var solid, og TypeScript-typer var nøyaktige. Klar til å limes inn og testes.

Opus 4.6 resultat: Produserte de samme fem endepunktene med nesten identisk struktur. La til litt mer detaljerte kommentarer. Inkluderte også et forslag til middleware for autentisering som jeg ikke hadde spurt om.

Vinner: Sonnet 4.6

Resultatene var funksjonelt identiske. Sonnet var raskere, billigere, og fylte ikke svaret med uoppfordrede arkitekturforslag. For veldefinerte, avgrensede oppgaver som CRUD-generering, gir den ekstra resonneringsdybden til Opus ingenting annet enn økte kostnader.

Kostnad: Sonnet $0.08 | Opus $0.41

Scenario 3: Refaktorering av en monolittisk komponent til mindre deler

Oppgaven: En React-komponent på 600 linjer som håndterer brukerprofiler — inkludert form state, API-kall, tillatelseskontroller og renderingslogikk — måtte brytes opp i mindre, testbare deler. Jeg oppga hele komponenten pluss tilhørende testfil.

Sonnet 4.6 resultat: Delte komponenten i fire deler: en container-komponent, en form-komponent, en hook for tillatelser og en hook for API. Rimelig dekomponering. Den glemte imidlertid å oppdatere to import-stier i testfilen, og hooken for tillatelser hadde et subtilt problem med state management der den ikke brukte memoizing på en callback.

Opus 4.6 resultat: Delte den i fem deler med en renere separasjon. Den opprettet en dedikert types-fil, oppdaterte alle importer korrekt inkludert testfilen, og hooken for tillatelser var riktig memoized. Den bemerket også at den opprinnelige komponenten hadde en potensiell minnelekkasje i en cleanup-effekt og fikset den.

Vinner: Opus 4.6

Det er her gapet blir reelt. Refaktorering over flere filer med avhengighetssporing er nøyaktig det scenarioet der Opus 4.6's 76% score on MRCR v2 (resonnering over flere filer og kodegjennomgang) oversettes til praktisk verdi. Sonnet's løsning trengte to runder med rettinger. Opus leverte korrekt på første forsøk.

Kostnad: Sonnet $0.22 (inkludert rettinger) | Opus $0.95

Scenario 4: Skrive enhetstester for eksisterende kode

Oppgaven: Skrive omfattende enhetstester for en betalingsprosesseringsmodul med flere grensetilfeller — utløpte kort, utilstrekkelige midler, nettverks-timeout, delvis refusjon og valutaomregning.

Sonnet 4.6 resultat: Genererte 14 testtilfeller som dekket alle scenarioene jeg beskrev. Testene var godt strukturerte med klare describe/it-blokker. Mock-oppsettet var korrekt. To grensetilfeller jeg ikke hadde nevnt eksplisitt (tomt beløp, negativt beløp) var inkludert.

Opus 4.6 resultat: Genererte 16 testtilfeller. Lignende struktur. La til én test i integrasjonsstil som verifiserte hele betalingsflyten ende-til-ende. Litt mer ordrik i testbeskrivelsene.

Vinner: Uavgjort (Sonnet 4.6 på verdi)

Begge produserte utmerkede testsuiter. Opus la til to ekstra tester, men de var ikke betydelig bedre. For testgenerering leverer Sonnet equivalent quality at 5x lower cost. Med mindre du tester ekstremt kompleks forretningslogikk, er Sonnet det rette valget.

Kostnad: Sonnet $0.09 | Opus $0.47

Scenario 5: Skrive teknisk dokumentasjon

Oppgaven: Generere API-dokumentasjon for en intern SDK — inkludert metodesignaturer, parameterbeskrivelser, returtyper, eksempler på bruk og veiledning for feilhåndtering for 12 offentlige metoder.

Sonnet 4.6 resultat: Ren, velorganisert dokumentasjon. Hver metode hadde en beskrivelse, parametertabell, returtype, eksempel og en feilseksjon. Konsekvent formatering gjennomgående.

Opus 4.6 resultat: Nesten identisk dokumentasjon. Opus la til en seksjon for "Vanlige mønstre" på slutten som viste hvordan metoder fungerer sammen — noe som var fint, men uoppfordret.

Vinner: Sonnet 4.6

Dokumentasjon er en oppgave der Sonnet's konsisthet faktisk er en fordel. Som bemerket av developers comparing the two models, legger Opus noen ganger til unødvendige forklaringer på enkle oppgaver, noe som sløser med tokens og tid. For dokumentasjon vil du ha det klart og fullstendig, ikke ordrikt og filosofisk.

Kostnad: Sonnet $0.14 | Opus $0.72

Scenario 6: Kodegjennomgang av en Pull Request

Oppgaven: Gjennomgå en Pull Request på 400 linjer som la til et caching-lag i et API. Jeg ville at begge modellene skulle identifisere bugs, foreslå forbedringer og flagge sikkerhetsproblemer.

Sonnet 4.6 resultat: Fant tre problemer — en manglende cache-invalidering ved oppdatering, en potensiell minnelekkasje fra ubegrenset cache-vekst, og et forslag om å legge til TTL. Gode, handlingsorienterte tilbakemeldinger.

Opus 4.6 resultat: Fant de samme tre problemene pluss to til — en sårbarhet for timing-angrep i generering av cache-nøkkel og et subtilt problem der samtidige forespørsler kunne returnere utdaterte data under cache-populering. Foreslo et spesifikt mønster (read-through cache med distribuerte låser) for å fikse problemene med samtidighet.

Vinner: Opus 4.6

Kodegjennomgang av sikkerhetsrelevant kode er et annet område der Opus drar i fra. Sårbarheten for timing-angrep var reell og ikke åpenbar. Dette samsvarer med reports from developers som opplever at Opus er spesielt sterk når feilen spenner over en stor arkitektonisk flate.

Kostnad: Sonnet $0.11 | Opus $0.53

Scenario 7: Hurtig prototyping av en ny funksjon

Oppgaven: Bygge et varslingssystem i sanntid ved bruk av WebSockets — server-side handler, client-side hook og en varslingskomponent med animasjoner. Tid var prioritet, ikke perfeksjon.

Sonnet 4.6 resultat: Leverte en fungerende implementering i ett enkelt svar. WebSocket-handleren, den tilpassede React-hooken og varslingskomponenten fungerte alle sammen. Animasjonen var CSS-basert og smidig. Mindre problem: ingen logikk for gjenoppretting av tilkobling.

Opus 4.6 resultat: Output av lignende kvalitet, men inkluderte logikk for gjenoppretting av tilkobling og en strategi for exponential backoff. La også til en heartbeat-mekanisme. Tok omtrent 30% lengre tid å generere på grunn av lavere token-hastighet.

Vinner: Sonnet 4.6

For prototyping betyr hastighet mer enn fullstendighet. Sonnet's faster output generation (omtrent 47 tokens per sekund mot 40 for Opus) betyr tettere iterasjonssykluser. Logikken for gjenoppretting som Opus la til var fin, men jeg ville ha lagt til det i en senere runde uansett. Prototyping belønner raske, gode nok resultater.

Kostnad: Sonnet $0.10 | Opus $0.48

Scenario 8: Arkitektoniske beslutninger

Oppgaven: Vi måtte velge mellom en monorepo- og polyrepo-struktur for et microservices-prosjekt. Jeg oppga teamstørrelse, distribusjonskrav, CI/CD-begrensninger og tjenestegrenser. Jeg ba begge modellene analysere avveininger og anbefale en tilnærming.

Sonnet 4.6 resultat: Ga en solid analyse av fordeler og ulemper. Anbefalte monorepo med Turborepo basert på teamstørrelse. Rimelig, men noe generisk.

Opus 4.6 resultat: Stilte tre avklarende spørsmål før den forpliktet seg til en anbefaling — om distribusjonsfrekvens, dataavhengigheter mellom tjenester og om teamet hadde erfaring med monorepo. Etter at jeg svarte, ga den en nyansert analyse som anbefalte en hybrid tilnærming: monorepo for delte biblioteker og tett koblede tjenester, og separate repos for tjenester som distribueres uavhengig med ulike lanseringssykluser. Den skisserte også en migreringssti fra nåværende struktur.

Vinner: Opus 4.6

Opus håndterer tvetydighet bedre. Som multiple developer reports confirm, stiller Opus bedre avklarende spørsmål og gjør mer forsvarlige antakelser. For seniorentusiaster som jobber med komplekse arkitektoniske beslutninger, sparer den oppførselen timer med frem-og-tilbake.

Kostnad: Sonnet $0.07 | Opus $0.62

Poengoversikten

Her er hvordan hver modell presterte på tvers av alle åtte scenarioer, scoret på en skala fra 1-10 for kvalitet på output:

Opus 4.6 vinner: 4 scenarioer (feilsøking, refaktorering, kodegjennomgang, arkitektur) Sonnet 4.6 vinner: 2 scenarioer (dokumentasjon, prototyping) Uavgjort: 2 scenarioer (CRUD-endepunkter, skriving av tester)

Men her er den delen poengoversikten skjuler: Sonnet 4.6 var det rette valget i 6 av 8 scenarioer når man regner inn kostnad. De to scenarioene der den scoret merkbart lavere (refaktorering og arkitektur) er oppgaver de fleste utviklere gjør noen få ganger i uken, ikke dusinvis av ganger om dagen.

Kostnadsvirkeligheten

Over tre uker med testing så regningen slik ut:

Opus kostet i gjennomsnitt 5.25x mer per oppgave. For det identiske settet med oppgaver leverte Sonnet 90% av kvaliteten til 19% av kostnaden.

Hvis jeg hadde brukt en hybrid tilnærming — Sonnet for rutineoppgaver, og Opus kun for de 20% av oppgavene som involverte refaktorering, feilsøking og arkitektur — ville den totale regningen min vært omtrent $160 i stedet for $500. Det er en reduksjon på 68% med nesten null kvalitetstap.

Dette er i samsvar med hva production deployments report: hybrid-router-mønsteret der 80-90% av forespørslene går til Sonnet og kun kritiske oppgaver eskaleres til Opus, sparer 60-80% på API-kostnader.

Tre mønstre jeg la merke til som benchmarks ikke fanger opp

1. Opus er bedre til å si "vent, jeg trenger mer informasjon"

Ved tvetydige prompts har Sonnet en tendens til å velge en rimelig standard og kjøre på. Opus tar en pause og spør. Dette er utrolig verdifullt for arkitektonisk arbeid, men litt irriterende for rutineoppgaver der du bare vil at den skal ta et valg og gå videre.

2. Sonnet er bedre til å følge instruksjoner bokstavelig

Når jeg ga en detaljert spesifikasjon, bygde Sonnet nøyaktig det jeg ba om. Opus "forbedret" noen ganger ting jeg ikke hadde bedt den om å forbedre — la til abstraksjonslag, foreslo mønstre, og inkluderte grensetilfeller utenfor omfanget. For oppgaver der du vil ha lydighet fremfor kreativitet, vinner Sonnet.

3. Kvalitetsgapet øker med kontekstlengden

For oppgaver under 10K tokens med kontekst, kunne jeg knapt se forskjell på modellene. Med en gang konteksten oversteg 30K tokens — store refaktoreringer, gjennomgang av flere filer — ble Opus merkbart mer sammenhengende. Dette samsvarer med Opus 4.6's 76% score on MRCR v2 for resonnering over flere filer i lange kontekster.

Hvor benchmarkene lander (for referanse)

For de som vil ha tallene, her er de viktigste benchmarkene per mars 2026:

Kilder: Anthropic model overview, Artificial Analysis, Claude 5 benchmark analysis

SWE-bench-gapet er bare 1.2 poeng. Men GPQA Diamond-gapet (vitenskapelig resonnering) er enormt — 17 poeng. Og MRCR v2-gapet (arbeid over flere filer i lang kontekst) er der den virkelige praktiske forskjellen ligger.

Min anbefaling: Rammeverk for beslutninger

Etter $500 og tre uker med testing, her er mitt beslutningstre:

Bruk Sonnet 4.6 når:

• Oppgaven er veldefinert med klare krav
• Du skriver ny kode fra bunnen av (endepunkter, komponenter, skript)
• Du trenger rask iterasjonshastighet (prototyping, utforskende koding)
• Du genererer tester eller dokumentasjon
• Kontekstlengden er under 20K tokens
• Du har et budsjett eller håndterer høyt volum av forespørsler

Bruk Opus 4.6 når:

• Oppgaven involverer refaktorering på tvers av flere filer med komplekse avhengigheter
• Du trenger at modellen resonnerer over avveininger før den låser seg til et design
• Du feilsøker ikke-åpenbare problemer i store kodebaser
• Du gjennomgår sikkerhetskritisk kode
• Kontekstlengden overstiger 30K tokens og sammenheng er viktig
• Kostnaden ved et feilsvar overstiger kostnaden ved selve modellkallet

Bruk begge (hybrid-router) når:

• Du bygger et produksjonssystem med blandet kompleksitet i oppgavene
• Du vil ha 60-80% cost savings fra Sonnet med sikkerhetsnettet til Opus for vanskelige problemer

For team som bygger utviklerverktøy — vi bruker en versjon av denne hybrid-tilnærmingen hos ZBuild — har router-mønsteret blitt bransjestandard i 2026.

Hva jeg ville gjort annerledes

Hvis jeg skulle gjennomført dette eksperimentet igjen, ville jeg lagt til en tredje dimensjon: måling av hvor mange oppfølgings-prompts hver modell trengte for å nå et produksjonsklart resultat. Min magefølelse sier at dette ville favorisert Opus sterkere på komplekse oppgaver, fordi dens nøyaktighet på første forsøk var konsekvent høyere for arbeid over flere filer.

Jeg ville også testet med extended thinking aktivert for Opus, som angivelig forbedrer dens allerede sterke feilsøking og arkitektoniske resonnering.

Konklusjonen: start med Sonnet 4.6 for alt. Du vil merke — raskt — når en oppgave krever Opus. Oppgavene som krever det er spesifikke, relativt sjeldne, og har høy nok verdi til å rettferdiggjøre prispåslaget.

Kilder

• Anthropic — Introducing Claude Opus 4.6
• Anthropic — Claude Models Overview
• Anthropic — Claude Pricing
• Artificial Analysis — Claude Sonnet 4.6 Performance
• Claude 5 — Opus 4.6 Benchmark Analysis
• Bind AI — Sonnet 4.6 vs Opus 4.6 for Coding
• Emergent — Claude Sonnet vs Opus 2026
• DEV Community — Opus 4.6 vs Sonnet 4.6 Coding Comparison
• Macaron — Claude Opus 4.6 for Code Review
• Apiyi — Opus 4.6 vs Sonnet 4.6 Comparison Guide
• Medium — Tested Sonnet 4.6 vs Opus 4.6 for Vibe Coding