Context window, tokens и сметката — измерени

Едното най-скъпо погрешно схващане в този бизнес е, че model помни разговор.

Не помни, и механизмът от Глава 13 показва точно защо. Състоянието на transformer по време на generation е KV cache: keys и values, изчислени за всеки token в sequence. Този cache живее за продължителността на един request. Когато request приключи, process, който го е държал, е свободен да обслужи някой друг и cache изчезва. От другата страна няма per-user store и няма session.

Затова следващият request трябва да пристигне, носейки всичко, което model трябва да знае, и model възстановява това състояние, като изпълнява forward pass върху целия prompt, преди да излъчи дори един нов token. Глава 15 нарече prompt „цялото състояние“. Това е физическата причина: prompt е пълното състояние, защото нищо друго не оцелява след call.

context window е максималната дължина на този prompt плюс неговия отговор. Това е таван за това колко състояние можете да възстановите, а не контейнер, който държи нещо между requests. Да го наричате „паметта на model“ обръща причинно-следствената връзка — не пълните памет, а плащате, за да установите такава наново.

Оттам идва числото двадесет и две. Ход $n$ носи всички $n-1$ предишни ходове, така че общият input през разговор от $n$ хода е сумата на растяща серия, която е квадратична:

където $s$ е system prompt, а $h_i$ — history на ход $i$. Напасването на измерения кумулативен input към $an^2 + bn$ през четиридесетте хода дава $60.22\,n^2 + 432.25\,n$, което предсказва 113.645 tokens на ход 40 срещу 112.617 измерени. Квадратичният член доминира, а линейният член е това, което потребителят всъщност е написал.

Последицата е изречението, което трябва да запомните от тази глава: сметката ви расте с квадрата на разговора, не с последния въпрос. Същите четиридесет въпроса, зададени без никаква history, струват $0.066036. Запазването на history струва $0.274386. History умножи сметката по 4,2 и ще продължи да я умножава, защото множителят е дължината на разговора.

Window е крайна по две причини, които дърпат в една и съща посока. Първата е тази от Глава 9: attention сравнява всеки token с всеки друг token, така че работата на този layer расте с квадрата на дължината на sequence. Втората е паметта: KV cache расте линейно с дължината на sequence, а Глава 13 направи тази аритметика — при дълги sequences той е по-голям от weights.

И двата лимита са атакувани, но нито един не е премахнат. FlashAttention¹ реорганизира изчислението така, че да чете и пише много по-малко към high-bandwidth memory, което прави дългите sequences практични, без да променя асимптотичната цена. Position Interpolation² и YaRN³ разширяват usable window на обучен model, като преоразмеряват positional encodings от Глава 9, вместо да го обучават наново. Заедно те са причината windows да преминат от 2K до 1M за пет години.

Това, което не направиха, е да превърнат long contexts в безплатни. Направиха тавана по-висок и наклона по-полегат. Наклонът още е там и именно него измерват ценовите tier-ове по-нататък в тази глава.

Почти всеки калкулатор на разходи в интернет моделира API call като input tokens по input цена плюс output tokens по output цена. Това беше вярно през 2023 г. Сега е грешно по начин, който произвежда сметки, отклонени с фактор две или повече и в двете посоки.

Има пет таксуеми token категории:

Три от тези пет не съществуваха като отделни редове преди две години, а двата cache реда са тези, които хората бъркат, защото cache write струва повече от обикновен input, не по-малко. Плащате премия, за да съхраните нещо, за да можете после да платите отстъпка, когато го прочетете обратно, а дали тази размяна е добра зависи изцяло от това колко пъти го четете.

Кофата reasoning е тази от Глава 12, вече с цена, и носи детайл, който си струва да се каже ясно: документацията на Google казва, че pricing „се базира на пълните thought tokens, които model трябва да генерира, въпреки че от API се извежда само summary“.⁴ Таксуват ви за tokens, които никога не се предават към вас. Това е единствената кофа, чието съдържание не можете да преброите, инспектирате или проверите.

Сега частта, която прави това проблем на нормализацията, а не проблем на умножението. Всеки provider отчита тези кофи под различни имена и — това е капанът — двама от тях използват една и съща дума за две различни величини.

Вземете един call: 4.837 tokens, прочетени от cache, 110 fresh, 142 видими 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 } }

Погледнете prompt_tokens: 4947 и input_tokens: 110. И двете полета са броят input tokens за същия prompt. Полето на OpenAI включва cached tokens; полето на Anthropic ги изключва — документацията му изрично посочва тъждеството total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens.⁵ input_tokens на Anthropic означава „tokens след последната ви cache breakpoint“.

И погледнете output. OpenAI и Anthropic отчитат 442, което вече съдържа 300 reasoning tokens. Gemini отчита 142 и поставя 300-те в отделно поле. Глава 12 посочи това като несъвместимост между два начина за броене на една и съща работа; ето колко струва.

Normalizer е тридесет реда и не е по избор:

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

Пуснете трите payload-а по-горе през трите readers и и трите произвеждат същото Usage, а следователно и същото число: $0.006491. Това съгласие е целият смисъл от написването на слоя.

Ако го сбъркате, ето колко струва при същия call:

Третото е опасното, защото се проваля тихо в посока на добрите новини. Dashboard показва reasoning model, който струва по-малко от половината от реалната си цена, и никъде нищо не вдига грешка.

Когато кофите са нормализирани, cost function е кратка. Единствената неочевидна част е tier lookup, който следващият раздел обяснява:

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

Две design решения там си струва да бъдат защитени. Fallbacks — cache цени, които падат обратно към input, reasoning към output — кодират какво означава липсваща таблица: reasoning tokens при Gemini се таксуват по output rate, така че липсваща цена reasoning не е нула, а output цена. А contextSize сумира и трите input кофи, а не само fresh, защото tier се избира според това колко дълъг е prompt, не според това за каква част от него сте били таксувани на пълна цена.

prompt cache съхранява изчисленото състояние на model за prefix на вашия prompt, така че по-късен request със същия prefix да пропусне повторното му изчисляване. Четири свойства следват от думата „prefix“ и и четирите изненадват хората.

Break-even е достатъчно малък, за да го държите в главата си, а документацията на OpenAI прави аритметиката: да запишете prefix веднъж и да го използвате повторно веднъж струва 1,35× обичайната му input цена срещу 2× за обработването му два пъти uncached; през десет requests един write и девет reads струват 2,15× срещу 10×. Едно reuse плаща write. Anthropic стига до същото място: един read за петминутния cache, два за едночасовия cache.

Сега отново разговорът от четиридесет хода, с включен caching и стабилен prefix:

Шестдесет и осем процента по-евтино, и три числа в тази таблица заслужават внимание.

Cache не се включва до ход 6. prompt не достига 1.024 tokens дотогава, така че първите пет хода се таксуват точно както преди — а шестият се таксува по-зле, с премията 1,25\u00d7 за write, защото това е ходът, който запълва cache. Първият read пристига на ход 7. 2.887 uncached tokens в таблицата са аритметиката: стойността на пет хода, не на шест. Caching е отстъпка за дълги prompts, а кратък разговор не получава нищо от него.

Премията за write е $0.002474, което е 2,8% от cached сметката. Всеки ход записва новата си tail, четиридесет пъти, и цялата премия за write е закръгляване спрямо това, което reads са спестили. Таксата за write си струва да се разбира точно, за да спрете да се тревожите за нея.

Само 2.887 tokens са таксувани по пълната input цена от 112.617. Това е формата на работещ cache: почти всичко е read.

Ето провала, който струва реални пари, и той е бъг от един ред.

Поставете нещо, което се променя при всеки call, близо до началото на prompt — timestamp, request id, името на потребителя, ред „днес е“, току-що извлечен документ — и prefix се различава от byte едно. Нищо не съвпада. Всеки call е miss. И понеже всеки call представя нов prefix, всеки call също пише.

Същият разговор, същите четиридесет хода, включен caching, с timestamp за всеки call в началото на system prompt:

Включването на prompt caching направи разговора двадесет процента по-скъп, отколкото без него. Платили сте премията 1,25× за write върху 109.730 tokens и сте прочели обратно нула. Няма грешка, няма предупреждение и feature е включен.

Затова правилото, и то е целият prompt caching в един ред: stable content отпред, variable content отзад. System instructions, tool definitions и reference material първо; timestamps, user identity и текущият въпрос последни. Anthropic прави йерархията явна — cache следва tools → system → messages, а промяна на което и да е ниво invalidates това ниво и всичко след него, така че редактирането на едно-единствено tool description invalidates целия cache.⁵

Две последици често спъват хората. Промяната на това кои tools са enabled променя tool definitions, така че feature flag, който добавя tool за някои потребители, разделя cache на две. А при Anthropic включването или изключването на web search или citations модифицира system prompt, което invalidates system и message caches, без да сте докоснали ред от собствен текст.

Очевидната реакция към квадратична сметка е да спрете да изпращате цялата history: пазите последните десетина messages и изхвърляте останалото. Това намалява сметката, и обикновено е грешният ход, а измерването показва защо.

Съкращаването до window от дванадесет messages е 57% по-евтино от изпращането на всичко uncached — сравнението, което всички правят, и причината technique да е популярна. Но е 39% по-скъпо от изпращането на всичко с работещ cache, а включването на caching заедно със съкращаването го прави леко по-зле, не по-добре.

Механизмът отново е prefix. Sliding window изхвърля най-старото message при всеки ход, така че prompt вече не започва там, откъдето е започвал последния път, и всеки ход представя нов prefix. Насоките на OpenAI казват точно това: „summarisation, compaction или context truncation могат да променят prefix и да reset-нат cache reuse.“⁶ До ход 40 windowed prompt е 813 tokens, под минимума от 1.024 tokens, така че изобщо не може да бъде cached.

А парите са евтината половина от цената. Това, което сте изхвърлили, е инструкцията, която потребителят е дал на ход 2 и която model е трябвало да има на ход 40. Truncation разменя сметка, която можете да видите, за провал, който не можете, а правилното му изпълнение — compaction, structured notes, държани извън window, retrieving history on demand — е темата на Глава 24.

Long contexts не са по-скъпи просто защото са по-дълги. След определен threshold те са по-скъпи per token, и threshold се прилага ретроактивно към целия prompt.

Страницата на OpenAI за model gpt-5.6-terra го казва в едно изречение: „Prompts с >272K input tokens се таксуват при 2x input и 1.5x output за целия request.“⁷ Не за надвишението. За цялото нещо.

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

Един token, петдесет и пет цента. Ако услугата ви изгражда prompts от retrieved documents, чийто размер не контролирате, имате cliff в cost model на граница, която никой в екипа ви не е записал.

Pricing на Google работи по същия начин с threshold от 200.000 tokens: Gemini 2.5 Pro е $1.25 за милион input tokens за prompts до 200K и $2.50 над него, като output се покачва от $10.00 до $15.00.⁸ Anthropic тръгна в другата посока — към 6 септември 2026 г. документацията му посочва, че Claude 4.6 и по-нови включват целия window от един милион tokens на standard pricing, така че „request от 900k-token се таксува по същия per-token rate като request от 9k-token“.⁹ По-ранните models запазваха surcharge.

Ето защо price не е число. Price е таблица от tiers, keyed by prompt length, за което е Tier[] в cost function, и затова computeCost избира tier, използвайки целия prompt, а не всяка кофа отделно.

Петте кофи се картографират към двете фази от Глава 13, и щом видите mapping-а, ценовите съотношения спират да изглеждат произволни.

Input tokens са prefill. Целият prompt минава през model с един pass, обработен паралелно — големи matrix multiplications, compute-bound. Cost per token е ниска и това е фазата, която задава time to first token: prompt от 4.947 tokens има 4.947 tokens prefill за изпълнение, преди да се появи първата дума.

Output tokens са decode. Те се произвеждат един по един, всеки е full forward pass, който чете целия KV cache, като GPU предимно чака паметта, вместо да изчислява. Това е фазата, която задава tokens per second, тя не може да се parallelized в рамките на един response, и затова output струва около шест пъти input при model, оценен тук: $12.00 срещу $2.00 за милион tokens.

Три последици следват директно. cache read заменя prefill работа, така че купува latency и пари едновременно — същата отстъпка се вижда като по-ниска сметка и по-кратко чакане за първия token. Reasoning tokens са decode, който никога не виждате, затова reasoning model не stream-ва нищо няколко секунди и после отговаря бързо: Глава 12 предупреди за последицата в интерфейса, а това е последицата във фактурата. И прекъсването на stream не спира generation — Глава 14 построи cancellation и остави цената за тази глава, а цената е пълният output count, защото tokens се произвеждат и таксуват, независимо дали някой слуша. Същото важи и за отговора, който никой не пази: regenerating отговор на ход 40 пет пъти струва $0.057990 за този, който остава на екрана.

Tokenizer от Глава 7 беше Python и остана там. Budgeting се случва в server, който изгражда request, така че трябва да се случи тук, и има точно три налични нива на точност.

Първо ниво: броене локално. js-tiktoken доставя същите BPE merge tables като Python tiktoken, така че byte-for-byte identical count за OpenAI encodings, без network call:

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

Двете константи имат значение и точно там local counts се отклоняват. Вашият текст не е това, което се tokenized — chat template от Глава 11 първо обвива всяко message в role markers, а те са tokens, за които плащате. Четири на message и три за reply priming е conventional approximation за OpenAI chat models; през осемдесет и едното messages на разговора по-горе те се събират до 324 tokens, 6,4% от дължината му. Броевете тук бяха cross-checked срещу Python tiktoken от Глава 7 върху всички осемдесет и един strings и са идентични.

Второ ниво: попитайте provider. Anthropic expose-ва /v1/messages/count_tokens, а Google expose-ва count_tokens, като и двете приемат същата request shape като реален call и връщат input token count безплатно. Използвайте ги, когато не можете да броите локално — а не можете да броите локално за Anthropic, чийто tokenizer не е публикуван. Документацията на Anthropic е внимателна за това какво ви дава: count „е estimate“ и „може да включва tokens, добавени автоматично от Anthropic за system optimizations“, за които „не ви таксуват“.¹⁰

Трето ниво: прочетете usage в response. Това е истината и пристига след като парите са похарчени. Точно затова съществуват първите две нива — за да решите дали да изпратите request, не за да таксувате за него.

Четири позиции, които не се появяват като отделни позиции.

System prompt, платен при всеки call. Този по-горе е 192 tokens със своя template overhead. През четиридесет calls това са 7.680 tokens — 5,6% от цялата сметка на този разговор, за осем реда, написани веднъж. Той е и най-добрият възможен cache кандидат, защото е едновременно stable и first.

Tool definitions. Името, описанието и JSON schema на всеки tool излизат при всеки request, а providers добавят scaffolding отгоре. Anthropic публикува числото: самото enabling tools добавя hidden system prompt от 496 tokens при Claude Sonnet 4.5 с tool_choice, зададено на auto, или 588 с any или named tool.⁹ Това е преди собствените ви schemas. Глава 18 строи catalogue; Глава 24 измерва какво изяжда.

Всяка generation, включително тези, които изхвърляте. Пет regenerations струват пет пъти. Chat показва една.

Thoughts, които не ви показват. Billing се базира на пълните thought tokens, въпреки че се връща само summary, и никое ваше accounting не може да audit-не това число.

Едно предупреждение за финал, защото това е естествената следваща мисъл, а отговорът не е очевидният.

Window от милион tokens не означава милион usable tokens. Retrieval accuracy деградира според позицията: Liu et al. установяват, че models намират информация надеждно в началото и края на дълъг input и много по-малко надеждно в средата.¹¹ По-голям window купува способността да изпратите повече, не сигурността, че ще бъде прочетено.

Този феномен се измерва веднъж в този курс — retrieval rate при девет позиции в същия prompt от 853 tokens — и принадлежи на Глава 24, където променя какво прави agent. Цитира се тук, защото променя какво трябва да купувате: най-евтиният token е този, който не сте изпратили.

Вече можете да предвидите колко ще струва call, преди да го направите, да прочетете колко е струвал след това и да различите двете. Това покрива всичко за request, освен частта, която още не сте пипали: knobs.

Глава 17 е sampling — temperature, top-p, top-k, penalties и determinism, който нямате. Тя започва с разглобяване на най-разпространената грешка в областта: че temperature е плъзгач за creativity. Не е: temperature дели logits от Глава 4 преди softmax, и повишаването ѝ не прави model въображаем, а повишава вероятността за tokens, които самият model е оценил като по-лоши. Оттам — защо greedy decoding произвежда измеримо по-лош текст от sampling, защо top-k и top-p се провалят при противоположни форми на distribution, и experiment, който завършва главата: двадесет идентични forward passes при temperature 0 се връщат bit-for-bit identical, когато model работи сам, а поставянето на същия prompt в batch до requests на някой друг размества 97% от неговите logits.

Не всички съвпадат. Причината започва с floating-point полето от Глава 2.

Всички цени, thresholds и multipliers в тази глава бяха прочетени от собствените страници на providers на 6 септември 2026 г. и са посочени с тази дата, защото ще се променят. Методът е по-важен от числата: кофите, prefix rule и tier arithmetic са стабилни от две години, докато всяка цифра в тях се е движила.

Лекция 2 на Stanford CS336, Resource accounting, е най-близкото академично разглеждане на този материал и правилното следващо четиво: тя прави същата аритметика от страната на training, която тази глава прави от страната на inference. Token counts тук бяха произведени с js-tiktoken 1.0.21, използвайки encodings o200k_base и cl100k_base, върху разговор от четиридесет хода с 5.090 tokens; per-message template overhead е conventional approximation четири-плюс-три и е посочен навсякъде, където е включен. Cache, tier и truncation figures са документираните pricing rules, приложени към тези измерени token counts, не наблюдения от live API responses — не е направен платен call за създаването на тази глава, което е и честната причина latency твърденията да са qualitative, а cost твърденията — не.