Anthropic ruller Claude Sonnet 5 ud som sin mest agentiske Sonnet-model til dato. Den kan planlægge, styre browsere og terminaler og holde kadencen på længere autonome opgaver. Den bliver default i Free og Pro, og brugere på Max, Team og Enterprise kan vælge den til. I porteføljen ligger den fortsat mellem Haiku 4.5 og flagskibet Opus 4.8, og den afløser Sonnet 4.6 fra februar 2026. Kort sagt: mere kraft til agentiske flows – men med en ny tokenøkonomi, der kræver opmærksomhed (kilde: MarkTechPost).
Hurtig teknisk status
Sonnet 5 er live i Claude Code og på Claude Platform. Default-skiftet i Free og Pro betyder, at mange udviklere og projekter rykker sig automatisk. Det øger både eksponering og risiko: få justeret tests, budgetalarmer og governance nu, ellers ryger både latenstid og spend ubemærket.
Benchmarks uden skyklapper
På papiret slår Sonnet 5 Sonnet 4.6 på de publicerede benchmarks: 63,2 procent på SWE-bench Pro, 81,2 procent på OSWorld-Verified og 57,4 procent på HLE. Det peger mod et tydeligt hop i retning af Opus 4.8 – uden at indhente det. Tallene stammer fra samme producentnære kilde, så læs dem som retvisende men ikke uafhængigt verificeret (kilde: MarkTechPost).
Tokenizer og tokenøkonomi
Sonnet 5 skifter til Anthropic’s nyere tokenizer (introduceret med Opus 4.7). Samme tekst kan mappe til cirka 1,0–1,35 gange flere tokens. Det er småting i korte prompts, men i lange kæder og ved høj effort bliver forskellen synlig i regnskabet. Opdater derfor interne estimatværktøjer og alarmgrænser før skalering (kilde: MarkTechPost).
Hvem rammes mest? Sprog og formater med meget symbolik og blandet kode/tekst har ofte større token-udvidelse, men kilden specificerer ikke hvilke domæner der ligger i 1,35× frem for 1,05×. Mål derfor på egne prompts og datasæt i en preflight med 2–3 realistiske scenarier – og planlæg med en buffer.
Priser, bånd og hvornår Sonnet 5 er billigst
Introduktionspriserne for Sonnet 5 er 2 dollar per million input-tokens og 10 dollar per million output-tokens til og med 31. august. Derefter stiger listen til 3 dollar og 15 dollar. Opus 4.8 ligger på 5 dollar for input og 25 dollar for output i samme skema. Sonnet 5 er dermed klart billigere – især på output, hvor mange agentiske flows betaler hovedparten af regningen (kilde: MarkTechPost).
Effort ændrer dog billedet. Højere effort bruger flere tokens på resonering og selvkontrol. Kilden angiver ikke hvor mange, kun at både kvalitet og pris påvirkes. Her er et hypotetisk regneeksempel med eksplicitte antagelser: Forestil en opgave med 8.000 input-tokens og 12.000 output-tokens ved medium effort og en tokenizer-faktor på 1,25. Så bliver input 10.000 tokens og output 15.000 tokens. Med intropriser koster det cirka 0,02 dollar for input og 0,15 dollar for output – i alt 0,17 dollar. Antag at high effort ganger tokenforbruget med 1,5× og xhigh med 2,2×. Så koster samme opgave cirka 0,26 dollar ved high og 0,37 dollar ved xhigh på Sonnet 5-intro. Kører man samme opgave på Opus 4.8 (uden effort-trin) til 5/25 dollar, ender medium-scenariet omkring 0,5 dollar. Under disse antagelser er Sonnet 5 markant billigere ved low/medium/high, men xhigh kan nærme sig mindre Opus-kørsler – især efter intropriserne udløber. Bemærk: effort-multiplikatorerne er antagelser til illustration, ikke fra kildematerialet.
Effort-niveauer i praksis
Low og medium passer til rutinekæder med høj fejltolerance og lav værdi pr. kald. High giver plads til dybere resonering og bedre selvkorrektion efter fejlede tool-kald – nyttigt for skrøbelige integrationer. Xhigh bør reserveres til sjældne, dyre opgaver eller som automatisk fallback efter gentagne fejl; ellers løber regningen, og SLA’er tager skade.
Operationelt kræver det skarp observability: skeln mellem effort-niveauer, ellers forsvinder cost- og kvalitetssignaler i støjen. Alarmer bør ligge pr. flow med kvoter pr. bruger eller agent. Kør testmiljøer med faste effort-profiler, så forskelle ikke sniger sig ind mellem test og produktion.
Sikkerhed og “lav cyber capability”
Anthropic beskriver Sonnet 5 som sikrere end 4.6 med “deliberately low cyber capability”. Det er positivt, men kræver konkretisering: hvilke logningskrav håndhæves, hvilke systemkald begrænses, og hvordan sandboxes browser- og terminaladgang i praksis? Kilderne angiver ikke de tekniske detaljer, så virksomheder bør selv validere egress-kontrol, audit-logs og isolation før semi-autonom drift (kilde: MarkTechPost).
Til workloads hvor nøjagtighed er kritisk – finansielle beregninger, regulerede indberetninger, kritiske kodeændringer – anbefaler producenten fortsat Opus. Praktisk skillelinje: Sonnet 5 som højværdi-arbejdshest i bredden; Opus som præcisionsværktøj når fejl er dyre.
Routing som økonomisk ventil
Model-routing er på vej mod standard i enterprise-stakken. VentureBeat beskriver ACRouter, der bruger et Context-Action-Feedback-loop og i test slog både statiske routere og “alt til premium”-strategier på omkostning. I et rapporteret eksempel blev en Opus-only-opsætning overgået med cirka 2,6× lavere omkostning ved at vælge model pr. opgave. Det er disciplineret opgavevalg baseret på feedback – ikke trylleri (kilde: VentureBeat).
Routing er realistisk når opgaver kan klassificeres stabilt, logs er rene, og man accepterer et ekstra lag i kæden. Det tilføjer kompleksitet: routerlaget skal overvåges, have fallback-politikker og lære af fejl. Men med prisforskellen mellem Sonnet 5 og Opus 4.8 er routing et af de få håndtag, der kan skalere omkostninger kontrolleret uden markant kvalitetstab.
Drift og arkitektur
Opdatér udrulningsplaner med fire ændringer: 1) Kontroller default-skiftet. Hvis Free/Pro indgår i udviklernes værktøjssæt, så pin model og effort i CI/CD og tests. 2) Brug dashboards for cost og kvalitet pr. effort-niveau, pr. agent og pr. tool-kald – ellers kan man ikke se hvor pengene forsvinder. 3) Indfør robust fallback: simple retries ved lavere effort, mere konservativ prompt eller routing til Opus for de sidste 5 procent edge-cases. 4) Test lange sessioner med periodiske værktøjsfejl, netværkslatens og halvbesvarelser – her bryder agentiske flows ofte sammen uden god selvkontrol.
Taktiske råd til beslutningstagere
Start småt, men målbart: én agentisk kæde i produktion med KPI’er for succesrate pr. kæde, gennemsnitlige tool-kald pr. opgave og omkostning pr. løst sag. Kør medium effort som default og tillad high ved verifikation eller fejlhåndtering. Lås xhigh bag en klar politik – fx kun i batch og kun ved eksplicit godkendelse i koden.
Skift model efter opgaven, ikke som standard. Opus giver stadig bedst mening til accuracy-kritiske skridt, mens Sonnet 5 ofte vinder i bredden ved lav/medium effort. Investér i et routing-lag, når spend’et er højt nok til at 20–40 procent besparelse rykker budgettet.
Risici og åbne spørgsmål
To tydelige huller i kilderne: 1) Tokenizeren: der angives en 1,0–1,35× token-multiplikator, men ingen detaljer om regler, sprog eller formater der rammes hårdest. 2) Langtidsadfærd: der loves “steadier behavior across extended sessions”, men uden data for latenstid, kontekst-overhead eller memory over tid. Begge punkter kræver egne målinger, før man skalerer (kilder: MarkTechPost).
Bundlinjen
Sonnet 5 er et oplagt valg til agentiske flows i skala uden Opus-priser på hvert kald. Ved lav og medium effort er værdi-for-pengene stærk. Når effort ryger op i xhigh – eller når tokenizerens 1,35× rammer ens datasæt – kan regnestykket tippe, og så er Opus 4.8 stadig bedre til de få, kritiske skridt.
Det mest sandsynlige for større opsætninger er blandet drift: Sonnet 5 som standard, Opus til præcision, og et routerlag til at skære spild fra. Ikke smukt, men praktisk – og målbart, hvis man sætter de rigtige guardrails.
