Token-kostnad: en räknebok för icke-utvecklare

Det första jag brukar fråga när någon CFO ringer och vill ha en AI-budget är vilken modell de tror att de kommer köra. Nio gånger av tio får jag svaret "GPT". Sedan blir det tyst när jag följer upp med vilken version, hur många tokens per request, om de räknar med caching, och vad input kontra output kostar. Det är ingen kritik. Det är bara att hela token-ekonomin är skriven av ingenjörer för ingenjörer, och om du sitter på finanssidan så finns det ingen självklar plats att lära sig grunderna utan att direkt drunkna i tokenizers och context windows.

Den här posten är ett försök att ge dig räkneverktyget. Inte en heltäckande guide. Bara tillräckligt mycket för att du ska kunna sitta i ett möte med en utvecklare och säga "vänta, varför kör vi Opus på det här flödet, kan vi inte cacha systemprompten" utan att låta som du läst en LinkedIn-tråd över helgen.

En token är ungefär ett halvt ord

Tokens är hur språkmodellerna mäter text. Inte tecken, inte ord, utan något mittemellan. På engelska går det ungefär fyra tecken på en token, eller cirka tre fjärdedels ord. På svenska är det tätare, runt tre tecken per token, dels för att vi har sammansatta ord som "kassaflödesprognos" och dels för att tokenizers från OpenAI och Anthropic är tränade primärt på engelsk text. Det betyder att samma mening på svenska typiskt kostar tjugo till trettio procent mer än på engelska. Det är inte mycket på en enskild request, men det adderar.

När du skickar en prompt till Claude eller gpt-5.4 så räknas allt. Systemprompten du satt en gång och glömt bort. Hela chathistoriken som följt med sedan användaren öppnade fönstret. Dokumentet du klistrade in. Filen som RAG-systemet plockat fram som kontext. Allt slås ihop och blir input. Sedan genererar modellen ett svar, och det blir output. Båda räknas, men de har olika prislappar.

Det är just det där sista som de flesta missar i sin första budget. Output kostar ungefär fem gånger mer än input. Hos Anthropic ligger Claude Sonnet 4.6 just nu på tre dollar per miljon input-tokens och femton dollar per miljon output. Haiku är mycket billigare, ungefär en tjugondel. Hos OpenAI ser strukturen liknande ut, även om priserna rör sig kvartalsvis. Logiken bakom prisskillnaden är att modellen "tänker" mer aktivt när den genererar text än när den läser den, och varje genererad token är ett helt eget inferenssteg på GPU.

Varför input-output-spliten är hela vitsen

Säg att du bygger ett kundtjänstflöde. En typisk konversation kan se ut så här: systemprompten är på 1500 tokens (instruktioner, ton, FAQ-utdrag, vad boten får och inte får svara på). Användarens första fråga är 50 tokens. Boten svarar med 200 tokens. Användaren följer upp med 80. Boten svarar med 250. Och så vidare i kanske sex omgångar.

När du räknar på det här missar de flesta att systemprompten skickas med varje gång. Eftersom modellen är stateless. Den minns inget mellan anrop. Hela historiken plus systemprompten plus den nya frågan måste skickas in vid varje tur. Vid sjätte svaret har du redan skickat in samma 1500-tokens-systemprompt sex gånger. Det är 9000 input-tokens bara där, och alla är identiska.

Det här är där prompt caching kommer in, och varför det är förmodligen den viktigaste enskilda kostnadsknappen för icke-utvecklare att förstå.

Caching halverar inte kostnaden, den decimerar den

Anthropic och OpenAI har båda nu prompt caching, fast de implementerar det olika. Hos Anthropic markerar du i din API-request vilka delar av prompten som är "stabila", typiskt systemprompten och eventuella RAG-dokument du ofta återanvänder. Första gången du skickar dem cachas de på Anthropics sida, och du betalar 25 procent extra för cache-write. Nästa gång du återanvänder samma cachade segment betalar du bara 10 procent av normalpriset. Cachen lever i fem minuter, eller en timme om du betalar lite mer.

För kundtjänstflödet ovan: utan caching betalar du för 1500 tokens systemprompt sex gånger, det vill säga 9000 input-tokens. Med caching betalar du 1875 första gången (1500 plus 25 procents cache-write-overhead), och sedan 150 tokens per återbesök i fem omgångar. Det blir 1875 plus 750, totalt 2625 tokens istället för 9000. Du har just dragit ner systemprompt-kostnaden med drygt 70 procent, och allt du behövde göra var att flagga ett par fält i API-anropet.

Det här är en av få saker där jag tycker att alla nya kundprojekt borde börja med caching-arkitekturen redan i designfasen, inte som en optimering vi adderar i produktion. Det jag är trött på är att se PoC-projekt som rusar igenom byggfasen, går live, och sedan får panikfaktura första månaden eftersom ingen tänkt på att samma fyrasidors instruktion skickas med varje enskild request.

Modellval: när lönar sig Sonnet över Haiku

Det andra stora budgetbeslutet är vilken modell-tier du kör. Och här finns det inget allmängiltigt svar. Det beror på vad uppgiften är.

Haiku, Anthropics minsta modell, är blixtsnabb och kostar ungefär en dollar per miljon output-tokens. Den är mer än tillräcklig för klassificering, kortare summeringar, enklare extraction-uppgifter, intent-routing, och alla sorters "är det här ett klagomål eller en fråga"-flöden. Sonnet är dyrare och långsammare, men avsevärt bättre på flerstegs-resonemang, kodgenerering, längre dokumentanalys och allt som kräver nyans. Opus är toppmodellen, ungefär fem gånger dyrare än Sonnet på output, och används mest för avancerad kvalitativ analys eller där du verkligen behöver en sista grad av precision.

Min tumregel när vi designar pipelines är att börja med Sonnet för allt, sedan systematiskt downgrade:a stegen som visar sig fungera lika bra på Haiku. En vanlig arkitektur är att ha Sonnet som "huvudhjärnan" som hanterar det centrala flödet, men Haiku som assistent på sidouppgifter: klassificera intent innan du skickar till Sonnet, summera långa dokument innan de går vidare, validera output, det där. Det är ofta så man får tio gångers kostnadsskillnad utan att kvaliteten på slutresultatet märkbart ändras.

Det här är också anledningen till att routing-bibliotek som LiteLLM eller egna LangGraph-orchestrators har blivit standard. Du vill kunna byta modell per task utan att skriva om hela kodbasen. Vi använder det själva för att kunna A/B-testa modeller på enskilda steg och se exakt var kvalitetstaket ligger.

Tre räkneexempel som fångar det mesta

Låt oss göra det konkret. Tre vanliga use cases, faktiska siffror, och vad det landar på i kronor.

En kundtjänstkonversation

Snittsessionen för ett B2C-bolag vi tittat på i en demo-arkitektur ligger på sex turtagningar. Med en systemprompt på 1500 tokens, RAG-context på cirka 800 tokens per fråga (en handfull relevanta utdrag från hjälpcentret), användarinput på 60 tokens i snitt, och svar på 220 tokens. Med Sonnet och full caching av systemprompt och RAG-bibliotek landar du på cirka 0.012 dollar per session. Utan caching, runt 0.038. Med Haiku istället för Sonnet på exakt samma flöde, runt 0.001 per session med caching.

För 10 000 sessioner per månad blir det 120 dollar med Sonnet plus caching, eller 10 dollar med Haiku plus caching. Frågan är då om Haiku håller måttet kvalitetsmässigt på just ditt flöde, och det får man bara svar på genom att A/B-testa. Min erfarenhet är att tier-1 support, alltså frågor som "var är min order" och "hur byter jag lösenord", går utmärkt på Haiku. Mer nyanserade dialoger där boten behöver väga olika alternativ mot varandra brukar kräva Sonnet.

En KYC-genomgång

Säg att du bygger en automatiserad genomgång av nya företagskunder. Boten får in en handling: registreringsbevis, ID-kopior, kanske en årsredovisning. Den ska extrahera nyckelinformation, kontrollera mot sanktionslistor, flagga eventuella röda flaggor, och producera en rapport för en mänsklig handläggare att signera av.

Inputmängden är hög här: en årsredovisning kan landa på 30 000 till 60 000 tokens om den är textrik. Plus systemprompt med regelverk på säg 4000 tokens. Output är moderat, kanske 1500 tokens i en strukturerad rapport. Med Sonnet utan caching: runt 0.18 dollar per genomgång på input-sidan plus 0.022 på output-sidan, alltså ungefär 0.20 totalt. Med systemprompten cachad sjunker det till runt 0.16. Om du dessutom kör en lokal modell som Llama 3.1 70B eller Qwen2.5 72B på ett RTX 6000-rigg eller via en H100-instans, så är inferenskostnaden i princip elkostnaden plus serveravskrivning, som ofta hamnar på en tiondel eller mindre per request, men då har du istället en investering på två till tio tusen dollar i hårdvara att amortera.

För 500 KYC per månad blir det runt 80 dollar via Anthropic, eller mer eller mindre noll på en lokal lösning som du redan betalat för. Och för dataskyddskänsliga use cases är "skickas aldrig till tredje part" ofta ett krav i sig, oavsett vad räknesnurran säger.

En sammanfattning

Det enklaste fallet. Du har ett 20-sidors mötesprotokoll, ungefär 12 000 tokens, och vill ha en sammanfattning på en halvsida. Systemprompt 300 tokens. Output 600 tokens. Med Sonnet: 0.037 input plus 0.009 output, totalt under fyra cent. Med Haiku: under en cent. Och här ärligt talat behöver du inte ens överväga caching. Det är en engångsoperation och hela kostnadsbilden är så låg att det inte är värt komplexiteten.

Det här är det jag försöker få CFO:er att förstå tidigt: vissa användningsfall är så billiga att hela budgeteringsdiskussionen är meningslös. Andra, som långa pågående konversationer eller storskalig dokumentbearbetning, kan ärligt talat dra iväg om man inte tänker på arkitekturen från början. Det är just där en API-faktura kan gå från 200 dollar till 8000 på en månad utan att ledningen riktigt fattar varför.

Det som inte syns i prislistan

Två saker till att lägga på bordet, eftersom de aldrig står i Anthropics eller OpenAIs prismatris men dyker upp i din faktiska budget.

Det första är retries. Om modellen returnerar ett dåligt svar, eller om JSON-parsingen failar, så kör de flesta system om requesten. Räkna med en 10 till 20 procents overhead på ett produktionsflöde av den anledningen ensam. Det andra är embedding-kostnader för RAG. Om du bygger ett retrievalsystem med pgvector eller liknande så behöver du embedda alla dokument i biblioteket, och varje gång användaren ställer en fråga embeddas också den. Embedding-modeller som BAAI/bge-m3 är gratis om du kör lokalt, eller cirka 0.02 dollar per miljon tokens om du använder OpenAIs eller Voyages tjänster. Inte mycket per request, men på ett bibliotek på en miljon dokument lägger det grunden till en initial engångskostnad värd att budgetera.

Min teori är att de flesta bolag som börjar bygga AI-funktioner överskattar tokenkostnaden för enskilda requests och underskattar den ackumulerade kostnaden av designval. Att köra Sonnet där Haiku räcker, att inte cacha återanvändbar kontext, att göra fyra modellanrop där tre räcker, att inte streama svar och därför skicka in samma långa kontext igen om användaren avbryter. Allt det adderar till något som ser harmlöst ut på en enskild rad i loggen men blir en post på fem siffror i månadsfakturan.

På Kapaciti gör vi mycket av det här. Hör av dig om det är aktuellt.