En token är inte ett ord. Det är det första som behöver sägas, för det är det första som de flesta får fel. En token är en bit text som modellen har lärt sig att se som en enhet. Ibland är det ett helt ord, ibland en stavelse, ibland bara ett mellanslag plus en bokstav. För engelska ligger snittet runt 0.75 ord per token. För svenska är det sämre. Vi har långa sammansatta ord, vi har å ä ö, och tokenizer-bibblan som Anthropic Claude och OpenAI gpt-5.4 är tränade på har sett betydligt mindre svensk text än engelsk. Resultatet är att samma mening på svenska kostar dig ungefär 30 till 50 procent mer i tokens än motsvarande engelsk mening.
Det här är inte en teknisk detalj. Det är en kostnadspost som dyker upp i varje offert vi skriver. Och min erfarenhet är att de flesta som beställer AI-lösningar har ingen aning om hur räkningen ser ut innan fakturan kommer.
Vad du faktiskt betalar för
När du skickar en prompt till en modell betalar du för två saker. Tokens in, alltså det du skickar dit, plus systemprompt, plus eventuell kontext från en RAG-pipeline eller tidigare meddelanden. Och tokens ut, det modellen genererar. Output kostar typiskt fyra till fem gånger mer än input. Det är värt att skriva det två gånger för det är där folk gör mest fel: output är dyrare. Mycket dyrare.
För Claude Sonnet 4.6, som är arbetshästen vi använder för ungefär 80 procent av alla produktionsflöden, ligger priset i skrivande stund på 3 dollar per miljon input-tokens och 15 dollar per miljon output-tokens. Sonnet 4.7 ligger i samma härad. För Claude Haiku 4.5, lillebror som vi använder för enklare klassificering och triage, är det runt 1 dollar in och 5 dollar ut per miljon. Opus 4.7, premiummodellen, kostar 15 in och 75 ut. Det är 25 gånger dyrare än Haiku på output. Den siffran ska du ha i magen när du designar en arkitektur.
Räknemodellen som faktiskt fungerar i en offert
Säg att en kund vill processa 1000 mail per dag. Klassisk use-case. Vi vill kategorisera, extrahera viktiga datapunkter, dra ut nästa steg. En realistisk svensk mail är runt 300 ord, vilket på svenska blir cirka 450 till 500 tokens. Lägg till en systemprompt på 800 tokens där vi beskriver kategorierna, exempel och format. Då har vi 1300 tokens in per mail. Output är typiskt en strukturerad JSON med 5 till 10 fält, kanske 200 tokens.
Räkningen blir: 1300 input-tokens gånger 1000 mail blir 1.3 miljoner tokens per dag in. 200 output-tokens gånger 1000 mail blir 200 000 tokens ut. På Sonnet 4.6 hamnar vi då på 3.9 dollar i input och 3 dollar i output. Knappt 7 dollar per dag, runt 75 kronor. På månadsbasis 2250 kronor. På årsbasis 27 000.
Det är fortfarande billigare än en halv timmes mänskligt arbete per dag. Men det är inte gratis, och det skalar linjärt. Tio gånger så mycket mail blir tio gånger så dyrt. Det är där folk halkar.
Var pengarna faktiskt försvinner
Det jag är trött på är att se demos där man skickar in hela dokumentet på 40 sidor i varje prompt för att svara på en enkel fråga. Det är så vanligt att det är skrattretande. En PDF-rapport på 40 sidor är runt 30 000 tokens på svenska. Om du processar den 500 gånger per dag för att svara på 500 olika frågor från användare, då drar du 15 miljoner tokens i input. Bara där. Det är 45 dollar om dagen i input, eller 1300 kronor i månaden, för att i 9 av 10 fall ha kunnat skicka 200 tokens om du först hade hämtat rätt avsnitt med en vector search.
Det är här RAG kommer in. Inte som magiskt buzzword, utan som ren ekonomi. Du embedar dokumenten med exempelvis BAAI/bge-m3 eller en svensk-stark embedding-modell, lägger dem i pgvector i Postgres, och hämtar bara de 3 till 5 mest relevanta chunkarna per fråga. Plötsligt skickar du 800 tokens istället för 30 000. Räkningen sjunker med 95 procent. Det är inte överdrift. Det är aritmetik.
Den andra övertrampsfällan är konversationshistorik. Folk lägger på hela tråden i varje prompt utan att tänka. Efter 20 turer i en chattbot har du kanske 15 000 tokens i historik som följer med varje ny fråga. Om bot:en svarar på 200 frågor per dag har du dragit 3 miljoner tokens bara på upprepad historik. Lösningen är summering: efter X turer komprimerar du historiken till en 500-tokens sammanfattning. Det är inte raketforskning. Men det är jobb som någon måste göra, och det är ofta först när fakturan kommer som någon faktiskt gör det.
Prompt caching, eller hur du halverar räkningen utan att ändra något
Det här är en av få saker där jag tycker att Anthropic har gjort något riktigt smart. Prompt caching låter dig markera delar av prompten som "den här delen är samma i de flesta anrop". Systemprompten, exemplen, ett dokument du återanvänder. Cachade input-tokens kostar 10 procent av normalpris efter första anropet, och cachen håller i 5 minuter (eller en timme om du betalar lite extra för det). På OpenAI fungerar det automatiskt, men du behöver fortfarande designa prompten så att den statiska biten ligger först.
I ett typscenario med en tung systemprompt, säg 5000 tokens med exempel och regler, och 100 anrop i sekvens, går kostnaden för systemprompten från 5000 gånger 100 lika med 500 000 tokens till 5000 plus 99 gånger 500 lika med 54 500 tokens. Drygt 90 procent reduktion på input. Och du behöver inte byta modell, inte skriva om något, bara använda cache-parametern i API-anropet.
Caveat: caching hjälper inte om varje anrop är unikt. En kund som ställer helt olika frågor på helt olika dokument får ingen nytta. Men i de flesta produktionsflöden där samma agent gör samma jobb hundratals gånger per dag är det gratispengar. Bokstavligen pengar du lämnar på bordet om du inte använder det.
När du ska byta till en mindre modell
Min teori är att 70 procent av alla AI-anrop som idag går till en frontier-modell kunde gått till en mindre. Folk är rädda för att kvaliteten ska sjunka. Det är legitimt. Men man testar inte. Man bara antar.
För klassificering, triage, JSON-extraktion, första-pass-läsning av mail eller chatlogs, är Haiku 4.5 i många fall lika bra som Sonnet. Vi har kört blindtester där vi låter Sonnet och Haiku göra samma kategoriseringsjobb på 1000 mail och sedan jämför mot en mänsklig referens. På enkla strukturerade jobb skiljer det ofta mindre än 2 procentenheter i precision, samtidigt som kostnaden är ungefär en tredjedel. På årsbasis i ett medelstort flöde blir det fem- till sexsiffriga belopp i besparing.
Sedan har vi den lokala vägen. Llama 3.1 70B eller Qwen2.5 72B körda lokalt via Ollama eller vLLM på en server du redan har, eller hyr för 500 till 2000 kronor i månaden beroende på GPU. Marginalkostnad per anrop: noll. Du betalar bara för hårdvaran. För kunder med höga volymer, kanske 100 000 anrop om dagen, och där svaren inte kräver toppmodellens resonemang, kan det vara en game-changer ekonomiskt. För kunder med 1000 anrop om dagen är det knappast värt komplexiteten. Men en gång om året är det värt att räkna om. Hårdvarupriserna sjunker, modellerna blir bättre, brytpunkten flyttar sig.
Det jag fattar fortfarande inte varför fler inte gör är att blanda. LiteLLM eller en egen router i FastAPI som skickar enkla frågor till Haiku eller en lokal Qwen, och bara eskalerar till Sonnet eller Opus när det behövs. Det kallas modell-tiering, det är 200 rader kod, och det kan halvera din OpenAI-faktura. På riktigt.
En räknemodell du kan använda imorgon
Om du ska estimera kostnad för ett nytt use-case, gör så här. Ta volymen per dag. Multiplicera med snittet tokens in per anrop (inklusive systemprompt och kontext). Det är input-volymen. Multiplicera med snittet tokens ut per anrop. Det är output-volymen. Multiplicera input-volymen med modellens input-pris per miljon tokens. Multiplicera output-volymen med output-priset. Summa per dag. Gånger 30 ger dig månadskostnaden. Gånger 365 ger årskostnaden.
Glöm inte att räkna med embeddings om du kör RAG. De är billiga, ofta 0.10 till 0.20 dollar per miljon tokens, men i ett system där du embedar 100 000 dokument vid uppstart är det fortfarande några hundralappar som ska in i kalkylen.
Lägg sedan på en buffert. Mitt tumregel är 30 procent. Inte för att modellerna ljuger om sina priser, utan för att verkligheten i produktion alltid sliter mer än prototypen. Användare ställer längre frågor än du trodde. Edge cases triggar retries. Felsökning genererar testanrop. Räkna högt så slipper du obehagliga möten med kundens ekonomichef.
Det som faktiskt avgör om en lösning är lönsam
Det är inte modellpriset. Det är prompt-arkitekturen. Vi har sett system där samma uppgift kostar 10 gånger mer hos en byrå än hos en annan, inte för att den ena använde fel modell utan för att den ena skickade fyra gånger så mycket kontext i varje anrop och inte hade cache påslaget. Den tekniska skickligheten ligger i att veta vad som behöver vara i prompten och vad som inte behöver vara där. I att designa RAG så att den hämtar 5 chunkar istället för 50. I att fatta att en kort systemprompt med skarpa exempel ofta slår en lång ramsa med regler.
Och i att räkna. På riktigt räkna. Inte gissa att "det kostar väl några tusenlappar i månaden". Räkna anrop, räkna tokens, läs fakturan när den kommer, och justera. Det är hantverk, inte magi.
På Kapaciti gör vi mycket av det här. Hör av dig om du sitter med en faktura som ser fel ut, eller en offert du inte vet hur du ska prissätta.