Context Window, Tokens e a conta, medidos

O equívoco mais caro deste negócio é achar que um modelo lembra uma conversa.

Ele não lembra, e o mecanismo do Capítulo 13 diz exatamente por quê. O estado de um transformer durante a geração é a KV cache: as chaves e valores calculados para cada token na sequência. Essa cache vive enquanto dura uma requisição. Quando a requisição termina, o processo que a mantinha fica livre para atender outra pessoa, e a cache desaparece. Não há armazenamento por usuário do outro lado, nem sessão.

Então a próxima requisição precisa chegar carregando tudo que o modelo deve saber, e o modelo reconstrói esse estado executando uma passagem forward por todo o prompt antes de emitir um único token novo. O Capítulo 15 chamou o prompt de “o estado inteiro”. Este é o motivo físico: o prompt é o estado completo porque nada mais sobrevive à chamada.

A context window é o comprimento máximo desse prompt mais sua resposta. É um teto para quanto estado você consegue reconstruir, não um contêiner que guarda algo entre requisições. Chamar isso de “memória do modelo” inverte a direção da causalidade — você não está preenchendo uma memória, está pagando para restabelecer uma.

É daí que vem o vinte e dois. O turno $n$ carrega todos os $n-1$ turnos anteriores, então o input total ao longo de uma conversa de $n$ turnos é a soma de uma série crescente, que é quadrática:

em que $s$ é o system prompt e $h_i$ o histórico no turno $i$. Ajustar o input cumulativo medido a $an^2 + bn$ nos quarenta turnos dá $60.22\,n^2 + 432.25\,n$, que prevê 113.645 tokens no turno 40 contra 112.617 medidos. O termo quadrático domina, e o termo linear é o que o usuário realmente digitou.

A consequência é a frase para levar deste capítulo: sua conta cresce com o quadrado da conversa, não com a última pergunta. As mesmas quarenta perguntas feitas sem histórico algum custam $0.066036. Manter o histórico custou $0.274386. O histórico multiplicou a conta por 4,2, e continuará multiplicando, porque o multiplicador é o comprimento da conversa.

A window é finita por dois motivos que puxam na mesma direção. O primeiro é o do Capítulo 9: attention compara cada token com todos os outros tokens, então o trabalho dessa camada cresce com o quadrado do comprimento da sequência. O segundo é memória: a KV cache cresce linearmente com o comprimento da sequência, e o Capítulo 13 fez essa aritmética — em sequências longas, ela é maior que os pesos.

Os dois limites foram atacados, e nenhum foi removido. FlashAttention¹ reorganiza a computação para ler e escrever muito menos em memória de alta largura de banda, o que torna sequências longas práticas sem mudar o custo assintótico. Position Interpolation² e YaRN³ ampliam a window utilizável de um modelo treinado redimensionando os positional encodings do Capítulo 9, em vez de retreinar. Juntos, eles explicam por que as windows foram de 2K para 1M em cinco anos.

O que eles não fizeram foi tornar contextos longos gratuitos. Eles elevaram o teto e suavizaram a inclinação. A inclinação ainda está lá, e é ela que os níveis de preço mais adiante neste capítulo estão medindo.

Quase todo calculador de custo na internet modela uma chamada de API como input tokens vezes um preço de input mais output tokens vezes um preço de output. Isso era verdade em 2023. Agora está errado de um jeito que gera contas erradas por um fator de dois ou mais nas duas direções.

Existem cinco categorias de tokens cobradas:

Três desses cinco não existiam como linhas separadas dois anos atrás, e as duas linhas de cache são as que as pessoas erram, porque uma cache write custa mais que input comum, não menos. Você paga um prêmio para armazenar algo para depois pagar com desconto ao ler de volta, e se essa troca compensa depende inteiramente de quantas vezes você lê.

O balde de reasoning é o do Capítulo 12, agora com preço, e carrega um detalhe que vale declarar com clareza: a documentação do Google diz que o preço “é baseado no total de thought tokens que o modelo precisa gerar, apesar de apenas o resumo sair pela API”.⁴ Você é cobrado por tokens que nunca são transmitidos a você. É o único balde cujo conteúdo você não consegue contar, inspecionar ou verificar.

Agora a parte que torna isso um problema de normalização, não de multiplicação. Cada provider relata esses baldes com nomes diferentes e — esta é a armadilha — dois deles usam a mesma palavra para duas quantidades diferentes.

Pegue uma chamada: 4.837 tokens lidos da cache, 110 novos, 142 output tokens visíveis, 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 } }

Veja prompt_tokens: 4947 e input_tokens: 110. Os dois campos são a contagem de input tokens do mesmo prompt. A da OpenAI inclui os tokens em cache; a da Anthropic exclui — a documentação dela declara a identidade explicitamente, total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens.⁵ input_tokens da Anthropic significa “os tokens depois do seu último ponto de interrupção da cache”.

E veja o output. OpenAI e Anthropic relatam 442, que já contém os 300 reasoning tokens. Gemini relata 142 e coloca os 300 em um campo próprio. O Capítulo 12 marcou isso como uma incompatibilidade entre duas formas de contar o mesmo trabalho; aqui está quanto isso custa.

Um normalizador tem trinta linhas, e não é opcional:

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

Passe os três payloads acima pelos três leitores e todos produzem o mesmo Usage, e portanto o mesmo número: $0.006491. Esse acordo é todo o propósito de escrever a camada.

Faça errado e aqui está o custo, na mesma chamada:

O terceiro é o perigoso, porque falha em silêncio na direção da boa notícia. Seu dashboard mostra um modelo de reasoning custando menos da metade do que custa, e nada em lugar nenhum levanta um erro.

Com os baldes normalizados, a função de custo é curta. A única parte não óbvia é a busca de tier, que a próxima seção explica:

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

Duas decisões de design ali merecem defesa. Os fallbacks — preços de cache caindo para input, reasoning para output — codificam o que uma tabela ausente significa: reasoning tokens no Gemini são cobrados à taxa de output, então um preço reasoning ausente não é zero, é o preço de output. E contextSize soma os três baldes de input em vez de apenas os novos, porque o tier é escolhido pelo comprimento do prompt, não por quanto dele foi cobrado pelo preço cheio.

Uma prompt cache armazena o estado computado do modelo para um prefixo do seu prompt, para que uma requisição posterior com o mesmo prefixo pule a recomputação. Quatro propriedades vêm da palavra “prefixo”, e as quatro surpreendem as pessoas.

O ponto de equilíbrio é pequeno o bastante para guardar de cabeça, e a documentação da OpenAI faz a conta: escrever um prefixo uma vez e reutilizá-lo uma vez custa 1,35× seu custo de input comum, contra 2× para processá-lo duas vezes sem cache; ao longo de dez requisições, uma escrita e nove leituras custam 2,15× contra 10×. Uma reutilização paga a escrita. A Anthropic chega ao mesmo lugar: uma leitura para a cache de cinco minutos, duas para a cache de uma hora.

Agora a conversa de quarenta turnos de novo, com caching ativado e o prefixo estável:

Sessenta e oito por cento mais barato, e três números nessa tabela merecem atenção.

A cache só entra no turno 6. O prompt não chega a 1.024 tokens até lá, então os cinco primeiros turnos são cobrados exatamente como antes — e o sexto é cobrado pior, com o prêmio de escrita de 1,25\u00d7, porque é o turno que preenche a cache. A primeira leitura chega no turno 7. Os 2.887 tokens sem cache na tabela são a aritmética: cinco turnos, não seis. Caching é desconto em prompts longos, e uma conversa curta não ganha nada com isso.

O prêmio de escrita é $0.002474, que é 2,8% da conta com cache. Todo turno escreve sua nova cauda, quarenta vezes, e o prêmio de escrita inteiro é erro de arredondamento perto do que as leituras economizaram. Vale entender a cobrança de escrita com precisão para parar de se preocupar com ela.

Apenas 2.887 tokens foram cobrados ao preço cheio de input de 112.617. Essa é a forma de uma cache funcionando: quase tudo é leitura.

Aqui está a falha que custa dinheiro de verdade, e é um bug de uma linha.

Coloque algo que muda a cada chamada perto do início do prompt — um timestamp, um ID de requisição, o nome do usuário, uma linha “hoje é”, um documento recém-recuperado — e o prefixo difere desde o primeiro byte. Nada bate. Toda chamada é miss. E como toda chamada apresenta um prefixo novo, toda chamada também escreve.

Mesma conversa, mesmos quarenta turnos, caching habilitado, com um timestamp por chamada no topo do system prompt:

Ativar prompt caching tornou a conversa vinte por cento mais cara do que não ativar. Você pagou o prêmio de escrita de 1,25× sobre 109.730 tokens e leu de volta zero. Não há erro, não há aviso, e o recurso está ligado.

Então a regra, e ela é todo o prompt caching em uma linha: conteúdo estável na frente, conteúdo variável atrás. Instruções de sistema, definições de tools e material de referência primeiro; timestamps, identidade do usuário e a pergunta atual por último. A Anthropic explicita a hierarquia — a cache segue tools → system → messages, e uma mudança em qualquer nível invalida esse nível e tudo depois dele, então editar uma única descrição de tool invalida a cache inteira.⁵

Duas consequências fazem as pessoas tropeçarem. Mudar quais tools estão habilitadas muda as definições de tool, então uma feature flag que adiciona uma tool para alguns usuários divide sua cache em duas. E, na Anthropic, alternar web search ou citations modifica o system prompt, o que invalida as caches de sistema e de mensagens sem você tocar em uma linha do seu próprio texto.

A resposta óbvia a uma conta quadrática é parar de enviar o histórico inteiro: manter a última dúzia de mensagens e descartar o resto. Isso reduz a conta, geralmente é o movimento errado, e a medição mostra por quê.

Truncar para uma window de doze mensagens é 57% mais barato do que enviar tudo sem cache — a comparação que todo mundo faz, e por isso a técnica é popular. Mas é 39% mais caro do que enviar tudo com uma cache funcionando, e ligar caching junto com truncamento deixa um pouco pior, não melhor.

O mecanismo é o prefixo de novo. Uma sliding window remove a mensagem mais antiga a cada turno, então o prompt já não começa onde começou da última vez e cada turno apresenta um novo prefixo. A orientação da OpenAI diz exatamente isso: “summarisation, compaction, or context truncation can change the prefix and reset cache reuse.”⁶ No turno 40, o prompt em window tem 813 tokens, abaixo do mínimo de 1.024 tokens, então não pode ser armazenado em cache.

E o dinheiro é a metade barata do custo. O que você descartou é a instrução que o usuário deu no turno 2 e que o modelo precisava no turno 40. Truncamento troca uma conta que você consegue ver por uma falha que não consegue, e fazer isso direito — compactação, notas estruturadas mantidas fora da window, recuperação de histórico sob demanda — é o assunto do Capítulo 24.

Contextos longos não são apenas mais caros porque são mais longos. Depois de um limiar, eles são mais caros por token, e o limiar se aplica retroativamente ao prompt inteiro.

A página de modelo da OpenAI para gpt-5.6-terra diz isso em uma frase: “Prompts with >272K input tokens are priced at 2x input and 1.5x output for the full request.”⁷ Não para o excedente. Para tudo.

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

Um token, cinquenta e cinco centavos. Se seu serviço monta prompts a partir de documentos recuperados cujo tamanho você não controla, você tem um penhasco no seu modelo de custo em uma fronteira que ninguém na sua equipe anotou.

O preço do Google funciona da mesma forma com um limiar de 200.000 tokens: Gemini 2.5 Pro custa $1.25 por milhão de input tokens para prompts até 200K e $2.50 acima disso, com output indo de $10.00 para $15.00.⁸ A Anthropic foi na direção oposta — em 6 de setembro de 2026, sua documentação afirma que Claude 4.6 e posteriores incluem a context window completa de um milhão de tokens no preço padrão, então “uma requisição de 900k tokens é cobrada pela mesma taxa por token que uma requisição de 9k tokens”.⁹ Modelos anteriores mantinham o adicional.

É por isso que um preço não é um número. Um preço é uma tabela de tiers indexada pelo comprimento do prompt, que é para isso que serve Tier[] na função de custo, e é por isso que computeCost seleciona o tier usando o prompt inteiro, em vez de cada balde separadamente.

Os cinco baldes se mapeiam para as duas fases do Capítulo 13, e, quando você vê o mapeamento, as proporções de preço param de parecer arbitrárias.

Input tokens são prefill. O prompt inteiro passa pelo modelo em uma só vez, processado em paralelo — grandes multiplicações de matrizes, limitadas por computação. O custo por token é baixo, e esta é a fase que define o tempo até o primeiro token: um prompt de 4.947 tokens tem 4.947 tokens de prefill para executar antes de a primeira palavra aparecer.

Output tokens são decode. Eles são produzidos um de cada vez, cada um uma passagem forward completa que lê a KV cache inteira, com a GPU majoritariamente esperando memória em vez de computar. Esta é a fase que define tokens por segundo, não pode ser paralelizada dentro de uma resposta, e é por isso que output custa cerca de seis vezes input no modelo precificado aqui: $12.00 contra $2.00 por milhão de tokens.

Três consequências vêm diretamente disso. Uma cache read substitui trabalho de prefill, então compra latência e dinheiro ao mesmo tempo — o mesmo desconto aparece como uma conta menor e uma espera mais curta pelo primeiro token. Reasoning tokens são decode que você nunca vê, e é por isso que um modelo de reasoning não transmite nada por vários segundos e depois responde rapidamente: o Capítulo 12 avisou sobre a consequência na interface, e esta é a consequência na fatura. E abortar um stream não interrompe a geração — o Capítulo 14 construiu cancelamento e deixou o preço para este capítulo, e o preço é a contagem completa de output, porque os tokens são produzidos e cobrados quer alguém esteja ouvindo ou não. O mesmo vale para a resposta que ninguém mantém: regenerar uma resposta do turno 40 cinco vezes custa $0.057990 pela única que fica na tela.

O tokenizer do Capítulo 7 era Python e ficou lá. O orçamento acontece no servidor que monta a requisição, então precisa acontecer aqui, e existem exatamente três níveis de precisão disponíveis.

Nível um: conte localmente. js-tiktoken entrega as mesmas tabelas de merge BPE que o tiktoken em Python, então uma contagem idêntica byte a byte para encodings da OpenAI, sem chamada de rede:

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

As duas constantes importam e são onde contagens locais derivam. Seu texto não é o que é tokenizado — o chat template do Capítulo 11 envolve cada mensagem em marcadores de papel primeiro, e esses são tokens pelos quais você paga. Quatro por mensagem e três para o reply priming é a aproximação convencional para modelos de chat da OpenAI; nas oitenta e uma mensagens da conversa acima, somam 324 tokens, 6,4% de seu comprimento. As contagens aqui foram verificadas contra o tiktoken em Python do Capítulo 7 em todas as oitenta e uma strings e são idênticas.

Nível dois: pergunte ao provider. A Anthropic expõe /v1/messages/count_tokens e o Google expõe count_tokens, ambos aceitando o mesmo formato de requisição de uma chamada real e retornando uma contagem de input tokens de graça. Use quando você não consegue contar localmente — e você não consegue contar localmente para a Anthropic, cujo tokenizer não é publicado. A documentação da Anthropic é cuidadosa sobre o que está dando a você: a contagem “é uma estimativa” e “pode incluir tokens adicionados automaticamente pela Anthropic para otimizações de sistema”, pelos quais “você não é cobrado”.¹⁰

Nível três: leia usage na resposta. Essa é a verdade, e ela chega depois que o dinheiro foi gasto. Justamente por isso os dois primeiros níveis existem — para decidir se deve enviar a requisição, não para cobrá-la.

Quatro itens que não aparecem como itens.

O system prompt, pago em cada chamada. O acima tem 192 tokens com o overhead do template. Ao longo de quarenta chamadas, são 7.680 tokens — 5,6% da conta inteira desta conversa, por oito linhas escritas uma vez. Também é o melhor candidato possível para cache, por ser estável e estar primeiro.

Definições de tools. O nome, a descrição e o schema JSON de cada tool saem em toda requisição, e os providers adicionam estrutura por cima. A Anthropic publica o número: habilitar tools já adiciona um system prompt oculto de 496 tokens no Claude Sonnet 4.5 com tool_choice definido como auto, ou 588 com any ou uma tool nomeada.⁹ Isso antes dos seus próprios schemas. O Capítulo 18 constrói o catálogo; o Capítulo 24 mede quanto ele consome.

Toda geração, incluindo as que você descarta. Cinco regenerações custam cinco vezes. O chat mostra uma.

Pensamentos que não são mostrados a você. A cobrança se baseia no total de thought tokens, embora apenas um resumo seja retornado, e nenhuma contabilidade sua consegue auditar esse número.

Um alerta para encerrar, porque é o próximo pensamento natural e a resposta não é a óbvia.

Uma window de um milhão de tokens não significa um milhão de tokens utilizáveis. A precisão de retrieval degrada com a posição: Liu et al. descobriram que modelos localizam informações de forma confiável no início e no fim de um input longo, e muito menos no meio.¹¹ Uma window maior compra a capacidade de enviar mais, não a certeza de ser lido.

Esse fenômeno é medido uma vez neste curso — a taxa de retrieval em nove posições no mesmo prompt de 853 tokens — e pertence ao Capítulo 24, onde muda o que um agent faz. Ele é citado aqui porque muda o que você deve comprar: o token mais barato é o que você não enviou.

Agora você consegue prever quanto uma chamada custará antes de fazê-la, ler quanto ela custou depois e distinguir as duas coisas. Isso cobre tudo sobre a requisição, exceto a parte em que você ainda não mexeu: os controles.

O Capítulo 17 é sampling — temperature, top-p, top-k, as penalidades e o determinismo que você não tem. Ele começa desmontando o erro mais disseminado da área: que temperature é um botão de criatividade. Não é: temperature divide os logits do Capítulo 4 antes da softmax, e aumentá-la não torna o modelo imaginativo, aumenta a probabilidade de tokens que o próprio modelo avaliou como piores. A partir daí, por que greedy decoding produz texto mensuravelmente pior que sampling, por que top-k e top-p falham em formatos opostos de distribuição, e o experimento que encerra o capítulo: vinte passagens forward idênticas em temperature 0 voltam idênticas bit a bit quando o modelo roda sozinho, e colocar o mesmo prompt em um batch ao lado das requisições de outra pessoa move 97% de seus logits.

Eles não batem todos. O motivo começa com a caixa de ponto flutuante do Capítulo 2.

Todos os preços, limiares e multiplicadores neste capítulo foram lidos nas páginas dos próprios providers em 6 de setembro de 2026 e são declarados com essa data porque vão mudar. O método importa mais que os números: os baldes, a regra do prefixo e a aritmética de tiers estão estáveis há dois anos, enquanto todos os valores dentro deles se moveram.

A aula 2 de Stanford CS336, Resource accounting, é o tratamento acadêmico mais próximo deste material e a próxima leitura certa: ela faz a mesma aritmética no lado de treinamento que este capítulo faz no lado de inferência. As contagens de tokens aqui foram produzidas com js-tiktoken 1.0.21 usando os encodings o200k_base e cl100k_base, sobre uma conversa de quarenta turnos com 5.090 tokens; o overhead de template por mensagem é a aproximação convencional de quatro-mais-três e é declarado sempre que incluído. Os números de cache, tier e truncamento são as regras de preço documentadas aplicadas a essas contagens de tokens medidas, não observações de respostas de API ao vivo — nenhuma chamada paga foi feita para produzir este capítulo, que também é o motivo honesto de as afirmações de latência serem qualitativas e as de custo não.