A context window, os tokens e a conta, medidos

O equívoco mais caro neste negócio é pensar que um modelo se lembra de uma conversa.

Não se lembra, e o mecanismo do Capítulo 13 diz exatamente porquê. O estado de um transformer durante a geração é a KV cache: as keys e values calculadas para cada token na sequência. Essa cache vive durante um único pedido. Quando o pedido termina, o processo que a mantinha fica livre para servir outra pessoa, e a cache desaparece. Não há um armazenamento por utilizador do outro lado, nem uma sessão.

Por isso, o pedido seguinte tem de chegar com tudo o que o modelo deve saber, e o modelo reconstrói esse estado executando uma forward pass sobre todo o prompt antes de emitir um único token novo. O Capítulo 15 chamou ao prompt «o estado inteiro». Esta é a razão física: o prompt é o estado completo porque nada mais sobrevive à chamada.

A context window é o comprimento máximo desse prompt mais a sua resposta. É um teto para a quantidade de estado que pode reconstruir, não um contentor que guarda seja o que for entre pedidos. Chamar-lhe «a memória do modelo» inverte a causalidade — não está a preencher uma memória, está a pagar para restabelecer uma.

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

onde $s$ é o system prompt e $h_i$ o histórico no turno $i$. Ajustar o input acumulado medido a $an^2 + bn$ ao longo dos quarenta turnos dá $60.22\,n^2 + 432.25\,n$, o que prevê 113.645 tokens no turno 40 contra 112.617 medidos. O termo quadrático domina, e o termo linear é aquilo que o utilizador realmente escreveu.

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

A janela é finita por duas razões que puxam na mesma direção. A primeira é a do Capítulo 9: attention compara cada token com todos os outros tokens, pelo que o trabalho dessa camada cresce com o quadrado do comprimento da sequência. A segunda é 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, é maior do que os pesos.

Ambos os 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 praticáveis sem alterar o custo assintótico. Position Interpolation² e YaRN³ alargam a janela utilizável de um modelo treinado ao reescalar os positional encodings do Capítulo 9 em vez de treinar de novo. Em conjunto, explicam porque é que as janelas passaram de 2K para 1M em cinco anos.

O que não fizeram foi tornar contextos longos gratuitos. Subiram o teto e suavizaram a inclinação. A inclinação continua lá, e é isso que os escalões de preço mais adiante neste capítulo estão a medir.

Quase todas as calculadoras de custos na internet modelam uma chamada 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 uma forma que produz contas desviadas por um fator de dois ou mais em ambas as direções.

Há cinco categorias de tokens faturáveis:

Três dessas cinco não existiam como linhas separadas há dois anos, e as duas linhas de cache são as que as pessoas entendem mal, porque uma escrita na cache custa mais do que input normal, não menos. Paga um prémio para armazenar algo para depois pagar um desconto ao lê-lo de volta, e se a troca compensa depende inteiramente de quantas vezes o lê.

A categoria reasoning é a do Capítulo 12, agora com um preço, e traz um detalhe que vale a pena dizer claramente: a documentação da Google diz que o preço «se baseia nos thought tokens completos que o modelo precisa de gerar, embora apenas o resumo seja emitido pela API».⁴ São-lhe cobrados tokens que nunca lhe são transmitidos. É a única categoria cujo conteúdo não pode contar, inspecionar nem verificar.

Agora vem a parte que faz disto um problema de normalização, e não um problema de multiplicação. Cada fornecedor comunica estas categorias com nomes diferentes e — esta é a armadilha — dois deles usam a mesma palavra para duas quantidades diferentes.

Tome 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. Ambos os campos são a contagem de input token para o mesmo prompt. A da OpenAI inclui os tokens em cache; a da Anthropic exclui-os — a documentação afirma a identidade explicitamente, total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens.⁵ O input_tokens da Anthropic significa «os tokens depois do seu último ponto de interrupção de cache».

E veja o output. OpenAI e Anthropic comunicam ambas 442, que já contém os 300 reasoning tokens. Gemini comunica 142 e coloca os 300 num campo próprio. O Capítulo 12 assinalou isto como uma incompatibilidade entre duas formas de contar o mesmo trabalho; aqui está o que 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 é o objetivo inteiro de escrever a camada.

Se o fizer mal, aqui está o custo, na mesma chamada:

O terceiro é o perigoso, porque falha silenciosamente na direção das boas notícias. O seu dashboard mostra um modelo de reasoning a custar menos de metade do que custa, e nada em lado nenhum dispara um erro.

Com as categorias normalizadas, a função de custo é curta. A única parte pouco óbvia é a pesquisa do escalão, que a secção seguinte 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);
}

Há duas decisões de desenho aí que vale a pena defender. Os fallbacks — preços de cache a cair para input, reasoning para output — codificam o que significa uma tabela em falta: reasoning tokens no Gemini são faturados à taxa de output, portanto um preço reasoning ausente não é zero, é o preço de output. E contextSize soma as três categorias de input em vez de apenas as novas, porque o escalão é escolhido pelo comprimento do prompt, não por quanto dele lhe foi cobrado ao preço cheio.

Uma prompt cache armazena o estado computado do modelo para um prefixo do seu prompt, para que um pedido posterior com o mesmo prefixo evite recomputá-lo. Quatro propriedades decorrem da palavra «prefixo», e as quatro surpreendem.

O ponto de equilíbrio é pequeno o suficiente para decorar, e a documentação da OpenAI faz a aritmética: escrever um prefixo uma vez e reutilizá-lo uma vez custa 1,35× o seu custo de input normal, contra 2× para o processar duas vezes sem cache; em dez pedidos, uma escrita e nove leituras custam 2,15× contra 10×. Uma reutilização paga a escrita. A Anthropic chega ao mesmo sítio: 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 ligado 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 em ação no turno 6. O prompt só chega aos 1.024 tokens nessa altura, pelo que os primeiros cinco turnos são faturados exatamente como antes — e o sexto é faturado 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 é um desconto em prompts longos, e uma conversa curta não recebe nada dele.

O prémio de escrita é $0.002474, ou 2,8 % da conta com cache. Cada turno escreve a sua nova cauda, quarenta vezes, e todo o prémio de escrita é um arredondamento face ao que as leituras pouparam. Vale a pena compreender a cobrança de escrita com precisão para deixar de se preocupar com ela.

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

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

Coloque algo que muda em todas as chamadas perto do início do prompt — um timestamp, um request id, o nome do utilizador, uma linha «hoje é», um documento acabado de recuperar — e o prefixo difere desde o primeiro byte. Nada corresponde. Todas as chamadas são falhas. E como cada chamada apresenta um prefixo novo, cada chamada também escreve.

A mesma conversa, os mesmos quarenta turnos, caching ativado, 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 o ativar. 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 a funcionalidade está ligada.

Portanto a regra, e ela é todo o prompt caching numa linha: conteúdo estável à frente, conteúdo variável atrás. Instruções de sistema, definições de ferramentas e material de referência primeiro; timestamps, identidade do utilizador e a pergunta atual por último. A Anthropic torna a hierarquia explícita — a cache segue tools → system → messages, e uma alteração em qualquer nível invalida esse nível e tudo o que vem depois, pelo que editar uma única descrição de ferramenta invalida toda a cache.⁵

Duas consequências em que as pessoas tropeçam. Alterar que ferramentas estão ativadas altera as definições de ferramentas, pelo que um feature flag que adiciona uma ferramenta para alguns utilizadores divide a sua cache em duas. E na Anthropic, ligar ou desligar pesquisa web ou citações modifica o system prompt, o que invalida as caches de sistema e de mensagens sem que toque numa linha do seu próprio texto.

A resposta óbvia a uma conta quadrática é parar de enviar o histórico inteiro: manter as últimas doze mensagens e descartar o resto. Reduz a conta, e normalmente é a jogada errada, e a medição diz porquê.

Truncar para uma janela de doze mensagens é 57 % mais barato do que enviar tudo sem cache — a comparação que toda a gente faz, e a razão pela qual a técnica é popular. Mas é 39 % mais caro do que enviar tudo com uma cache funcional, e ligar caching juntamente com truncation torna-o ligeiramente pior em vez de melhor.

O mecanismo é novamente o prefixo. Uma janela deslizante remove a mensagem mais antiga em cada turno, pelo que 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 isto: «summarisation, compaction, or context truncation can change the prefix and reset cache reuse.»⁶ No turno 40, o prompt em janela tem 813 tokens, abaixo do mínimo de 1.024 tokens, por isso não pode ser armazenado em cache.

E o dinheiro é a metade barata do custo. O que descartou foi a instrução que o utilizador deu no turno 2 e que o modelo precisava no turno 40. Truncation troca uma conta que consegue ver por uma falha que não consegue, e fazê-lo corretamente — compactação, notas estruturadas mantidas fora da janela, recuperação de histórico a pedido — é o assunto do Capítulo 24.

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

A página de modelo da OpenAI para gpt-5.6-terra diz isso numa 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 a coisa toda.

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 cêntimos. Se o seu serviço constrói prompts a partir de documentos recuperados cujo tamanho não controla, tem um precipício no seu modelo de custos numa fronteira que ninguém na sua equipa anotou.

O preço da 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, com o output a passar de $10.00 para $15.00.⁸ A Anthropic foi no sentido oposto — a 6 de setembro de 2026, a sua documentação afirma que Claude 4.6 e posteriores incluem a context window completa de um milhão de tokens ao preço standard, pelo que «a 900k-token request is billed at the same per-token rate as a 9k-token request.»⁹ Modelos anteriores mantinham a sobretaxa.

É por isso que um preço não é um número. Um preço é uma tabela de escalões indexada pelo comprimento do prompt, que é a razão de existir Tier[] na função de custo, e é por isso que computeCost seleciona o escalão usando o prompt inteiro em vez de cada categoria separadamente.

As cinco categorias mapeiam para as duas fases do Capítulo 13, e quando vê esse mapeamento os rácios de preço deixam de parecer arbitrários.

Input tokens são prefill. O prompt inteiro atravessa o modelo numa só passagem, processado em paralelo — grandes multiplicações de matrizes, limitadas por computação. O custo por token é baixo, e esta é a fase que define o time to first token: um prompt de 4.947 tokens tem 4.947 tokens de prefill para fazer antes de a primeira palavra aparecer.

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

Daqui seguem diretamente três consequências. Uma leitura da cache substitui trabalho de prefill, pelo que compra latência e dinheiro ao mesmo tempo — o mesmo desconto aparece como conta mais baixa e espera mais curta pelo primeiro token. Reasoning tokens são decode que nunca vê, razão pela qual um modelo de reasoning não faz stream de nada durante vários segundos e depois responde depressa: o Capítulo 12 avisou sobre a consequência de interface, e esta é a consequência na fatura. E abortar um stream não para 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 faturados quer alguém esteja a ouvir quer não. O mesmo vale para a resposta que ninguém guarda: regenerar uma resposta do turno 40 cinco vezes custa $0.057990 pela única que fica no ecrã.

O tokenizer do Capítulo 7 era Python e ficou lá. O budgeting acontece no servidor que constrói o pedido, por isso tem de acontecer aqui, e há exatamente três níveis de precisão disponíveis.

Nível um: contar localmente. js-tiktoken traz as mesmas tabelas de merges BPE que o tiktoken em Python, portanto uma contagem byte a byte idêntica 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 as contagens locais divergem. O seu texto não é o que é tokenizado — o template de chat do Capítulo 11 envolve cada mensagem em marcadores de role primeiro, e esses são tokens pelos quais paga. Quatro por mensagem e três para preparar a resposta é a aproximação convencional para modelos de chat da OpenAI; nas oitenta e uma mensagens da conversa acima somam 324 tokens, 6,4 % do 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: perguntar ao fornecedor. A Anthropic expõe /v1/messages/count_tokens e a Google expõe count_tokens, ambos aceitando a mesma forma de pedido de uma chamada real e devolvendo gratuitamente uma contagem de input token. Use-os quando não consegue contar localmente — e não consegue contar localmente para a Anthropic, cujo tokenizer não é publicado. A documentação da Anthropic é cuidadosa sobre o que lhe dá: a contagem «is an estimate», e «may include tokens added automatically by Anthropic for system optimizations», pelos quais «you are not billed».¹⁰

Nível três: ler usage na resposta. Essa é a verdade, e chega depois de o dinheiro estar gasto. É precisamente por isso que existem os dois primeiros níveis — para decidir se envia o pedido, não para o faturar.

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 vir primeiro.

Definições de ferramentas. O nome, a descrição e o schema JSON de cada ferramenta seguem em todos os pedidos, e os fornecedores acrescentam scaffolding por cima. A Anthropic publica o número: ativar ferramentas acrescenta por si só um system prompt oculto de 496 tokens no Claude Sonnet 4.5 com tool_choice definido para auto, ou 588 com any ou uma ferramenta nomeada.⁹ Isto é antes dos seus próprios schemas. O Capítulo 18 constrói o catálogo; o Capítulo 24 mede o que ele consome.

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

Pensamentos que não lhe são mostrados. A faturação baseia-se nos thought tokens completos embora apenas seja devolvido um resumo, e nenhuma contabilidade sua consegue auditar esse número.

Um aviso para fechar, porque é o pensamento natural seguinte e a resposta não é a óbvia.

Uma janela de um milhão de tokens não significa um milhão de tokens utilizáveis. A precisão de retrieval degrada-se com a posição: Liu et al. descobriram que os modelos localizam informação de forma fiável no início e no fim de um input longo, e muito menos fiável no meio.¹¹ Uma janela 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. É citado aqui porque muda aquilo que deve comprar: o token mais barato é o que não enviou.

Agora consegue prever quanto uma chamada custará antes de a fazer, ler quanto custou depois, e distinguir as duas coisas. Isso cobre tudo sobre o pedido exceto a parte em que ainda não tocou: os botões.

O Capítulo 17 é sampling — temperature, top-p, top-k, as penalizações, e o determinismo que não tem. Começa por desmontar o erro mais difundido na área: que temperature é um seletor 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 classificou como piores. A partir daí, porque greedy decoding produz texto mensuravelmente pior do que sampling, porque top-k e top-p falham em formas opostas de distribuição, e a experiência que encerra o capítulo: vinte forward passes idênticas a temperature 0 voltam bit a bit idênticas quando o modelo corre sozinho, e colocar o mesmo prompt num batch ao lado dos pedidos de outra pessoa move 97 % dos seus logits.

Nem todas coincidem. A razão começa com a caixa de floating-point do Capítulo 2.

Todos os preços, limiares e multiplicadores neste capítulo foram lidos nas páginas dos próprios fornecedores em 6 de setembro de 2026 e são apresentados com essa data porque vão mudar. O método importa mais do que os números: as categorias, a regra do prefixo e a aritmética dos escalões mantiveram-se estáveis durante dois anos, enquanto todos os valores nelas se mexeram.

A aula 2 de Stanford CS336, Resource accounting, é o tratamento académico mais próximo deste material e a leitura certa a seguir: faz a mesma aritmética do lado do treino que este capítulo faz do lado da inference. As contagens de token 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 é indicado sempre que está incluído. Os números de cache, escalão e truncation são as regras de preço documentadas aplicadas a essas contagens de token medidas, não observações de respostas API reais — nenhuma chamada paga foi feita para produzir este capítulo, o que é também a razão honesta pela qual as afirmações de latência são qualitativas e as de custo não são.