Tokens: hva kunstig intelligens faktisk bruker når du gir den et oppdrag

En advokat som bruker kunstig intelligens til å finpusse en e-post, oversette en klausul eller forberede et møte, tenker sjelden over forbruket.

Man skriver. Får et svar. Og arbeider videre.

Med et abonnement virker det hele enda enklere: Man betaler et fast beløp hver måned, og følelsen av å bruke ressurser for hver forespørsel forsvinner.

Denne roen endrer seg når vi slutter å samtale med kunstig intelligens og begynner å delegere arbeid til den.

Et moderne system kan få et mål, lese dokumenter, søke etter informasjon, bruke verktøy, kontrollere resultatene sine og korrigere kursen. Det kan også fordele deler av oppdraget mellom flere spesialiserte agenter.

Da møter vi en innsikt som strider mot nesten alle våre intuitive forestillinger:

Lengden på svaret sier ingenting om hvor mye arbeid maskinen har utført for å produsere det.

Be en trainee oppsummere en sak på tusen sider i fire linjer. Resultatet er fire linjer, men bak dem ligger tusen leste sider.

Noe lignende gjelder for kunstig intelligens. Forskjellen er at den kan utføre svært mye mellomarbeid uten at dette blir synlig i svaret.

Derfor er det nyttig å forstå hva tokens er. Ikke for å bli programmerer, men for å kunne delegere bedre.

1. Drivstoffet, motoren og lasten

Et token er én av enhetene en modell deler informasjonen den behandler inn i. Det kan tilsvare et helt ord, en del av et ord, et tegn, et tall eller bestemte byte. Forholdet varierer med språk, innhold og tokeniseringssystem. Det finnes ingen universell omregning mellom sider, ord og tokens.

For å forstå begrepet holder det med en sammenligning:

• Tokens er drivstoffet.
• Modellen er motoren.
• Kontekstvinduet er lastekapasiteten.

Dette er tre forskjellige ting.

Inndatatokens omfatter det vi gir systemet: instruksjoner, spørsmål, dokumenter, deler av samtalen og – avhengig av arkitekturen – verktøydefinisjoner og innhentede resultater.

Utdatatokens er det modellen genererer. I enkelte systemer omfatter de også resonneringsarbeid som ikke vises i sin helhet i den endelige teksten. OpenAIs API spesifiserer for eksempel reasoning_tokens som en del av de forbrukte utdatatokenene.

Kontekstvinduet angir hvor mye informasjon modellen kan ha tilgjengelig i én forespørsel. At et helt saksdokument får plass, betyr ikke at det bør sendes inn i sin helhet eller ligge i konteksten gjennom hele arbeidet.

I denne artikkelen bruker vi ett gjennomgående eksempel:

En kontrakt på 100 sider som, etter konvertering til tekst, utgjør omtrent 40 000 tokens.

Tallet er illustrerende og bevisst avrundet. Det faktiske forbruket må måles for det konkrete dokumentet, språket og modellen.

2. Første situasjon: én enkelt forespørsel

La oss anta at vi gir hele kontrakten til en modell og ber den om følgende:

«Oppsummer de viktigste risikoene for leietakeren i ti punkter.»

Systemet må behandle omtrent 40 000 tokens selv om svaret bare fyller én side.

Som eksempel var grunnprisen i API-et for inndatatokens i GPT-6 Astra og Claude Fable 5.1 den 14. september 2026 på 10 dollar per million tokens. Én behandling av våre 40 000 tokens ville dermed koste omtrent 0,40 dollar i inndata.

Dette er ikke oppdragets samlede kostnad. Tilleggsinstruksjoner, utdata, mulig resonnering, verktøy og senere operasjoner kommer i tillegg.

Eksemplet viser noe viktigere: Et kort svar kan kreve omfattende lesing.

Det viser også hvorfor tilgjengelig kapasitet ikke må forveksles med fornuftig bruk. Astra og Fable 5.1 har for tiden kontekstvinduer på rundt én million tokens, men det finnes ingen premie for å fylle hele vinduet. I Astra får dessuten en forespørsel med mer enn 272 000 inndatatokens høyere prismultiplikatorer for hele forespørselen.

Et stort bord gjør det mulig å åpne mange dokumenter. Det betyr ikke at hele arkivet bør legges på bordet.

3. Andre situasjon: tjue spørsmål om den samme kontrakten

Nå stiller vi tjue spørsmål etter hverandre.

Dersom en enkel integrasjon behandlet hele kontrakten på nytt for hver forespørsel, ville dokumentet alene utgjøre:

40 000 × 20 = 800 000 inndatatokens.

Med API-grunnprisen i eksemplet ville det kostet 8 dollar, før annet forbruk ble regnet med.

Det betyr ikke at alle applikasjoner fungerer slik. Moderne produkter kan bevare tilstand, gjenbruke deler av konteksten gjennom hurtigbuffer (cache), komprimere samtaler eller kombinere flere teknikker. Det er derfor ikke riktig å hevde at enhver samtale nødvendigvis fakturerer hele historikken på nytt fra grunnen av.

Men det økonomiske prinsippet består:

Det koster å beholde og behandle kontekst på nytt, selv om brukergrensesnittet ikke viser det.

En hurtigbuffer gjør det mulig å gjenbruke gjentakende informasjon til en lavere pris, men begrepene må brukes presist. For Claude Fable 5.1 var API-prisene, kontrollert 14. september 2026, som følger:

• Ordinære inndata kostet 10 dollar per million tokens.
• Skriving til hurtigbuffer med fem minutters lagring kostet 12,50 dollar per million.
• Skriving med én times lagring kostet 20 dollar per million.
• Lesing fra og oppfriskning av hurtigbuffer kostet 0,25 dollar per million.
• Utdata kostet 50 dollar per million.

For vår kontrakt ville én skriving av 40 000 tokens kostet omtrent 0,50 dollar med fem minutters lagring eller 0,80 dollar med én time. Hver senere lesing eller oppfriskning av de samme 40 000 tokenene ville kostet omtrent én cent.

I et ideelt scenario ville én femminutters skriving og nitten senere lesinger til sammen kostet omtrent 0,69 dollar i inndata, mot 8 dollar uten hurtigbuffer. Det faktiske beløpet vil avhenge av om innholdet fortsatt kan gjenbrukes, tiden mellom forespørslene, eventuelle oppfriskninger, nye deler av konteksten og hvordan systemet er bygget.

For den som ikke programmerer, finnes det en langt enklere regel:

Når du faktisk skifter tema eller sak, åpner du en ny samtale.

Det handler ikke bare om pris. Når irrelevante saksdokumenter, instruksjoner og beslutninger blir hengende med, kan det også bli vanskeligere for modellen å identifisere det vesentlige.

4. Tredje situasjon: kontrakten går til en agent

Så langt har vi stilt spørsmål. En agent arbeider på en annen måte.

Den mottar et mål og arbeider i en løkke:

1. Analyserer oppdraget.
2. Bestemmer neste skritt.
3. Bruker et verktøy eller konsulterer en kilde.
4. Undersøker resultatet.
5. Justerer strategien.
6. Fortsetter til en avslutningsbetingelse er oppfylt.

Forskjellen kan oppsummeres slik:

I en chat bestemmer brukeren som regel hvert skritt. I et agentbasert system gir vi systemet fullmakt til selv å bestemme noen av skrittene som er nødvendige for å nå målet.

Tenk deg nå følgende oppdrag:

«Analyser kontrakten, identifiser juridiske og økonomiske risikoer, kontroller henvisningene til regelverket, sammenlign problematiske klausuler med oppdaterte kilder og utarbeid en sluttrapport.»

Resultatet kan være på bare tre sider. For å produsere det kan agenten likevel ha:

• lest forskjellige klausuler flere ganger;
• hentet ut datoer, beløp og forpliktelser;
• utført søk;
• åpnet og vurdert flere kilder;
• forkastet uegnede resultater;
• skrevet et første rapportutkast;
• kontrollert sine egne kildehenvisninger;
• rettet feil;
• og generert den endelige versjonen.

Hver runde i løkken kan innebære nye modellforespørsler, ny kontekst, resonneringstokens, verktøyresultater og i enkelte tilfeller særskilte kostnader for verktøybruken.

I agentbasert KI er den økonomiske enheten derfor ikke svaret.

Den er hele kjøringen vi har gitt fullmakt til.

Spørsmålet «hvor lang er rapporten?» er ikke lenger tilstrekkelig. Vi må spørre hvor mange skritt som ble utført, hvilken informasjon som ble behandlet i hvert skritt, hvilke verktøy som ble brukt, hvor mange ganger arbeidet ble forsøkt på nytt, og hvilken betingelse som fikk agenten til å stoppe.

5. Fjerde situasjon: kontrakten går til et team av agenter

Det neste spranget er et multiagentsystem.

En koordinerende agent kan dele kontrakten mellom spesialister: Én undersøker forpliktelsene, en annen garantiene, en tredje de økonomiske konsekvensene, og en fjerde kontrollerer kilder og henvisninger. Deretter samler koordinatoren resultatene og utarbeider det endelige svaret.

Dette kan gi større kapasitet, parallellitet og spesialisering. Det kan også raskt mangedoble forbruket.

La oss føre eksemplet til en bevisst ytterlighet. Dersom vi sender hele kontrakten på 40 000 tokens til 25 agenter:

40 000 × 25 = 1 000 000 inndatatokens.

Med en API-grunnpris på 10 dollar per million ville det kostet 10 dollar bare å gi dem dokumentet. Instruksjoner, resonnering, verktøy, svar, kommunikasjon og koordinatorens sammenstilling kommer i tillegg.

Dette er ikke en anbefalt konfigurasjon. Det er en stresstest som viser hvordan arkitekturen kan ha større betydning enn dokumentets størrelse.

Et bedre utformet system kan behandle kontrakten én gang, bygge en felles struktur og bare gi hver spesialist de klausulene og bakgrunnsopplysningene vedkommende trenger. Det kan også hindre at flere agenter utfører det samme søket eller gjentar en kontroll som allerede er ferdig.

Anthropic publiserte i 2025 data fra sitt eget forskningssystem. Der brukte agentene deres etter selskapets erfaring omtrent fire ganger så mange tokens som en chatinteraksjon, mens multiagentsystemet brukte rundt femten ganger så mange. Dette er ikke universelle multiplikatorer og kan ikke brukes til å beregne kostnaden for en hvilken som helst agent. Det er observasjoner fra én bestemt arkitektur, bygget for kompleks forskning som kan utføres parallelt.

Den samme tekniske redegjørelsen forteller at enkelte tidlige prototyper opprettet 50 underagenter for enkle spørsmål, søkte i det uendelige etter kilder som ikke fantes, eller lot seg avspore av unødvendige statusoppdateringer. Dette var ikke ønsket kapasitet, men feil Anthropic måtte rette gjennom bedre regler for delegering og avslutning.

Lærdommen er ikke at agenter bruker for mye, eller at vi bør unngå agentteam.

Den er denne:

Styringsrammen som organiserer arbeidet – grensene, verktøyene, minnet, fordelingen av kontekst og stoppkriteriene – er økonomisk like viktig som modellen den bruker.

Agentteam gir mening når oppgaven er tilstrekkelig verdifull, faktisk kan deles opp og har nytte av parallelt arbeid. Å bruke dem til ethvert oppdrag skaper mer aktivitet uten å garantere bedre resultater.

6. Abonnement, API og mellomleverandør

Den økonomiske erfaringen avhenger også av hvordan vi får tilgang.

Med et abonnement mottar brukeren vanligvis ikke en faktura for hver million tokens. Man arbeider innenfor bestemte kvoter og grenser som kan variere med modell, verktøy og bruksintensitet.

Med et API er sammenhengen mer direkte. Inndata, hurtigbuffer, utdata og – når det er aktuelt – verktøy eller andre tjenester måles og prises.

I virksomheter og advokatfirmaer finnes dessuten ofte en tredje løsning: Man kjøper et spesialisert produkt som i bakgrunnen bruker modeller fra OpenAI, Anthropic eller andre leverandører.

Fakturaen kan være fast, men den variable kostnaden forsvinner ikke. I første omgang bæres den av mellomleverandøren. Det kan påvirke hvilken modell leverandøren bruker, hvor mye kontekst den får, hvor mange skritt som tillates, og hvor ofte agentfunksjoner aktiveres.

Når vi vurderer en profesjonell leverandør, holder det derfor ikke å spørre om produktet «bruker kunstig intelligens». Det er også relevant å vite:

• hvilke modeller og versjoner som brukes;
• om modellen skiftes etter oppgavens art;
• hvilke grenser som gjelder for agenter og verktøy;
• hvordan konteksten velges;
• om leverandøren kan forklare hvilke operasjoner som er utført;
• og hvordan kostnader, kvalitet og feil måles.

En fastpris kan gjøre innkjøpet enklere. Den gjør ikke arkitekturen irrelevant.

Neste prosjekt · KI-økonomi — Fullstendige og sammenlignbare priser for OpenAI, Anthropic, Gemini, Grok, DeepSeek, Kimi og andre leverandører skal samles i en fremtidig, uavhengig kostnadsmonitor. Frem til da beholder denne artikkelen bare daterte og etterprøvbare eksempler.

7. Den nye faglige ferdigheten: å gi og avgrense oppdrag

En advokat vet allerede hvordan man delegerer.

Det skjer når man instruerer en trainee, en advokatfullmektig eller en ekstern sakkyndig. Man definerer problemet, gir nødvendig bakgrunn, avgrenser kildene og bestemmer hvilket resultat man trenger.

La oss sammenligne to oppdrag knyttet til kontrakten vår.

Åpent oppdrag:

«Analyser denne kontrakten og fortell meg alt du finner.»

Hva betyr «alt»? Skal agenten søke etter rettspraksis? Fra hvilken periode? Kan den bruke internett? Hvor mange kilder? Skal den også undersøke skattemessige konsekvenser? Når kan den anse arbeidet som avsluttet?

Det vet vi ikke.

Kontrollert oppdrag:

«Gjennomgå klausulene 7 til 12. Identifiser avvik fra bakgrunnsretten og påpek dem som er til ulempe for leietakeren. Bruk bare kontrakten og de offisielle kildene jeg gir deg. Ikke foreta mer enn åtte eksterne oppslag. Åpne originalkilden før du viser til den. Lever en kort tabell og en konklusjon på maksimalt 400 ord. Opplys dersom informasjon mangler. Be om tillatelse før du utvider omfanget.»

Det andre oppdraget fastsetter:

• målet;
• omfanget;
• kildene;
• tillatte verktøy;
• formatet;
• og avslutningsbetingelsen.

Det gjør ikke analysen svakere. Det gir den retning.

Det finnes likevel et grunnleggende skille:

Prompten gir retning. Systemet håndhever grensene.

Å skrive «ikke bruk for mye» eller «ikke utfør mer enn åtte søk» gir agenten veiledning, men oppretter ikke i seg selv en pålitelig teknisk grense.

I en profesjonell applikasjon bør styringsrammen kunne fastsette:

• maksimalt antall agenter;
• maksimalt antall skritt;
• maksimalt antall verktøykall;
• økonomisk budsjett;
• grenser for kontekst og utdata;
• maksimal kjøretid;
• stoppkriterier;
• aktivitetslogg;
• og menneskelig godkjenning før sensitive eller kostbare oppdrag utvides.

Målingen bør heller ikke begrenses til antall tokens. En dyrere modell kan løse oppgaven riktig ved første forsøk, mens en annen tvinger oss til å gjenta den fire ganger. Ett ekstra søk kan forhindre en uriktig juridisk påstand. En ny kontroll kan oppdage en alvorlig profesjonell feil.

Det relevante målet er kostnaden per nyttig og korrekt verifisert resultat.

8. Hva kan vi gjøre allerede i morgen?

Hvis vi bruker en KI-applikasjon:

• Opprette et nytt arbeidsrom når vi skifter sak eller tema.
• Bare legge ved dokumentasjonen som er nødvendig.
• Velge kapasitet i samsvar med oppgavens vanskelighetsgrad.
• Skille mellom «kort svar» og «overflatisk analyse».
• Definere omfang, kilder, resultat og avslutningsbetingelse.
• Be systemet innhente godkjenning før oppdraget utvides.
• Kontrollere hva abonnementet faktisk omfatter.

Hvis vi bygger eller kjøper et profesjonelt system:

• Måle forbruket for hele oppgaven, ikke bare for hvert enkelt kall.
• Gjenbruke gjentakende kontekst gjennom hurtigbuffer.
• Unngå at alle underagenter mottar hele saksmappen.
• Rute rutineoppgaver til modeller som er tilstrekkelige og rimelige.
• Reservere de mest avanserte modellene for oppgaver som faktisk krever kapasiteten deres.
• Innføre tekniske grenser for skritt, agenter, verktøy, tid og budsjett.
• Registrere hvilken modell, versjon og konfigurasjon som produserte hvert resultat.
• Evaluere kvalitet og kostnader før prosessen skaleres.

Det handler ikke bare om å bruke mindre

Å optimalisere tokens betyr ikke å få den kunstige intelligensen til å arbeide mindre.

Det betyr å få den til å utføre riktig arbeid.

Effektivitet og grundighet er ikke motsetninger. Målet er å fordele maskinens intellektuelle ressurser etter en logikk som ligner den vi bruker når vi organiserer menneskelige ressurser: definere målet, gi nødvendig informasjon, velge riktig kapasitet, følge arbeidet og vite når det skal avsluttes.

Tokens er ikke et mål på intelligens.

De garanterer heller ikke kvalitet.

De er én av enhetene vi kan bruke til å observere og måle deler av systemets arbeid.

Etter hvert som kunstig intelligens går fra bare å svare på spørsmål til å bruke verktøy, ta operative beslutninger og koordinere agenter, blir det stadig viktigere å forstå dette arbeidet.

Det profesjonelle spørsmålet er derfor ikke lenger bare:

«Kan maskinen gjøre det?»

Et annet spørsmål er trolig viktigere:

«Hvilket arbeid gir jeg den fullmakt til å utføre for å få det til?»

Avgrensning

Denne artikkelen handler om ressursbruk og den grunnleggende økonomiske arkitekturen i oppdrag som utføres med kunstig intelligens.

Konfidensialitet, taushetsplikt, lokalisering og lagring av data samt behandling av klientdokumentasjon er andre og prioriterte spørsmål. De behandles separat i KI og virksomhetens dokumenter: det holder ikke å vite hvor PDF-ene ligger.