Context window, tokens и счет: измерено

Самое дорогое заблуждение в этой области — что модель помнит разговор.

Не помнит, и механизм из главы 13 точно объясняет почему. Состояние transformer во время генерации — это KV cache: keys и values, вычисленные для каждого token в последовательности. Этот cache живет только в течение одного запроса. Когда запрос заканчивается, процесс, который его держал, свободен обслуживать кого-то еще, а cache исчезает. На другой стороне нет хранилища на пользователя и нет сессии.

Поэтому следующий запрос должен прийти со всем, что модель должна знать, а модель заново строит это состояние, выполняя forward pass по всему prompt, прежде чем выпустить хотя бы один новый token. Глава 15 называла prompt «всем состоянием». Физическая причина такая: prompt — это полное состояние, потому что после вызова больше ничего не сохраняется.

context window — это максимальная длина этого prompt плюс его ответ. Это потолок объема состояния, которое вы можете восстановить, а не контейнер, который что-то хранит между запросами. Называть его «памятью модели» — значит перепутать направление причинности: вы не заполняете память, вы платите за ее повторное восстановление.

Вот откуда берется двадцать два. Ход $n$ несет все $n-1$ предыдущих ходов, поэтому общий input за разговор из $n$ ходов — это сумма растущего ряда, то есть квадратичная величина:

где $s$ — system prompt, а $h_i$ — история на ходе $i$. Подгонка измеренного накопительного input к $an^2 + bn$ на сорока ходах дает $60.22\,n^2 + 432.25\,n$, что предсказывает 113 645 tokens на 40-м ходе против 112 617 измеренных. Квадратичный член доминирует, а линейный член — это то, что пользователь действительно набрал.

Главный вывод этой главы: ваш счет растет с квадратом длины разговора, а не с последним вопросом. Те же сорок вопросов без какой-либо истории стоили бы $0.066036. С сохранением истории они стоили $0.274386. История умножила счет на 4,2 и продолжит умножать, потому что множитель — длина разговора.

Окно конечно по двум причинам, которые тянут в одну сторону. Первая — из главы 9: attention сравнивает каждый token с каждым другим token, поэтому работа этого слоя растет с квадратом длины последовательности. Вторая — память: KV cache растет линейно с длиной последовательности, и глава 13 уже сделала эту арифметику — на длинных последовательностях он больше весов.

Обе границы пытались сдвинуть, но ни одну не убрали. FlashAttention¹ переорганизует вычисление так, чтобы гораздо меньше читать из высокоскоростной памяти и писать в нее; это делает длинные последовательности практичными, не меняя асимптотическую стоимость. Position Interpolation² и YaRN³ расширяют usable window обученной модели, масштабируя positional encodings из главы 9 вместо переобучения. Вместе они объясняют, почему окна выросли с 2K до 1M за пять лет.

Чего они не сделали — так это не сделали длинные contexts бесплатными. Они подняли потолок и смягчили наклон. Наклон все еще есть, и именно его измеряют тарифные уровни далее в этой главе.

Почти каждый калькулятор стоимости в интернете моделирует API-вызов как input tokens, умноженные на цену input, плюс output tokens, умноженные на цену output. В 2023 году это было верно. Сейчас это неверно так, что счета могут отличаться в два раза и больше в обе стороны.

Есть пять оплачиваемых категорий tokens:

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

Bucket reasoning — из главы 12, теперь с ценой, и у него есть деталь, которую стоит сказать прямо: в документации Google сказано, что pricing «основан на полном количестве thought tokens, которые модели нужно сгенерировать, хотя через API выводится только summary».⁴ Вам выставляют счет за tokens, которые вам никогда не передают. Это единственный bucket, содержимое которого вы не можете посчитать, проверить или увидеть.

Теперь часть, которая делает это задачей нормализации, а не умножения. Каждый провайдер сообщает эти buckets под разными именами, и — вот ловушка — двое из них используют одно и то же слово для двух разных величин.

Возьмем один вызов: 4 837 tokens прочитаны из cache, 110 свежих, 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.⁵ Anthropic input_tokens означает «tokens после вашей последней cache breakpoint».

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

Нормализатор — это тридцать строк, и он не 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
  };
};

Пропустите три payload выше через три reader, и все три дадут один и тот же Usage, а значит одно и то же число: $0.006491. Именно ради этого согласия и пишется слой.

Если ошибиться, вот цена на том же вызове:

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

Когда buckets нормализованы, cost function короткая. Единственная неочевидная часть — поиск tier, который объясняет следующий раздел:

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

Два проектных решения здесь стоит защитить. Fallbacks — cache prices падают обратно к input, reasoning к output — кодируют смысл отсутствующей таблицы: reasoning tokens в Gemini оплачиваются по ставке output, поэтому отсутствующая цена reasoning не равна нулю, она равна цене output. А contextSize суммирует все три input buckets, а не только свежие, потому что tier выбирается по длине prompt, а не по тому, за какую его часть с вас взяли полную цену.

prompt cache хранит вычисленное состояние модели для prefix вашего prompt, чтобы последующий запрос с тем же prefix пропустил повторное вычисление. Из слова «prefix» следуют четыре свойства, и все четыре удивляют людей.

Точку безубыточности достаточно легко держать в голове, и документация OpenAI делает арифметику: записать prefix один раз и переиспользовать его один раз стоит 1.35× обычной стоимости input против 2× за двукратную обработку без cache; на десяти запросах одна запись и девять чтений стоят 2.15× против 10×. Одно reuse окупает запись. У Anthropic результат тот же: одно чтение для пятиминутного cache, два — для одночасового.

Теперь снова сорок ходов разговора, с включенным caching и стабильным prefix:

На шестьдесят восемь процентов дешевле, и три числа в этой таблице заслуживают внимания.

Cache не включается до 6-го хода. Prompt не достигает 1 024 tokens до этого момента, поэтому первые пять ходов оплачиваются ровно как раньше — а шестой оплачивается хуже, с write premium 1.25\u00d7, потому что именно этот ход заполняет cache. Первое read приходит на 7-м ходе. 2 887 uncached tokens в таблице — это арифметика: стоимость пяти ходов, а не шести. Caching — скидка на длинные prompts, и короткий разговор ничего от него не получает.

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

Только 2 887 tokens были оплачены по полной цене input из 112 617. Так выглядит работающий cache: почти все — read.

Вот сбой, который стоит реальных денег, и это bug в одну строку.

Поместите в начало prompt что-то, что меняется при каждом вызове, — timestamp, request id, имя пользователя, строку «сегодня», свежедоставленный документ — и prefix отличается с первого byte. Ничего не совпадает. Каждый вызов — miss. И поскольку каждый вызов предъявляет новый prefix, каждый вызов также пишет.

Тот же разговор, те же сорок ходов, caching включен, но с timestamp для каждого вызова вверху system prompt:

Включение prompt caching сделало разговор на двадцать процентов дороже, чем если бы его не включали. Вы заплатили write premium 1.25× за 109 730 tokens и не прочитали обратно ничего. Нет ошибки, нет предупреждения, feature включена.

Итак, правило — весь prompt caching в одну строку: стабильный контент впереди, переменный позади. Сначала system instructions, tool definitions и reference material; timestamp, user identity и текущий вопрос — в конце. Anthropic делает иерархию явной: cache следует tools → system → messages, и изменение на любом уровне инвалидирует этот уровень и все после него, так что правка одного tool description инвалидирует весь cache.⁵

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

Очевидный ответ на квадратичный счет — перестать отправлять всю историю: оставить последние дюжину сообщений и выбросить остальное. Это снижает счет, обычно это неверный ход, и измерение показывает почему.

Усечение до окна в двенадцать сообщений на 57 % дешевле, чем отправлять все без cache, — именно это сравнение делают все, и поэтому техника популярна. Но это на 39 % дороже, чем отправлять все с работающим cache, а включение caching вместе с усечением делает результат чуть хуже, а не лучше.

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

И деньги — дешевая половина цены. То, что вы выбросили, — инструкция, которую пользователь дал на 2-м ходе и которая понадобилась модели на 40-м. Усечение меняет видимый счет на невидимый сбой, а правильная реализация — compaction, структурированные notes вне window, retrieval истории по запросу — тема главы 24.

Длинные contexts дороже не только потому, что они длиннее. После порога они дороже за token, и порог применяется задним числом ко всему prompt.

Страница модели OpenAI для gpt-5.6-terra говорит это одной фразой: «Prompts with >272K input tokens are priced at 2x input and 1.5x output for the full 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, размер которых вы не контролируете, в вашей модели затрат есть обрыв на границе, которую никто в команде не записал.

Ценообразование Google работает так же с порогом 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 и новее включают full one-million-token window по standard pricing, так что «a 900k-token request is billed at the same per-token rate as a 9k-token request».⁹ Более ранние модели сохраняли surcharge.

Вот почему price — не число. Price — это таблица tiers с ключом по длине prompt, именно для этого в cost function есть Tier[], и поэтому computeCost выбирает tier по всему prompt, а не по каждому bucket отдельно.

Пять buckets сопоставляются с двумя фазами из главы 13, и как только вы видите это сопоставление, ценовые соотношения перестают выглядеть произвольными.

Input tokens — это prefill. Весь prompt проходит через модель за один проход, обрабатывается параллельно — большие matrix multiplications, compute-bound. Стоимость за token низкая, и именно эта фаза задает time to first token: у prompt из 4 947 tokens есть 4 947 tokens prefill, которые нужно сделать до появления первого слова.

Output tokens — это decode. Они создаются по одному, каждый — полный forward pass, читающий весь KV cache, при этом GPU в основном ждет память, а не вычисляет. Эта фаза задает tokens per second, ее нельзя распараллелить внутри одного ответа, и поэтому output стоит примерно в шесть раз дороже input на модели, оцененной здесь: $12.00 против $2.00 за миллион tokens.

Из этого напрямую следуют три последствия. Cache read заменяет prefill work, поэтому одновременно покупает latency и деньги — та же скидка проявляется как меньший счет и меньшее ожидание первого token. Reasoning tokens — это decode, который вы не видите, поэтому reasoning model несколько секунд ничего не streams, а затем быстро отвечает: глава 12 предупреждала об интерфейсном последствии, а это последствие для счета. И aborting stream не останавливает генерацию — глава 14 построила cancellation и оставила цену этой главе, а цена — полный output count, потому что tokens произведены и оплачены независимо от того, слушает ли кто-то. То же верно для ответа, который никто не сохраняет: пять regenerations ответа на 40-м ходе стоят $0.057990 за один, оставшийся на экране.

Tokenizer из главы 7 был на Python и там остался. Бюджетирование происходит на сервере, который строит запрос, поэтому должно происходить здесь, и есть ровно три уровня точности.

Уровень один: считать локально. js-tiktoken поставляет те же BPE merge tables, что и Python tiktoken, поэтому дает byte-for-byte идентичный счетчик для OpenAI encodings, без сетевого вызова:

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

Две константы важны, и именно на них локальные подсчеты начинают расходиться. Ваш текст — не то, что tokenized: chat template из главы 11 сначала оборачивает каждое сообщение role markers, и это tokens, за которые вы платите. Четыре на сообщение и три на priming ответа — обычное приближение для OpenAI chat models; на восьмидесяти одном сообщении разговора выше они дают 324 tokens, 6,4 % его длины. Подсчеты здесь были сверены с Python tiktoken из главы 7 на всех восьмидесяти одной строке и совпали.

Уровень два: спросить провайдера. Anthropic предоставляет /v1/messages/count_tokens, а Google — count_tokens; оба принимают ту же форму запроса, что реальный вызов, и бесплатно возвращают input token count. Используйте их, когда не можете считать локально — а для Anthropic вы не можете считать локально, потому что ее tokenizer не опубликован. Документация Anthropic аккуратно уточняет, что именно она дает: count «is an estimate» и «may include tokens added automatically by Anthropic for system optimizations», за которые «you are not billed».¹⁰

Уровень три: читать usage в ответе. Это истина, и она приходит после того, как деньги потрачены. Именно поэтому существуют первые два уровня — чтобы решить, отправлять ли запрос, а не чтобы выставлять счет.

Четыре статьи, которые не появляются как статьи.

System prompt, оплачиваемый в каждом вызове. Тот, что выше, занимает 192 tokens с учетом template overhead. За сорок вызовов это 7 680 tokens — 5,6 % всего счета за этот разговор, за восемь строк, написанных один раз. Он также лучший возможный кандидат для cache: стабильный и первый.

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

Каждая generation, включая те, которые вы отбрасываете. Пять regenerations стоят в пять раз больше. Chat показывает одну.

Thoughts, которые вам не показывают. Billing основан на full thought tokens, хотя возвращается только summary, и никакой ваш учет не может audit это число.

В завершение — одно предупреждение, потому что это естественная следующая мысль, а ответ не очевиден.

Окно в миллион tokens не означает миллион usable tokens. Retrieval accuracy ухудшается с позицией: Liu et al. обнаружили, что модели надежно находят информацию в начале и конце длинного input и гораздо хуже — в середине.¹¹ Bigger window покупает возможность отправить больше, а не уверенность, что это будет прочитано.

Это явление измеряется в курсе один раз — retrieval rate в девяти позициях одного и того же prompt на 853 tokens — и относится к главе 24, где оно меняет поведение agent. Здесь оно процитировано потому, что меняет то, что вам стоит покупать: самый дешевый token — тот, который вы не отправили.

Теперь вы можете предсказать стоимость вызова до его выполнения, прочитать фактическую стоимость после и отличить одно от другого. Это покрывает все в запросе, кроме части, которой вы еще не касались: ручек настройки.

Глава 17 — о sampling: temperature, top-p, top-k, penalties и детерминизме, которого у вас нет. Она начинается с разбора самой распространенной ошибки в отрасли: будто temperature — это регулятор креативности. Это не так: temperature делит logits из главы 4 перед softmax, и повышение не делает модель изобретательной, а повышает вероятность tokens, которые сама модель оценила как худшие. Затем — почему greedy decoding дает измеримо худший текст, чем sampling, почему top-k и top-p ломаются на противоположных формах распределения, и эксперимент в конце главы: двадцать одинаковых forward passes при temperature 0 возвращаются bit-for-bit идентичными, когда модель работает одна, а помещение того же prompt в batch рядом с чужими запросами сдвигает 97 % его logits.

Они не все совпадают. Причина начинается с блока о floating-point из главы 2.

Все цены, thresholds и multipliers в этой главе были прочитаны на собственных страницах провайдеров 6 сентября 2026 года и указаны с этой датой, потому что они изменятся. Метод важнее чисел: buckets, prefix rule и tier arithmetic остаются стабильными два года, тогда как каждое число внутри них двигалось.

Stanford CS336 lecture 2, Resource accounting, — ближайшая академическая трактовка этого материала и правильное следующее чтение: она делает ту же арифметику на стороне training, какую эта глава делает на стороне inference. Token counts здесь были получены с js-tiktoken 1.0.21 с использованием encodings o200k_base и cl100k_base на разговоре из сорока ходов длиной 5 090 tokens; per-message template overhead — обычное приближение four-plus-three, и оно указано везде, где включено. Figures для cache, tier и truncation — это документированные pricing rules, примененные к измеренным token counts, а не наблюдения live API responses: для этой главы не было сделано ни одного платного вызова, и это также честная причина, по которой claims о latency качественные, а claims о стоимости — нет.