Por que duas requisições de 1,4M tokens no Cursor custaram valores tão diferentes

Outro dia, analisando o painel de uso do Cursor para entender para onde meus tokens estavam indo, parei em duas requisições que tinham acabado de rodar. O instinto é olhar a contagem de tokens e assumir que a maior foi a mais cara. Ao comparar as duas, não foi isso que encontrei.

As duas tinham praticamente o mesmo tamanho: uma com 1,34 milhão de tokens, a outra com 1,40 milhão. Volume quase idêntico. A primeira custou US$ 1,13. A segunda custou US$ 2,96, quase o triplo.

Se o número de tokens fosse o que define o custo, duas requisições do mesmo tamanho custariam quase o mesmo. Não foi o que aconteceu. A intuição de que mais tokens significam mais dinheiro é, na melhor das hipóteses, incompleta, e entender o que de fato define o custo muda a forma como você lê qualquer fatura de LLM.

O instinto é olhar para o Total, o número que resume a requisição. Mas o Total mede a quantidade de texto que passou pela janela de contexto, não o custo. As duas coisas não andam juntas.

O custo não é uma função simples do total de tokens. Ele é uma soma ponderada por categoria: input fresco, cache write, cache read e output.

O detalhamento de uma requisição separa o uso em quatro categorias, cada uma com preço próprio. Usando os valores do Opus, por milhão de tokens:

A distância entre as pontas é o ponto central. Output custa cinquenta vezes o Cache Read. O mesmo token tem custo radicalmente diferente dependendo da categoria em que ele entra. Prever o custo de uma requisição exige conhecer a distribuição entre essas categorias, não o total.

O modelo é stateless. Ele não retém nada entre uma chamada e outra. A cada nova mensagem, a aplicação reenvia o contexto inteiro desde o início: instruções de sistema, rules, definições de tools, histórico da conversa e arquivos já lidos. Tudo, a cada chamada.

Reprocessar todo esse conteúdo do zero a cada interação seria caro demais. A solução é o cache de prefixo, e a palavra prefixo é literal. O cache funciona do início do contexto para a frente, enquanto o conteúdo for idêntico ao da chamada anterior.

Na primeira chamada de uma sessão não existe nada cacheado. Todo o contexto é gravado pela primeira vez, e gravar é caro (é o Cache Write). Essa é a razão de a primeira requisição de qualquer sessão ser a mais cara por token: ela paga para construir o cache. A partir da segunda chamada, esse mesmo início é reaproveitado como Cache Read, cerca de dez vezes mais barato. É por isso que uma sessão longa e contínua tende a sair barata: o custo de montar o cache é pago uma vez e diluído por todas as chamadas seguintes.

O detalhe que mais pega na prática: o cache vale apenas até o primeiro ponto em que o contexto mudou. Como ele é casado do início para a frente, qualquer alteração numa parte inicial invalida tudo o que vem depois dela.

Um exemplo concreto. Suas rules ficam no começo do contexto, logo após as instruções de sistema. Se você editar uma rule no meio da sessão, tudo o que vem depois dela (as tools, o histórico inteiro, os arquivos) deixa de bater com o cache anterior e precisa ser regravado, de novo a preço de Cache Write. Uma mudança de poucas linhas, por estar no início, força reprocessar centenas de milhares de tokens. A consequência prática é direta: o que é estável deve ficar na frente do contexto, e o que muda com frequência, mais para o fim.

A mesma coisa acontece quando o Cursor resume o contexto ao atingir o limite da janela. A sumarização reescreve o histórico, e reescrever é mudar. O cache se perde a partir da parte reescrita.

Mesmo sem você mudar nada, o cache não dura para sempre. No caso da Anthropic, o cache padrão expira após cerca de cinco minutos de inatividade, e esse contador reinicia a cada novo acesso. Na prática, enquanto você trabalha de forma contínua, com chamadas separadas por menos de cinco minutos, o cache se mantém quente por tempo indeterminado. Se você para por mais que isso, sai para uma reunião, almoça, volta no dia seguinte, o cache esfria, e a próxima chamada volta a ser um Cache Write do zero, como um novo cold start. Há também uma opção de janela mais longa, de uma hora, a um custo de gravação maior.

O mecanismo, resumido: o começo estável e contínuo é barato. Mexer no início do contexto, ou deixar a sessão esfriar, é o que custa.

Com o mecanismo claro, dá para ler minhas requisições pelos quatro campos, em vez do Total.

A requisição A é o cenário ideal. 99% do uso foi Cache Read: ela operava no meio de uma sessão quente, reaproveitando o cache construído pelas anteriores. Quase nada de Input fresco, pouco Output. Saiu a uns US$ 0,84 por milhão de tokens, e essa é a cara de uma requisição eficiente.

A requisição B é a cara. Tem volume parecido com o da A, mas custou quase o triplo. A explicação está em dois campos: 302 mil de Cache Write e 170 mil de Input fresco, dentro de uma única requisição. Esse é o churn. Algo mudou no início do contexto durante a sessão, uma rule editada ou uma sumarização disparada pelo Cursor, e o cache foi invalidado a partir daquele ponto. O modelo regravou grande parte do contexto a preço de Write e ainda processou arquivos novos como Input. Três categorias caras concentradas numa requisição só.

A e B têm praticamente o mesmo volume de tokens, 1,34 milhão contra 1,40 milhão, e quase o triplo de diferença no custo. A variável não foi o tamanho. Foi a composição.

O Total não é uma métrica útil para prever ou diagnosticar custo. Os quatro campos são.

Quando uma requisição sai cara, o caminho é abrir o detalhamento e identificar a categoria responsável:

Cada categoria tem uma causa e uma mitigação distintas. O Total agrega tudo num único número e oculta justamente a informação necessária para agir.

No próximo post trato das mitigações: as duas alavancas que de fato reduzem essa conta, maximizar o Cache Read e reduzir o Output desperdiçado.