OpenAI API-kostnader 2026: beräkna indata, utdata och tokenbudget

Du sätter in pengar på ett API-konto och stöter nästan genast på frågan: hur länge räcker de? Du har något i stil med ”Jag har tiotusen, indata kostar så här mycket, utdata kostar mer, och det finns någon sorts cacherabatt också” i huvudet – men det är oklart hur allt ska omvandlas till en enda siffra. Jag går igenom det steg för steg, med siffror.

Huvudpoängen först: en API-faktura beräknas med en enda formel – antal token multiplicerat med priset per token. Indata- och utdatatoken räknas separat eftersom de har olika priser. Härnäst visar jag hur du använder detta för att räkna ut hur länge din budget räcker och var cachelagring kommer in i beräkningen.

Information om hur du använder Ailoot finns i dokumentationen.

Vad består en API-faktura av?#

När du anropar en modell via ett API debiteras du för mängden text som passerat genom modellen. Mängden mäts i token. En token är en liten textbit; jag återkommer till det i nästa avsnitt, men tills vidare kan du se den som måttenheten för allt.

Ett enskilt anrop har två sidor. Den första är det du skickade till modellen: själva frågan, bifogade kodstycken eller ett dokument, tidigare meddelanden i konversationen och systeminstruktionen i början. Det är indata. Den andra är det som modellen skrev som svar. Det är utdata. DeepSeek säger det uttryckligen i sin prisbeskrivning: fakturan baseras på det totala antalet in- och utdatatoken.

Indata och utdata har olika priser, så de räknas separat. Formeln för en förfrågan är enkel:

cost = (input tokens × input price) + (output tokens × output price)

Priser anges vanligtvis per miljon token – det är smidigare eftersom en enskild token kostar en bråkdel av en valutaenhet. All räkning härefter utgår från den här formeln, och din budget räcker till precis så många förfrågningar som ryms inom dina tillgängliga medel till det priset.

En token är inte ett ord: Hur uppskattar du hur många du använder?#

Det första många snubblar på: en token är inte detsamma som ett ord. Modellen delar upp texten i delar enligt sina egna regler, och en del kan vara ett helt kort ord, en del av ett längre ord, ett mellanslag med en bokstav eller ett skiljetecken. Därför kan du inte räkna ut exakt i huvudet ”hur många token min förfrågan kommer att ta” – du kan bara uppskatta.

Här är en grov tumregel. I engelsk text motsvarar en token ungefär fyra tecken; det är en utgångspunkt från Anthropic och OpenAI själva. Modeller delar upp rysk text i mindre delar: kyrillisk skrift bryts upp i kortare bitar, så samma text sett till betydelsen använder fler token. Hur många fler beror på modellen, men räkna med en och en halv till två gånger så många som på engelska.

Så här ser det ut i token. Om du skickar en sida text till modellen och får ett stycke som svar handlar det redan om tusentals indatatoken och hundratals utdatatoken. Och om du bifogar en stor fil till en förfrågan eller har en lång konversationshistorik kan indata växa till tiotusentals token, och merparten av fakturan kommer då därifrån. API-svaret visar den exakta siffran – i sina metadatafält anger det hur många token som faktiskt användes för indata och utdata. Men för att uppskatta din budget i förväg räcker en grov uppskattning utifrån antal tecken.

Varför kostar utdata mer än indata, och hur påverkar det fakturan?#

Här är en tabell med officiella priser per miljon token i början av september 2026 – du ser att utdata kostar flera gånger mer än indata över hela linjen.

Prisskillnaden mellan leverantörerna är enorm: en miljon indatatoken för Claude Opus 5 kostar lika mycket som cirka 7,58 miljoner för DeepSeek Pro enligt tabellens indatapriser (5 dollar ÷ 0,66 dollar ≈ 7,58). Men inom varje prisnivå gäller en regel: utdata kostar tre till sex gånger mer än indata. Anledningen är enkel: det är lättare för modellen att läsa din förfrågan än att skriva ett svar, och det mer krävande arbetet kostar mer.

Det leder till en slutsats som direkt påverkar din faktura. Ett långt svar är dyrare än en lång fråga. Om du ber modellen att ”förklara så utförligt som möjligt” blåser du själv upp den dyraste delen av fakturan. Samma innebörd uttryckt i ett kort svar kostar flera gånger mindre. Det är en anledning till att vibe coding är billigt för en person men förbrukar en annan persons budget på en dag – även med samma modell.

Hur räknar du ut hur länge din budget räcker?#

Låt oss räkna ut allt steg för steg. Sätt in dina egna priser, typiska tokenvolymer och din budget.

1. Uppskatta en typisk förfrågan. Anta att ett anrop använder 20 000 indatatoken (frågan plus ett kodstycke och lite historik) och 2 000 utdatatoken (modellens svar).
2. Beräkna kostnaden för indata: dividera antalet indatatoken med en miljon och multiplicera med ditt indatpris per miljon token.
3. Beräkna kostnaden för utdata: dividera antalet utdatatoken med en miljon och multiplicera med ditt utdatapris per miljon token.
4. Lägg ihop kostnaderna för indata och utdata.
5. Dividera din budget med den resulterande kostnaden per förfrågan.

Med Opus 5-priserna i artikelns tabell: 20 000 ÷ 1 000 000 × 5 dollar = 0,10 dollar för indata och 2 000 ÷ 1 000 000 × 25 dollar = 0,05 dollar för utdata. Totalt: 0,15 dollar per förfrågan utan cache. En budget på 10 dollar räcker till 66 hela förfrågningar (9,90 dollar), förutsatt samma tokenantal och inga andra avgifter.

En verklig förfrågan är nästan aldrig ”genomsnittlig”: bifoga en stor fil eller dra ut på en lång konversation, så växer indata från 20 000 token till 200 000. Räkna därför utifrån hur du brukar arbeta; en idealiserad förfrågan ger fel svar. Det är också bättre att avrunda uppåt.

Devin, Claude Code och alla andra AI-agenter använder samma API och förbrukar token enligt samma formel – den enda skillnaden är att en agent använder mer eftersom den gör många anrop i bakgrunden. Jag har separat gått igenom varför vibe coding kostar mer än väntat i artikeln om vibe codings dolda kostnad.

Vad är cacherabatten, och när gäller den?#

Nu till cachelagring – ”upp till 80 procents rabatt”, vilket får beräkningen att verka komplicerad. Mekaniken är enkel. En del indata förblir oförändrad från en förfrågan till nästa: systeminstruktionen i början, ett stort sammanhang eller ett bifogat dokument som du arbetar med under flera anrop. Cachelagring gör att modellen slipper läsa den delen från början varje gång och i stället kan hämta den ur minnet till ett mycket lägre pris.

Hur mycket lägre beror på leverantören. För Claude kostar en omläsning från cache en tiondel av vanlig indata: för Opus 5 kostar vanlig indata 5 dollar per miljon, medan en cachad läsning kostar 0,50 dollar. DeepSeeks rabatt är ännu större: cachad indata för flashmodellen kostar 0,007 dollar jämfört med 0,22 dollar för vanlig indata, mer än trettio gånger mindre. Så ”upp till 80 procent rabatt” är en försiktig uppskattning; den verkliga rabatten kan vara större.

Tänk på två villkor så att din cacheberäkning inte blir fel.

• Rabatten gäller bara upprepad indata. Modellen genererar utdata från grunden varje gång, och den får ingen cacherabatt alls. Om merparten av din faktura kommer från långa svar sparar cachelagring väldigt lite.
• Den första skrivningen till cachen kostar något mer än vanlig indata. För korttidslagring tar Claude 1,25 gånger det vanliga indatapriset för en cacheskrivning. Besparingen börjar med den andra förfrågan, som läser den del som redan har cachats. Cachelagring hjälper inte alls för en engångsförfrågan och kostar till och med något mer.

Hur räknar du om budgeten med hänsyn till cachelagring?#

Vi återgår till exempelvolymen för en förfrågan och lägger till cachelagring. Tanken är att dela upp indata i två delar: den del som upprepas och berättigar till rabatten och den del som är ny i varje förfrågan.

Ta samma förfrågan med 20 000 indatatoken och 2 000 utdatatoken. Låt 15 000 indatatoken vara oförändrad kontext och 5 000 vara nya. Använd Opus 5-priserna ovan: 5 dollar per miljon nya indatatoken, 0,50 dollar per miljon cachelästa token, 6,25 dollar per miljon korttids-cacheskrivna token (1,25 × 5 dollar) och 25 dollar per miljon utdatatoken.

Den upprepade förfrågan är 45% billigare än förfrågan utan cache för 0,15 dollar, trots att den cachade indatadelen är 90% billigare. Den första skrivningen kostar mer. Två anrop (en skrivning och en träff) kostar 0,25125 dollar i stället för 0,30 dollar. Med en budget på 10 dollar ger en skrivning följd av 119 verifierade träffar 120 anrop för 9,98625 dollar. Detta förutsätter att cachen förblir giltig, att alla anrop har dessa tokenantal och att inga andra avgifter tillkommer; använd faktisk cacheläsnings- och cacheskrivningsanvändning i stället för att anta att varje upprepning ger träff.

Då får vi regeln: cachelagring lönar sig när du använder ett stort sammanhang i många förfrågningar och är meningslös för enstaka korta frågor.

Var förbrukas token utan att du märker det?#

Fakturor blir ofta högre än beräknat, nästan alltid på grund av tre saker som du inte ser vid första anblicken.

Den första och största är konversationshistoriken. Modellen kommer inte ihåg tidigare meddelanden av sig själv; hela konversationen skickas till den igen som en del av indata varje gång. Det innebär att det tionde meddelandet i en lång konversation innehåller alla nio tidigare meddelanden och deras svar. En förfrågan kostar lite i början av en konversation, men mot slutet kostar en fråga med samma innebörd flera gånger mer eftersom indata har vuxit. Här är ett enkelt knep: börja en ny konversation när ämnet ändras. Du behöver inte dra ut på en och samma konversation i all evighet.

Den andra är resonemangsläget. Nyare modeller har ett läge där modellen först går igenom sitt resonemang internt och först därefter svarar. Även det resonemanget räknas som utdatatoken, och utdata är den dyraste delen. Svaret ser kort ut, men det ligger många token bakom det, så fakturan kommer som en överraskning.

Den tredje är stora bilagor. Bifoga ett stort dokument eller en samling filer till en förfrågan, så skickas de i sin helhet som indata med varje anrop så länge de finns kvar i sammanhanget. Om du arbetar med samma dokument ett tag är det värt att hålla det cachat, så att du inte fortsätter betala fullt pris för det. Att hantera vad som finns kvar i sammanhanget är en separat färdighet som kallas context engineering, och den påverkar fakturan direkt.

Hur kan du följa utgifterna utan att räkna manuellt?#

Du behöver bara uppskatta manuellt en gång – för att förstå hur länge pengarna räcker i allmänhet. Därefter behöver du inte räkna för hand; API:t gör det åt dig.

Varje modellsvar åtföljs av metadatafält som visar det exakta antalet token i förfrågan: hur många som gick till indata, hur många till utdata, hur många indatatoken som lästes från cache och hur många som skrevs till den för första gången. Det är exakta uppgifter om ett visst anrop, och de visar vart budgeten faktiskt tar vägen. Om du använder ett verktyg som Claude Code visar det vanligtvis användningen efter varje uppgift.

Det finns också en användningssida i leverantörens kontopanel med utgifter per dag och ditt aktuella saldo. Titta in där då och då, särskilt under de första veckorna, tills du får en känsla för ditt vanliga utgiftsmönster. Ett par vanor hjälper också till att spara pengar: sätt en månatlig utgiftsgräns om leverantören tillåter det och slå inte på automatisk saldopåfyllning innan du förstår hur mycket du brukar spendera. Annars kan en agent som skenar iväg över natten debitera mer än väntat.

Lär känna Ailoot.