Context window, tokens og regningen — målt

Den dyreste misforståelse i denne branche er, at en model husker en samtale.

Det gør den ikke, og mekanismen fra kapitel 13 siger præcis hvorfor. En transformers tilstand under generering er KV cache: de keys og values, der beregnes for hver token i sekvensen. Den cache lever i varigheden af én anmodning. Når anmodningen slutter, er processen, der holdt den, fri til at betjene en anden, og cachen er væk. Der er ikke noget lager pr. bruger på den anden side, og ingen session.

Så den næste anmodning skal ankomme med alt det, modellen skal vide, og modellen genopbygger den tilstand ved at køre et forward pass over hele prompt, før den udsender en eneste ny token. Kapitel 15 kaldte prompt’en ”hele tilstanden”. Dette er den fysiske grund: prompt’en er den komplette tilstand, fordi intet andet overlever kaldet.

Context window er den maksimale længde af den prompt plus dens svar. Det er et loft over, hvor meget tilstand du kan genopbygge, ikke en beholder, der holder på noget mellem anmodninger. At kalde det ”modellens hukommelse” vender årsagssammenhængen baglæns — du fylder ikke en hukommelse, du betaler for at genetablere en.

Det er der, de toogtyve kommer fra. Tur $n$ bærer alle $n-1$ tidligere ture, så det samlede input på tværs af en samtale på $n$ ture er summen af en voksende række, som er kvadratisk:

hvor $s$ er system prompt, og $h_i$ er historikken ved tur $i$. Tilpasning af det målte kumulative input til $an^2 + bn$ over de fyrre ture giver $60.22\,n^2 + 432.25\,n$, hvilket forudsiger 113.645 tokens ved tur 40 mod 112.617 målte. Det kvadratiske led dominerer, og det lineære led er det, brugeren faktisk skrev.

Konsekvensen er den sætning, du skal tage med fra kapitlet: din regning vokser med kvadratet på samtalen, ikke med det sidste spørgsmål. De samme fyrre spørgsmål stillet helt uden historik kostede $0.066036. At beholde historikken kostede $0.274386. Historik gangede regningen med 4,2, og den vil blive ved med at gange, fordi multiplikatoren er samtalelængden.

Vinduet er endeligt af to grunde, der trækker i samme retning. Den første er kapitel 9’s: attention sammenligner hver token med hver anden token, så lagets arbejde vokser med kvadratet på sekvenslængden. Den anden er hukommelse: KV cache vokser lineært med sekvenslængden, og kapitel 13 lavede den aritmetik — ved lange sekvenser er den større end vægtene.

Begge grænser er blevet angrebet, og ingen af dem er blevet fjernet. FlashAttention¹ omorganiserer beregningen, så den læser og skriver langt mindre til high-bandwidth memory, hvilket gør lange sekvenser praktiske uden at ændre den asymptotiske omkostning. Position Interpolation² og YaRN³ udvider en trænet models brugbare vindue ved at reskalere de positionelle encodings fra kapitel 9 i stedet for at træne på ny. Tilsammen er de grunden til, at vinduer gik fra 2K til 1M på fem år.

Det, de ikke gjorde, var at gøre lange contexts gratis. De hævede loftet og gjorde hældningen mildere. Hældningen er der stadig, og det er den, pristiers senere i kapitlet måler.

Næsten alle cost calculators på internettet modellerer et API-kald som input tokens gange en inputpris plus output tokens gange en outputpris. Det var sandt i 2023. Nu er det forkert på en måde, der giver regninger, som kan ramme ved siden af med en faktor to eller mere i begge retninger.

Der er fem fakturerbare token-kategorier:

Tre af de fem fandtes ikke som separate linjer for to år siden, og de to cache-linjer er dem, folk tager fejl af, fordi et cache write koster mere end almindeligt input, ikke mindre. Du betaler en præmie for at gemme noget, så du kan betale rabat for at læse det tilbage, og om den handel er god, afhænger helt af, hvor mange gange du læser det.

Reasoning-bucket’en er kapitel 12’s, nu med pris på, og den har en detalje, der er værd at sige tydeligt: Googles dokumentation siger, at pricing ”is based on the full thought tokens the model needs to generate, despite only the summary being output from the API.”⁴ Du bliver faktureret for tokens, der aldrig bliver transmitteret til dig. Det er den eneste bucket, hvis indhold du ikke kan tælle, inspicere eller verificere.

Nu den del, der gør dette til et normaliseringsproblem i stedet for et multiplikationsproblem. Hver udbyder rapporterer disse buckets under forskellige navne, og — dette er fælden — to af dem bruger det samme ord om to forskellige størrelser.

Tag ét kald: 4.837 tokens læst fra cache, 110 friske, 142 synlige 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 } }

Se på prompt_tokens: 4947 og input_tokens: 110. Begge felter er input token-antallet for den samme prompt. OpenAI’s inkluderer de cached tokens; Anthropic’s udelukker dem — deres dokumentation angiver identiteten eksplicit, total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens.⁵ Anthropic’s input_tokens betyder ”tokens efter dit sidste cache-breakpoint”.

Og se på output. OpenAI og Anthropic rapporterer begge 442, som allerede indeholder de 300 reasoning tokens. Gemini rapporterer 142 og lægger de 300 i et felt for sig. Kapitel 12 pegede på dette som en inkompatibilitet mellem to måder at tælle det samme arbejde på; her er, hvad det koster.

En normalizer er tredive linjer, og den er ikke valgfri:

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 ovenfor gennem de tre readers, og alle tre producerer den samme Usage og derfor det samme tal: $0.006491. Den enighed er hele pointen med at skrive laget.

Tag fejl, og her er, hvad det koster, på samme kald:

Den tredje er den farlige, fordi den fejler stille i retning af gode nyheder. Dit dashboard viser en reasoning model, der koster mindre end halvdelen af, hvad den koster, og intet nogen steder rejser en fejl.

Når buckets er normaliseret, er cost-funktionen kort. Den eneste ikke-oplagte del er tier-opslaget, som næste afsnit forklarer:

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);
}

To designbeslutninger dér er værd at argumentere for. Fallbacks — cache-priser, der falder tilbage til input, reasoning til output — indkoder, hvad en manglende tabel betyder: reasoning tokens på Gemini faktureres til output-satsen, så en fraværende reasoning-pris er ikke nul, den er outputprisen. Og contextSize summerer alle tre input-buckets i stedet for de friske, fordi tier vælges efter, hvor lang prompt’en er, ikke efter hvor meget af den du blev opkrævet fuld pris for.

En prompt cache gemmer modellens beregnede tilstand for et præfiks af din prompt, så en senere anmodning med samme præfiks springer genberegningen over. Fire egenskaber følger af ordet ”præfiks”, og alle fire overrasker folk.

Break-even er lille nok til at holde i hovedet, og OpenAI’s dokumentation laver aritmetikken: at skrive et præfiks én gang og genbruge det én gang koster 1,35× dets almindelige inputpris, mod 2× for at behandle det to gange uncached; over ti anmodninger koster ét write og ni reads 2,15× mod 10×. Én reuse betaler for write’et. Anthropic lander samme sted: ét read for fem-minutters-cachen, to for en-times-cachen.

Nu samtalen på fyrre ture igen, med caching slået til og stabilt præfiks:

Otteogtres procent billigere, og tre tal i tabellen fortjener opmærksomhed.

Cachen aktiveres først ved tur 6. Prompt’en når ikke 1.024 tokens før da, så de første fem ture faktureres præcis som før — og den sjette faktureres værre, med 1,25× write-præmien, fordi det er turen, der fylder cachen. Det første read kommer ved tur 7. De 2.887 uncached tokens i tabellen er aritmetikken: fem tures værdi, ikke seks. Caching er en rabat på lange prompts, og en kort samtale får intet ud af den.

Write-præmien er $0.002474, hvilket er 2,8 % af den cached regning. Hver tur skriver sin nye hale, fyrre gange, og hele write-præmien er en afrundingsfejl i forhold til, hvad reads sparede. Write-opkrævningen er værd at forstå præcist, så du holder op med at bekymre dig om den.

Kun 2.887 tokens blev opkrævet til fuld inputpris ud af 112.617. Det er formen på en fungerende cache: næsten alt er et read.

Her er fejlen, der koster rigtige penge, og det er en bug på én linje.

Læg noget, der ændrer sig ved hvert kald, nær starten af prompt’en — et timestamp, et request id, brugerens navn, en ”i dag er”-linje, et frisk hentet dokument — og præfikset afviger fra byte ét. Intet matcher. Hvert kald er et miss. Og fordi hvert kald præsenterer et nyt præfiks, skriver hvert kald også.

Samme samtale, samme fyrre ture, caching slået til, med et timestamp pr. kald øverst i system prompt:

At slå prompt caching til gjorde samtalen tyve procent dyrere end ikke at slå det til. Du betalte 1,25× write-præmien på 109.730 tokens og læste nul tilbage. Der er ingen fejl, ingen advarsel, og funktionen er slået til.

Så reglen, og det er hele prompt caching på én linje: stabilt indhold forrest, variabelt indhold bagerst. Systeminstruktioner, tool-definitioner og referencemateriale først; timestamps, brugeridentitet og det aktuelle spørgsmål sidst. Anthropic gør hierarkiet eksplicit — cachen følger tools → system → messages, og en ændring på ethvert niveau invaliderer det niveau og alt efter det, så redigering af en enkelt tool-beskrivelse invaliderer hele cachen.⁵

To konsekvenser folk snubler over. At ændre hvilke tools der er enabled, ændrer tool-definitionerne, så en feature flag, der tilføjer et tool for nogle brugere, deler din cache i to. Og hos Anthropic ændrer toggling af web search eller citations system prompt, hvilket invaliderer system- og message-caches uden at du rører en linje af din egen tekst.

Den oplagte reaktion på en kvadratisk regning er at stoppe med at sende hele historikken: behold de sidste dusin beskeder og drop resten. Det reducerer regningen, og det er som regel det forkerte træk, og målingen siger hvorfor.

At trunkere til et vindue på tolv beskeder er 57 % billigere end at sende alt uncached — den sammenligning alle laver, og grunden til at teknikken er populær. Men det er 39 % dyrere end at sende alt med en fungerende cache, og at slå caching til sammen med trunkering gør det en smule værre i stedet for bedre.

Mekanismen er igen præfikset. Et glidende vindue dropper den ældste besked ved hver tur, så prompt’en starter ikke længere, hvor den startede sidste gang, og hver tur præsenterer et nyt præfiks. OpenAI’s vejledning siger præcis dette: ”summarisation, compaction, or context truncation can change the prefix and reset cache reuse.”⁶ Ved tur 40 er den vinduede prompt 813 tokens, under minimum på 1.024 tokens, så den kan slet ikke caches.

Og pengene er den billige halvdel af omkostningen. Det, du droppede, er instruktionen, brugeren gav ved tur 2, som modellen havde brug for ved tur 40. Trunkering bytter en regning, du kan se, for en fejl, du ikke kan, og at gøre det ordentligt — komprimering, strukturerede noter holdt uden for vinduet, hente historik on demand — er kapitel 24’s emne.

Lange contexts er ikke blot dyrere, fordi de er længere. Efter en tærskel er de dyrere pr. token, og tærsklen gælder retroaktivt for hele prompt’en.

OpenAI’s modelside for gpt-5.6-terra siger det i én sætning: ”Prompts with >272K input tokens are priced at 2x input and 1.5x output for the full request.”⁷ Ikke for overskuddet. For det hele.

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

Én token, femoghalvtreds cent. Hvis din service bygger prompts fra hentede dokumenter, hvis størrelse du ikke kontrollerer, har du en klippe i din cost-model ved en grænse, ingen på dit team har skrevet ned.

Googles pricing fungerer på samme måde med en tærskel på 200.000 tokens: Gemini 2.5 Pro koster $1.25 pr. million input tokens for prompts op til 200K og $2.50 over den, hvor output går fra $10.00 til $15.00.⁸ Anthropic gik den anden vej — pr. 6. september 2026 angiver deres dokumentation, at Claude 4.6 og senere inkluderer hele vinduet på én million tokens til standardpris, så ”a 900k-token request is billed at the same per-token rate as a 9k-token request.”⁹ Tidligere modeller beholdt tillægget.

Derfor er en pris ikke et tal. En pris er en tabel af tiers nøgleført efter prompt-længde, hvilket er, hvad Tier[] i cost-funktionen er til, og det er derfor, computeCost vælger tier ved hjælp af hele prompt’en i stedet for hver bucket separat.

De fem buckets mapper til kapitel 13’s to faser, og når du først ser mappingen, holder prisforholdene op med at se vilkårlige ud.

Input tokens er prefill. Hele prompt’en går gennem modellen i ét pass, behandlet parallelt — store matrixmultiplikationer, compute-bound. Pris pr. token er lav, og dette er fasen, der sætter time to first token: en prompt på 4.947 tokens har 4.947 tokens prefill at udføre, før det første ord dukker op.

Output tokens er decode. De produceres én ad gangen, hver som et fuldt forward pass, der læser hele KV cache, mens GPU’en mest venter på hukommelse i stedet for at beregne. Dette er fasen, der sætter tokens per second, den kan ikke paralleliseres inden for ét svar, og det er derfor, output koster cirka seks gange input på modellen prissat her: $12.00 mod $2.00 pr. million tokens.

Tre konsekvenser følger direkte. Et cache read erstatter prefill-arbejde, så det køber latency og penge på én gang — den samme rabat viser sig som en lavere regning og en kortere ventetid på den første token. Reasoning tokens er decode, du aldrig ser, og derfor streamer en reasoning model ingenting i flere sekunder og svarer så hurtigt: Kapitel 12 advarede om interface-konsekvensen, og dette er fakturakonsekvensen. Og at afbryde en stream stopper ikke genereringen — kapitel 14 byggede cancellation og lod prisen vente til dette kapitel, og prisen er det fulde output-antal, fordi tokens produceres og faktureres, uanset om nogen lytter. Det samme gælder svaret, ingen beholder: at regenerere et tur 40-svar fem gange koster $0.057990 for det ene, der bliver stående på skærmen.

Tokenizer’en fra kapitel 7 var Python og blev dér. Budgettering sker på den server, der bygger anmodningen, så det skal ske her, og der er præcis tre niveauer af nøjagtighed til rådighed.

Niveau ét: tæl lokalt. js-tiktoken leverer de samme BPE merge-tabeller som Python-tiktoken, så du får en byte-for-byte identisk optælling for OpenAI encodings uden netværkskald:

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 to konstanter betyder noget, og det er dér lokale optællinger driver. Din tekst er ikke det, der tokenizes — chat-skabelonen fra kapitel 11 pakker først hver besked ind i role markers, og de er tokens, du betaler for. Fire pr. besked og tre for reply priming er den konventionelle approksimation for OpenAI chat-modeller; på tværs af de enogfirs beskeder i samtalen ovenfor løber de op i 324 tokens, 6,4 % af dens længde. Optællingerne her blev krydstjekket mod Python-tiktoken fra kapitel 7 på alle enogfirs strenge og er identiske.

Niveau to: spørg udbyderen. Anthropic eksponerer /v1/messages/count_tokens, og Google eksponerer count_tokens, begge accepterer den samme request shape som et rigtigt kald og returnerer et input token-antal gratis. Brug dem, når du ikke kan tælle lokalt — og du kan ikke tælle lokalt for Anthropic, hvis tokenizer ikke er offentliggjort. Anthropic’s dokumentation er omhyggelig med, hvad den giver dig: optællingen ”is an estimate”, og den ”may include tokens added automatically by Anthropic for system optimizations”, som ”you are not billed” for.¹⁰

Niveau tre: læs usage i svaret. Det er sandheden, og den ankommer, efter pengene er brugt. Det er præcis derfor, de første to niveauer findes — for at beslutte, om anmodningen skal sendes, ikke for at fakturere den.

Fire line items, der ikke optræder som line items.

System prompt, betalt ved hvert kald. Den ovenfor er 192 tokens med sit template-overhead. Over fyrre kald er det 7.680 tokens — 5,6 % af hele samtalens regning, for otte linjer skrevet én gang. Den er også den bedst mulige cache-kandidat, fordi den både er stabil og først.

Tool-definitioner. Hvert tools navn, beskrivelse og JSON schema sendes ud på hver anmodning, og udbydere lægger scaffolding ovenpå. Anthropic offentliggør tallet: at enable tools overhovedet tilføjer en skjult system prompt på 496 tokens på Claude Sonnet 4.5 med tool_choice sat til auto, eller 588 med any eller et navngivet tool.⁹ Det er før dine egne schemas. Kapitel 18 bygger kataloget; kapitel 24 måler, hvad det æder.

Hver generation, inklusive dem du kasserer. Fem regenereringer koster fem gange. Chatten viser én.

Tanker, du ikke får vist. Fakturering er baseret på de fulde thought tokens, selv om kun et summary returneres, og intet af dit eget regnskab kan auditere det tal.

Én advarsel at slutte på, fordi det er den naturlige næste tanke, og svaret er ikke det oplagte.

Et vindue på en million tokens betyder ikke en million brugbare tokens. Retrieval-nøjagtighed forringes med position: Liu et al. fandt, at modeller finder information pålideligt i begyndelsen og slutningen af et langt input og langt mindre pålideligt i midten.¹¹ Et større vindue køber evnen til at sende mere, ikke sikkerheden for at blive læst.

Det fænomen måles én gang i dette kursus — retrieval-rate ved ni positioner i den samme 853-token prompt — og det hører hjemme i kapitel 24, hvor det ændrer, hvad en agent gør. Det citeres her, fordi det ændrer, hvad du bør købe: den billigste token er den, du ikke sendte.

Du kan nu forudsige, hvad et kald vil koste, før du laver det, læse hvad det faktisk kostede bagefter, og kende forskel på de to. Det dækker alt om anmodningen bortset fra den del, du ikke har rørt: knapperne.

Kapitel 17 er sampling — temperature, top-p, top-k, penalties og den determinisme, du ikke har. Det starter med at pille den mest udbredte fejl i feltet fra hinanden: at temperature er en kreativitetsskyder. Det er det ikke: temperature dividerer logits fra kapitel 4 før softmax, og at hæve den gør ikke modellen fantasifuld, det hæver sandsynligheden for tokens, modellen selv scorede som dårligere. Derfra: hvorfor greedy decoding giver målbart dårligere tekst end sampling, hvorfor top-k og top-p fejler på modsatte distributionsformer, og eksperimentet, der slutter kapitlet: tyve identiske forward passes ved temperature 0 kommer tilbage bit-for-bit identiske, når modellen kører alene, og at lægge den samme prompt i en batch sammen med andres anmodninger flytter 97 % af dens logits.

De matcher ikke alle. Årsagen begynder med floating-point-boksen fra kapitel 2.

Alle priser, thresholds og multiplikatorer i dette kapitel blev læst fra udbydernes egne sider den 6. september 2026 og angives med den dato, fordi de vil ændre sig. Metoden betyder mere end tallene: buckets, præfiksreglen og tier-aritmetikken har været stabile i to år, mens hver figur i dem har flyttet sig.

Stanford CS336 lecture 2, Resource accounting, er den nærmeste akademiske behandling af dette materiale og den rigtige næste læsning: den laver den samme aritmetik på træningssiden, som dette kapitel laver på inference-siden. Token-antallene her blev produceret med js-tiktoken 1.0.21 ved hjælp af o200k_base- og cl100k_base-encodings over en fyrre-tures samtale på 5.090 tokens; template-overhead pr. besked er den konventionelle fire-plus-tre-approksimation og angives, hvor den er inkluderet. Cache-, tier- og truncation-tallene er de dokumenterede pricing-regler anvendt på de målte token-antal, ikke observationer af live API-svar — der blev ikke lavet noget betalt kald for at producere dette kapitel, hvilket også er den ærlige grund til, at latency-påstandene er kvalitative, og cost-påstandene ikke er det.