Billig AI kan bli dyrt – mål kostnaden per ferdig oppgave

Den billigste AI-modellen er ikke nødvendigvis den som koster minst. En modell kan ha lav pris per token og likevel bruke flere tokens, ta flere omveier, gjøre jobben på nytt eller kreve mer opprydding fra et menneske. Da blir den billige modellen fort den dyre løsningen.

Jeg skrev tidligere at du kunne kutte AI-agent-kostnadene kraftig ved å sende enkle oppgaver til rimelige modeller. Prinsippet står fortsatt, men forklaringen var for enkel. Det holder ikke å dele modeller inn i «dyr og smart» og «billig og rask». Du må måle hva en ferdig, godkjent oppgave faktisk koster.

Det betyr at tokenpris bare er starten. Du må også regne inn antall forsøk, output-mengde, ventetid, verktøykall, menneskelig kontroll og hva en feil faktisk koster. Først da kan du velge riktig modell til riktig jobb.

Hvorfor kan en billig AI-modell bli dyrere?

Pristabellene viser vanligvis kostnad per million input- og output-tokens. Det er nyttig, men de forteller ikke hvor mange tokens modellen trenger for å løse oppgaven, om den lykkes på første forsøk eller hvor mye arbeid som står igjen etterpå.

To modeller kan få nøyaktig samme oppgave og ende svært forskjellig:

• Modell A koster lite per token, men bruker 40 verktøykall og må prøve tre ganger.
• Modell B har høyere tokenpris, men forstår oppgaven, velger riktig verktøy og leverer et godkjent resultat på første forsøk.
• Modell C er billig og god nok, men bruker så lang tid at den blokkerer resten av arbeidsflyten.

Hvis du bare ser på pris per token, vinner modell A. Hvis du ser på kostnad per godkjent resultat, kan modell B eller C være det bedre kjøpet.

Kimi K3 er et konkret eksempel på hvorfor dette skillet betyr noe. Moonshot oppgir en API-pris på 3 dollar per million vanlige input-tokens og 15 dollar per million output-tokens. Det er lavere enn 5 og 30 dollar for GPT-5.6 Sol hos OpenAI. Likevel målte Artificial Analysis Kimi K3 til 10,57 dollar og 56,4 minutter per fullført oppgave i sin agenttest. Modellen brukte i gjennomsnitt rundt 120 000 output-tokens og 83 turer.

Det beviser ikke at Kimi K3 alltid er et dårligere kjøp. Én test er ikke en fasit. Men den viser hvorfor den lave prisen i en produkttabell ikke automatisk gir lavest pris på en hel jobb.

Hva bør du regne inn i AI-agent-kostnadene?

Jeg ville målt minst disse seks delene:

1. Input: instrukser, dokumenter, kode, historikk og verktøyresultater som sendes inn.
2. Output: svar, kode, rapporter, resonnement og nye verktøykall modellen produserer.
3. Nye forsøk: oppgaver som feiler, stopper eller må kjøres om igjen.
4. Verktøy: nettsøk, databaser, bilde- og video-API-er, eksterne tjenester og databehandling.
5. Tid: hvor lenge jobben tar, og om ventetiden stopper andre deler av systemet.
6. Menneskelig arbeid: kontroll, retting, ny prompting og opprydding etter modellen.

En enkel formel kan se slik ut:

Kostnad per godkjent oppgave = modellkostnad + verktøykostnad + kostnad for nye forsøk + menneskelig kontroll + kostnaden ved ventetid og feil.

De to siste postene er vanskeligere å måle enn tokens, men de er ofte de viktigste. Hvis en ansatt bruker 20 minutter på å rydde opp etter en modell for å spare 30 øre i API-kostnad, har du neppe spart penger.

Hvorfor betyr output-prisen så mye?

Output er ofte langt dyrere enn input. I OpenAIs standardpriser koster GPT-5.6 Sol 5 dollar per million input-tokens og 30 dollar per million output-tokens. GPT-5.6 Terra ligger på 2,50 og 15 dollar, mens Luna ligger på 1 og 6 dollar.

Det gir en viktig praktisk forskjell mellom planlegging og utføring. En planlegger leser gjerne mye kontekst og lager en forholdsvis kort plan. En utførende agent kan derimot produsere store mengder kode, tekst og verktøykall. Det er derfor ikke sikkert toppmodellen bør gjøre begge deler.

La oss bruke et åpent, forenklet regneeksempel. Tallene under er ikke en påstand om hva alle oppgaver bruker. De viser bare hvordan arbeidsdelingen påvirker prisen med OpenAIs oppgitte standardpriser.

I dette eksempelet faller modellkostnaden med omtrent 52 prosent. Men besparelsen er bare ekte hvis Luna faktisk leverer godt nok. Hvis utføringen må kjøres på nytt to ganger, eller et menneske må reparere resultatet, forsvinner gevinsten raskt.

Det er derfor ruting må styres av målte resultater, ikke bare av prislisten.

Hvordan fordeler du planlegging, utføring og kontroll?

En praktisk arbeidsflyt kan deles i tre roller:

1. En sterk modell lager planen

Planleggeren får målet, kravene, relevante filer og grensene for oppgaven. Den bør finne avhengigheter, risiko og hva som må kontrolleres før noen begynner å produsere store mengder output.

Her kan en toppmodell være verdt prisen. En dårlig plan gjør resten av jobben dyrere, uansett hvor billig utføreren er.

2. En rimeligere modell utfører avgrensede deler

Utføreren bør få en konkret deloppgave med tydelige akseptansekriterier. Den kan skrive utkast, gjøre mekaniske kodeendringer, formatere data eller gjennomføre andre oppgaver der målet allerede er bestemt.

Dette er stedet der rimeligere modeller ofte kan spare mest, særlig når jobben produserer mye output. Men modellen må få lov til å eskalere når den er usikker. Den skal ikke gjette seg videre bare fordi ruteren valgte et billig nivå.

3. En uavhengig modell kontrollerer resultatet

Kontrolløren får planen, leveransen, kildene og kravene. Den leter etter faktafeil, manglende deler, sikkerhetsproblemer og avvik fra bestillingen.

Det kan være en fordel å bruke en annen modellfamilie enn den som laget resultatet. Modeller har forskjellige blindsoner. Greptile fant i et kodeeksperiment at GPT oppdaget flere alvorlige feil i Claude-generert kode, mens Claude oppdaget flere i Codex-generert kode. Forsøket gjelder kodegjennomgang og kan ikke uten videre overføres til all tekst og research, men prinsippet er nyttig: en kontrollør som tenker litt annerledes kan finne andre feil enn produsenten.

Det betyr ikke at du alltid må betale for tre toppmodeller. En enkel oppgave kan klare seg med én modell og en regelbasert kontroll. Poenget er å bruke ekstra kontroll der konsekvensene av feil forsvarer kostnaden.

Hva viser ekte modellruting i praksis?

Cursor lanserte i juli 2026 en ruter som velger modell ut fra blant annet oppgavens kompleksitet, kodekontekst og type arbeid. Ifølge Cursors egne målinger ga ruteren 60 prosent lavere kostnad ved frontier-kvalitet, mens tidlige kunder brukte 30 til 50 prosent mindre enn om alle oppgaver gikk til Claude Opus 4.8.

Dette er leverandørens egne tall, så de må behandles som det. Likevel er målemetoden interessant. Cursor så ikke bare på en benchmark. Selskapet målte kostnad per commit, om brukeren beholdt koden og om brukeren var fornøyd.

Cursor tok også med en detalj som mange glemmer: caching. Hvis du bytter modell midt i en lang økt, kan den nye modellen miste cache-fordelen og måtte lese hele konteksten på nytt. En ruter som hopper mellom modeller for ofte kan derfor spise opp sin egen besparelse.

Det finnes allerede flere varianter av samme idé. NadirClaw ruter kodeoppgaver mellom modeller, mens Perplexity kombinerer lokal og skybasert behandling. Fellesnevneren er at modellvalg blir en del av systemdesignet, ikke en knapp brukeren må velge på nytt for hver melding.

Når bør du ikke bruke en billigere modell?

Modellruting passer dårlig når feil er kostbare, oppgaven er dårlig definert eller modellen trenger dyp forståelse av mange avhengigheter. Jeg ville vært forsiktig med å sende disse oppgavene automatisk til laveste nivå:

• endringer med høy sikkerhetsrisiko
• juridiske, medisinske eller økonomiske konklusjoner
• store arkitekturvalg som påvirker mange systemer
• publisering uten menneskelig eller maskinell kvalitetsport
• oppgaver der et nesten riktig svar er farligere enn et tydelig stopp

Den rimelige modellen passer best når oppgaven er avgrenset, lett å kontrollere og billig å kjøre om igjen. Den sterke modellen bør brukes når feil retning tidlig kan gjøre hele leveransen bortkastet.

Slik tester du modellruting uten å bygge et stort system

Du trenger ikke starte med en avansert automatisk ruter. Begynn manuelt og logg resultatene.

1. Velg 20 til 50 representative oppgaver fra din faktiske arbeidsflyt.
2. Kjør dem med modellen du bruker i dag, og noter tokenkostnad, tidsbruk, nye forsøk og hvor mye du må rette.
3. Prøv en rimeligere modell på de enkle og output-tunge delene.
4. Definer hva «godkjent» betyr før testen starter.
5. Mål kostnad per godkjent resultat, ikke kostnad per kjøring.
6. Lag en eskaleringsregel for oppgaver som feiler, er usikre eller overskrider en tidsgrense.

Når du har nok data, kan rutingen automatiseres. En enkel ruter kan se på oppgavetype, kontekstlengde, sikkerhetsnivå og forventet output. En mer avansert løsning kan lære av hvilke resultater som faktisk ble godkjent.

Dette er også prinsippet jeg bruker i andre AI-produksjoner: ikke én modell til alt, men modeller valgt etter styrke. I AI-videoarbeid bruker jeg forskjellige modeller til bevegelse, lipsync og b-roll. Den dyreste modellen brukes der egenskapen faktisk trengs. Resten går til et rimeligere verktøy som er godt nok til akkurat den delen.

Hvilke tall bør du følge over tid?

Et godt målekort trenger ikke være komplisert. Følg disse fem tallene per oppgavetype:

• kostnad per godkjent oppgave
• andel godkjent på første forsøk
• gjennomsnittlig tid til ferdig resultat
• mengde menneskelig retting
• andel oppgaver som eskaleres til en sterkere modell

Da blir det mulig å oppdage når en modellendring faktisk hjelper. En ny modell kan ha lavere pris, men dårligere førsteforsøk. En annen kan koste mer per kjøring, men redusere kontrollarbeidet nok til at totalen faller.

Det viktigste er egentlig ganske enkelt: Ikke gjør modellvalg til religion. Den beste modellen er den som løser den konkrete oppgaven med riktig kvalitet, akseptabel risiko og lavest reell totalkostnad.

Ofte stilte spørsmål