{"slug": "por-que-duas-requisicoes-de-14m-tokens-no-cursor-custaram-valores-tao-diferentes", "title": "Por que duas requisições de 1,4M tokens no Cursor custaram valores tão diferentes", "summary": "An engineer analyzing Cursor's usage dashboard found two requests with nearly identical token counts (1.34M and 1.40M) that cost vastly different amounts: $1.13 and $2.96. The cost discrepancy is explained by the model's pricing structure, which depends on token category (cache read, cache write, input, output) rather than total token count. The first request in a session pays for cache write, while subsequent requests benefit from cheaper cache reads, and any change early in the context invalidates the cache, forcing expensive rewrites.", "body_md": "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.\n\nAs 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.\n\nSe 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.\n\nO 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.\n\nO 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.\n\nO 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:\n\n| Categoria | Preço por milhão | O que é |\n|---|---|---|\n| Cache Read | ~US$ 0,50 | contexto já cacheado, reaproveitado |\n| Input (fresco) | ~US$ 5 | texto novo entrando no contexto |\n| Cache Write | ~US$ 6,25 | gravar contexto no cache pela primeira vez |\n| Output | ~US$ 25 | tudo que o modelo gera: código, texto e raciocínio |\n\nA 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.\n\nO 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.\n\nReprocessar 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.\n\nNa 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.\n\nO 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.\n\nUm 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.\n\nA 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.\n\nMesmo 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.\n\nO 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.\n\nCom o mecanismo claro, dá para ler minhas requisições pelos quatro campos, em vez do Total.\n\n| Requisição | Total | Cache Read | Cache Write | Input | Output | Custo | Custo/milhão |\n|---|---|---|---|---|---|---|---|\n| A | 1.343.927 | 1.334.715 | 5.613 | 10 | 3.589 | US$ 1,13 | ~US$ 0,84 |\n| B | 1.399.381 | 912.025 | 302.010 | 169.871 | 15.475 | US$ 2,96 | ~US$ 2,12 |\n\nA 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.\n\nA 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ó.\n\nA 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.\n\nO Total não é uma métrica útil para prever ou diagnosticar custo. Os quatro campos são.\n\nQuando uma requisição sai cara, o caminho é abrir o detalhamento e identificar a categoria responsável:\n\nCada 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.\n\nNo 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.", "url": "https://wpnews.pro/news/por-que-duas-requisicoes-de-14m-tokens-no-cursor-custaram-valores-tao-diferentes", "canonical_source": "https://dev.to/queziabalonecker/por-que-duas-requisicoes-de-14m-tokens-no-cursor-custaram-valores-tao-diferentes-3c19", "published_at": "2026-06-25 16:59:51+00:00", "updated_at": "2026-06-25 17:13:11.293356+00:00", "lang": "en", "topics": ["large-language-models", "developer-tools", "ai-infrastructure"], "entities": ["Cursor", "Anthropic", "Opus"], "alternates": {"html": "https://wpnews.pro/news/por-que-duas-requisicoes-de-14m-tokens-no-cursor-custaram-valores-tao-diferentes", "markdown": "https://wpnews.pro/news/por-que-duas-requisicoes-de-14m-tokens-no-cursor-custaram-valores-tao-diferentes.md", "text": "https://wpnews.pro/news/por-que-duas-requisicoes-de-14m-tokens-no-cursor-custaram-valores-tao-diferentes.txt", "jsonld": "https://wpnews.pro/news/por-que-duas-requisicoes-de-14m-tokens-no-cursor-custaram-valores-tao-diferentes.jsonld"}}