Context window, tokens і рахунок: виміряно

Найдорожче хибне уявлення в цьому бізнесі — що model памʼятає розмову.

Не памʼятає, і механізм із Chapter 13 точно пояснює чому. Стан transformer під час generation — це KV cache: keys і values, обчислені для кожного token у sequence. Цей cache живе протягом одного request. Коли request завершується, процес, який його тримав, може обслуговувати когось іншого, а cache зникає. На іншому боці немає ні per-user store, ні session.

Тому наступний request має прийти з усім, що model має знати, і model відбудовує цей стан, виконуючи forward pass через увесь prompt, перш ніж видати бодай один новий token. Chapter 15 назвав prompt «the entire state». Фізична причина така: prompt є повним станом, бо ніщо інше не переживає call.

context window — це максимальна довжина цього prompt плюс його відповідь. Це стеля для того, скільки стану ви можете відбудувати, а не контейнер, який щось утримує між requests. Називати її «памʼяттю model» — означає переплутати напрям причинності: ви не заповнюєте памʼять, ви платите, щоб відновити її.

Звідси й береться двадцять два. Turn $n$ несе всі $n-1$ попередні turns, тому загальний input у розмові з $n$ turns — це сума зростального ряду, тобто квадратична величина:

де $s$ — system prompt, а $h_i$ — history на turn $i$. Підгонка виміряного cumulative input до $an^2 + bn$ за сорок turns дає $60.22\,n^2 + 432.25\,n$, що прогнозує 113 645 tokens на turn 40 проти 112 617 виміряних. Квадратичний член домінує, а лінійний — це те, що користувач фактично набрав.

Наслідок і головна фраза цього розділу: ваш рахунок зростає з квадратом розмови, а не з останнім запитанням. Ті самі сорок запитань без жодної history коштували б $0.066036. Зберігання history коштувало $0.274386. History помножила рахунок на 4,2 і продовжуватиме множити, бо multiplier — це довжина розмови.

Window скінченна з двох причин, які тягнуть в один бік. Перша — з Chapter 9: attention порівнює кожен token із кожним іншим token, тому робота цього шару зростає з квадратом довжини sequence. Друга — памʼять: KV cache зростає лінійно з довжиною sequence, і Chapter 13 уже робив цю арифметику — на довгих sequences він більший за weights.

Обидва limits атакували, але жоден не зник. FlashAttention¹ реорганізує обчислення так, що воно значно менше читає й записує в high-bandwidth memory; це робить довгі sequences практичними, не змінюючи asymptotic cost. Position Interpolation² і YaRN³ розширюють usable window навченої model, масштабуючи positional encodings із Chapter 9, а не перенавчаючи її. Разом саме вони пояснюють, чому windows за пʼять років виросли з 2K до 1M.

Чого вони не зробили — не зробили довгі contexts безкоштовними. Вони підняли стелю й помʼякшили схил. Але схил усе ще є, і саме його вимірюють price tiers далі в цьому розділі.

Майже кожен cost calculator в інтернеті моделює API call як input tokens, помножені на input price, плюс output tokens, помножені на output price. Це було правдою у 2023 році. Тепер це хибно так, що рахунки можуть відрізнятися вдвічі або більше в обидва боки.

Є пʼять billable token categories:

Три з цих пʼяти ще два роки тому не існували як окремі рядки, а два cache-рядки — саме ті, у яких люди найчастіше помиляються, бо cache write коштує дорожче за звичайний input, а не дешевше. Ви платите premium, щоб щось зберегти, і потім платите зі знижкою, щоб прочитати це назад; чи вигідна така угода, повністю залежить від того, скільки разів ви це прочитаєте.

Reasoning bucket — це bucket із Chapter 12, тепер із ціною, і в ньому є деталь, яку варто сказати прямо: документація Google каже, що pricing «is based on the full thought tokens the model needs to generate, despite only the summary being output from the API».⁴ Вам виставляють рахунок за tokens, які ніколи вам не передаються. Це єдиний bucket, вміст якого ви не можете порахувати, перевірити чи переглянути.

Тепер частина, яка робить це проблемою normalization, а не множення. Кожен provider повідомляє ці buckets під різними назвами, і — ось пастка — двоє з них використовують одне й те саме слово для двох різних величин.

Візьмімо один call: 4 837 tokens прочитано з cache, 110 fresh, 142 visible 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 token count для того самого prompt. У OpenAI воно включає cached tokens; у Anthropic — виключає їх, і документація прямо формулює тотожність: total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens.⁵ Anthropic input_tokens означає «tokens після вашого останнього cache breakpoint».

І подивіться на output. OpenAI та Anthropic обидва повідомляють 442, куди вже входять 300 reasoning tokens. Gemini повідомляє 142 і кладе 300 в окреме поле. Chapter 12 позначив це як несумісність між двома способами рахувати ту саму роботу; тут видно, у що це обходиться.

Normalizer займає тридцять рядків, і він не є optional:

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

Пропустіть три payloads вище через три readers, і всі три дадуть той самий Usage, а отже й те саме число: $0.006491. У цьому збігу й полягає весь сенс такого шару.

Помиліться — і ось скільки це коштує на тому самому call:

Третя помилка найнебезпечніша, бо вона тихо провалюється в бік хороших новин. Ваш dashboard показує reasoning model, яка коштує менш ніж половину реальної ціни, і ніде нічого не сигналізує про помилку.

Коли buckets normalized, 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 decisions тут варто захистити. Fallbacks — cache prices falling back to input, reasoning to output — кодують, що означає відсутня таблиця: reasoning tokens у Gemini billed за output rate, тож відсутня ціна reasoning — це не нуль, а output price. А contextSize підсумовує всі три input buckets, а не лише fresh, бо tier обирається за довжиною prompt, а не за тим, за яку його частину з вас взяли full price.

prompt cache зберігає обчислений стан model для prefix вашого prompt, тож пізніший request із тим самим prefix пропускає повторне обчислення. Зі слова «prefix» випливають чотири властивості, і всі чотири дивують людей.

Break-even достатньо малий, щоб тримати його в голові, і документація OpenAI робить арифметику: записати prefix один раз і повторно використати його один раз коштує 1,35× його звичайної input cost проти 2× за дві uncached обробки; для десяти requests один write і девʼять reads коштують 2,15× проти 10×. Один reuse окупає write. Anthropic приходить туди ж: один read для five-minute cache, два для one-hour cache.

Тепер знову forty-turn розмова, з caching увімкненим і stable prefix:

На шістдесят вісім відсотків дешевше, і три числа в цій таблиці заслуговують уваги.

Cache не вмикається до turn 6. prompt не досягає 1 024 tokens до цього моменту, тож перші пʼять turns billed точно як раніше — а шостий billed гірше, з premium 1,25× за write, бо саме цей turn заповнює cache. Перший read приходить на turn 7. 2 887 uncached tokens у таблиці — це арифметика: пʼять turns, не шість. Caching — це знижка на довгі prompts, і коротка розмова не отримує від нього нічого.

Write premium — $0.002474, тобто 2,8 % cached bill. Кожен turn записує свій новий tail, сорок разів, і весь write premium — похибка округлення порівняно з тим, що заощадили reads. Write charge варто точно розуміти саме для того, щоб перестати через нього хвилюватися.

Лише 2 887 tokens були charged за full input price із 112 617. Ось форма working cache: майже все — read.

Ось збій, який коштує реальних грошей, і це one-line bug.

Поставте щось, що змінюється на кожному call, близько до початку prompt — timestamp, request id, імʼя користувача, рядок «today is», щойно retrieved document — і prefix відрізняється з першого byte. Нічого не збігається. Кожен call — miss. І оскільки кожен call подає novel prefix, кожен call також writes.

Та сама розмова, ті самі сорок turns, caching enabled, із per-call timestamp на початку system prompt:

Увімкнення prompt caching зробило розмову на двадцять відсотків дорожчою, ніж без нього. Ви заплатили write premium 1,25× за 109 730 tokens і не прочитали назад нічого. Немає error, немає warning, а feature увімкнена.

Отже правило — і це весь prompt caching в одному рядку: stable content попереду, variable content позаду. System instructions, tool definitions і reference material спершу; timestamps, user identity і current question — в кінці. Anthropic явно задає hierarchy: cache йде tools → system → messages, і зміна на будь-якому level invalidates цей level і все після нього, тому редагування одного tool description invalidates увесь cache.⁵

Два наслідки, об які часто спотикаються. Зміна того, які tools enabled, змінює tool definitions, тож feature flag, який додає tool для частини користувачів, ділить ваш cache надвоє. А в Anthropic перемикання web search або citations модифікує system prompt, що invalidates system і message caches, навіть якщо ви не торкалися жодного рядка власного тексту.

Очевидна відповідь на квадратичний рахунок — перестати надсилати всю history: лишити останній десяток messages і відкинути решту. Це справді зменшує рахунок, але зазвичай це хибний хід, і вимірювання показує чому.

Truncating до twelve-message window на 57 % дешевше, ніж надсилати все uncached — саме це порівняння всі роблять, і тому техніка популярна. Але це на 39 % дорожче, ніж надсилати все з working cache, а вмикання caching разом із truncation робить трохи гірше, а не краще.

Механізм знову prefix. Sliding window на кожному turn відкидає найстаріше message, тому prompt більше не починається там, де починався минулого разу, і кожен turn подає новий prefix. Настанова OpenAI каже саме це: «summarisation, compaction, or context truncation can change the prefix and reset cache reuse».⁶ На turn 40 windowed prompt має 813 tokens, нижче за minimum 1 024 tokens, тому його взагалі не можна cached.

І гроші — дешевша половина cost. Те, що ви відкинули, — це instruction, яку користувач дав на turn 2 і яка model була потрібна на turn 40. Truncation міняє рахунок, який ви бачите, на збій, якого не бачите, а правильне виконання — compaction, structured notes поза window, retrieving history on demand — це тема Chapter 24.

Long contexts дорожчі не лише тому, що вони довші. Після threshold вони дорожчі per token, і threshold застосовується retroactively до всього prompt.

Сторінка model OpenAI для gpt-5.6-terra формулює це одним реченням: «Prompts with >272K input tokens are priced at 2x input and 1.5x output for the full request».⁷ Не для excess. Для всього.

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

Один token — пʼятдесят пʼять центів. Якщо ваш service будує prompts із retrieved documents, розмір яких ви не контролюєте, у вашій cost model є урвище на межі, яку ніхто у вашій команді не записав.

Pricing Google працює так само з threshold 200 000 tokens: Gemini 2.5 Pro коштує $1.25 за million input tokens для prompts до 200K і $2.50 вище, а output зростає з $10.00 до $15.00.⁸ Anthropic пішов іншим шляхом — станом на 6 вересня 2026 року його документація стверджує, що Claude 4.6 і пізніші включають повне one-million-token window за standard pricing, тож «a 900k-token request is billed at the same per-token rate as a 9k-token request».⁹ Раніші models зберігали surcharge.

Ось чому price — це не число. Price — це table of tiers, keyed by prompt length; саме для цього в cost function існує Tier[], і саме тому computeCost обирає tier за whole prompt, а не за кожним bucket окремо.

Пʼять buckets відображаються на дві фази з Chapter 13, і щойно ви бачите це відображення, price ratios перестають виглядати довільними.

Input tokens — це prefill. Увесь prompt проходить через model за один pass, обробляючись паралельно: великі matrix multiplications, compute-bound. Cost per token низька, і саме ця фаза визначає time to first token: prompt на 4 947 tokens має виконати prefill для 4 947 tokens, перш ніж зʼявиться перше слово.

Output tokens — це decode. Вони створюються по одному, кожен — full forward pass, який читає весь KV cache, і GPU здебільшого чекає на memory, а не обчислює. Саме ця фаза визначає tokens per second, її не можна parallelized в межах однієї response, і саме тому output коштує приблизно вшестеро дорожче за input на model, priced тут: $12.00 проти $2.00 за million tokens.

Звідси прямо випливають три наслідки. Cache read замінює prefill work, тож купує latency і гроші одночасно: та сама знижка проявляється як нижчий bill і коротше очікування першого token. Reasoning tokens — це decode, який ви не бачите, тому reasoning model кілька секунд нічого не streams, а потім швидко відповідає: Chapter 12 попереджав про interface consequence, а це invoice consequence. І aborting a stream не зупиняє generation — Chapter 14 побудував cancellation і залишив price для цього розділу, а price — це повний output count, бо tokens produced і billed незалежно від того, чи хтось слухає. Те саме стосується відповіді, яку ніхто не зберігає: regenerate відповіді turn 40 пʼять разів коштує $0.057990 за одну, що лишилася на екрані.

Tokenizer із Chapter 7 був Python і там залишився. Budgeting відбувається на server, який будує request, тож має відбуватися тут, і є рівно три levels accuracy.

Level one: count locally. 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);
}

Дві constants важливі, і саме на них local counts розʼїжджаються. Ваш text — не те, що tokenized: chat template із Chapter 11 спершу обгортає кожне message в role markers, і це tokens, за які ви платите. Чотири на message і три для reply priming — conventional approximation для OpenAI chat models; у вісімдесяти одному message розмови вище вони додають 324 tokens, 6,4 % її довжини. Ці counts були cross-checked із Python tiktoken з Chapter 7 на всіх вісімдесяти одному рядку й збігаються.

Level two: ask the provider. Anthropic надає /v1/messages/count_tokens, а Google — count_tokens; обидва приймають ту саму request shape, що й real call, і безкоштовно повертають input token count. Використовуйте їх, коли не можете count locally — а для Anthropic ви не можете count locally, бо його tokenizer не published. Документація Anthropic обережно пояснює, що саме дає: count «is an estimate», і він «may include tokens added automatically by Anthropic for system optimizations», за які «you are not billed».¹⁰

Level three: read usage in the response. Це правда, і вона приходить після того, як гроші вже витрачено. Саме тому існують перші два levels — щоб вирішити, чи надсилати request, а не щоб виставляти bill.

Чотири line items, які не зʼявляються як line items.

System prompt, оплачений на кожному call. Наведений вище має 192 tokens із template overhead. За сорок calls це 7 680 tokens — 5,6 % усього bill цієї розмови, за вісім рядків, написаних один раз. Це також найкращий можливий cache candidate, бо він і stable, і first.

Tool definitions. Name, description і JSON schema кожного tool виходять у кожному request, а providers додають scaffolding зверху. Anthropic публікує число: саме вмикання tools додає hidden system prompt на 496 tokens у Claude Sonnet 4.5 з tool_choice, установленим у auto, або 588 із any чи named tool.⁹ І це ще до ваших schemas. Chapter 18 будує catalogue; Chapter 24 вимірює, що він зʼїдає.

Кожна generation, включно з тими, які ви відкидаєте. Пʼять regenerations коштують упʼятеро. Chat показує одну.

Thoughts, яких вам не показують. Billing based on full thought tokens, хоча повертається лише summary, і жоден ваш accounting не може audit це число.

Одне попередження на завершення, бо це природна наступна думка, а відповідь не очевидна.

Million-token window не означає million usable tokens. Retrieval accuracy погіршується залежно від position: Liu et al. виявили, що models надійно знаходять information на початку й у кінці long input і значно гірше — посередині.¹¹ Bigger window купує можливість надіслати більше, а не certainty of being read.

Це phenomenon вимірюється в course один раз — retrieval rate у девʼяти positions у тому самому 853-token prompt — і належить до Chapter 24, де воно змінює те, що робить agent. Тут його наведено, бо воно змінює те, що вам варто купувати: найдешевший token — той, який ви не надіслали.

Тепер ви можете передбачити, скільки коштуватиме call до його виконання, прочитати, скільки він коштував після, і відрізнити одне від іншого. Це покриває все про request, крім частини, якої ви ще не торкалися: knobs.

Chapter 17 — це sampling: temperature, top-p, top-k, penalties і determinism, якого у вас немає. Він починається з демонтажу найпоширенішої помилки в галузі: що temperature — це регулятор creativity. Ні: temperature ділить logits із Chapter 4 перед softmax, і її підвищення не робить model imaginative, а підвищує ймовірність tokens, які сама model оцінила як гірші. Далі — чому greedy decoding produces measurably worse text than sampling, чому top-k і top-p fail на протилежних формах distribution, і experiment, яким завершується chapter: двадцять identical forward passes at temperature 0 повертаються bit-for-bit identical, коли model runs alone, а розміщення того самого prompt у batch поруч із чужими requests зсуває 97 % його logits.

Вони не всі збігаються. Причина починається з floating-point box із Chapter 2.

Усі prices, thresholds і multipliers у цьому розділі були прочитані з власних сторінок providers 6 вересня 2026 року і подані з цією датою, бо вони зміняться. Method важливіший за numbers: buckets, prefix rule і tier arithmetic були stable два роки, тоді як кожна figure всередині них рухалася.

Stanford CS336 lecture 2, Resource accounting, — найближчий academic treatment цього матеріалу й правильне next read: вона робить ту саму арифметику на training side, яку цей chapter робить на inference side. Token counts тут produced with js-tiktoken 1.0.21 using the o200k_base and cl100k_base encodings, over a forty-turn conversation of 5 090 tokens; per-message template overhead — conventional four-plus-three approximation і stated wherever it is included. Cache, tier і truncation figures — це documented pricing rules, applied to those measured token counts, not observations of live API responses — жоден paid call не був made to produce this chapter, що також є чесною причиною, чому latency claims qualitative, а cost claims — ні.