Context window, tokens a účet — změřeno

Jediný nejdražší omyl v tomto byznysu je představa, že si model pamatuje konverzaci.

Nepamatuje, a mechanismus z kapitoly 13 přesně říká proč. Stav transformer během generování je KV cache: keys a values spočítané pro každý token v sekvenci. Tato cache žije po dobu jednoho requestu. Když request skončí, proces, který ji držel, může obsloužit někoho jiného a cache zmizí. Na druhé straně není žádné úložiště pro konkrétního uživatele a žádná session.

Další request proto musí přijít se vším, co má model vědět, a model tento stav znovu vybuduje tím, že před vypsáním jediného nového token provede forward pass přes celý prompt. Kapitola 15 nazvala prompt „celým stavem“. Fyzický důvod je tento: prompt je kompletní stav, protože nic jiného call nepřežije.

Context window je maximální délka tohoto prompt plus jeho odpovědi. Je to strop toho, kolik stavu můžete znovu vybudovat, ne kontejner, který mezi requesty něco drží. Říkat mu „paměť modelu“ obrací příčinnost naruby — nenaplňujete paměť, platíte za její opětovné vytvoření.

Odtud pochází těch dvaadvacet. Kolo $n$ nese všech $n-1$ předchozích kol, takže celkový input napříč konverzací o $n$ kolech je součtem rostoucí řady, tedy kvadratický:

kde $s$ je system prompt a $h_i$ historie v kole $i$. Proložení naměřeného kumulativního input přes $an^2 + bn$ během čtyřiceti kol dává $60.22\,n^2 + 432.25\,n$, což v kole 40 predikuje 113 645 token oproti 112 617 naměřeným. Kvadratický člen dominuje a lineární člen je to, co uživatel skutečně napsal.

Věta, kterou si z této kapitoly odnést: váš účet roste se čtvercem konverzace, ne s poslední otázkou. Stejných čtyřicet otázek položených úplně bez historie by stálo $0.066036. Udržování historie stálo $0.274386. Historie účet vynásobila 4,2× a bude ho násobit dál, protože násobitelem je délka konverzace.

Okno je konečné ze dvou důvodů, které táhnou stejným směrem. První je z kapitoly 9: attention porovnává každý token s každým jiným token, takže práce této vrstvy roste se čtvercem délky sekvence. Druhý je paměť: KV cache roste s délkou sekvence lineárně a kapitola 13 tuto aritmetiku provedla — u dlouhých sekvencí je větší než weights.

Na oba limity se útočilo a ani jeden nezmizel. FlashAttention¹ reorganizuje výpočet tak, aby mnohem méně četl a zapisoval do high-bandwidth memory, díky čemuž jsou dlouhé sekvence praktické, aniž by se změnil asymptotický náklad. Position Interpolation² a YaRN³ rozšiřují použitelné okno natrénovaného modelu rescalováním positional encodings z kapitoly 9 místo retrainingu. Společně vysvětlují, proč se okna za pět let posunula z 2K na 1M.

Co ale neudělaly: neudělaly dlouhé kontexty zdarma. Zvedly strop a zjemnily sklon. Sklon pořád existuje a právě ten měří cenové tier později v této kapitole.

Skoro každý kalkulátor nákladů na internetu modeluje API call jako input tokens krát input cena plus output tokens krát output cena. V roce 2023 to byla pravda. Dnes je to špatně způsobem, který produkuje účty odchýlené dvojnásobně nebo víc oběma směry.

Existuje pět účtovatelných kategorií token:

Tři z těch pěti před dvěma lety neexistovaly jako samostatné řádky a dva řádky cache jsou ty, ve kterých se lidé pletou, protože cache write stojí víc než obyčejný input, ne méně. Platíte prémii za uložení něčeho, abyste pak mohli platit slevu za opětovné čtení, a jestli se to vyplatí, závisí výhradně na tom, kolikrát to přečtete.

Kbelík reasoning je z kapitoly 12, teď s cenovkou, a nese detail, který stojí za přímé pojmenování: dokumentace Googlu říká, že pricing „vychází z úplných thought tokens, které model potřebuje vygenerovat, přestože z API je jako output vrácen pouze souhrn.“⁴ Účtují se vám tokens, které se k vám nikdy nepřenášejí. Je to jediný kbelík, jehož obsah nemůžete spočítat, zkontrolovat ani ověřit.

Teď část, která z toho dělá problém normalizace, ne problém násobení. Každý provider vykazuje tyto kbelíky pod jinými názvy a — tady je past — dva z nich používají stejné slovo pro dvě různé veličiny.

Vezměte jeden call: 4 837 token přečtených z cache, 110 čerstvých, 142 viditelných 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 } }

Podívejte se na prompt_tokens: 4947 a input_tokens: 110. Obě pole jsou počet input token pro stejný prompt. OpenAI do něj cached tokens zahrnuje; Anthropic je vylučuje — jeho dokumentace identitu uvádí výslovně, total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens.⁵ Anthropic input_tokens znamená „tokens po posledním cache breakpointu“.

A podívejte se na output. OpenAI i Anthropic vykazují 442, což už obsahuje 300 reasoning tokens. Gemini vykazuje 142 a 300 dává do vlastního pole. Kapitola 12 to označila jako nekompatibilitu mezi dvěma způsoby počítání stejné práce; tady vidíte, kolik to stojí.

Normalizátor má třicet řádků a není volitelný:

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

Prožeňte tři payloady výše přes tři readery a všechny tři vyprodukují stejné Usage, a tedy stejné číslo: $0.006491. Právě tato shoda je celý smysl této vrstvy.

Když to uděláte špatně, tady je cena na stejném callu:

Třetí chyba je nebezpečná, protože selže potichu směrem k dobré zprávě. Váš dashboard ukazuje reasoning model, který stojí méně než polovinu toho, co skutečně stojí, a nikde nic nevyhodí chybu.

Když jsou kbelíky normalizované, cost function je krátká. Jediná ne zcela zřejmá část je tier lookup, který vysvětluje další sekce:

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

Za dvě rozhodnutí v návrhu stojí argumentovat. Fallbacky — cache ceny padající zpět na input, reasoning na output — kódují význam chybějící tabulky: reasoning tokens na Gemini jsou účtovány output sazbou, takže chybějící cena reasoning není nula, ale output cena. A contextSize sčítá všechny tři input kbelíky, ne jen ty čerstvé, protože tier se volí podle délky prompt, ne podle toho, za jak velkou část jste zaplatili plnou cenu.

Prompt cache ukládá vypočtený stav modelu pro prefix vašeho prompt, takže pozdější request se stejným prefixem přeskočí jeho přepočítání. Ze slova „prefix“ plynou čtyři vlastnosti a všechny čtyři lidi překvapují.

Break-even je dost malý na to, abyste ho udrželi v hlavě, a dokumentace OpenAI aritmetiku ukazuje: zapsat prefix jednou a jednou ho znovu použít stojí 1,35× jeho běžný input náklad, oproti 2× při dvojím nezacachovaném zpracování; přes deset requestů stojí jeden zápis a devět čtení 2,15× oproti 10×. Jedno reuse zaplatí zápis. Anthropic vychází stejně: jedno čtení u pětiminutové cache, dvě u hodinové cache.

Teď znovu čtyřicetikolová konverzace, s caching zapnutým a stabilním prefixem:

O šedesát osm procent levnější a tři čísla v tabulce si zaslouží pozornost.

Cache se nezapojí až do kola 6. Prompt dosáhne 1 024 token teprve tehdy, takže prvních pět kol se účtuje přesně jako předtím — a šesté se účtuje hůř, s 1,25× write prémií, protože právě to je kolo, které cache naplní. První read přijde v kole 7. Těch 2 887 uncached tokens v tabulce je aritmetika: hodnota pěti kol, ne šesti. Caching je sleva na dlouhé prompts a krátká konverzace z něj nemá nic.

Write prémie je $0.002474, tedy 2,8 % cached účtu. Každé kolo zapisuje svůj nový tail, čtyřicetkrát, a celá write prémie je zaokrouhlovací chyba proti tomu, co reads ušetřily. Write charge stojí za přesné pochopení proto, abyste se jí přestali bát.

Jen 2 887 token bylo účtováno plnou input cenou ze 112 617. Tak vypadá fungující cache: skoro všechno je read.

Tady je selhání, které stojí skutečné peníze, a je to jednořádkový bug.

Dejte něco, co se při každém callu mění, blízko začátku prompt — timestamp, request id, jméno uživatele, řádek „dnes je“, čerstvě vyhledaný dokument — a prefix se liší od prvního bytu. Nic se neshoduje. Každý call je miss. A protože každý call představuje nový prefix, každý call také zapisuje.

Stejná konverzace, stejných čtyřicet kol, caching zapnutý, s timestampem pro každý call nahoře v system prompt:

Zapnutí prompt caching konverzaci zdražilo o dvacet procent víc než kdybyste ho nezapnuli. Zaplatili jste 1,25× write prémii na 109 730 token a nepřečetli zpět nic. Není tu chyba, není tu varování a funkce je zapnutá.

Pravidlo — a v jedné větě celé prompt caching — tedy zní: stabilní obsah dopředu, proměnlivý obsah dozadu. System instructions, tool definitions a referenční materiál nejdřív; timestamps, identita uživatele a aktuální otázka nakonec. Anthropic hierarchii uvádí výslovně — cache následuje tools → system → messages a změna na jakékoli úrovni invaliduje tuto úroveň a všechno po ní, takže úprava jediného popisu tool invaliduje celou cache.⁵

Dva důsledky, o které lidé zakopávají. Změna toho, které tools jsou enabled, mění tool definitions, takže feature flag, který některým uživatelům přidá tool, rozdělí vaši cache na dvě. A u Anthropic přepnutí web search nebo citací upravuje system prompt, což invaliduje system a message caches, aniž byste se dotkli jediného řádku vlastního textu.

Zřejmá reakce na kvadratický účet je přestat posílat celou historii: nechat posledních dvanáct zpráv a zbytek zahodit. Účet to sníží, a obvykle je to špatný tah; měření říká proč.

Zkrácení na okno dvanácti zpráv je o 57 % levnější než posílat všechno uncached — to je srovnání, které dělá každý, a důvod popularity této techniky. Jenže je o 39 % dražší než posílat všechno s fungující cache, a zapnutí caching vedle truncation ho mírně zhorší, ne zlepší.

Mechanismus je znovu prefix. Sliding window v každém kole zahodí nejstarší zprávu, takže prompt už nezačíná tam, kde začínal minule, a každé kolo představuje nový prefix. Doporučení OpenAI říká přesně toto: „summarisation, compaction nebo context truncation mohou změnit prefix a resetovat cache reuse.“⁶ V kole 40 má windowed prompt 813 token, pod minimem 1 024 token, takže se vůbec nedá cachovat.

A peníze jsou levnější polovina nákladu. Zahodili jste instrukci, kterou uživatel dal v kole 2 a kterou model potřeboval v kole 40. Truncation mění účet, který vidíte, za selhání, které nevidíte, a udělat to správně — compaction, strukturované poznámky držené mimo okno, retrieval historie na vyžádání — je tématem kapitoly 24.

Dlouhé kontexty nejsou dražší jen proto, že jsou delší. Za prahem jsou dražší za token a práh se retroaktivně vztahuje na celý prompt.

Stránka modelu OpenAI pro gpt-5.6-terra to uvádí jednou větou: „Prompts s >272K input tokens jsou účtovány za 2× input a 1,5× output pro celý request.“⁷ Ne pro přebytek. Pro celé.

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

Jeden token, padesát pět centů. Pokud vaše služba staví prompts z vyhledaných dokumentů, jejichž velikost nekontrolujete, máte v nákladovém modelu útes na hranici, kterou si nikdo ve vašem týmu nezapsal.

Pricing Googlu funguje stejně s prahem 200 000 token: Gemini 2.5 Pro stojí $1.25 za milion input tokens u prompts do 200K a $2.50 nad ním, output jde z $10.00 na $15.00.⁸ Anthropic šel opačně — k 6. září 2026 jeho dokumentace uvádí, že Claude 4.6 a novější zahrnují celé milionové context window ve standardním pricing, takže „request s 900k token je účtován stejnou sazbou za token jako request s 9k token.“⁹ Dřívější modely příplatek držely.

Proto cena není číslo. Cena je tabulka tiers klíčovaná délkou prompt, k čemuž v cost function slouží Tier[], a proto computeCost vybírá tier podle celého prompt, ne podle každého kbelíku zvlášť.

Pět kbelíků se mapuje na dvě fáze z kapitoly 13, a jakmile toto mapování uvidíte, cenové poměry přestanou vypadat svévolně.

Input tokens jsou prefill. Celý prompt prochází modelem jedním průchodem, zpracovaný paralelně — velké maticové násobení, compute-bound. Náklad na token je nízký a tato fáze určuje time to first token: prompt o 4 947 token má 4 947 token prefill, které je potřeba udělat, než se objeví první slovo.

Output tokens jsou decode. Vznikají po jednom, každý jako celý forward pass, který čte celou KV cache, zatímco GPU většinou čeká na paměť místo výpočtu. Tato fáze určuje tokens per second, nelze ji paralelizovat uvnitř jedné odpovědi a proto output stojí u zde oceněného modelu asi šestkrát tolik co input: $12.00 proti $2.00 za milion token.

Přímo z toho plynou tři důsledky. Cache read nahrazuje prefill work, takže kupuje latenci i peníze zároveň — stejná sleva se projeví jako nižší účet i kratší čekání na první token. Reasoning tokens jsou decode, který nikdy nevidíte, proto reasoning model několik sekund nic nestreamuje a pak rychle odpoví: kapitola 12 varovala před dopadem na rozhraní a toto je dopad na fakturu. A přerušení streamu nezastaví generování — kapitola 14 postavila cancellation a cenu nechala na tuto kapitolu, a cenou je plný počet output, protože tokens vzniknou a jsou účtovány bez ohledu na to, jestli někdo poslouchá. Totéž platí pro odpověď, kterou si nikdo nenechá: pět regenerací odpovědi v kole 40 stojí $0.057990 za tu jednu, která zůstane na obrazovce.

Tokenizer z kapitoly 7 byl v Pythonu a tam zůstal. Rozpočtování probíhá na serveru, který staví request, takže musí probíhat tady, a existují přesně tři úrovně přesnosti.

Úroveň jedna: počítat lokálně. js-tiktoken dodává stejné BPE merge tables jako pythoní tiktoken, takže pro OpenAI encodings získáte byte-for-byte identický count bez síťového callu:

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

Na dvou konstantách záleží a právě tam se lokální počty rozjíždějí. Váš text není to, co se tokenizuje — chat template z kapitoly 11 nejdřív obalí každou zprávu značkami rolí a to jsou tokens, za které platíte. Čtyři na zprávu a tři pro reply priming je obvyklá aproximace pro chat modely OpenAI; přes jednaosmdesát zpráv výše uvedené konverzace dají dohromady 324 token, 6,4 % její délky. Zdejší počty byly zkontrolovány proti pythonímu tiktoken z kapitoly 7 na všech jednaosmdesáti řetězcích a jsou identické.

Úroveň dvě: zeptejte se providera. Anthropic vystavuje /v1/messages/count_tokens a Google vystavuje count_tokens, oba přijímají stejný tvar requestu jako skutečný call a vracejí input token count zdarma. Použijte je, když neumíte počítat lokálně — a u Anthropic lokálně počítat neumíte, protože jeho tokenizer není zveřejněný. Dokumentace Anthropic je opatrná v tom, co vám dává: count „je odhad“ a „může obsahovat tokens automaticky přidané Anthropic pro system optimizations“, za které „vám není účtováno“.¹⁰

Úroveň tři: přečtěte usage v response. To je pravda a přijde poté, co jsou peníze utracené. Právě proto existují první dvě úrovně — abyste se rozhodli, jestli request poslat, ne abyste podle nich účtovali.

Čtyři line items, které se jako line items neobjevují.

System prompt, placený při každém callu. Ten výše má se svým template overhead 192 token. Napříč čtyřiceti cally je to 7 680 token — 5,6 % celého účtu této konverzace, za osm řádků napsaných jednou. Je to zároveň nejlepší možný kandidát na cache, protože je stabilní i první.

Tool definitions. Název, popis a JSON schema každého tool odchází v každém requestu a provideři navrch přidávají scaffolding. Anthropic zveřejňuje číslo: samotné zapnutí tools přidá hidden system prompt o 496 token na Claude Sonnet 4.5 s tool_choice nastaveným na auto, nebo 588 s any či named tool.⁹ To je před vašimi vlastními schemas. Kapitola 18 staví katalog; kapitola 24 měří, co spotřebuje.

Každé generování, včetně těch, která zahodíte. Pět regenerací stojí pětkrát. Chat ukazuje jednu.

Thoughts, které vám nejsou ukázány. Billing vychází z úplných thought tokens, přestože je vrácen jen souhrn, a žádné vaše účetnictví to číslo nemůže auditovat.

Jedno závěrečné varování, protože je to přirozená další myšlenka a odpověď není ta zřejmá.

Milionové okno neznamená milion použitelných token. Přesnost retrieval se s pozicí zhoršuje: Liu et al. zjistili, že modely spolehlivě nacházejí informace na začátku a na konci dlouhého input a mnohem méně spolehlivě uprostřed.¹¹ Větší okno kupuje možnost poslat víc, ne jistotu, že to bude přečteno.

Tento jev je v kurzu změřen jednou — retrieval rate na devíti pozicích ve stejném 853-token prompt — a patří do kapitoly 24, kde mění to, co agent dělá. Tady je citován proto, že mění to, co byste měli kupovat: nejlevnější token je ten, který jste neposlali.

Teď umíte předpovědět, kolik bude call stát, než ho provedete, přečíst, kolik stál poté, a rozlišit jedno od druhého. Tím je pokryto všechno o requestu kromě části, které jste se ještě nedotkli: knoflíků.

Kapitola 17 je sampling — temperature, top-p, top-k, penalty a determinismus, který nemáte. Začíná rozebráním nejrozšířenější chyby v oboru: představy, že temperature je kolečko kreativity. Není: temperature dělí logits z kapitoly 4 před softmax a její zvýšení nedělá model imaginativním, zvyšuje pravděpodobnost tokens, které sám model ohodnotil jako horší. Odtud pokračuje k tomu, proč greedy decoding produkuje měřitelně horší text než sampling, proč top-k a top-p selhávají na opačných tvarech distribuce, a k experimentu, který kapitolu uzavírá: dvacet identických forward passes při temperature 0 se vrátí bit po bitu identicky, když model běží sám, a vložení stejného prompt do batch vedle requestů někoho jiného posune 97 % jeho logits.

Ne všechny se shodují. Důvod začíná boxem o floating-point z kapitoly 2.

Všechny ceny, prahy a násobitele v této kapitole byly přečteny z vlastních stránek providerů 6. září 2026 a jsou uvedeny s tímto datem, protože se změní. Metoda je důležitější než čísla: kbelíky, prefixové pravidlo a tier aritmetika jsou stabilní dva roky, zatímco každé číslo v nich se pohnulo.

Stanford CS336 lecture 2, Resource accounting, je nejbližší akademické zpracování tohoto materiálu a správné další čtení: dělá stejnou aritmetiku na straně training, jakou tato kapitola dělá na straně inference. Počty token zde byly vyprodukovány pomocí js-tiktoken 1.0.21 s encodings o200k_base a cl100k_base nad čtyřicetikolovou konverzací o 5 090 token; per-message template overhead je obvyklá aproximace čtyři-plus-tři a je uveden všude, kde je zahrnut. Čísla pro cache, tier a truncation jsou zdokumentovaná cenová pravidla aplikovaná na tyto naměřené počty token, ne pozorování živých API responses — k vytvoření této kapitoly nebyl proveden žádný placený call, což je také poctivý důvod, proč jsou tvrzení o latenci kvalitativní a tvrzení o nákladech ne.