Det er lett \u00e5 bli nummen av den konstante str\u00f8mmen med nye AI-modeller. Enda en uke, enda en benchmark som flytter seg noen prosentpoeng.<\/p>\n
Men lanseringen av Claude Opus 4.5 og de nye funksjonene for Advanced Tool Use fanget oppmerksomheten min av helt andre grunner enn kun marginale hopp p\u00e5 et s\u00f8ylediagram.<\/p>\n
Det Anthropic har gjort her, handler mindre om at modellen har lest flere b\u00f8ker, og mer om at de har endret m\u00e5ten modellen jobber p\u00e5. De har tatt tak i de kjedelige, men kritiske flaskehalsene vi utviklere m\u00f8ter: begrensninger i kontekst, latency i API-kall og kostnaden av komplekse oppgaver.<\/p>\n
Her er en gjennomgang av hva som er nytt, og hvorfor dette er interessant for deg \u2013 enten du bygger avanserte agenter eller bare bruker verkt\u00f8y som Claude Code i hverdagen.<\/p>\n
Tool Search Tool: «Lazy loading» for kontekst<\/p>\n
Hvis du har fors\u00f8kt \u00e5 gi en LLM tilgang til mange verkt\u00f8y samtidig \u2013 enten det er i en agent du bygger, eller i et CLI-milj\u00f8 som Claude Code \u2013 kjenner du problemet: «Context Bloat».<\/p>\n
\u00c5 legge inn definisjoner for 50+ verkt\u00f8y spiser opp tusenvis av tokens f\u00f8r du i det hele tatt har stilt det f\u00f8rste sp\u00f8rsm\u00e5let. Det gj\u00f8r prosesseringen tregere, dyrere, og \u00f8ker sjansen for at modellen blir forvirret.<\/p>\n
L\u00f8sningen Anthropic n\u00e5 ruller ut minner mye om lazy loading: I stedet for \u00e5 laste alle verkt\u00f8yene inn i konteksten ved oppstart, gir du modellen et «s\u00f8ke-verkt\u00f8y». N\u00e5r Claude innser at den trenger \u00e5 gj\u00f8re noe den ikke har verkt\u00f8y for i minnet (f.eks. «sjekk deployment-status» eller \u201csjekk v\u00e6ret\u201d), s\u00f8ker den i katalogen, og laster kun inn definisjonen for det relevante verkt\u00f8yet der og da.<\/p>\n
![\"\"](\"https:\/\/www.europesays.com\/no\/wp-content\/uploads\/2025\/11\/250275.webp\" "\\"Forskjellen")
<\/p>\n
\n Forskjellen er tydelig: I det \u00f8verste eksempelet («Traditional approach») spiser ubrukte verkt\u00f8ysdefinisjoner opp store deler av kontekstvinduet. Med Tool Search (nederst) lastes kun det n\u00f8dvendige, noe som frigj\u00f8r mye mer plass til selve oppgaven.
\n \ud83d\udcf8: Anthropic\n <\/p>\n
Dette betyr at du i teorien kan ha tusenvis av tilgjengelige verkt\u00f8y i systemet ditt, uten at det p\u00e5virker ytelsen eller prisen p\u00e5 hver enkelt request p\u00e5 en drastisk m\u00e5te.<\/p>\n
Programmatic Tool Calling<\/p>\n
Tradisjonell «Function Calling» f\u00f8les ofte som en ping-pong-match:<\/p>\n
- \n
- \n
Modellen ber om \u00e5 kj\u00f8re verkt\u00f8y A.<\/p>\n<\/li>\n
- \n
Verkt\u00f8y A kj\u00f8res og sender svaret tilbake til modellen.<\/p>\n<\/li>\n
- \n
Modellen leser svaret og ber om verkt\u00f8y B.<\/p>\n<\/li>\n
- \n
Verkt\u00f8y B kj\u00f8res og sender svaret tilbake til modellen.<\/p>\n<\/li>\n<\/ol>\n
Dette skaper mye latency. Med Programmatic Tool Calling kan Claude i stedet skrive og kj\u00f8re et Python-script i en sandbox (hos Anthropic). Dette scriptet kan kalle flere verkt\u00f8y, prosessere dataene, kj\u00f8re l\u00f8kker og logikk, og kun returnere det endelige svaret.<\/p>\n
Hvorfor er dette viktig?<\/p>\n
- \n
- \n
F\u00e6rre hallusinasjoner: LLM-er sliter ofte med presis matte og logikk. Python er perfekt til det. Ved \u00e5 la modellen skrive koden for \u00e5 l\u00f8se problemet, i stedet for \u00e5 «tenke» seg frem til svaret, \u00f8ker presisjonen.<\/p>\n<\/li>\n
- \n
Effektivitet: Du bytter ut ti frem-og-tilbake kall med 1 eksekvering.<\/p>\n<\/li>\n<\/ul>\n
![\"\"](\"https:\/\/www.europesays.com\/no\/wp-content\/uploads\/2025\/11\/250277.webp\" "\\"Flytdiagrammet")
<\/p>\n\n Flytdiagrammet viser forskjellen: I stedet for \u00e5 g\u00e5 frem og tilbake til brukeren («Request» -> «Response»), kj\u00f8rer Claude en indre loop med Python-kode i en sikker container f\u00f8r det endelige svaret leveres.
\n \ud83d\udcf8: Anthropic\n <\/p>\nBeviset: «The Puzzle Room Challenge»<\/p>\n
Teori er vel og bra, men Anthropic kj\u00f8rte et interessant eksperiment for \u00e5 vise forskjellen i praksis. De satte opp to modeller til \u00e5 l\u00f8se en serie med 7 matematiske l\u00e5ser for \u00e5 \u00e5pne en digital safe:<\/p>\n
- \n
- \n
Sonnet 4.5 med tradisjonell tool calling.<\/p>\n<\/li>\n
- \n
Opus 4.5 med programmatic tool calling.<\/p>\n<\/li>\n<\/ol>\n
![\"\"](\"https:\/\/www.europesays.com\/no\/wp-content\/uploads\/2025\/11\/250279.webp\" "\\"Til")
<\/p>\n\n Til venstre ser vi Sonnet 4.5 som sliter med h\u00f8y token-bruk (den r\u00f8de baren) ved bruk av tradisjonelle verkt\u00f8y. Til h\u00f8yre har Opus 4.5 (den gr\u00f8nne baren) l\u00f8st problemet programmatisk med en br\u00f8kdel av ressursene. Skjermbilde fra \u201cClaude Opus 4.5 solves a puzzle game\u201d.<\/p>\n
Resultatet var en tankevekker:<\/p>\n
- \n
- \n
Sonnet (Tradisjonell): Pr\u00f8vde \u00e5 gjette koder, feilet, fikk hint, og pr\u00f8vde igjen. Den brukte over 7.6 millioner tokens p\u00e5 \u00e5 l\u00f8se oppgavene, fordi den m\u00e5tte «prate» seg gjennom logikken.<\/p>\n<\/li>\n
- \n
Opus (Programmatic): Skrev Python-script for \u00e5 knekke kodene (f.eks. kalkulere Fibonacci-rekker eller modulo-aritmetikk). Den l\u00f8ste alt med under 670 000 tokens.<\/p>\n<\/li>\n<\/ul>\n
Opus brukte alts\u00e5 under 10% av token-mengden til Sonnet. Selv om prisen per token er h\u00f8yere for Opus, ble totalkostnaden for oppgaven drastisk lavere, og oppgaven ble l\u00f8st raskere og mer presist. Dette viser at «dyrere» modeller n\u00e5 kan v\u00e6re billigere i drift hvis de l\u00f8ser oppgaven p\u00e5 f\u00f8rste fors\u00f8k ved hjelp av bedre verkt\u00f8y.<\/p>\n
Se hele eksperimentet her:<\/p>\n
Hvorfor jeg har sluttet \u00e5 bry meg om tallene<\/p>\n
Det er i m\u00f8te med slike resultater at jeg kjenner jeg bryr meg fint lite om benchmarks.\u00a0<\/p>\n
Om en modell scorer 70, 100 eller 80.9% (som Opus 4.5 faktisk scorer p\u00e5 SWE-bench Verified), blir bare abstrakte tall p\u00e5 et s\u00f8ylediagram for meg.<\/p>\n
I min hverdag handler det kun om effekt: Hastighet, kostnad og p\u00e5litelighet. Det Anthropic viser her, er et faktisk konkurransefortrinn som betyr noe.\u00a0<\/p>\n
Konkurrentene kan gjerne v\u00e6re marginalt «smartere» p\u00e5 papiret, men hvis de m\u00e5 brenne av ti ganger s\u00e5 mange tokens og bruke ti ganger s\u00e5 lang tid p\u00e5 \u00e5 komme frem til samme svar, har de tapt i mine \u00f8yne.<\/p>\n
<\/p>\n
Mener KI ikke er grunnen til at juniorer kuttes<\/p>\n
\n \u2013 KI er katalysatoren som avdekker et gammelt problem: En hel bransje har utsatt sin egen omstilling, skriver Johan Gr\u00f6nlund, daglig leder i Forte.\n<\/p>\n
<\/a><\/p>\n
Det store bildet: Hvorfor dette er viktig n\u00e5<\/p>\n
Det er verdt \u00e5 l\u00f8fte blikket litt fra koden for \u00e5 se hva som skjer i bakgrunnen her. Det er noen strukturelle endringer som gj\u00f8r at Anthropic posisjonerer seg annerledes enn konkurrentene akkurat n\u00e5:<\/p>\n
- \n
- «Cost of Intelligence» g\u00e5r ned. Selv om vi ser modeller med h\u00f8yere «sticker price» (som Opus 4.5), faller den faktiske kostnaden for \u00e5 f\u00e5 utf\u00f8rt komplekst arbeid. Som vi s\u00e5 i eksempelet over: En smart modell som bruker effektive verkt\u00f8y er billigere enn en billig modell som roter seg bort i lange samtaler.<\/li>\n
- Infrastruktur og partnerskap. Anthropic opererer ikke i et vakuum. Deres tette samarbeid med Google gir dem tilgang til enorm regnekraft \u2013 rapportene sier de har sikret tilgang til over 1 million TPUs (Tensor Processing Units) i 2026. Dette er viktig fordi det garanterer at de har infrastrukturen til \u00e5 skalere disse «tunge» agent-modellene i produksjon.<\/li>\n
- Fra Chatbot til «Compute Engine». Vi ser en dreining hvor modellene g\u00e5r fra \u00e5 v\u00e6re noe vi chatter med, til \u00e5 bli en motor som utf\u00f8rer arbeid i bakgrunnen.<\/li>\n<\/ol>\n
Dette er teknologien som ligger til grunn for verkt\u00f8y som Claude Code. N\u00e5r du sitter i terminalen din og ber Claude fikse en bug, er det nettopp denne evnen til \u00e5 s\u00f8ke opp filer, forst\u00e5 kontekst, og kj\u00f8re tester selvstendig som gj\u00f8r at det tidvis oppleves helt magisk.<\/p>\n
<\/p>\n
Microsoft-topp frustrert av kritikk mot KI-Windows<\/p>\n
\n \u2013 Jeez, det er s\u00e5 mange kynikere! melder Microsoft-topp, etter at hverken journalister eller folk flest lar seg imponere over Copilot- og Windows-sammensmelting.\n<\/p>\n
<\/a><\/p>\n
Oppsummert<\/p>\n
Claude Opus 4.5 er en imponerende modell, men det er verkt\u00f8yene rundt modellen som gj\u00f8r dette til en viktig utgivelse.\u00a0<\/p>\n
For oss utviklere betyr dette at vi kan begynne \u00e5 bygge systemer som er mer autonome, mer presise og \u2013 kanskje overraskende nok \u2013 billigere i drift p\u00e5 komplekse oppgaver.<\/p>\n
Sp\u00f8rsm\u00e5let er ikke lenger hvilken modell som er smartest p\u00e5 papiret, men hvilken modell som faktisk f\u00e5r jobben gjort.\u00a0<\/p>\n
Med Opus 4.5 har Anthropic lagt listen for hva vi kan forvente av autonome agenter. N\u00e5 blir det spennende \u00e5 se hvordan konkurrentene svarer.<\/p>\n
- \n
- \n
- \n