Räknebok för icke-utvecklare
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, vilket Anthropic anger i sin egen dokumentation (platform.claude.com/docs/en/about-claude/pricing, läst 19 september 2026). För svenska är det sämre. Vi har långa sammansatta ord, vi har å ä ö, och tokenizern som Anthropic Claude och OpenAI:s modeller är tränade på har sett betydligt mindre svensk text än engelsk. Resultatet är att samma mening på svenska kostar dig fler tokens än motsvarande engelsk mening. Någon primärkälla som satt en exakt siffra på den svenska påslaget har jag inte hittat, så räkna på din egen text i stället för att lita på en tumregel.
Det här är inte en teknisk detalj. Det är en kostnadspost som hör hemma i varje offert. Och min bild är att de flesta som beställer AI-lösningar inte vet hur räkningen ser ut förrän 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 ett sökbibliotek, alltså RAG, där systemet först hämtar relevanta textstycken och skickar med dem, plus tidigare meddelanden. Och tokens ut, det modellen genererar. Output kostar hos Anthropic fem gånger mer än input, på alla modellnivåerna enligt deras prislista. 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.
Claude Sonnet 4.6, den modell jag själv skulle lägga merparten av flödena på, kostar 3 dollar per miljon input-tokens och 15 dollar per miljon output-tokens. Haiku 4.5, den minsta modellen och den jag skulle använda för enklare klassificering och sortering av inkommande ärenden, ligger på 1 dollar in och 5 dollar ut per miljon. Opus 4.7, den tyngsta, kostar 5 in och 25 ut. Alla fyra siffrorna står i Anthropics egen prislista på platform.claude.com/docs/en/about-claude/pricing, läst 19 september 2026. Opus är alltså fem gånger dyrare än Haiku på output, och det förhållandet ska du ha i magen när du designar en arkitektur.
Räknemodellen som faktiskt fungerar i en offert
Säg att ett bolag vill processa 1000 mail per dag. Det här är ett räkneexempel och alla antaganden i det är mina egna. Uppgiften är att 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, som kostar 3 dollar in och 15 dollar ut per miljon tokens enligt Anthropics prislista, hamnar vi då på 3.9 dollar i input och 3 dollar i output. Knappt 7 dollar per dag, runt 75 kronor med en kurs på ungefär 11 kronor per dollar. På månadsbasis 2250 kronor. På årsbasis 27 000.
Det är fortfarande billigare än en halv timmes mänskligt arbete per dag så snart en arbetstimme kostar mer än 150 kronor. 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, drygt 1300 dollar i månaden, för att i de flesta fall ha kunnat skicka 200 tokens om du först hade hämtat rätt avsnitt med en sökning i en vektordatabas.
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 textstyckena, chunkarna, per fråga. Plötsligt skickar du 800 tokens istället för 30 000. I räkneexemplet ovan sjunker input-kostnaden med över 95 procent, och det är ren aritmetik på de antaganden jag satt.
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. Enligt Anthropics prisdokumentation kostar en cache-läsning 10 procent av normalpriset, medan själva cache-skrivningen kostar 25 procent mer än vanlig input, och cachen håller i fem minuter eller en timme om du betalar dubbelt för skrivningen (platform.claude.com/docs/en/about-claude/pricing, läst 19 september 2026). Hos OpenAI sköts en del av 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 6250 för cache-skrivningen plus 99 gånger 500 för läsningarna, alltså 55 750 tokens. Knappt 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.
En reservation: caching hjälper inte om varje anrop är unikt. Den som ställer helt olika frågor på helt olika dokument får ingen nytta. Men i ett flöde där samma agent gör samma jobb hundratals gånger per dag är det 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 en stor del av alla AI-anrop som idag går till den största modellen 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 min gissning att Haiku 4.5 ofta räcker där folk kör Sonnet. Testet är enkelt att sätta upp. Låt de två modellerna göra samma kategoriseringsjobb på samma tusen mail och jämför båda mot en mänsklig referens. Prisskillnaden känner du redan, Haiku ligger på en tredjedel av Sonnets output-pris enligt prislistan ovan, så det enda du behöver mäta är hur mycket precision du tappar. Gör du inte mätningen betalar du för en trygghet du inte vet om du har.
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 på en hyrd GPU-instans. Marginalkostnaden per anrop blir i praktiken noll, du betalar för hårdvaran. Vid höga volymer, kanske 100 000 anrop om dagen, och där svaren inte kräver toppmodellens resonemang, kan det räkna hem sig ordentligt. Vid 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, alltså att olika modeller får olika svåra uppgifter, och det är inte mycket kod. Det är där jag skulle leta först om fakturan känns för hög.
En räknemodell du kan använda imorgon
Om du ska estimera kostnad för ett nytt användningsfall, 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 jämfört med generering, men i ett system där du embedar 100 000 dokument vid uppstart är det fortfarande en post som ska in i kalkylen. Priset per miljon tokens står i leverantörens prislista, hämta det därifrån när du räknar.
Lägg sedan på en buffert. Min tumregel är trettio procent påslag, och den är min egen, inte hämtad ur någon studie. Skälet är att verkligheten i skarp drift 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. Samma uppgift kan kosta mångdubbelt mer i ett bygge än i ett annat, och då handlar det sällan om modellvalet. Det handlar om att det ena skickar betydligt mer kontext i varje anrop och saknar cache. 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 till exempel 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.
Det här är den typen av räknande jag gärna gör tillsammans med någon. 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.