Experimentet
Jag tog 10 verkliga kodningsuppgifter — den sorten utvecklare faktiskt gör varje dag — och skickade exakt samma prompt till både GPT-5.4 och Claude Opus 4.6. Samma system prompt, samma sammanhang, samma utvärderingskriterier.
Inga syntetiska benchmarks. Inga handplockade exempel. Bara verkliga uppgifter poängsatta utifrån tre dimensioner:
- Korrekthet (fungerar det utan modifieringar?)
- Kodkvalitet (läsbarhet, typer, felhantering, edge cases)
- Effektivitet (token-användning, responstid, antal uppföljningsprompter som krävdes)
Varje dimension poängsätts 1-10. Maximal möjlig poäng per uppgift: 30.
Modellerna nåddes via deras respektive API till standardpriser: GPT-5.4 för $2.50/$15 per million tokens och Claude Opus 4.6 för $15/$75 per million tokens.
Här är de 10 uppgifterna och exakt vad som hände.
Uppgift 1: Bygg en 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 kod. Zod-valideringsschemat var precist. Bcrypt-hashningen använde en korrekt salt round-konstant. Prisma-frågan använde select för att exkludera lösenordsfältet på databasnivå snarare än att ta bort det från svarsobjektet — en subtil men viktig säkerhetsåtgärd. TypeScript-typerna var strikta.
Claude Opus 4.6 Resultat
Också ren och korrekt. Använde ett liknande tillvägagångssätt för Zod-validering men lade till rate limiting middleware för endpointen och inkluderade en kommentar som förklarade varför. Lösenordsexkluderingen använde Prismas omit-funktion. Lade till en try/catch med specifika feltyper för Prisma unique constraint violations.
Poäng
| Dimension | GPT-5.4 | Opus 4.6 |
|---|---|---|
| Korrekthet | 10 | 10 |
| Kodkvalitet | 9 | 9 |
| Effektivitet | 9 | 8 |
| Totalt | 28 | 27 |
Vinnare: GPT-5.4 (marginalt, på grund av hastighet och korthet)
Båda resultaten var utmärkta. GPT-5.4 var snabbare och använde färre tokens. Opus lade till rate limiting middleware utan att det efterfrågades — användbart men inte begärt. För väldefinierade API-uppgifter är modellerna i princip utbytbara.
Uppgift 2: Bygg 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
Levererade en välstrukturerad generisk komponent. TypeScript generics användes korrekt för kolumndefinitionen och datatyperna. Sorteringslogiken var ren med en extraherad anpassad useSortable hook. Pagineringen använde useMemo för prestanda. ARIA-attributen var korrekta — role="grid", aria-sort på sorterbara rubriker, aria-selected på kryssrutor.
Claude Opus 4.6 Resultat
Liknande struktur men med några skillnader. Opus skapade en useDataTable hook som kapslade in logik för sortering, paginering och filtrering — renare separation men mer abstraktion. TypeScript generics var lika korrekta. Saknade aria-sort på rubrikcellerna. CSS-modulen inkluderade en responsiv layout som växlade till kortvy på mobilen, vilket inte efterfrågades men var ett genomtänkt tillägg.
Poäng
| Dimension | GPT-5.4 | Opus 4.6 |
|---|---|---|
| Korrekthet | 10 | 9 |
| Kodkvalitet | 9 | 9 |
| Effektivitet | 9 | 8 |
| Totalt | 28 | 26 |
Vinnare: GPT-5.4
GPT-5.4:s ARIA-implementering var mer komplett, vilket är viktigt för en komponent som ska användas i hela applikationen. Som noterats i MindStudios jämförelse, utmärker sig GPT-5.4 vid generering av boilerplate, inklusive React-komponenter och TypeScript-gränssnitt.
Uppgift 3: Skriv en komplex SQL-fråga
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 för aggregering av nuvarande period, en för aggregering av föregående period, en för den procentuella beräkningen. Ren, korrekt, välformaterad. Använde COALESCE för att hantera kunder utan data från föregående period. Lade till en kommentar med index-tips.
Claude Opus 4.6 Resultat
Fyra CTEs med en något annorlunda struktur: separerade beräkningen av "senaste orderdatum" till en egen CTE för att undvika en korrelerad underfråga. Lade till en NULLIF för att förhindra division med noll i den procentuella beräkningen — ett verkligt edge case som GPT-5.4 missade. Inkluderade ett alternativ med window function i ett kommentarsblock.
Poäng
| Dimension | GPT-5.4 | Opus 4.6 |
|---|---|---|
| Korrekthet | 9 | 10 |
| Kodkvalitet | 8 | 9 |
| Effektivitet | 9 | 8 |
| Totalt | 26 | 27 |
Vinnare: Claude Opus 4.6
Edge caset med division med noll var den avgörande faktorn. I produktions-SQL orsakar den typen av buggar tysta datakorruptioner. Opus lyfter konsekvent fram edge cases som spelar roll i verkliga datapipelines.
Uppgift 4: Felsök en race condition
Prompt: Jag tillhandahöll 3 filer (~200 rader totalt) från en Node.js-applikation med ett intermittent testfel. Buggen var en race condition i ett cachningslager där samtidiga cache-missar kunde utlösa dubbla databasfrågor och inkonsekvent tillstånd. "Find the bug, explain why it only manifests intermittently, and provide a fix."
GPT-5.4 Resultat
Identifierade den korrekta kodvägen för cache-missar. Föreslog att lägga till ett mutex lock med async-mutex. Fixen var korrekt men behandlade symptomet snarare än rotorsaken — den serialiserade alla cache-åtkomster, vilket skulle skada prestandan under belastning.
Claude Opus 4.6 Resultat
Identifierade samma kodväg men spårade också tillståndsinkonsekvensen till ett andra problem: cache-uppdateringen var inte atomär — det fanns ett fönster mellan läskontrollen och skrivningen där en annan förfrågan kunde flätas in. Opus föreslog ett "single-flight"-mönster (sammanslagning av samtidiga identiska förfrågningar) snarare än ett globalt mutex. Fixen var mer kirurgisk och bevarade samtidighet för icke-konflikterande cache-nycklar.
Poäng
| Dimension | GPT-5.4 | Opus 4.6 |
|---|---|---|
| Korrekthet | 7 | 10 |
| Kodkvalitet | 7 | 9 |
| Effektivitet | 8 | 8 |
| Totalt | 22 | 27 |
Vinnare: Claude Opus 4.6
Ett tydligt gap. Opus förstod samtidighetsmodellen tillräckligt djupt för att föreslå en riktad fix. Detta stämmer överens med Claude Opus 4.6:s 80.8% poäng på SWE-bench Verified, som testar just denna typ av verklig bugglösning.
Uppgift 5: Kodgranskning
Prompt: Jag tillhandahöll en pull request på 350 rader som lade till en ny modul för betalningsbehandling. "Review this PR for bugs, security issues, performance problems, and code quality. Prioritize findings by severity."
GPT-5.4 Resultat
Hittade 5 problem: en saknad null-kontroll på betalningssvaret, en ohanterad promise rejection, en hårdkodad timeout som borde vara konfigurerbar, en saknad idempotency key och ett förslag om att extrahera magic numbers till konstanter. Organiserat efter allvarlighetsgrad. Tydligt och handlingskraftigt.
Claude Opus 4.6 Resultat
Hittade 8 problem: samma 5 som GPT-5.4 hittade plus tre till — en TOCTOU-sårbarhet (time-of-check-time-of-use) i valideringen av belopp, en potentiell informationsläcka i felsvaret som exponerade interna stack traces, och ett subtilt problem där retry-logik kunde orsaka dubbeldebitering om den första förfrågan lyckades men svaret gick förlorat. Varje fynd inkluderade det specifika radnumret och en föreslagen fix.
Poäng
| Dimension | GPT-5.4 | Opus 4.6 |
|---|---|---|
| Korrekthet | 8 | 10 |
| Kodkvalitet | 8 | 10 |
| Effektivitet | 9 | 8 |
| Totalt | 25 | 28 |
Vinnare: Claude Opus 4.6
De tre ytterligare fynden var alla säkerhetskritiska. Buggen med dubbeldebitering ensam skulle kunna kosta ett företag betydande summor och rykte. Opus 76% på MRCR v2 (resonemang över flera filer) översätts direkt till bättre kodgranskning av komplexa moduler.
Uppgift 6: Skriv en testsvit
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." Jag tillhandahöll källfilen för middleware (~120 rader).
GPT-5.4 Resultat
Genererade 18 testfall organiserade i rena describe-block. Varje scenario från prompten täcktes. Lade till tre extra edge cases: tom sträng som token, token med fel algoritm och authorization header med endast blanksteg. Mocks var välstrukturerade med vi.mock. Testbeskrivningarna var tydliga och följde mönstret "should X when Y".
Claude Opus 4.6 Resultat
Genererade 15 testfall. Alla efterfrågade scenarier täcktes. Teststrukturen använde en helper factory för att skapa tokens med olika egenskaper — smart men lade till komplexitet. Saknade testet för "concurrent authentication requests" som uttryckligen efterfrågades. Dess mocks var renare men antalet tester var lägre.
Poäng
| Dimension | GPT-5.4 | Opus 4.6 |
|---|---|---|
| Korrekthet | 10 | 8 |
| Kodkvalitet | 9 | 9 |
| Effektivitet | 9 | 8 |
| Totalt | 28 | 25 |
Vinnare: GPT-5.4
GPT-5.4 följde prompten mer troget och lade till meningsfulla edge cases. Som flera jämförelser noterar, är GPT-5.4:s testgenerering bland de bästa, och den skriver omfattande sviter med god täckning av edge cases.
Uppgift 7: Refaktorera en monolitisk modul
Prompt: Jag tillhandahöll en Python-modul på 500 rader som hanterade användarhantering — registrering, autentisering, profiluppdateringar, lösenordsåterställningar och e-postaviseringar, allt i en fil. "Refactor this into a clean module structure following SOLID principles. Maintain backward compatibility with the existing public API."
GPT-5.4 Resultat
Delade upp i 5 moduler: auth.py, registration.py, profile.py, password.py, notifications.py. Lade till en __init__.py som återexporterade de ursprungliga publika funktionerna för bakåtkompatibilitet. Ren separation. Varje modul var självständig.
Däremot missade den att uppdatera det cirkulära beroendet mellan registration.py och notifications.py — registrering skickar ett välkomstmeddelande, och aviseringsmodulen behövde en referens tillbaka till användardata. Koden skulle krascha vid import.
Claude Opus 4.6 Resultat
Delade upp i 6 moduler med samma uppdelning plus en types.py för delade dataklasser. Avgörande var att den identifierade problemet med det cirkulära beroendet och löste det genom att introducera ett händelsebaserat mönster — registrering skickar en "user_created"-händelse och aviseringsmodulen prenumererar på den. Den bakåtkompatibla __init__.py var identisk i sitt tillvägagångssätt.
Opus lade också till en kort kommentar överst i varje modul som förklarade vad som hör hemma där och vad som inte gör det — vilket fungerar som en guide för framtida utvecklare.
Poäng
| Dimension | GPT-5.4 | Opus 4.6 |
|---|---|---|
| Korrekthet | 6 | 10 |
| Kodkvalitet | 8 | 10 |
| Effektivitet | 8 | 7 |
| Totalt | 22 | 27 |
Vinnare: Claude Opus 4.6
Buggen med det cirkulära beroendet skulle ha orsakat ett produktionsfel. Detta är den typ av resonemang över flera filer där Opus glänser — den förstår beroenden mellan filer och arkitektoniska konsekvenser innan den genererar kod.
Uppgift 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." Jag tillhandahöll källkoden för SDK.
GPT-5.4 Resultat
Omfattande dokumentation som täcker alla efterfrågade avsnitt. Endpoint-beskrivningarna var detaljerade med curl-exempel och svarsscheman. Avsnittet om felkoder var välorganiserat som en tabell. Migreringsguiden var tydlig med före/efter-kodexempel. Ren markdown-formatering.
Claude Opus 4.6 Resultat
Också omfattande, med en något annorlunda struktur — den inledde med ett "Quick Start"-avsnitt före de detaljerade dokumenten, vilket är ett bra mönster för utvecklardokumentation. Webhook-avsnittet var mer detaljerat och inkluderade retry-beteende, kod för signaturverifiering och vägledning för testning. Migreringsguiden inkluderade en tidsplan för utfasning som inte fanns i källkoden — den härledde detta från versioneringsmönster.
Poäng
| Dimension | GPT-5.4 | Opus 4.6 |
|---|---|---|
| Korrekthet | 9 | 9 |
| Kodkvalitet | 9 | 9 |
| Effektivitet | 9 | 8 |
| Totalt | 27 | 26 |
Vinnare: Oavgjort (GPT-5.4 med en poäng för effektivitet)
Båda producerade utmärkt dokumentation. Kvalitetsskillnaden är försumbar. GPT-5.4 var något snabbare. För dokumentationsuppgifter fungerar båda modellerna bra — detta stämmer överens med rapporter från utvecklare om att dokumentationskvaliteten är jämförbar mellan de ledande modellerna.
Uppgift 9: Designa 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
Valde OT (Operational Transformation) med en central server. Rimlig arkitektur med Redis för närvaro, PostgreSQL för dokumentlagring och en WebSocket-gateway bakom en load balancer. Mermaid-diagrammet var rent. Analysen var kompetent men följde en standardmall — den analyserade inte djupt avvägningarna mellan CRDTs och OT för just denna skala.
Claude Opus 4.6 Resultat
Började med att ställa en förtydligande fråga om dokumentmodellen (rich text vs. plain text vs. strukturerad data), som jag svarade var "rich text". Rekommenderade sedan CRDTs (specifikt Yjs) framför OT, med en detaljerad förklaring till varför CRDTs är överlägsna vid denna skala — eventual consistency utan en central sekvenserare eliminerar single point of failure.
Arkitekturen inkluderade en nyskapande detalj: ett lager för "document gateway" som hanterar CRDT-merge-operationer och agerar både som WebSocket-terminator och ett lager för tillståndspersistens. Mermaid-diagrammet inkluderade dataflödespilar med protokollanteckningar. Distributionsavsnittet rekommenderade en specifik partitioneringsstrategi (shard efter dokument-ID) med resonemang kring hot partitions.
Poäng
| Dimension | GPT-5.4 | Opus 4.6 |
|---|---|---|
| Korrekthet | 8 | 10 |
| Kodkvalitet | 7 | 10 |
| Effektivitet | 8 | 7 |
| Totalt | 23 | 27 |
Vinnare: Claude Opus 4.6
Arkitektur är där gapet i resonemangsdjup mellan dessa modeller är som mest synligt. Opus resonerar mer explicit kring problemet innan den genererar resultat, går igenom edge cases och ställer förtydligande frågor när kraven är genuint tvetydiga.
Uppgift 10: Skriv ett DevOps-distributionsskript
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 komplett workflow-fil med alla efterfrågade steg. OIDC-konfigurationen var korrekt och använde aws-actions/configure-aws-credentials med rollens ARN. Blue-green deployment använde ECS service update med CODE_DEPLOY deployment controller. Smoke testet var en curl-baserad hälsokontroll. Rollback utlöstes av smoke testets exit-kod. Välkommenterat, produktionsklart.
Claude Opus 4.6 Resultat
Också komplett och korrekt. Använde samma OIDC-metod. Den viktigaste skillnaden var i smoke testet — Opus skapade ett mer grundligt test som inte bara kontrollerade hälsoporten utan också verifierade att distributionen körde korrekt version genom att kontrollera en /version-endpoint. Rollback inkluderade ett steg för Slack-avisering. Dock var dess workflow märkbart mer ordrikt — 40% fler rader för liknande funktionalitet.
Poäng
| Dimension | GPT-5.4 | Opus 4.6 |
|---|---|---|
| Korrekthet | 10 | 10 |
| Kodkvalitet | 9 | 9 |
| Effektivitet | 9 | 7 |
| Totalt | 28 | 26 |
Vinnare: GPT-5.4
För DevOps-skript är GPT-5.4:s korthet en fördel. Arbetsflödet är lättare att underhålla och modifiera. Opus tillägg (Slack-avisering, versionsverifiering) är trevliga men efterfrågades inte och lade till komplexitet. GPT-5.4 leder på Terminal-bench (75.1% mot 65.4%), och denna fördel syns i terminalorienterade uppgifter.
Den slutgiltiga poängtavlan
| Uppgift | GPT-5.4 | Opus 4.6 | Vinnare |
|---|---|---|---|
| 1. REST API endpoint | 28 | 27 | GPT-5.4 |
| 2. React-komponent | 28 | 26 | GPT-5.4 |
| 3. SQL-fråga | 26 | 27 | Opus 4.6 |
| 4. Felsök race condition | 22 | 27 | Opus 4.6 |
| 5. Kodgranskning | 25 | 28 | Opus 4.6 |
| 6. Testsvit | 28 | 25 | GPT-5.4 |
| 7. Refaktorera modul | 22 | 27 | Opus 4.6 |
| 8. Dokumentation | 27 | 26 | Oavgjort |
| 9. Arkitekturdesign | 23 | 27 | Opus 4.6 |
| 10. DevOps-skript | 28 | 26 | GPT-5.4 |
| Totalt | 257 | 266 | Opus 4.6 |
Slutresultat: Claude Opus 4.6 vinner med 266 mot 257.
Men den sammanlagda poängen döljer den verkliga historien.
Mönstret som betyder mer än poängen
Titta på var varje modell vinner:
GPT-5.4 vinner på:
- API endpoints (väldefinierade, avgränsade uppgifter)
- React-komponenter (boilerplate med tydliga specifikationer)
- Testskrivning (omfattande täckning utifrån en specifikation)
- DevOps-skript (terminalorienterad, kortfattad output)
Claude Opus 4.6 vinner på:
- SQL edge cases (hittar subtila databuggar)
- Felsökning (förstår rotorsaker i komplexa system)
- Kodgranskning (hittar säkerhets- och korrekthetsprogram)
- Refaktorering (hanterar beroenden mellan filer)
- Arkitektur (djupgående resonemang om avvägningar)
Mönstret är tydligt: GPT-5.4 är den snabbare, billigare och bättre modellen för väldefinierade kodningsuppgifter. Claude Opus 4.6 är den djupare och mer noggranna modellen för uppgifter som kräver resonemang i komplexitet.
Detta matchar vad DataCamps analys fann: GPT-5.4 är den bästa allround-modellen medan Opus 4.6 utmärker sig specifikt vid agentiska och djupgående kodningsuppgifter.
Kostnadsfaktorn
Poängskillnaden (9 poäng) är relativt liten. Kostnadsskillnaden är det inte.
| Mått | GPT-5.4 | Claude Opus 4.6 |
|---|---|---|
| Input-prissättning | $2.50/MTok | $15/MTok |
| Output-prissättning | $15/MTok | $75/MTok |
| Hastighet | 73.4 tok/s | 40.5 tok/s |
| Kontextfönster | 1M (tillägg >272K) | 1M (fast pris) |
| Besparingar genom verktygssökning | ~47% token-minskning | N/A |
För detta test med 10 uppgifter var den totala API-kostnaden cirka $4.20 för GPT-5.4 och $31.50 för Opus 4.6. Det är en 7.5x kostnadsskillnad för en kvalitetsskillnad på 3.5%.
För ett team som kör hundratals AI-assisterade kodningsuppgifter per dag, talar matematiken starkt för GPT-5.4 för merparten av arbetet, med Opus reserverad för de högkänsliga 10-20% där dess resonemangsdjup gör en reell skillnad.
Den smarta strategin: Använd båda
De flesta yrkesverksamma utvecklare under 2026 väljer inte en modell — de väljer när de ska använda vilken. Mönstret som framkom i detta test matchar det vi använder på ZBuild:
Vardagsverktyg: GPT-5.4 (via Codex CLI eller API)
- Skriva nya endpoints, komponenter och skript
- Generera tester från specifikationer
- Snabb felsökning av isolerade problem
- DevOps och CI/CD-automatisering
Grovjobbare: Claude Opus 4.6 (via Claude Code eller API)
- Refaktorering över flera filer med komplexa beroenden
- Granskning av säkerhetskritisk kod
- Sessioner för arkitekturdesign
- Felsökning av icke-uppenbara problem i stora kodbaser
Denna tvåmodells-strategi fångar 95% av båda modellernas styrkor samtidigt som kostnaderna hålls hanterbara. Portkeys guide för att välja mellan dessa modeller rekommenderar samma hybridmetod.
Vad benchmarks säger (för sammanhang)
Resultaten för varje uppgift ovan stämmer överens med de formella benchmarksen:
| Benchmark | GPT-5.4 | Opus 4.6 | Vad det mäter |
|---|---|---|---|
| SWE-bench Verified | ~80% | 80.8% | Lösning av verkliga GitHub-problem |
| SWE-bench Pro | 57.7% | ~46% | Svårare, striktare kodningsuppgifter |
| Terminal-bench 2.0 | 75.1% | 65.4% | Terminal- och systemuppgifter |
| HumanEval | 93.1% | 90.4% | Kodgenerering på funktionsnivå |
| GPQA Diamond | 92.0-92.8% | 87.4-91.3% | Resonemang på expertnivå |
| ARC-AGI-2 | 73.3% | 68.8-69.2% | Nytt resonemang |
Källor: MindStudio benchmarks, Evolink analys, Anthropic
GPT-5.4 leder på de flesta benchmarks. Opus 4.6 leder på SWE-bench Verified — den benchmark som ligger närmast verklig buggfixning — vilket förklarar dess fördel vid felsökning och refaktorering i mina tester.
Utlåtandet
Om du bara kan välja en modell: GPT-5.4. Den hanterar 80% av kodningsuppgifterna med samma eller bättre kvalitet, kostar 6-7x mindre och är 80% snabbare. De 20% av uppgifterna där Opus är bättre (felsökning, refaktorering, arkitektur) kan ofta hanteras med mer detaljerade prompter i GPT-5.4.
Om du kan använda båda: Gör det. GPT-5.4 för daglig kodning, Opus 4.6 för komplext arbete. Detta är ingen kompromiss — det är den optimala strategin.
Om kostnaden inte spelar någon roll och du vill ha maximal kvalitet i varje uppgift: Claude Opus 4.6. Den vann den totala poängen och dess vinster var i de uppgifter där kvalitet spelar störst roll (buggar kostar mer än boilerplate).
Resultaten var inte vad jag förväntade mig eftersom jag antog att den dyrare modellen skulle dominera. Det gjorde den inte. De två modellerna har genuint olika styrkor, och den bästa strategin är att veta vilken styrka du behöver för uppgiften framför dig.
Källor
- 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