Eksperimentet
Jeg tog 10 virkelige kodningsopgaver — den slags som udviklere rent faktisk udfører hver dag — og indsendte nøjagtig den samme prompt til både GPT-5.4 og Claude Opus 4.6. Samme system prompt, samme kontekst, samme evalueringskriterier.
Ingen syntetiske benchmarks. Ingen håndplukkede eksempler. Kun virkelige opgaver bedømt ud fra tre dimensioner:
- Korrekthed (virker det uden ændringer?)
- Kodekvalitet (læsbarhed, typer, fejlhåndtering, kanttilfælde)
- Effektivitet (token brug, responstid, antal nødvendige opfølgende prompts)
Hver dimension scores fra 1-10. Maksimal mulig score per opgave: 30.
Modellerne blev tilgået via deres respektive API'er til standardpriser: GPT-5.4 til $2.50/$15 per million tokens og Claude Opus 4.6 til $15/$75 per million tokens.
Her er de 10 opgaver og præcis hvad der skete.
Opgave 1: Byg et REST API Endpoint
Prompt: "Create a POST /api/users endpoint in Express.js with TypeScript. Validate email format and password strength (min 8 chars, 1 uppercase, 1 number). Hash the password with bcrypt. Store in PostgreSQL via Prisma. Return the user without the password field. Handle duplicate emails with a 409 status."
GPT-5.4 Resultat
Ren, produktionsklar kode. Zod valideringsskemaet var præcist. Bcrypt hashing brugte en korrekt salt round konstant. Prisma forespørgslen brugte select til at ekskludere password-feltet på databaseniveau fremfor at slette det fra respons-objektet — en subtil men vigtig sikkerhedspraksis. TypeScript typerne var stærke.
Claude Opus 4.6 Resultat
Også ren og korrekt. Brugte en lignende Zod valideringsmetode, men tilføjede rate limiting middleware til endpointet og inkluderede en kommentar, der forklarede hvorfor. Ekskluderingen af password brugte Prismas omit funktion. Tilføjede en try/catch med specifikke fejltyper for Prisma unique constraint overtrædelser.
Scores
| Dimension | GPT-5.4 | Opus 4.6 |
|---|---|---|
| Korrekthed | 10 | 10 |
| Kodekvalitet | 9 | 9 |
| Effektivitet | 9 | 8 |
| Total | 28 | 27 |
Vinder: GPT-5.4 (marginalt, på hastighed og kortfattethed)
Begge outputs var fremragende. GPT-5.4 var hurtigere og brugte færre tokens. Opus tilføjede rate limiting middleware uden at være blevet bedt om det — nyttigt, men ikke efterspurgt. Til veldefinerede API opgaver er modellerne i det væsentlige udskiftelige.
Opgave 2: Byg en React Komponent
Prompt: "Create a React component called DataTable that accepts generic typed data, supports sortable columns, pagination (client-side), a search filter, and row selection with checkboxes. Use TypeScript generics. No UI library — just HTML/CSS with CSS modules. Include proper ARIA attributes."
GPT-5.4 Resultat
Leverede en velstruktureret generisk komponent. TypeScript generics blev brugt korrekt til kolonne-definitionen og datatyperne. Sorteringslogikken var ren med en tilpasset useSortable hook udtrukket. Pagination brugte useMemo for ydeevne. ARIA attributter var korrekte — role="grid", aria-sort på sorterbare headers, aria-selected på tjekbokse.
Claude Opus 4.6 Resultat
Lignende struktur men med et par forskelle. Opus oprettede en useDataTable hook, der indkapslede sortering, pagination og filtreringslogik — renere adskillelse men mere abstraktion. TypeScript generics var lige så korrekte. Manglede aria-sort på header-cellerne. CSS modulet inkluderede et responsivt layout, der skiftede til kortvisning på mobil, hvilket ikke var efterspurgt, men var en gennemtænkt tilføjelse.
Scores
| Dimension | GPT-5.4 | Opus 4.6 |
|---|---|---|
| Korrekthed | 10 | 9 |
| Kodekvalitet | 9 | 9 |
| Effektivitet | 9 | 8 |
| Total | 28 | 26 |
Vinder: GPT-5.4
GPT-5.4's ARIA implementering var mere komplet, hvilket betyder noget for en komponent, der skal bruges på tværs af en applikation. Som bemærket af MindStudios sammenligning, excellerer GPT-5.4 i boilerplate generering inklusiv React komponenter og TypeScript interfaces.
Opgave 3: Skriv en kompleks SQL-forespørgsel
Prompt: "Write a PostgreSQL query that returns the top 10 customers by lifetime value (total order amount) who have placed at least 3 orders in the last 12 months, including their most recent order date, average order value, and the percentage change in their spending compared to the previous 12-month period. Use CTEs for readability."
GPT-5.4 Resultat
Tre CTEs: en til aggregering af den nuværende periode, en til aggregering af den foregående periode, og en til beregning af procenter. Rent, korrekt og velformateret. Brugte COALESCE til at håndtere kunder uden data fra den foregående periode. Tilføjede en kommentar med index hint.
Claude Opus 4.6 Resultat
Fire CTEs med en lidt anden struktur: adskilte beregningen af "sidste ordredato" i sin egen CTE for at undgå en korreleret underforespørgsel. Tilføjede en NULLIF for at forhindre division med nul i procentberegningen — et reelt kanttilfælde som GPT-5.4 oversså. Inkluderede et alternativ med window function i en kommentarblok.
Scores
| Dimension | GPT-5.4 | Opus 4.6 |
|---|---|---|
| Korrekthed | 9 | 10 |
| Kodekvalitet | 8 | 9 |
| Effektivitet | 9 | 8 |
| Total | 26 | 27 |
Vinder: Claude Opus 4.6
Division-med-nul kanttilfældet var den afgørende faktor. I produktions-SQL forårsager den slags fejl lydløs datakorruption. Opus finder konsekvent kanttilfælde, der betyder noget i virkelighedens datapipelines.
Opgave 4: Debug en Race Condition
Prompt: Jeg leverede 3 filer (~200 linjer i alt) fra en Node.js applikation med en intermitterende testfejl. Fejlen var en race condition i et caching-lag, hvor samtidige cache misses kunne udløse duplikerede database-forespørgsler og inkonsekvent tilstand. "Find the bug, explain why it only manifests intermittently, and provide a fix."
GPT-5.4 Resultat
Identificerede den korrekte cache miss kodevej. Foreslog at tilføje en mutex lock ved hjælp af async-mutex. Rettelsen var korrekt, men behandlede symptomet snarere end rodårsagen — den serialiserede alle cache-adgange, hvilket ville skade ydeevnen under belastning.
Claude Opus 4.6 Resultat
Identificerede den samme kodevej, men sporede også tilstandsinkonsekvensen til et andet problem: cache-opdateringen var ikke atomar — der var et vindue mellem læse-tjekket og skrivningen, hvor en anden anmodning kunne flette sig ind. Opus foreslog et "single-flight" mønster (sammenlægning af samtidige identiske anmodninger) i stedet for en global mutex. Rettelsen var mere kirurgisk og bevarede samtidighed for cache-nøgler uden konflikter.
Scores
| Dimension | GPT-5.4 | Opus 4.6 |
|---|---|---|
| Korrekthed | 7 | 10 |
| Kodekvalitet | 7 | 9 |
| Effektivitet | 8 | 8 |
| Total | 22 | 27 |
Vinder: Claude Opus 4.6
En tydelig forskel. Opus forstod samtidighedsmodellen dybt nok til at foreslå en målrettet rettelse. Dette stemmer overens med Claude Opus 4.6's 80.8% score på SWE-bench Verified, som tester netop denne form for fejlafhjælpning i virkelige scenarier.
Opgave 5: Code Review
Prompt: Jeg leverede en 350-linjers pull request, der tilføjede et nyt betalingsbehandlingsmodul. "Review this PR for bugs, security issues, performance problems, and code quality. Prioritize findings by severity."
GPT-5.4 Resultat
Fandt 5 problemer: et manglende null-tjek på betalingsresponsen, en ubehandlet promise rejection, en hårdkodet timeout der burde være konfigurerbar, en manglende idempotency key, og et forslag om at udtrække magic numbers til konstanter. Organiseret efter alvorlighed. Klart og handlingsorienteret.
Claude Opus 4.6 Resultat
Fandt 8 problemer: de samme 5 som GPT-5.4 fandt plus tre mere — en TOCTOU (time-of-check-time-of-use) sårbarhed i beløbsvalideringen, et potentielt informationslæk i fejlresponsen der eksponerede interne stack traces, og et subtilt problem hvor retry logik kunne forårsage dobbelt-debitering, hvis den første anmodning lykkedes, men responserne gik tabt. Hvert fund inkluderede det specifikke linjenummer og en foreslået rettelse.
Scores
| Dimension | GPT-5.4 | Opus 4.6 |
|---|---|---|
| Korrekthed | 8 | 10 |
| Kodekvalitet | 8 | 10 |
| Effektivitet | 9 | 8 |
| Total | 25 | 28 |
Vinder: Claude Opus 4.6
De tre ekstra fund var alle sikkerhedskritiske. Alene fejlen med dobbelt-debitering kunne koste en virksomhed betydelige beløb og omdømme. Opus's 76% på MRCR v2 (multi-file reasoning) oversættes direkte til bedre code review på komplekse moduler.
Opgave 6: Skriv en Test Suite
Prompt: "Write comprehensive tests for this authentication middleware using Vitest. Cover: valid tokens, expired tokens, malformed tokens, missing authorization header, revoked tokens, rate limiting, and concurrent authentication requests." Jeg leverede middleware-kildekoden (~120 linjer).
GPT-5.4 Resultat
Genererede 18 test cases organiseret i rene describe blokke. Hvert scenarie fra prompten blev dækket. Tilføjede tre ekstra kanttilfælde: tom streng token, token med forkert algoritme, og authorization header med kun blanktegn. Mocks var velstrukturerede ved hjælp af vi.mock. Testbeskrivelser var klare og fulgte "should X when Y" mønsteret.
Claude Opus 4.6 Resultat
Genererede 15 test cases. Alle efterspurgte scenarier blev dækket. Teststrukturen brugte en helper factory til at oprette tokens med forskellige egenskaber — smart, men tilføjede kompleksitet. Manglede testen for "concurrent authentication requests", som eksplicit var efterspurgt. Mocks var renere, men antallet af tests var lavere.
Scores
| Dimension | GPT-5.4 | Opus 4.6 |
|---|---|---|
| Korrekthed | 10 | 8 |
| Kodekvalitet | 9 | 9 |
| Effektivitet | 9 | 8 |
| Total | 28 | 25 |
Vinder: GPT-5.4
GPT-5.4 fulgte prompten mere trofast og tilføjede meningsfulde kanttilfælde. Som flere sammenligninger bemærker, er GPT-5.4's testgenerering blandt de bedste og skriver omfattende suites med stærk dækning af kanttilfælde.
Opgave 7: Refaktorer et monolitisk modul
Prompt: Jeg leverede et 500-linjers Python modul, der håndterede brugerstyring — registrering, autentificering, profilopdateringer, nulstilling af adgangskode og e-mailnotifikationer alt sammen i én fil. "Refactor this into a clean module structure following SOLID principles. Maintain backward compatibility with the existing public API."
GPT-5.4 Resultat
Opdelt i 5 moduler: auth.py, registration.py, profile.py, password.py, notifications.py. Tilføjede en __init__.py, der re-eksporterede de oprindelige offentlige funktioner for bagudkompatibilitet. Ren adskillelse. Hvert modul var selvstændigt.
Det missede dog at opdatere den cirkulære afhængighed mellem registration.py og notifications.py — registrering sender en velkomstmail, og notifikationsmodulet havde brug for en reference tilbage til brugerdata. Koden ville crashe ved import.
Claude Opus 4.6 Resultat
Opdelt i 6 moduler med samme opdeling plus en types.py til delte dataklasser. Vigtigst af alt identificerede den problemet med cirkulær afhængighed og løste det ved at introducere et event-baseret mønster — registrering udsender en "user_created" event, og notifikationsmodulet abonnerer på den. Den bagudkompatible __init__.py var identisk i sin tilgang.
Opus tilføjede også en kort kommentar øverst i hvert modul, der forklarede, hvad der hører til der, og hvad der ikke gør — fungerende som en guide for fremtidige udviklere.
Scores
| Dimension | GPT-5.4 | Opus 4.6 |
|---|---|---|
| Korrekthed | 6 | 10 |
| Kodekvalitet | 8 | 10 |
| Effektivitet | 8 | 7 |
| Total | 22 | 27 |
Vinder: Claude Opus 4.6
Fejlen med den cirkulære afhængighed ville have forårsaget et nedbrud i produktion. Dette er den type ræsonnement over flere filer, hvor Opus excellerer — den forstår afhængigheder på tværs af filer og arkitektoniske konsekvenser, før den genererer kode.
Opgave 8: Skriv teknisk dokumentation
Prompt: "Write API documentation for this payment processing SDK. Include: overview, authentication, rate limits, error codes, 5 endpoint descriptions with request/response examples, a webhook section, and a migration guide from v1 to v2." Jeg leverede SDK-kildekoden.
GPT-5.4 Resultat
Omfattende dokumentation, der dækkede alle efterspurgte sektioner. Endpoint-beskrivelserne var detaljerede med curl eksempler og respons-skemaer. Sektionen med fejlkoder var velorganiseret som en tabel. Migrationsguiden var klar med før/efter kodeeksempler. Ren markdown formatering.
Claude Opus 4.6 Resultat
Også omfattende, med en lidt anden struktur — den startede med en "Quick Start" sektion før de detaljerede dokumenter, hvilket er et godt mønster for udviklerdokumentation. Webhook-sektionen var mere detaljeret og inkluderede retry-adfærd, kode til signaturverificering og testvejledning. Migrationsguiden inkluderede en tidslinje for udfasning, som ikke var i kildekoden — den udledte dette fra versionsmønstre.
Scores
| Dimension | GPT-5.4 | Opus 4.6 |
|---|---|---|
| Korrekthed | 9 | 9 |
| Kodekvalitet | 9 | 9 |
| Effektivitet | 9 | 8 |
| Total | 27 | 26 |
Vinder: Uafgjort (GPT-5.4 med ét point på effektivitet)
Begge producerede fremragende dokumentation. Kvalitetsforskellen er ubetydelig. GPT-5.4 var lidt hurtigere. Til dokumentationsopgaver fungerer begge modeller godt — dette stemmer overens med udviklerrapporter, om at dokumentationskvaliteten er sammenlignelig på tværs af topmodellerne.
Opgave 9: Design en systemarkitektur
Prompt: "Design the architecture for a real-time collaborative document editor supporting 10,000 concurrent users. Cover: data model, conflict resolution strategy (CRDTs vs OT), WebSocket infrastructure, storage layer, presence system, and deployment topology. Provide a diagram in Mermaid syntax."
GPT-5.4 Resultat
Valgte OT (Operational Transformation) med en central server. Fornuftig arkitektur med Redis til presence, PostgreSQL til dokumentopbevaring og en WebSocket gateway bag en load balancer. Mermaid-diagrammet var rent. Analysen var kompetent, men fulgte en standardopskrift — den analyserede ikke dybt trade-offs mellem CRDTs og OT for denne specifikke skala.
Claude Opus 4.6 Resultat
Startede med at stille et uddybende spørgsmål om dokumentmodellen (rich text vs. plain text vs. strukturerede data), som jeg besvarede som "rich text". Anbefalede derefter CRDTs (specifikt Yjs) frem for OT, med en detaljeret forklaring på hvorfor CRDTs er overlegne i denne skala — eventual consistency uden en central sequencer eliminerer single point of failure.
Arkitekturen inkluderede en ny detalje: et "document gateway" lag, der håndterer CRDT merge-operationer og fungerer som både WebSocket terminator og et lag til tilstandspersistens. Mermaid-diagrammet inkluderede dataflow-pile med protokol-notationer. Deployment-sektionen anbefalede en specifik partitioneringsstrategi (shard efter dokument-ID) med ræsonnement omkring hot partitions.
Scores
| Dimension | GPT-5.4 | Opus 4.6 |
|---|---|---|
| Korrekthed | 8 | 10 |
| Kodekvalitet | 7 | 10 |
| Effektivitet | 8 | 7 |
| Total | 23 | 27 |
Vinder: Claude Opus 4.6
Arkitektur er der, hvor gabet i ræsonnementsdybde mellem disse modeller er mest synligt. Opus ræsonnerer mere eksplicit over problemet, før den genererer output, arbejder sig igennem kanttilfælde og stiller uddybende spørgsmål, når kravene er reelt tvetydige.
Opgave 10: Skriv et DevOps Deployment Script
Prompt: "Write a GitHub Actions workflow that: builds a Docker image, runs tests, pushes to ECR, deploys to ECS Fargate with blue-green deployment, runs a smoke test against the new deployment, and rolls back automatically if the smoke test fails. Use OIDC for AWS authentication — no hardcoded credentials."
GPT-5.4 Resultat
En komplet workflow-fil med alle efterspurgte trin. OIDC konfigurationen var korrekt ved hjælp af aws-actions/configure-aws-credentials med role ARN. Blue-green deployment brugte ECS service update med CODE_DEPLOY deployment controller. Smoke testen var et curl-baseret health check. Rollback blev udløst af smoke testens exit code. Velkommenteret, produktionsklar.
Claude Opus 4.6 Resultat
Også komplet og korrekt. Brugte den samme OIDC tilgang. Den største forskel var i smoke testen — Opus oprettede en mere grundig test, der ikke kun tjekkede health endpointet, men også verificerede at deploymenten kørte den korrekte version ved at tjekke et /version endpoint. Rollback inkluderede et Slack notifikations-trin. Dog var workflowet betydeligt mere ordrigt — 40% flere linjer for lignende funktionalitet.
Scores
| Dimension | GPT-5.4 | Opus 4.6 |
|---|---|---|
| Korrekthed | 10 | 10 |
| Kodekvalitet | 9 | 9 |
| Effektivitet | 9 | 7 |
| Total | 28 | 26 |
Vinder: GPT-5.4
Til DevOps scripting er GPT-5.4's kortfattethed en fordel. Workflowet er nemmere at vedligeholde og ændre. Opus's tilføjelser (Slack notifikation, versionsverificering) er fine, men var ikke efterspurgt og tilføjede kompleksitet. GPT-5.4 fører på Terminal-bench (75.1% mod 65.4%), og denne fordel viser sig i terminal-orienterede opgaver.
Den endelige pointtavle
| Opgave | GPT-5.4 | Opus 4.6 | Vinder |
|---|---|---|---|
| 1. REST API endpoint | 28 | 27 | GPT-5.4 |
| 2. React komponent | 28 | 26 | GPT-5.4 |
| 3. SQL-forespørgsel | 26 | 27 | Opus 4.6 |
| 4. Debug race condition | 22 | 27 | Opus 4.6 |
| 5. Code review | 25 | 28 | Opus 4.6 |
| 6. Test suite | 28 | 25 | GPT-5.4 |
| 7. Refaktorer modul | 22 | 27 | Opus 4.6 |
| 8. Dokumentation | 27 | 26 | Uafgjort |
| 9. Arkitekturdesign | 23 | 27 | Opus 4.6 |
| 10. DevOps script | 28 | 26 | GPT-5.4 |
| Total | 257 | 266 | Opus 4.6 |
Slutresultat: Claude Opus 4.6 vinder 266 mod 257.
Men den samlede score skjuler den virkelige historie.
Mønsteret der betyder mere end scoren
Se på hvor hver model vinder:
GPT-5.4 vinder på:
- API endpoints (veldefinerede, afgrænsede opgaver)
- React komponenter (boilerplate med klare specifikationer)
- Testskrivning (omfattende dækning ud fra en specifikation)
- DevOps scripts (terminal-orienteret, kortfattet output)
Claude Opus 4.6 vinder på:
- SQL kanttilfælde (finder subtile datafejl)
- Debugging (forståelse af rodårsager i komplekse systemer)
- Code review (finder sikkerheds- og korrekthedsproblemer)
- Refaktoring (håndtering af afhængigheder på tværs af filer)
- Arkitektur (dybe ræsonnementer om trade-offs)
Mønsteret er klart: GPT-5.4 er den hurtigere, billigere og bedre model til veldefinerede kodningsopgaver. Claude Opus 4.6 er den dybere, mere omhyggelige model til opgaver, der kræver ræsonnement på tværs af kompleksitet.
Dette matcher hvad DataCamps analyse fandt: GPT-5.4 er den bedste all-around model, mens Opus 4.6 excellerer specifikt ved agentiske og dybe kodningsopgaver.
Omkostningsfaktoren
Pointgabet (9 point) er relativt lille. Det er omkostningsgabet ikke.
| Metrik | GPT-5.4 | Claude Opus 4.6 |
|---|---|---|
| Input prissætning | $2.50/MTok | $15/MTok |
| Output prissætning | $15/MTok | $75/MTok |
| Hastighed | 73.4 tok/s | 40.5 tok/s |
| Kontekstvindue | 1M (tillæg >272K) | 1M (flad prissætning) |
| Tool search besparelser | ~47% token reduktion | N/A |
For denne 10-opgavers test var de samlede API-omkostninger cirka $4.20 for GPT-5.4 og $31.50 for Opus 4.6. Det er en 7.5x prisforskel for et 3.5% kvalitetsgab.
For et team, der kører hundredvis af AI-assisterede kodningsopgaver om dagen, taler matematikken stærkt for GPT-5.4 til størstedelen af arbejdet, mens Opus reserveres til de kritiske 10-20%, hvor dens ræsonnementsdybde gør en væsentlig forskel.
Den smarte strategi: Brug begge
De fleste arbejdende udviklere i 2026 vælger ikke én model — de vælger, hvornår de skal bruge hver især. Mønsteret der opstod i denne test, matcher det vi bruger hos ZBuild:
Hverdagshesten: GPT-5.4 (via Codex CLI eller API)
- Skrivning af nye endpoints, komponenter og scripts
- Generering af tests fra specifikationer
- Hurtig debugging på isolerede problemer
- DevOps og CI/CD automatisering
Det tunge skyts: Claude Opus 4.6 (via Claude Code eller API)
- Refaktoring på tværs af filer med komplekse afhængigheder
- Gennemgang af sikkerhedskritisk kode
- Arkitektoniske design-sessioner
- Debugging af ikke-indlysende problemer i store kodebaser
Denne to-model-tilgang fanger 95% af begge modellers styrker, mens omkostningerne holdes under kontrol. Portkey guiden til valg mellem disse modeller anbefaler den samme hybride tilgang.
Hvad benchmarks siger (til kontekst)
Resultaterne for hver opgave ovenfor stemmer overens med de formelle benchmarks:
| Benchmark | GPT-5.4 | Opus 4.6 | Hvad det måler |
|---|---|---|---|
| SWE-bench Verified | ~80% | 80.8% | Løsning af virkelige GitHub issues |
| SWE-bench Pro | 57.7% | ~46% | Sværere, strengere kodningsopgaver |
| Terminal-bench 2.0 | 75.1% | 65.4% | Terminal- og systemopgaver |
| HumanEval | 93.1% | 90.4% | Kodegenerering på funktionsniveau |
| GPQA Diamond | 92.0-92.8% | 87.4-91.3% | Ræsonnement på ekspertniveau |
| ARC-AGI-2 | 73.3% | 68.8-69.2% | Nyt ræsonnement |
Kilder: MindStudio benchmarks, Evolink analyse, Anthropic
GPT-5.4 fører på de fleste benchmarks. Opus 4.6 fører på SWE-bench Verified — det benchmark, der er tættest knyttet til virkelighedens fejlafhjælpning — hvilket forklarer dens fordel ved debugging og refaktoring i mine tests.
Dommen
Hvis du kun kan vælge én model: GPT-5.4. Den håndterer 80% af kodningsopgaverne med samme eller bedre kvalitet, koster 6-7 gange mindre og er 80% hurtigere. De 20% af opgaverne, hvor Opus er bedre (debugging, refaktoring, arkitektur), kan ofte håndteres med mere detaljerede prompts på GPT-5.4.
Hvis du kan bruge begge: Gør det. GPT-5.4 til daglig kodning, Opus 4.6 til komplekst arbejde. Dette er ikke et kompromis — det er den optimale strategi.
Hvis omkostninger ikke betyder noget, og du vil have maksimal kvalitet på hver opgave: Claude Opus 4.6. Den vandt den samlede score, og dens sejre var på de opgaver, hvor kvalitet betyder mest (fejl koster mere end boilerplate).
Resultaterne var ikke, hvad jeg forventede, da jeg antog, at den dyreste model ville dominere. Det gjorde den ikke. De to modeller har reelt forskellige styrker, og den bedste strategi er at vide, hvilken styrke du har brug for til den opgave, du står overfor.
Kilder
- OpenAI — Introducing GPT-5.4
- OpenAI — API Pricing
- Anthropic — Introducing Claude Opus 4.6
- Anthropic — Claude Pricing
- MindStudio — GPT-5.4 vs Claude Opus 4.6 vs Gemini 3.1 Pro Benchmarks
- MindStudio — Which AI Model Is Right for Your Workflow
- Portkey — GPT-5.4 vs Claude Opus 4.6 Guide
- DataCamp — GPT-5.4 vs Claude Opus 4.6 for Agentic Tasks
- Artificial Analysis — GPT-5.4 vs Claude Opus 4.6
- Bind AI — GPT-5.4 vs Claude Opus 4.6 for Coding
- Evolink — SWE-bench Verified 2026: Claude vs GPT
- DEV Community — ChatGPT vs Claude for Coding 2026
- Claude 5 — Opus 4.6 Benchmark Analysis