Context window, tokens och räkningen – uppmätt

Den enskilt dyraste missuppfattningen i den här branschen är att en modell minns ett samtal.

Det gör den inte, och mekanismen från kapitel 13 säger exakt varför. En transformers tillstånd under generering är KV cache: de keys och values som beräknas för varje token i sekvensen. Den cachen lever under ett enda anrop. När anropet slutar är processen som höll den fri att betjäna någon annan, och cachen är borta. Det finns inget användarspecifikt lager på andra sidan, och ingen session.

Nästa begäran måste därför komma med allt modellen förväntas känna till, och modellen bygger upp det tillståndet igen genom att köra en forward pass över hela prompt innan den avger en enda ny token. Kapitel 15 kallade prompt ”hela tillståndet”. Det här är den fysiska orsaken: prompt är det kompletta tillståndet eftersom inget annat överlever anropet.

context window är den maximala längden på den prompt plus dess svar. Det är ett tak för hur mycket tillstånd du kan bygga upp igen, inte en behållare som håller kvar något mellan anrop. Att kalla det ”modellens minne” vänder kausaliteten åt fel håll — du fyller inte ett minne, du betalar för att återetablera ett.

Det är där tjugotvå kommer ifrån. Tur $n$ bär alla $n-1$ tidigare turer, så den totala input över ett samtal med $n$ turer är summan av en växande serie, vilket är kvadratiskt:

där $s$ är system prompt och $h_i$ historiken vid tur $i$. Att passa den uppmätta kumulativa input till $an^2 + bn$ över de fyrtio turerna ger $60.22\,n^2 + 432.25\,n$, vilket förutspår 113 645 tokens vid tur 40 mot 112 617 uppmätta. Den kvadratiska termen dominerar, och den linjära termen är vad användaren faktiskt skrev.

Konsekvensen är meningen att ta med sig från det här kapitlet: din räkning växer med kvadraten på samtalet, inte med den senaste frågan. Samma fyrtio frågor utan någon historik alls kostade $0.066036. Att behålla historiken kostade $0.274386. Historik multiplicerade räkningen med 4,2, och den fortsätter multiplicera, eftersom multiplikatorn är samtalets längd.

Fönstret är ändligt av två skäl som drar åt samma håll. Det första är kapitel 9:s: attention jämför varje token med varje annan token, så det lagrets arbete växer med kvadraten på sekvenslängden. Det andra är minne: KV cache växer linjärt med sekvenslängden, och kapitel 13 gjorde den aritmetiken — vid långa sekvenser är den större än vikterna.

Båda gränserna har angripits och ingen har tagits bort. FlashAttention¹ organiserar om beräkningen så att den läser och skriver mycket mindre till minne med hög bandbredd, vilket gör långa sekvenser praktiska utan att ändra den asymptotiska kostnaden. Position Interpolation² och YaRN³ utökar en tränad modells användbara fönster genom att skala om de positionella kodningarna från kapitel 9 i stället för att träna om. Tillsammans är de orsaken till att fönster gick från 2K till 1M på fem år.

Det de inte gjorde var att göra långa context gratis. De höjde taket och gjorde lutningen mildare. Lutningen finns fortfarande kvar, och det är den prisnivåerna senare i kapitlet mäter.

Nästan varje kostnadskalkylator på internet modellerar ett API-anrop som input tokens gånger ett input-pris plus output tokens gånger ett output-pris. Det var sant 2023. Nu är det fel på ett sätt som ger räkningar som avviker med en faktor två eller mer åt båda hållen.

Det finns fem fakturerbara token-kategorier:

Tre av de fem fanns inte som separata rader för två år sedan, och de två cache-raderna är de som folk missförstår, eftersom en cache write kostar mer än vanlig input, inte mindre. Du betalar ett påslag för att lagra något så att du kan betala rabatt för att läsa tillbaka det, och om det bytet är bra beror helt på hur många gånger du läser det.

Reasoning-hinken är kapitel 12:s, nu med ett pris på sig, och den bär en detalj som är värd att säga rakt ut: Googles dokumentation säger att prissättningen ”is based on the full thought tokens the model needs to generate, despite only the summary being output from the API.”⁴ Du faktureras för tokens som aldrig överförs till dig. Det är den enda hink vars innehåll du inte kan räkna, inspektera eller verifiera.

Nu delen som gör detta till ett normaliseringsproblem snarare än ett multiplikationsproblem. Varje leverantör rapporterar de här hinkarna under olika namn, och — det här är fällan — två av dem använder samma ord för två olika storheter.

Ta ett anrop: 4 837 tokens lästa från cache, 110 färska, 142 synliga output tokens, 300 reasoning tokens.

// OpenAI-compatible
{ "usage": { "prompt_tokens": 4947,
             "prompt_tokens_details": { "cached_tokens": 4837 },
             "completion_tokens": 442,
             "completion_tokens_details": { "reasoning_tokens": 300 } } }

// Anthropic
{ "usage": { "input_tokens": 110,
             "cache_read_input_tokens": 4837,
             "cache_creation_input_tokens": 0,
             "output_tokens": 442 } }

// Gemini
{ "usageMetadata": { "promptTokenCount": 4947,
                     "cachedContentTokenCount": 4837,
                     "candidatesTokenCount": 142,
                     "thoughtsTokenCount": 300 } }

Titta på prompt_tokens: 4947 och input_tokens: 110. Båda fälten är input token count för samma prompt. OpenAI:s inkluderar cachade tokens; Anthropic:s exkluderar dem — dess dokumentation anger identiteten uttryckligen, total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens.⁵ Anthropic:s input_tokens betyder ”tokens efter din senaste cache-brytpunkt”.

Och titta på output. OpenAI och Anthropic rapporterar båda 442, vilket redan innehåller de 300 reasoning tokens. Gemini rapporterar 142 och lägger de 300 i ett eget fält. Kapitel 12 markerade detta som en inkompatibilitet mellan två sätt att räkna samma arbete; här är vad det kostar.

En normaliserare är trettio rader och den är inte valfri:

export interface Usage {
  promptTokens?: number;        // input, NOT cached
  cachedInputTokens?: number;   // read from cache
  cacheWriteTokens?: number;    // written to cache on this call
  completionTokens?: number;    // output
  reasoningTokens?: number;     // billed apart from output (Gemini only)
}

const num = (v: unknown) => (typeof v === "number" && isFinite(v) ? v : 0);

export const fromOpenAI = (raw: any): Usage => {
  const u = raw.usage ?? {}, d = u.prompt_tokens_details ?? {};
  const cached = num(d.cached_tokens), write = num(d.cache_write_tokens);
  return {
    promptTokens: Math.max(0, num(u.prompt_tokens) - cached - write), 
    cachedInputTokens: cached,
    cacheWriteTokens: write,
    completionTokens: num(u.completion_tokens),   // reasoning already inside
    reasoningTokens: 0,
  };
};

export const fromAnthropic = (raw: any): Usage => {
  const u = raw.usage ?? {};
  return {
    promptTokens: num(u.input_tokens),            // already excludes cache
    cachedInputTokens: num(u.cache_read_input_tokens),
    cacheWriteTokens: num(u.cache_creation_input_tokens),
    completionTokens: num(u.output_tokens),
    reasoningTokens: 0,
  };
};

export const fromGemini = (raw: any): Usage => {
  const m = raw.usageMetadata ?? {}, cached = num(m.cachedContentTokenCount);
  return {
    promptTokens: Math.max(0, num(m.promptTokenCount) - cached),
    cachedInputTokens: cached,
    cacheWriteTokens: 0,
    completionTokens: num(m.candidatesTokenCount), // EXCLUDES thinking
    reasoningTokens: num(m.thoughtsTokenCount),    // billed at output rate
  };
};

Kör de tre payloads ovan genom de tre läsarna så producerar alla tre samma Usage, och därmed samma tal: $0.006491. Den överensstämmelsen är hela poängen med att skriva lagret.

Gör fel och här är vad det kostar, på samma anrop:

Det tredje är det farliga, eftersom det misslyckas tyst i riktning mot goda nyheter. Din dashboard visar en reasoning-modell som kostar mindre än hälften av vad den kostar, och ingenting någonstans ger ett fel.

När hinkarna är normaliserade är kostnadsfunktionen kort. Den enda icke-uppenbara delen är uppslagningen av prisnivå, som nästa avsnitt förklarar:

export interface Tier { maxPromptTokens: number | null; price: number }
export interface Pricing {
  input: Tier[]; output: Tier[];
  cachedInput?: Tier[]; cacheWrite?: Tier[]; reasoning?: Tier[];
}

const tierPrice = (tiers: Tier[] | undefined, contextSize: number, fallback?: Tier[]) => {
  const table = tiers ?? fallback;
  if (!table?.length) return 0;
  const sorted = [...table].sort(
    (a, b) => (a.maxPromptTokens ?? Infinity) - (b.maxPromptTokens ?? Infinity));
  for (const t of sorted)
    if (t.maxPromptTokens === null || contextSize <= t.maxPromptTokens) return t.price;
  return sorted[sorted.length - 1].price;
};

export function computeCost(pricing: Pricing, usage: Usage): number {
  const fresh = usage.promptTokens ?? 0;
  const read  = usage.cachedInputTokens ?? 0;
  const write = usage.cacheWriteTokens ?? 0;
  const out   = usage.completionTokens ?? 0;
  const think = usage.reasoningTokens ?? 0;
  const contextSize = fresh + read + write;   // the tier depends on the WHOLE prompt
  return fresh * tierPrice(pricing.input, contextSize)
       + read  * tierPrice(pricing.cachedInput, contextSize, pricing.input)
       + write * tierPrice(pricing.cacheWrite,  contextSize, pricing.input)
       + out   * tierPrice(pricing.output, contextSize)
       + think * tierPrice(pricing.reasoning, contextSize, pricing.output);
}

Två designbeslut där är värda att argumentera för. Fallbacks — cache-priser som faller tillbaka till input, reasoning till output — kodar vad en saknad tabell betyder: reasoning tokens på Gemini faktureras till output-priset, så ett frånvarande reasoning-pris är inte noll, det är output-priset. Och contextSize summerar alla tre input-hinkarna snarare än de färska, eftersom prisnivån väljs efter hur lång prompt är, inte efter hur mycket av den du debiterades fullt pris för.

En prompt cache lagrar modellens beräknade tillstånd för ett prefix av din prompt, så en senare begäran med samma prefix hoppar över att beräkna om det. Fyra egenskaper följer av ordet ”prefix”, och alla fyra överraskar folk.

Break-even är liten nog att hålla i huvudet, och OpenAI:s dokumentation gör aritmetiken: att skriva ett prefix en gång och återanvända det en gång kostar 1,35× dess vanliga input-kostnad, mot 2× för att bearbeta det två gånger utan cache; över tio begäranden kostar en write och nio reads 2,15× mot 10×. En återanvändning betalar för skrivningen. Anthropic hamnar på samma plats: en read för femminuterscachen, två för entimmescachen.

Nu fyrtioturerssamtalet igen, med caching på och stabilt prefix:

Sextioåtta procent billigare, och tre tal i den tabellen förtjänar uppmärksamhet.

Cachen börjar inte användas förrän tur 6. Prompt når inte 1 024 tokens förrän då, så de första fem turerna faktureras exakt som tidigare — och den sjätte faktureras sämre, med skrivpåslaget 1,25×, eftersom det är turen som fyller cachen. Den första read kommer vid tur 7. De 2 887 uncached tokens i tabellen är aritmetiken: fem turers värde, inte sex. Caching är en rabatt på långa prompts, och ett kort samtal får ingenting av den.

Skrivpåslaget är $0.002474, vilket är 2,8 % av den cachade räkningen. Varje tur skriver sin nya svans, fyrtio gånger, och hela skrivpåslaget är ett avrundningsfel jämfört med vad läsningarna sparade. Skrivavgiften är värd att förstå exakt så att du slutar oroa dig för den.

Bara 2 887 tokens debiterades till fullt input-pris av 112 617. Det är formen på en fungerande cache: nästan allt är en read.

Här är felet som kostar riktiga pengar, och det är en enradsbugg.

Lägg något som ändras vid varje anrop nära början av prompt — en tidsstämpel, ett request id, användarens namn, en ”idag är”-rad, ett nyligen hämtat dokument — och prefixet skiljer sig från byte ett. Ingenting matchar. Varje anrop är en miss. Och eftersom varje anrop presenterar ett nytt prefix, skriver varje anrop också.

Samma samtal, samma fyrtio turer, caching aktiverad, med en tidsstämpel per anrop högst upp i system prompt:

Att aktivera prompt caching gjorde samtalet tjugo procent dyrare än att inte aktivera det. Du betalade skrivpåslaget 1,25× på 109 730 tokens och läste tillbaka noll. Det finns inget fel, ingen varning, och funktionen är påslagen.

Så regeln, och det är hela prompt caching på en rad: stabilt innehåll längst fram, variabelt innehåll bakom. Systeminstruktioner, tool-definitioner och referensmaterial först; tidsstämplar, användaridentitet och aktuell fråga sist. Anthropic gör hierarkin explicit — cachen följer tools → system → messages, och en ändring på någon nivå ogiltigförklarar den nivån och allt efter den, så att redigera en enda tool-beskrivning ogiltigförklarar hela cachen.⁵

Två konsekvenser som folk snubblar på. Att ändra vilka tools som är aktiverade ändrar tool-definitionerna, så en feature flag som lägger till ett tool för vissa användare delar din cache i två. Och på Anthropic modifierar växling av webbsökning eller citeringar system prompt, vilket ogiltigförklarar system- och message-cacher utan att du rör en rad av din egen text.

Den uppenbara responsen på en kvadratisk räkning är att sluta skicka hela historiken: behåll de senaste dussinet meddelandena och släpp resten. Det minskar räkningen, och det är oftast fel drag, och mätningen säger varför.

Att kapa till ett fönster på tolv meddelanden är 57 % billigare än att skicka allt utan cache — jämförelsen alla gör, och skälet till att tekniken är populär. Men det är 39 % dyrare än att skicka allt med en fungerande cache, och att slå på caching tillsammans med kapning gör det något sämre snarare än bättre.

Mekanismen är prefixet igen. Ett glidande fönster släpper det äldsta meddelandet varje tur, så prompt börjar inte längre där den började förra gången och varje tur presenterar ett nytt prefix. OpenAI:s vägledning säger exakt detta: ”summarisation, compaction, or context truncation can change the prefix and reset cache reuse.”⁶ Vid tur 40 är fönster-prompt 813 tokens, under minimumet 1 024 tokens, så den kan inte cachas alls.

Och pengarna är den billiga halvan av kostnaden. Det du släppte är instruktionen användaren gav vid tur 2 som modellen behövde vid tur 40. Truncation byter en räkning du kan se mot ett fel du inte kan se, och att göra det ordentligt — compaction, strukturerade anteckningar utanför fönstret, hämta historik vid behov — är ämnet för kapitel 24.

Långa context är inte bara dyrare för att de är längre. Efter en tröskel är de dyrare per token, och tröskeln tillämpas retroaktivt på hela prompt.

OpenAI:s modellsida för gpt-5.6-terra säger det i en mening: ”Prompts with >272K input tokens are priced at 2x input and 1.5x output for the full request.”⁷ Inte för överskottet. För hela saken.

prompt 271,999 + 500 output  ->  $0.5500
prompt 272,000 + 500 output  ->  $0.5500
prompt 272,001 + 500 output  ->  $1.0970

En token, femtiofem cent. Om din tjänst bygger prompts från hämtade dokument vars storlek du inte kontrollerar har du ett stup i din kostnadsmodell vid en gräns som ingen i ditt team har skrivit ned.

Googles prissättning fungerar på samma sätt med en tröskel på 200 000 tokens: Gemini 2.5 Pro kostar $1.25 per miljon input tokens för prompts upp till 200K och $2.50 över den, med output som går från $10.00 till $15.00.⁸ Anthropic gick åt andra hållet — den 6 september 2026 anger dess dokumentation att Claude 4.6 och senare inkluderar hela fönstret på en miljon tokens till standardpris, så ”a 900k-token request is billed at the same per-token rate as a 9k-token request.”⁹ Tidigare modeller hade påslaget kvar.

Det är därför ett pris inte är ett tal. Ett pris är en tabell med nivåer nycklade på prompt-längd, vilket är vad Tier[] i kostnadsfunktionen är till för, och därför väljer computeCost nivån med hela prompt snarare än varje hink separat.

De fem hinkarna mappar till kapitel 13:s två faser, och när du ser mappningen slutar prisrelationerna se godtyckliga ut.

Input tokens är prefill. Hela prompt går genom modellen i ett pass, bearbetad parallellt — stora matrismultiplikationer, beräkningsbundna. Kostnad per token är låg, och det här är fasen som sätter time to first token: en prompt på 4 947 tokens har 4 947 tokens prefill att göra innan det första ordet visas.

Output tokens är decode. De produceras en i taget, var och en en full forward pass som läser hela KV cache, med GPU:n mestadels väntande på minne snarare än beräknande. Det här är fasen som sätter tokens per second, den kan inte parallelliseras inom ett svar, och det är därför output kostar omkring sex gånger input på modellen som prissätts här: $12.00 mot $2.00 per miljon tokens.

Tre konsekvenser följer direkt. En cache read ersätter prefill-arbete, så den köper latency och pengar samtidigt — samma rabatt syns som en lägre räkning och kortare väntan på första token. Reasoning tokens är decode du aldrig ser, vilket är varför en reasoning-modell inte streamar något på flera sekunder och sedan svarar snabbt: kapitel 12 varnade för gränssnittskonsekvensen, och detta är fakturakonsekvensen. Och att avbryta en stream stoppar inte genereringen — kapitel 14 byggde cancellation och lämnade priset till detta kapitel, och priset är hela output-antalet, eftersom tokens produceras och faktureras oavsett om någon lyssnar. Detsamma gäller svaret ingen behåller: att regenerera ett tur 40-svar fem gånger kostar $0.057990 för det enda som blir kvar på skärmen.

Tokenizern i kapitel 7 var Python och stannade där. Budgetering sker i servern som bygger begäran, så den måste ske här, och det finns exakt tre nivåer av noggrannhet.

Nivå ett: räkna lokalt. js-tiktoken levererar samma BPE merge-tabeller som Python-tiktoken, alltså ett byte-för-byte identiskt antal för OpenAI-kodningar, utan nätverksanrop:

import { getEncoding } from "js-tiktoken";

const enc = getEncoding("o200k_base");
const PER_MESSAGE = 4;   // role and delimiters added by the chat template
const PER_REPLY = 3;     // priming for the assistant turn

export function promptTokens(messages: { role: string; content: string }[]) {
  return messages.reduce(
    (sum, m) => sum + enc.encode(m.content).length + PER_MESSAGE, PER_REPLY);
}

De två konstanterna spelar roll och det är där lokala räkningar driver isär. Din text är inte det som tokeniseras — chat template från kapitel 11 omsluter varje meddelande med rollmarkörer först, och de är tokens du betalar för. Fyra per meddelande och tre för svarsprep är den konventionella approximationen för OpenAI-chatmodeller; över de åttioen meddelandena i samtalet ovan summerar de till 324 tokens, 6,4 % av dess längd. Antalen här dubbelkontrollerades mot Python-tiktoken från kapitel 7 på alla åttioen strängar och är identiska.

Nivå två: fråga leverantören. Anthropic exponerar /v1/messages/count_tokens och Google exponerar count_tokens, båda accepterar samma begärandeform som ett riktigt anrop och returnerar ett input token count gratis. Använd dem när du inte kan räkna lokalt — och du kan inte räkna lokalt för Anthropic, vars tokenizer inte är publicerad. Anthropic:s dokumentation är noggrann med vad den ger dig: antalet ”is an estimate”, och det ”may include tokens added automatically by Anthropic for system optimizations”, som ”you are not billed” för.¹⁰

Nivå tre: läs usage i svaret. Det är sanningen, och den kommer efter att pengarna är spenderade. Vilket är exakt varför de två första nivåerna finns — för att avgöra om begäran ska skickas, inte för att fakturera för den.

Fyra radposter som inte visas som radposter.

System prompt, betald vid varje anrop. Den ovan är 192 tokens med sitt template-påslag. Över fyrtio anrop är det 7 680 tokens — 5,6 % av hela samtalets räkning, för åtta rader skrivna en gång. Den är också den bästa möjliga cache-kandidaten, eftersom den både är stabil och först.

Tool-definitioner. Varje tools namn, beskrivning och JSON-schema skickas med varje begäran, och leverantörer lägger scaffold ovanpå. Anthropic publicerar talet: att aktivera tools alls lägger till en dold system prompt på 496 tokens på Claude Sonnet 4.5 med tool_choice satt till auto, eller 588 med any eller ett namngivet tool.⁹ Det är före dina egna scheman. Kapitel 18 bygger katalogen; kapitel 24 mäter vad den äter.

Varje generering, inklusive dem du slänger. Fem regenereringar kostar fem gånger. Chatten visar en.

Tankar du inte får se. Fakturering baseras på alla thought tokens även om bara en sammanfattning returneras, och ingen redovisning från din sida kan granska det talet.

En avslutande varning, eftersom det är den naturliga nästa tanken och svaret inte är det uppenbara.

Ett fönster på en miljon tokens betyder inte en miljon användbara tokens. Retrieval-noggrannhet försämras med position: Liu et al. fann att modeller lokaliserar information pålitligt i början och slutet av en lång input och mycket mindre pålitligt i mitten.¹¹ Ett större fönster köper förmågan att skicka mer, inte säkerheten att bli läst.

Det fenomenet mäts en gång i den här kursen — retrieval-frekvensen vid nio positioner i samma prompt på 853 tokens — och det hör hemma i kapitel 24, där det förändrar vad en agent gör. Det citeras här eftersom det förändrar vad du bör köpa: den billigaste token är den du inte skickade.

Du kan nu förutsäga vad ett anrop kommer att kosta innan du gör det, läsa vad det faktiskt kostade efteråt och se skillnaden mellan de två. Det täcker allt om begäran utom den del du inte har rört: rattarna.

Kapitel 17 är sampling — temperature, top-p, top-k, straffen och determinismen du inte har. Det börjar med att montera ned det mest spridda felet i fältet, att temperature är ett kreativitetsreglage. Det är det inte: temperature dividerar logits från kapitel 4 före softmax, och att höja den gör inte modellen fantasifull, det höjer sannolikheten för tokens som modellen själv gav sämre poäng. Därifrån: varför greedy decoding producerar mätbart sämre text än sampling, varför top-k och top-p fallerar på motsatta former av distribution, och experimentet som avslutar kapitlet: tjugo identiska forward passes vid temperature 0 kommer tillbaka bit-för-bit identiska när modellen kör ensam, och att lägga samma prompt i en batch tillsammans med någon annans begäranden flyttar 97 % av dess logits.

De matchar inte alla. Orsaken börjar med floating-point-rutan från kapitel 2.

Alla priser, trösklar och multiplikatorer i det här kapitlet lästes från leverantörernas egna sidor den 6 september 2026 och anges med det datumet eftersom de kommer att ändras. Metoden spelar större roll än siffrorna: hinkarna, prefixregeln och nivåaritmetiken har varit stabila i två år medan varje tal i dem har rört sig.

Stanford CS336 lecture 2, Resource accounting, är den närmaste akademiska behandlingen av detta material och rätt nästa läsning: den gör samma aritmetik på träningssidan som detta kapitel gör på inferenssidan. Token-antalen här producerades med js-tiktoken 1.0.21 med kodningarna o200k_base och cl100k_base, över ett fyrtioturerssamtal på 5 090 tokens; template-påslaget per meddelande är den konventionella fyra-plus-tre-approximationen och anges överallt där det ingår. Cache-, nivå- och truncation-siffrorna är de dokumenterade prissättningsreglerna tillämpade på de uppmätta token-antalen, inte observationer av live-API-svar — inget betalt anrop gjordes för att producera det här kapitlet, vilket också är det ärliga skälet till att latency-påståendena är kvalitativa och kostnadspåståendena inte är det.