Anthropic ruller Claude Opus 5 ud som ny topmodel i Opus-laget og afløser dermed Opus 4.8. Prisen er uændret, men adfærden er ikke: modellen tænker som standard, effort styrer dybden, og kontekstvinduet går op til 1 million tokens uden mindre varianter. De detaljer ændrer både integration, omkostningsprofil og det daglige arbejde med agentiske og kodende workflows. Det lyder tørt, men konsekvenserne er praktiske og mærkes allerede ved første API‑kald (kilde: Marktechpost).
Opus 5 bliver samtidig standardmodellen på Claude Max og den stærkeste på Claude Pro, mens positioneringen er klar: næsten Fable 5‑intelligens til omtrent halv pris. Det er ikke kun et slogan, men et valg af fokus på økonomi i daglig brug frem for ren kapabilitet. VentureBeat beskriver samme placering og bekræfter uændret takst på $5 pr. million input‑tokens og $25 pr. million output‑tokens (kilde: VentureBeat; Marktechpost).
Hvad er nyt teknisk
Det vigtigste først: Opus 5 har thinking slået til som standard. Hvor Opus 4.8 krævede en indstilling som thinking:{“type”:”adaptive”} for at aktivere tænkning, kører Opus 5 med tænkning uden ekstra flag, og dybden justeres via effort‑parameteret. Det har en konkret konsekvens for max_tokens, fordi loftet nu gælder for både tænketekst og det synlige svar. Med andre ord: de gamle max_tokens‑værdier kan give afskårne outputs, hvis de ikke får et serviceeftersyn (kilde: Marktechpost).
Der er også en egentlig breaking change. Hvis et kald sætter thinking:{“type”:”disabled”} samtidig med effort=xhigh eller max, svarer API’et med en 400‑fejl. Restriktionen håndhæves per request. Man skal enten sænke effort til high eller helt droppe thinking‑feltet i den kombination. Det er dokumenteret adfærd i udmeldingen (kilde: Marktechpost).
ID, kontekst og outputlofter
Model‑ID’et er claude‑opus‑5. Samtidig oplyser Anthropic, at kontekstvinduet er 1 million tokens som både default og maksimum, uden en mindre variant at vælge imellem. Det er et markant valg, for de fleste applikationer har historisk balanceret pris og latenstid ved at nedskalere kontekst, men her er der ikke noget “lite” vindue at falde tilbage på (kilde: Marktechpost).
Outputlofterne ændrer også praktikken. På den synkrone Messages API kan svaret løbe op til 128k tokens. I Message Batches API kan der gås op til 300k tokens, men kun hvis man tilføjer beta‑headeren output‑300k‑2026‑03‑24. Det kræver et batch‑flow og accept af beta‑vilkår. Det er store tal, men orkestrering, tidsforbrug og fejlhåndtering kommer til at bide, hvis arkitekturen ikke er bygget til lange svarstrømme fra dag ét (kilde: Marktechpost).
Caching og små, men vigtige ændringer
Den mindste cachebare prompt er reduceret til 512 tokens – før var den 1.024. Det åbner for at cache mindre blokke og potentielt spare både tid og penge på gentagne kald, men det kræver en opdatering af cache‑nøgler, udløb og invalideringsstrategi. Det er en detalje, der ser ubetydelig ud på papiret og bliver kritisk i drift, når trafikken stiger og fejlmønstre dukker op (kilde: Marktechpost).
Anthropic anbefaler desuden at fjerne egen “verifikations‑prompting”. Opus 5 foretager intern verifikation, og ekstra “tjek dit svar en ekstra gang”‑instrukser kan udløse over‑verification, altså unødigt lange og gentagne kontroltrin i svaret. Det er uvant for mange kode‑ og agent‑prompter, som traditionelt lægger verifikation ovenpå. Her rammer man dobbelt, og regningen vokser uden at kvaliteten nødvendigvis følger med (kilde: Marktechpost).
Uændret pris – hvorfor det alligevel betyder noget
Prisen for Opus‑laget forbliver $5 pr. million input og $25 pr. million output. Det lyder neutralt. Men hvis modellen leverer tæt på Fable 5s intelligensniveau, bliver “kapabilitet pr. dollar” bedre. Det er i hvert fald den påstand Anthropic selv lægger frem, gengivet i både Marktechpost og VentureBeat. Den praktiske betydning er, at cost‑per‑task kan falde, selv uden prisnedsættelse pr. token – hvis færre omgange og kortere svar er nok til at løse opgaven (kilder: Marktechpost; VentureBeat).
Derfor giver rene cost‑per‑token‑sammenligninger mindre mening end før. Det, der batter, er totalomkostningen pr. gennemført opgave. Hvis Opus 5 kræver færre omkald eller færre forklaringsomveje, vinder den i ROI – omvendt er gevinsten væk, hvis thinking‑dybden kører for højt, eller hvis pipelines stadig tvinger lange verifikationsspor. Her afgør opsætning og disciplin i prompts økonomien mere end listepriserne gør.
Benchmarks for agenter og kodning
På FrontierBench v0.1, et 74‑task setup som efterfølger til Terminal‑Bench 2.1, er Opus 5 noteret til 43,3 procent ved max effort. Opus 4.8 lå på 18,7 procent. Fable 5 på 33,7 og GPT‑5.6 Sol på 37,5. Ved xhigh effort toppede Opus 5 til 44,4 procent. Detaljen i materialet: Opus 5s safety‑klassifikatorer afviste 5 procent af API‑kald på tværs af 4 procent af forsøg, mens Fable 5s klassifikatorer afviste 42 procent af kald på tværs af 26 procent af forsøg. Det er en markant forskel i flagging‑raten, som kan ændre hverdagen i automatiserede flows (kilde: Marktechpost).
Usikkerhed i tal, men retning er tydelig
Kilderne viser ikke fuld transparens om dataset‑versioner, seeds og alle parametre ud over effort‑niveauer. Retningen virker troværdig, men størrelsen på gevinsterne bør gentestes uafhængigt i egne miljøer. Især fordi safety‑flagging og prompt‑stil kan flytte scoren mere end man lige tror. VentureBeat refererer samme positionering, men uden ekstra metodisk dokumentation (kilder: Marktechpost; VentureBeat).
Der er også en bemærkning om ræsonnering: Opus 5 blev ifølge Anthropic promptet på alle seks IMO 2026‑opgaver uden værktøjer, hvor tremodel‑dommere vurderede samtlige 24 svar som korrekte, og menneskelige eksperter gav 7/7 på en forudvalgt løsning pr. problem. ARC‑AGI‑3 er rapporteret til 30,16 procent ved high effort, cirka fire gange over tidligere toplister. GPT‑5.6 Sol og Opus 4.8 stod lavere. Imponerende – men stadig en testkontekst, ikke en erstatning for produktionsmålinger (kilde: Marktechpost).
Konsekvenser for integration og drift
Thinking som default betyder, at max_tokens nu er et loft over både tænkning og svar. Hvis applikationen tidligere kørte med stramme max‑værdier for at spare, kan svar pludselig blive kappet. Løsningen er ikke bare at hæve loftet. Bedre er det at styre effort per opgavetype og justere prompts, så intern verifikation ikke eksploderer i længde. Ellers forsvinder gevinsten ved uændret pris hurtigt i flere output‑tokens (kilde: Marktechpost).
Den dokumenterede 400‑fejl ved kombinationen disabled thinking + xhigh/max bør trigge nye CI‑tests. Kør matrixer af thinking‑indstillinger og effort‑niveauer i staging, så fejl opfanges før deployment. Log de præcise kombinationer – det er en af de fejl, der kan dukke op sporadisk, når teams kopierer prompts mellem services.
Promptmønstre, pipelines og cache
Fjernelsen af manuelle verifikations‑instrukser er ikke bare en smagssag. Over‑verification er reelt spild af tokens og tid. Det kræver dog tillid til modellens interne verifikation, og mange vil indføre et tyndt menneske‑i‑løkken review først. Giv det en prøveperiode – men slip de gamle “tjek, dobbelttjek, opsummér”‑refræner, ellers fordufter pointen med Opus 5s egenkontrol (kilde: Marktechpost).
Caching skal genbesøges. Med 512 tokens som ny minimumsgrænse kan man cache hyppigere komponenter i prompts – instruktioner, domæneordbøger, politikker – i mindre bidder. Det kræver en ny nøglestruktur, så kollisionsraten ikke stiger, og invalidering, der tager højde for versionsskift af de små blokke. Resultatet kan være hurtigere svartider og lavere omkostninger, men kun hvis nøgledesignet er robust (kilde: Marktechpost).
Streaming og lange outputs
Med 128k tokens i synkront output og 300k i batches (beta‑header output‑300k‑2026‑03‑24) kommer spørgsmålet om gengivelse. Klientsiden skal kunne modtage, paginate og søge i meget lange svar – og afbryde dem pænt. Logging og observability skal også kunne håndtere det. Lange svar er fristende, men uden god chunking er de sværere at fejlsøge og retrye per sektion (kilde: Marktechpost).
Der er en praktisk faldgrube i mixet mellem streaming og thinking. Dokumentationen fastslår, at max_tokens dækker både tænkning og svar, men beskriver ikke i detaljer, hvordan det spiller med streamede svar i alle tilfælde. Planlæg derfor konservativt: sæt headroom i max_tokens, mål reel token‑fordeling pr. opgavetype, og hold øje med edge‑cases hvor tænkningen sluger uventet meget.
Sikkerhed og governance
At Opus 5s safety‑klassifikatorer i kildens rapportering afviser langt færre kald end Fable 5, kan let blive mistolket som “mere permissiv, ergo mere brugbar”. Det kan være sandt i praksis – færre falske positiver giver færre stop. Men uden indblik i præcis, hvad der blev flagged, og hvorfor, kan man ikke konkludere på risikoprofilen. Det, man kan gøre nu, er at rekalibrere interne regler og audit‑punkter og teste egne high‑risk prompts før produktion (kilde: Marktechpost; VentureBeat).
Lavere flagging kan også betyde flere falsk‑negative. Indfør derfor målrettede tests for policy‑overtrædelser, ikke kun generelle benchmarks. Og vær opmærksom på, at ændret klassifikator‑adfærd kan kræve opdatering i content‑moderation‑flows, så menneskelig review kun lander på de rigtige sager.
Konkrete næste skridt for danske udviklingsteams
Start en begrænset pilot med cost‑per‑task som primær metrik frem for pris pr. token. Mål antal omkald, gennemsnitligt output‑forbrug og fejlrate pr. opgavetype. Brug tre effort‑profiler – medium, high, xhigh – og kortlæg hvor gevinsten knækker, så I undgår at betale for dyb tænkning, der ikke flytter nøjagtighed.
Test CI for API‑kombinationer af thinking og effort for at fange 400‑fejlen, og opdatér promptbiblioteket for at fjerne verifikations‑instrukser, som nu konflikter med modellens egenkontrol. Genbyg cache‑laget til 512‑blokke og introducér versionsnøgler pr. modul. Og planlæg for 1M‑kontekst med memory‑budgetter, så ingest ikke pludselig eksploderer ved store dokumentpakker.
Forhandling og kapacitetsplan
Selv med uændret listepris er der noget at forhandle om. Volumener i 1M‑kontekst og lange outputs ændrer spidsbelastninger, og batch‑flows kan forrykke kø‑prioriteter. Forhandl derfor på gennemløb, fejlrater og evt. rabatter knyttet til batch‑API, hvis det ender som arbejdshesten. Dokumentér også de metrikker, der betyder mest i jeres forretning, og bind dem til SLO’er i stedet for kun pris pr. token.
Endelig: læg en latency‑måling ind før udrulning i produktion. Kilderne oplyser ikke tal for ventetid ved fuld 1M‑kontekst. Det kan dræne brugeroplevelsen, hvis ikke applikationen er designet til at vise progressivt indhold eller til at parallelisere opslåning og svargenerering.
Risici, usikkerheder og åbne spørgsmål
Benchmarktallene er stærke, men der mangler uafhængig replikation, inklusive præcise parametre, seeds og dataset‑revisioner. Ligeledes er der få konkrete detaljer om latenstid og omkostningsprofil ved 1M‑kontekst i kontinuerlig produktion. Her bør udviklingsteams insistere på egne målinger, før der skaleres op (kilde: Marktechpost; VentureBeat).
Det er uklart, hvordan thinking præcist interagerer med streaming i alle kanter af Messages API. Og safety‑klassifikator‑forskelle er svære at oversætte til reel risikoprofil uden flere data om falsk‑positiv/falsk‑negativ‑balancen. Spørgsmål til Anthropic kunne være: hvordan fordelte tokens sig mellem thinking og svar i deres egne testkørsler; hvilke latensintervaller ser de ved fuld kontekst; og om batch‑headeren output‑300k‑2026‑03‑24 forbliver uændret ved GA.
Et kort blik frem
Opus 5 peger på en markedsdrejning mod økonomi og driftsbarhed. Mindre rå prang, mere daglig nytte. “Daily driver” lyder amerikansk, men giver mening: man vælger modellen, der får mest arbejde gjort pr. krone og pr. minut. I det lys bliver uændret pris kombineret med ny adfærd afgørende – fordi den tvinger teams til at rydde op i prompts og styre effort bevidst.
Den praktiske test bliver jordnær og benhård: færre manuelle verifikationsspor, strammere max_tokens‑styring, caching i mindre bidder – og en beredskabsplan for 400‑fejlen. Først når de fire ting sidder, bliver forspringet i kapabilitet også et økonomisk forspring i produktion.
Kilder og videre læsning
Primær kilde: Marktechpost – “Meet the New Claude Opus 5: Frontier‑Class Agentic Coding and Computer Use at Unchanged Opus Pricing” med detaljer om API‑adfærd, model‑ID, kontekst, outputlofter, cachegrænse, benchmarks og sikkerhedsflagning. Supplerende kilde: VentureBeat – “Anthropic launches Claude Opus 5…” med pris, positionering og platformstilgængelighed. Læs dem, og tjek særligt API‑afsnittene før migration.
