# OpenAI API-priser i 2026: beregn inndata, utdata og tokenbudsjett
> Jeg forklarer med tall hvordan API-tokenbruk beregnes: hvorfor utdata koster mer enn inndata, hvordan du anslår antall tokens i en forespørsel, og når cacherabatten faktisk reduserer regningen.
Source: https://ailoot.ai/blog/nb/api-token-usage-calculation/
Canonical: https://ailoot.ai/blog/nb/api-token-usage-calculation/
Language: nb
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-143
Revision: sha256-6abaf5e660d18677a56c83cf42301b010c5f35517bb2a313e7288d7ca4ad6bc1
Du setter penger inn på en API-konto, og nesten med en gang dukker spørsmålet opp: Hvor lenge varer de? Du tenker omtrent «Jeg har ti tusen, inndata koster så mye, utdata koster mer, og det finnes visst også en cacherabatt» — men det er uklart hvordan du gjør alt dette om til ett tall. Jeg går gjennom det trinn for trinn, med tall.
Hovedpoenget først: API-regningen beregnes med én formel — antall tokens multiplisert med prisen per token. Inndata- og utdata-tokens telles hver for seg fordi de har ulike priser. Deretter viser jeg hvordan du bruker dette til å finne ut hvor lenge budsjettet ditt varer, og hvordan caching inngår i beregningen.
Informasjon om bruk av Ailoot finner du i [dokumentasjonen](https://ailoot.ai/docs/).
Obs
Jeg oppgir tokenpriser fra de offisielle sidene til Anthropic, DeepSeek og OpenAI slik de var tidlig i september 2026 — de endres, så sjekk dine egne tall på leverandørens nettsted før du regner. Sett inn dine egne tall i den samme formelen.
## Hva består en API-regning av?
Viktig poeng
En API-regning består av to deler: kostnaden for inndata og kostnaden for utdata. Inndata er alt du sender til modellen: spørsmålet ditt, vedlagte filer, samtalehistorikken og systeminstruksjonen. Utdata er svaret modellen genererer. Begge måles i tokens, og hver type token har sin egen pris. Totalbeløpet for én forespørsel er antall inndata-tokens multiplisert med inndataprisen, pluss antall utdata-tokens multiplisert med utdataprisen. Det koster ingenting å koble til selve API-et; du betaler bare for tokens.
Når du kaller en modell via et API, betaler du for mengden tekst som gikk gjennom modellen. Denne mengden måles i tokens. Et token er en liten tekstdel; jeg kommer tilbake til det i neste del, men foreløpig kan du tenke på det som måleenheten for alt.
Ett kall har to sider. Den første er det du sendte til modellen: selve spørsmålet, vedlagte kodebiter eller et dokument, tidligere meldinger i samtalen og systeminstruksjonen i begynnelsen. Dette er inndata. Den andre er det modellen skrev som svar. Dette er utdata. DeepSeek sier det rett ut i prisbeskrivelsen: regningen beregnes ut fra det samlede antallet inndata- og utdata-tokens.
Inndata og utdata har ulike priser, så de telles separat. Formelen for én forespørsel er enkel:
```
cost = (input tokens × input price) + (output tokens × output price)
```
Prisene oppgis vanligvis per million tokens — det er mer praktisk fordi ett token koster en brøkdel av en pengeenhet. Alle beregningene videre tar utgangspunkt i denne formelen, og budsjettet ditt dekker nøyaktig så mange forespørsler som får plass innenfor beløpet du har tilgjengelig, til den prisen.
## Et token er ikke et ord: Hvordan anslår du hvor mange du kommer til å bruke?
Viktig poeng
Et token er verken et ord eller en bokstav, men en tekstdel som vanligvis består av flere tegn. Et grovt anslag for engelsk er omtrent fire tegn per token, så et ord på fem eller seks bokstaver blir til ett eller to tokens. Russisk tekst deles opp i mindre tokens, så den samme frasen på russisk bruker merkbart flere tokens enn på engelsk. Du kan ikke regne ut det nøyaktige antallet på forhånd, men et grovt anslag holder for budsjettering: anslå omtrent hvor mange tegn forespørselen og svaret inneholder, og del deretter på fire for engelsk eller på to eller tre for russisk.
Det første alle snubler over, er at et token ikke er det samme som et ord. Modellen deler opp tekst i biter etter sine egne regler, og en bit kan være et helt kort ord, en del av et lengre ord, et mellomrom sammen med en bokstav eller et tegnsettingstegn. Derfor kan du ikke regne ut nøyaktig i hodet «hvor mange tokens forespørselen min kommer til å bruke» — du kan bare anslå.
Her er en grov tommelfingerregel. I engelsk tekst tilsvarer ett token omtrent fire tegn; det er et utgangspunkt fra Anthropic og OpenAI selv. Modeller deler russisk tekst i mindre biter: kyrilliske tegn brytes opp i kortere deler, så en tekst med samme betydning bruker flere tokens. Hvor mange flere avhenger av modellen, men du bør regne med halvannen til to ganger så mange som på engelsk.
Slik ser det ut målt i tokens. Hvis du sender modellen en side med tekst og får et avsnitt tilbake, er det allerede snakk om tusenvis av inndata-tokens og hundrevis av utdata-tokens. Og hvis du legger ved en stor fil i en forespørsel eller har en lang samtalehistorikk, kan inndata vokse til titusenvis av tokens, og mesteparten av regningen kan komme derfra. API-svaret viser det nøyaktige tallet — metadatafeltene oppgir hvor mange tokens som faktisk ble brukt til inndata og utdata. Men når du skal anslå budsjettet på forhånd, holder det med et grovt anslag basert på antall tegn.
## Hvorfor koster utdata mer enn inndata, og hvordan påvirker det regningen?
Viktig poeng
Alle de store leverandørene tar flere ganger mer betalt for utdata enn for inndata. For Claude Opus 5 koster inndata $5 per million tokens, mens utdata koster $25, altså fem ganger så mye. Claude Sonnet 5 har samme forhold: $2 mot $10. Grunnen er at det er vanskeligere for modellen å generere et svar enn å lese en forespørsel. Den praktiske lærdommen er at et langt svar belaster regningen mer enn et langt spørsmål. Den samme tekstmengden koster flere ganger mer som utdata enn som inndata, så det er billigere å be modellen om et kortfattet svar. «Forklar det så detaljert som mulig» øker direkte den dyreste delen av regningen.
Her er en tabell med offisielle priser per million tokens tidlig i september 2026 — du ser at utdata koster flere ganger mer enn inndata over hele linja.
| Model | Inndata, per 1M | Utdata, per 1M | Hvor mye mer utdata koster |
|------------------|---------------|----------------|----------------------------|
| Claude Opus 5 | $5 | $25 | 5 ganger |
| Claude Sonnet 5 | $2 | $10 | 5 ganger |
| Claude Haiku 4.5 | $1 | $5 | 5 ganger |
| GPT-5.6-terra | $2 | $12 | 6 ganger |
| DeepSeek V4 Pro | $0.66 | $1.98 | 3 ganger |
Prisforskjellen mellom leverandørene er enorm: én million inndata-tokens for Claude Opus 5 koster like mye som omtrent 7.58 millioner for DeepSeek Pro med tabellens inndatapriser ($5 ÷ $0.66 ≈ 7.58). Men innenfor hver prisklasse gjelder én regel: utdata koster tre til seks ganger mer enn inndata. Grunnen er enkel: Det er lettere for modellen å lese forespørselen din enn å skrive et svar, og det mer krevende arbeidet koster mer.
Det leder til en konklusjon som påvirker regningen direkte. Et langt svar er dyrere enn et langt spørsmål. Hvis du ber modellen om å «forklare det så detaljert som mulig», øker du selv den dyreste delen av regningen. Den samme betydningen uttrykt i et kort svar koster flere ganger mindre. Dette er én av grunnene til at vibe coding er billig for én person, men kan tømme budsjettet til en annen på én dag — selv med samme modell.
## Hvordan beregner du hvor lenge budsjettet ditt varer?
Viktig poeng
For å beregne hvor lenge pengene varer, anslår du kostnaden for en typisk forespørsel og deler budsjettet på dette beløpet. Ta gjennomsnittlig antall inndata- og utdata-tokens per forespørsel, multipliser hvert antall med sin egen pris og legg dem sammen — da får du kostnaden for én forespørsel. Del deretter budsjettet på denne kostnaden for å finne ut hvor mange forespørsler pengene dine dekker.
La oss sette det hele inn i en trinnvis beregning. Bruk dine egne priser, typiske tokenmengder og budsjett.
1. Anslå en typisk forespørsel. La oss si at ett kall bruker 20,000 inndata-tokens (spørsmålet pluss en kodebit og litt historikk) og 2,000 utdata-tokens (modellens svar).
2. Beregn kostnaden for inndata: del antallet inndata-tokens på én million og multipliser med inndataprisen per million tokens.
3. Beregn kostnaden for utdata: del antallet utdata-tokens på én million og multipliser med utdataprisen per million tokens.
4. Legg sammen kostnadene for inndata og utdata.
5. Del budsjettet på den beregnede kostnaden per forespørsel.
Med Opus 5-prisene i artikkelens tabell: 20,000 ÷ 1,000,000 × $5 = $0.10 for inndata, og 2,000 ÷ 1,000,000 × $25 = $0.05 for utdata. Totalt: **$0.15 per forespørsel uten cache**. Et budsjett på $10 dekker 66 hele forespørsler ($9.90), forutsatt samme tokenantall og ingen andre kostnader.
En faktisk forespørsel er nesten aldri «gjennomsnittlig»: Legger du ved en stor fil eller trekker ut en lang samtale, vokser inndata fra 20,000 tokens til 200,000. Regn derfor ut fra måten du vanligvis jobber på; en idealisert forespørsel gir feil svar. Det er også best å runde opp.
Devin, Claude Code og alle andre AI-agenter bruker samme API og bruker tokens etter samme formel — den eneste forskjellen er at en agent bruker mer fordi den foretar mange kall i bakgrunnen. Jeg har skrevet separat om hvorfor dette gjør vibe coding dyrere enn forventet i artikkelen om de [skjulte kostnadene ved vibe coding](https://ailoot.ai/blog/nb/vibe-coding-kostnad-tid/).
## Hva er cacherabatten, og når gjelder den?
Viktig poeng
Caching betyr at modellen husker en del av inndataene den allerede har lest, og ikke tar full pris for å behandle dem neste gang. Cacherabatten gjelder bare inndata som gjentas fra én forespørsel til den neste: en systeminstruksjon, en stor kontekst eller et vedlagt dokument. Cachelesing hos Claude koster ti ganger mindre enn vanlig inndata; hos DeepSeek koster det mer enn tretti ganger mindre. Rabatten gjelder aldri utdata: modellen genererer svaret fra bunnen av hver gang. En detalj til: Den første skrivingen til cachen koster litt mer enn vanlig inndata, så besparelsen begynner med den andre forespørselen.
Nå til caching — «opptil 80 prosent rabatt» som får beregningen til å virke komplisert. Mekanismen er enkel. Noen inndata er de samme fra én forespørsel til den neste: systeminstruksjonen i begynnelsen, en stor kontekstdel eller et vedlagt dokument du jobber med gjennom flere kall. Caching gjør at modellen slipper å lese denne delen på nytt fra bunnen av hver gang, og i stedet kan hente den fra minnet til en mye lavere pris.
Hvor mye lavere prisen blir, avhenger av leverandøren. For Claude koster det ti ganger mindre å lese fra cachen enn å bruke vanlig inndata: For Opus 5 er vanlig inndata $5 per million, mens en cachelesing koster $0.50. DeepSeeks rabatt er enda større: bufrede inndata for flash-modellen koster $0.007 mot $0.22 for vanlig inndata, altså mer enn tretti ganger mindre. «Opptil 80 prosent rabatt» er derfor et forsiktig anslag; den faktiske rabatten kan være større.
Husk på to vilkår, ellers blir cacheberegningen feil.
- Rabatten gjelder bare gjentatte inndata. Modellen genererer utdata fra bunnen av hver gang, og får ingen cacherabatt for dem. Hvis det meste av regningen kommer fra lange svar, vil caching spare deg for svært lite.
- Den første skrivingen til cachen koster litt mer enn vanlig inndata. For korttidslagring tar Claude 1.25 ganger den vanlige inndataprisen for en cachelagring. Besparelsen begynner med den andre forespørselen, som leser delen som allerede er bufret. Caching hjelper ikke i det hele tatt ved en engangsforespørsel og koster faktisk litt mer.
## Hvordan beregner du budsjettet på nytt når du tar hensyn til caching?
Viktig poeng
For å ta hensyn til caching deler du inndataene i to deler: Den gjentatte delen faktureres til cacheprisen, og den nye delen til full pris. Resten av formelen er den samme.
La oss gå tilbake til eksempelet på forespørselsmengden og legge til caching. Tanken er å dele inndataene i to deler: delen som gjentas og kvalifiserer for rabatten, og delen som er ny i hver forespørsel.
Ta samme forespørsel med 20,000 inndata-tokens og 2,000 utdata-tokens. La 15,000 inndata-tokens være uendret kontekst og 5,000 være nye. Bruk Opus 5-prisene ovenfor: $5 per million nye inndata-tokens, $0.50 per million cacheleste tokens, $6.25 per million tokens ved kortvarig cacheskriving (1.25 × $5), og $25 per million utdata-tokens.
| Forespørsel | Beregning av inndata | Utdata | Totalt |
|----|----|----|----|
| Uten cache | 20,000 / 1M × $5 = $0.10 | 2,000 / 1M × $25 = $0.05 | **$0.15** |
| Første cacheskriving | 15,000 / 1M × $6.25 + 5,000 / 1M × $5 = $0.11875 | $0.05 | **$0.16875** |
| Senere verifisert cachetreff | 15,000 / 1M × $0.50 + 5,000 / 1M × $5 = $0.0325 | $0.05 | **$0.0825** |
Den gjentatte forespørselen er 45 % billigere enn $0.15 uten cache, selv om den bufrede inndatadelen er 90 % billigere. Første skriving koster mer. To kall, én skriving og ett treff, koster $0.25125 i stedet for $0.30. Med $10 gir én skriving fulgt av 119 verifiserte treff 120 kall for $9.98625. Dette forutsetter gyldig cache, samme tokenantall i alle kall og ingen andre kostnader. Bruk faktiske tall for cachelesing og cacheskriving fremfor å anta at hver gjentakelse treffer.
Da får vi denne regelen: Caching lønner seg når du bruker én stor kontekst i mange forespørsler, og er nytteløst for korte, spredte spørsmål.
## Hvor brukes tokens uten at du merker det?
Viktig poeng
Den største skjulte utgiften er en samtalehistorikk som stadig vokser. Hver nye melding tar med hele den tidligere samtalen som inndata, så mot slutten av en lang samtale koster én forespørsel flere ganger mer enn den gjorde i begynnelsen. Den andre kilden er modellens resonneringsmodus: skjult resonnering telles også som utdata-tokens, den dyreste typen. Den tredje er store vedlagte filer, som sendes i sin helhet som inndata ved hver forespørsel. For å unngå at budsjettet renner ut uten grunn, start lange samtaler på nytt med jevne mellomrom og hold tung kontekst bufret.
Regningene ender ofte høyere enn anslått, nesten alltid på grunn av tre ting du ikke ser med et raskt blikk.
Den første og største er samtalehistorikken. Modellen husker ikke tidligere meldinger på egen hånd; hele samtalen sendes på nytt som en del av inndataene hver gang. Det betyr at den tiende meldingen i en lang samtale alle de ni tidligere meldingene og svarene deres tar med seg. En forespørsel koster lite i starten av en samtale, men tegen slutten koster et spørsmål met dezelfde betekenis flera gånger mer fordi inndataene har vokst. Et enkelt triks: Start en ny samtale når temaet endres. Du trenger ikke dra én samtale ut i det uendelige.
Den andre er resonneringsmodus. Nyere modeller har en modus der modellen først arbeider seg gjennom resonneringen internt og deretter svarer. Denne resonneringen telles også som utdata-tokens, og utdata er den dyreste delen. Svaret ser kort ut, men det ligger mange tokens bak det, så regningen kommer som en overraskelse.
Den tredje er store vedlegg. Legger du et stort dokument eller en samling filer ved en forespørsel, sendes de i sin helhet som inndata ved hvert kall så lenge de ligger i konteksten. Hvis du jobber med det samme dokumentet en stund, lønner det seg å holde det bufret, så du slipper å betale full pris for det hver gang. Å styre hva som blir værende i konteksten, er en egen ferdighet som kalles context engineering, og den påvirker regningen direkte.
## Hvordan følger du med på forbruket uten å regne det ut manuelt?
Viktig poeng
Hvert API-svar returnerer metadatafelter med det nøyaktige antallet tokens som ble brukt til inndata og utdata, inkludert den bufrede delen separat. De viser den faktiske kostnaden for en bestemt forespørsel, så det er ikke lenger nødvendig å anslå. Kontooversikten hos leverandøren har en bruksside som viser daglige utgifter og gjenværende saldo — sjekk den mens du fortsatt har penger. For å holde kontroll er det nyttig å sette en månedlig forbruksgrense og slå av automatisk påfyll til du kjenner det vanlige forbruket ditt.
Du trenger bare å anslå manuelt én gang — for å forstå omtrent hvor lenge pengene dine varer. Etter det trenger du ikke regne for hånd; API-et gjør det for deg.
Hvert modellsvar kommer med metadatafelter som viser det nøyaktige antallet tokens i forespørselen: hvor mange som gikk til inndata, hvor mange som gikk til utdata, hvor mange inndata-tokens som ble lest fra cachen, og hvor mange som ble skrevet til den for første gang. Dette er nøyaktige fakta om et bestemt kall, og de viser hvor budsjettet ditt faktisk går. Hvis du bruker et verktøy som Claude Code, viser det vanligvis forbruket selv etter hver oppgave.
Det finnes også en bruksside i leverandørens kontooversikt, med utgifter per dag og gjeldende saldo. Sjekk den av og til, særlig de første ukene, til du får en følelse av det vanlige forbruksmønsteret ditt. Et par vaner kan også hjelpe deg med å spare penger: Sett en månedlig forbruksgrense hvis leverandøren tilbyr det, og ikke slå på automatisk påfyll av saldo før du vet hvor mye du vanligvis bruker. Ellers kan en agent som løper løpsk over natten, belaste deg mer enn du forventet.
### Kilder
- [Anthropic - modellpriser](https://docs.claude.com/en/docs/about-claude/pricing) - priser for inndata, utdata og cache for alle Claude-modeller
- [Anthropic - hurtigbufring av forespørsler](https://docs.claude.com/en/docs/build-with-claude/prompt-caching) - hvordan caching fungerer, skrive- og lesepriser, minste lengde
- [DeepSeek - modeller og priser](https://api-docs.deepseek.com/quick_start/pricing) - bruksformel, priser ved cachetreff og cachemiss, priser på dag- og nattid
- [OpenAI - API-priser](https://platform.openai.com/docs/pricing) - priser på inndata, bufrede inndata og utdata for GPT-modeller
Bli kjent med [Ailoot](https://ailoot.ai/).
## Spørsmål om denne veiledningen: OpenAI API-priser i 2026: beregn tokenbruk og budsjett
### Hva koster eksempelforespørselen uten cache?
Med artikkelens Opus 5-priser koster 20,000 inndata-tokens $0.10 og 2,000 utdata-tokens $0.05, totalt $0.15. Et budsjett på $10 dekker 66 hele kall med denne faste størrelsen, før andre kostnader.
### Hvorfor er cacherabatten mindre for hele forespørselen enn for bufret inndata?
Nye inndata og utdata koster fortsatt vanlig pris. I eksemplet gir 15,000 bufrede inndata-tokens, 5,000 nye og 2,000 utdata en total på $0.0825, altså 45 % mindre enn $0.15. Den første cacheskrivingen koster derimot $0.16875.
## Ailoot · Selskapet og dets prosjektportefølje
Ailoot bygger på etablert driftserfaring, en stor kundebase, stabil tjeneste og løpende KPI-kontroll.
Selskapet og dets prosjektportefølje: millioner av kunder; månedlig salg for milliarder.
Ailoot bruker denne driftserfaringen til API-tilgang til AI-funksjoner i kundenes produkter, agenter, applikasjoner og automatiseringer.