Jeg brugte $500 på at teste Claude Sonnet 4.6 vs Opus 4.6 — Her er hvad jeg fandt

Hvorfor jeg udførte dette eksperiment

Alle udgiver benchmark-tabeller, der sammenligner Claude Sonnet 4.6 og Opus 4.6. Du kan finde en snes af dem med en hurtig søgning. Men benchmarks måler model-performance på standardiserede opgaver — de fortæller dig ikke, hvad der sker, når du sidder til knæene i en rodet codebase klokken 2 om natten og prøver at færdiggøre en feature.

Jeg ønskede at besvare et enklere spørgsmål: På tværs af de faktiske opgaver, jeg udfører hver dag som udvikler, hvornår gør Opus 4.6 sig fortjent til sin 5x pris-premium?

Så jeg opsatte et kontrolleret eksperiment. Over tre uger kørte jeg hver eneste kodningsopgave gennem begge modeller — samme prompts, samme codebases, samme evalueringskriterier. Jeg sporede omkostninger, output-kvalitet, tid til færdiggørelse og antallet af nødvendige opfølgende rettelser.

Regningen løb op i cirka $500. Her er alt, hvad jeg har lært.

Opsætningen: Hvordan jeg strukturerede testen

Jeg brugte Claude API direkte med identiske system prompts for begge modeller. Ingen wrappers, ingen assistenter, ingen specielle konfigurationer — bare rå API-kald, så sammenligningen blev ren.

Testede modeller:

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

Metodik:

• Samme prompt for hver opgave, sendt til begge modeller inden for samme time
• Hver opgave blev scoret på: korrekthed, kodekvalitet, fuldstændighed og antallet af nødvendige opfølgende prompts
• Alle opgaver er taget fra virkelige projekter — ingen syntetiske benchmarks
• Jeg scorede hver model på en skala fra 1-10 for hver dimension

Prisdata kommer direkte fra Anthropic's officielle prisside. Hastighedsmålinger kommer fra Artificial Analysis benchmarks.

Scenarie 1: Fejlfinding af en Race Condition i Async-kode

Opgaven: En Node.js applikation havde en periodisk fejl, hvor database-skrivninger blev udført i forkert rækkefølge. Fejlen opstod kun under belastning. Jeg gav begge modeller de relevante kildefiler (ca. 8K tokens af kontekst) og fejlloggerne.

Sonnet 4.6 resultat: Identificerede det manglende await i en Promise-kæde inden for to udvekslinger. Foreslog at pakke skrivningerne ind i en transaktion. Ren, korrekt rettelse.

Opus 4.6 resultat: Identificerede den samme rodårsag ved første udveksling, men gik videre — den markerede en anden potentiel race condition, som jeg ikke havde bemærket i et tilstødende modul. Den forklarede også, hvorfor fejlen var periodisk (event loop timing under samtidige forbindelser) og foreslog en strukturel rettelse ved hjælp af en skrive-kø.

Vinder: Opus 4.6

Forskellen lå ikke i at finde fejlen. Begge fandt den. Opus fandt den anden fejl og gav arkitektonisk kontekst, der forhindrede et fremtidigt problem. Dette stemmer overens med, hvad Anthropic rapporterer om, at Opus 4.6 har bedre debugging-færdigheder og evnen til at fange sine egne fejl.

Omkostning: Sonnet $0.12 | Opus $0.58

Scenarie 2: Opbygning af CRUD-endpoints til et REST API

Opgaven: Generer et komplet sæt CRUD-endpoints til en "projects" ressource i en Express.js applikation med TypeScript, Prisma ORM, input-validering via Zod og korrekt fejlhåndtering.

Sonnet 4.6 resultat: Producerede alle fem endpoints (create, read one, read all med paginering, update, delete) i et enkelt svar. Input-validering var korrekt, fejlhåndtering var solid, TypeScript typer var nøjagtige. Klar til at kopiere og teste.

Opus 4.6 resultat: Producerede de samme fem endpoints med næsten identisk struktur. Tilføjede lidt mere detaljerede kommentarer. Inkluderede også et forslag til middleware til autentificering, som jeg ikke havde bedt om.

Vinder: Sonnet 4.6

Outputtene var funktionelt identiske. Sonnet var hurtigere, billigere og polstrede ikke svaret med uopfordrede arkitekturforslag. For veldefinerede, afgrænsede opgaver som CRUD-generering tilføjer den ekstra ræsonnementsdybde i Opus intet andet end omkostninger.

Omkostning: Sonnet $0.08 | Opus $0.41

Scenarie 3: Refaktorering af en monolitisk komponent til mindre dele

Opgaven: En React komponent på 600 linjer, der håndterer brugerprofiler — inklusiv form-state, API-kald, tilladelsestjek og renderingslogik — skulle opdeles i mindre, testbare dele. Jeg leverede hele komponenten plus dens testfil.

Sonnet 4.6 resultat: Opdelte komponenten i fire dele: en container-komponent, en form-komponent, et tilladelses-hook og et API-hook. Fornuftig dekomponering. Den glemte dog at opdatere to import-stier i testfilen, og tilladelses-hooket havde et subtilt state management-problem, hvor det ikke memoizede et callback.

Opus 4.6 resultat: Opdelt i fem dele med en renere adskillelse. Den oprettede en dedikeret types-fil, opdaterede korrekt alle imports inklusiv testfilen, og tilladelses-hooket var korrekt memoized. Den bemærkede også, at den oprindelige komponent havde et potentielt memory leak i en effect-cleanup og rettede det.

Vinder: Opus 4.6

Det er her, gabet bliver virkeligt. Multi-fil refaktorering med afhængighedssporing er præcis det scenarie, hvor Opus 4.6's score på 76% på MRCR v2 (multi-fil ræsonnement og kodeanmeldelse) oversættes til praktisk værdi. Sonnets løsning krævede to runder med rettelser. Opus leverede korrekt i første forsøg.

Omkostning: Sonnet $0.22 (inklusiv rettelser) | Opus $0.95

Scenarie 4: Skrivning af Unit Tests til eksisterende kode

Opgaven: Skriv omfattende unit tests til et betalingsmodul med flere kanttilfælde — udløbne kort, utilstrækkelige midler, netværks-timeouts, delvise refusioner og valutaomregning.

Sonnet 4.6 resultat: Genererede 14 testcases, der dækkede alle de scenarier, jeg beskrev. Testene var velstrukturerede med klare describe/it-blokke. Mock-setup var korrekt. To kanttilfælde, jeg ikke eksplicit havde nævnt (tomt beløb, negativt beløb), blev inkluderet.

Opus 4.6 resultat: Genererede 16 testcases. Lignende struktur. Tilføjede en test i integrationsstil, der verificerede hele betalingsflowet end-to-end. Lidt mere ordrig i testbeskrivelserne.

Vinder: Uafgjort (Sonnet 4.6 på værdi)

Begge producerede fremragende test-suites. Opus tilføjede to ekstra tests, men de var ikke betydeligt bedre. Til testgenerering leverer Sonnet tilsvarende kvalitet til en 5x lavere pris. Medmindre du tester ekstremt kompleks forretningslogik, er Sonnet det rigtige valg.

Omkostning: Sonnet $0.09 | Opus $0.47

Scenarie 5: Skrivning af teknisk dokumentation

Opgaven: Generer API-dokumentation til en intern SDK — inklusiv metode-signaturer, parameterbeskrivelser, returtyper, eksempler på brug og vejledning i fejlhåndtering for 12 offentlige metoder.

Sonnet 4.6 resultat: Ren, velorganiseret dokumentation. Hver metode havde en beskrivelse, parametertabel, returtype, eksempel og fejlsektion. Konsekvent formatering overalt.

Opus 4.6 resultat: Næsten identisk dokumentation. Opus tilføjede en "Common Patterns"-sektion til sidst, der viste, hvordan metoderne kan sammensættes — hvilket var fint, men uopfordret.

Vinder: Sonnet 4.6

Dokumentation er en opgave, hvor Sonnets kortfattethed faktisk er en fordel. Som bemærket af udviklere, der sammenligner de to modeller, tilføjer Opus undertiden unødvendige forklaringer på enkle opgaver, hvilket spilder tokens og tid. Til dokumentation ønsker du klarhed og fuldstændighed, ikke ordrigdom og filosofi.

Omkostning: Sonnet $0.14 | Opus $0.72

Scenarie 6: Code Review på en Pull Request

Opgaven: Gennemse en pull request på 400 linjer, der tilføjede et caching-lag til et API. Jeg ønskede, at begge modeller skulle identificere fejl, foreslå forbedringer og markere sikkerhedsproblemer.

Sonnet 4.6 resultat: Fandt tre problemer — en manglende cache-invalidering ved opdatering, et potentielt memory leak fra ubegrænset cache-vækst og et forslag om at tilføje TTL. God, brugbar feedback.

Opus 4.6 resultat: Fandt de samme tre problemer plus to mere — en timing attack-sårbarhed i genereringen af cache-nøgler og et subtilt problem, hvor samtidige forespørgsler kunne returnere forældede data under cache-populering. Foreslog et specifikt mønster (read-through cache med distribuerede låse) for at løse samtidighedsproblemet.

Vinder: Opus 4.6

Code review på sikkerhedsrelevant kode er et andet område, hvor Opus trækker fra. Timing attack-sårbarheden var reel og ikke indlysende. Dette matcher rapporter fra udviklere, der finder Opus særligt stærk, når fejlen spænder over en stor arkitektonisk overflade.

Omkostning: Sonnet $0.11 | Opus $0.53

Scenarie 7: Hurtig prototyping af en ny funktion

Opgaven: Byg et realtids-notifikationssystem ved hjælp af WebSockets — server-side handler, client-side hook og en notifikationskomponent med animationer. Tid var prioriteten, ikke perfektion.

Sonnet 4.6 resultat: Leverede en fungerende implementering i et enkelt svar. WebSocket-handleren, det brugerdefinerede React-hook og notifikationskomponenten fungerede alle sammen. Animationen var CSS-baseret og glidende. Mindre problem: ingen reconnection logic.

Opus 4.6 resultat: Output af lignende kvalitet, men inkluderede reconnection logic og en exponential backoff-strategi. Tilføjede også en heartbeat-mekanisme. Tog ca. 30% længere tid at generere på grund af lavere token-hastighed.

Vinder: Sonnet 4.6

Til prototyping betyder hastighed mere end fuldstændighed. Sonnets hurtigere output-generering (ca. 47 tokens i sekundet mod 40 for Opus) betyder strammere iterationscyklusser. Reconnection logic, som Opus tilføjede, var fin, men jeg ville alligevel have tilføjet det i anden omgang. Prototyping belønner hurtigt, godt-nok output.

Omkostning: Sonnet $0.10 | Opus $0.48

Scenarie 8: Arkitektonisk beslutningstagning

Opgaven: Vi skulle vælge mellem en monorepo- og polyrepo-struktur til et microservices-projekt. Jeg oplyste teamstørrelse, implementeringskrav, CI/CD-begrænsninger og servicegrænser. Jeg bad begge modeller om at analysere fordele og ulemper og anbefale en tilgang.

Sonnet 4.6 resultat: Gav en solid fordele/ulemper-analyse. Anbefalede en monorepo med Turborepo baseret på teamstørrelse. Fornuftig, men noget generisk.

Opus 4.6 resultat: Stillede tre opklarende spørgsmål, før den forpligtede sig til en anbefaling — om implementeringsfrekvens, datadependenser på tværs af services, og om teamet havde erfaring med monorepos. Efter jeg svarede, gav den en nuanceret analyse, der anbefalede en hybrid tilgang: monorepo til delte biblioteker og tæt koblede services, separate repos til uafhængigt implementerede services med forskellige release-cyklusser. Den skitserede også en migrationsvej fra den nuværende struktur.

Vinder: Opus 4.6

Opus håndterer tvetydighed bedre. Som flere udviklerrapporter bekræfter, stiller Opus bedre opklarende spørgsmål og træffer mere forsvarlige antagelser. For senior-ingeniører, der arbejder med komplekse arkitektoniske beslutninger, sparer den adfærd timers frem-og-tilbage.

Omkostning: Sonnet $0.07 | Opus $0.62

Det endelige resultatkort

Her er, hvordan hver model præsterede på tværs af alle otte scenarier, scoret på en skala fra 1-10 for output-kvalitet:

Opus 4.6 vinder: 4 scenarier (fejlfinding, refaktorering, code review, arkitektur) Sonnet 4.6 vinder: 2 scenarier (dokumentation, prototyping) Uafgjort: 2 scenarier (CRUD-endpoints, testskrivning)

Men her er den del, som resultatkortet skjuler: Sonnet 4.6 var det rigtige valg i 6 ud af 8 scenarier, når man tager omkostningerne med i betragtning. De to scenarier, hvor den scorede mærkbart lavere (refaktorering og arkitektur), er opgaver, som de fleste udviklere udfører et par gange om ugen, ikke snesevis af gange om dagen.

Omkostningsrealiteten

Over tre uger med test så regningen således ud:

Opus kostede i gennemsnit 5.25x mere pr. opgave. For det identiske sæt opgaver leverede Sonnet 90% af kvaliteten til 19% af omkostningerne.

Hvis jeg havde brugt hybrid-tilgangen — Sonnet til rutineopgaver, Opus kun til de 20% af opgaverne, der involverede refaktorering, fejlfinding og arkitektur — ville min samlede regning have været på ca. $160 i stedet for $500. Det er en reduktion på 68% med næsten intet kvalitetstab.

Dette stemmer overens med, hvad produktionsimplementeringer rapporterer: hybrid-router-mønsteret, hvor 80-90% af forespørgslerne går til Sonnet, og kun kritiske opgaver eskaleres til Opus, sparer 60-80% på API-omkostninger.

Tre mønstre jeg bemærkede, som benchmarks ikke fanger

1. Opus er bedre til at sige "vent, jeg har brug for mere information"

Ved tvetydige prompts har Sonnet tendens til at vælge en rimelig standard og køre med den. Opus holder pause og spørger. Dette er utroligt værdifuldt til arkitektonisk arbejde, men en smule irriterende til rutineopgaver, hvor man bare vil have den til at træffe et valg og komme videre.

2. Sonnet is better at following instructions literally

Når jeg gav en detaljeret specifikation, byggede Sonnet præcis det, jeg bad om. Opus "forbedrede" undertiden ting, jeg ikke bad den om at forbedre — tilføjede abstraktionslag, foreslog mønstre, inkluderede kanttilfælde uden for rammen. Til opgaver, hvor man ønsker overholdelse frem for kreativitet, vinder Sonnet.

3. Kvalitetsgabet øges med kontekstlængden

For opgaver med under 10K tokens af kontekst kunne jeg næsten ikke se forskel på modellerne. Da konteksten oversteg 30K tokens — store refaktoreringer, anmeldelser af flere filer — blev Opus mærkbart mere sammenhængende. Dette stemmer overens med Opus 4.6's score på 76% på MRCR v2 for multi-fil ræsonnement i lange kontekster.

Hvor benchmarks lander (til reference)

For dem, der ønsker tallene, er her de vigtigste benchmarks pr. marts 2026:

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

SWE-bench-gabet er kun 1.2 point. Men GPQA Diamond-gabet (videnskabeligt ræsonnement) er massivt — 17 point. Og MRCR v2-gabet (multi-fil arbejde i lang kontekst) er der, hvor den reelle praktiske forskel ligger.

Min anbefaling: Beslutningsrammen

Efter $500 og tre uger med test er her mit beslutningstræ:

Brug Sonnet 4.6 når:

• Opgaven er veldefineret med klare krav
• Du skriver ny kode fra bunden (endpoints, komponenter, scripts)
• Du har brug for hurtig iterationshastighed (prototyping, eksplorativ kodning)
• Du genererer tests eller dokumentation
• Kontekstlængden er under 20K tokens
• Du er på et budget eller håndterer store mængder forespørgsler

Brug Opus 4.6 når:

• Opgaven involverer refaktorering på tværs af flere filer med komplekse afhængigheder
• Du har brug for, at modellen ræsonnerer over kompromiser, før den lægger sig fast på et design
• Du fejlsøger ikke-indlysende problemer i store codebases
• Du gennemser sikkerhedskritisk kode
• Kontekstlængden overstiger 30K tokens, og sammenhæng er vigtig
• Omkostningen ved et forkert svar overstiger omkostningen ved model-kaldet

Brug begge (hybrid-router) når:

• Du bygger et produktionssystem med blandet opgavekompleksitet
• Du ønsker de 60-80% omkostningsbesparelser ved Sonnet med sikkerhedsnettet fra Opus til de svære problemer

For teams, der bygger udviklerværktøjer — vi bruger en version af denne hybrid-tilgang hos ZBuild — er router-mønsteret blevet branchestandarden for 2026.

Hvad jeg ville gøre anderledes

Hvis jeg kørte dette eksperiment igen, ville jeg tilføje en tredje dimension: måling af, hvor mange opfølgende prompts hver model havde brug for for at nå et produktionsklar output. Min mavefornemmelse siger, at dette ville favorisere Opus stærkere på komplekse opgaver, fordi dens nøjagtighed i første forsøg var konsekvent højere for multi-fil arbejde.

Jeg ville også teste med extended thinking aktiveret for Opus, hvilket efter sigende forbedrer dens i forvejen stærke debugging og arkitektoniske ræsonnement.

Den vigtigste konklusion: start med Sonnet 4.6 til alt. Du vil hurtigt mærke, når en opgave kræver Opus. De opgaver, der kræver det, er specifikke, relativt sjældne og værdifulde nok til at retfærdiggøre merprisen.

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