Uso de tokens em LLMs: por que uma resposta de 4 tokens cobra 217

Faça uma pergunta matemática de uma linha ao GPT-5.6 e 88% da cobrança de saída virá de raciocínio que você nunca verá: 10 tokens visíveis, 81 cobrados. E o GPT-5.6 é um caso moderado. Para a mesma pergunta, o GLM 5.2 cobrou 217 tokens de conclusão por uma resposta de 4 tokens, enquanto o Qwen3.7-max cobrou 1,104 pela mesma resposta. Isso não é uma anomalia. É assim que modelos de raciocínio cobram por design, e essa é apenas a primeira de várias classes de tokens que a maioria dos dashboards de custo não detalha. Neste post, analisamos um objeto usage real, classe por classe, com valores medidos.

TL;DR

• A configuração padrão do GPT-5.6 cobrou 81 tokens por uma resposta de 10 tokens, com 88% de raciocínio; no GLM 5.2, a proporção foi de 98%, e no Qwen3.7-max, de 99.3%.
• O Claude Sonnet 5 cobrou 114 tokens de raciocínio por uma resposta de 5 tokens, mesmo sem receber nenhum parâmetro de raciocínio.
• Cinco famílias responderam errado sem raciocínio (399, 400, 427, 466, 467); apenas o GPT-5.6 acertou sem ele, e todas as execuções com raciocínio responderam 401.
• Uma gravação de 1,181 tokens no cache do Claude, seguida de uma leitura, custou $0.01246 e $0.00566, exatamente de acordo com os preços de tabela.

O que usamos nos testes

Todas as medições deste post usam o mesmo prompt de turno único, enviado a cada modelo com as configurações padrão, salvo quando a linha indica o contrário:

How many positive integers n <= 1000 are divisible by 3 or 5
but not by 15? Reply with just the number, nothing else.

A resposta correta é 401: há 333 múltiplos de 3 e 200 múltiplos de 5; subtraindo os 66 contados duas vezes, chegamos a 467; removendo os 66 múltiplos de 15, restam 401. Escolhemos essa pergunta de propósito. A resposta visível é curta e ocupa 3-4 tokens em qualquer tokenizer. Há uma única resposta correta, então é possível verificar se o raciocínio compensou. E a questão é difícil o bastante para os modelos quererem raciocinar, que é justamente o comportamento analisado.

As cinco classes de tokens na sua fatura

Uma conclusão moderna pode cobrar até cinco classes de tokens, com quatro tarifas diferentes. Um único número agregado de “tokens usados” esconde tudo isso.

Os nomes acima seguem o formato compatível com OpenAI. O Claude registra as mesmas cinco classes com nomes próprios: input_tokens e output_tokens, com o raciocínio em output_tokens_details.thinking_tokens, cobrado como saída. A gravação no cache ainda é separada por TTL em um objeto cache_creation (ephemeral_5m_input_tokens a 1.25x e ephemeral_1h_input_tokens a 2x). A estrutura é a mesma; só mudam os nomes. Voltaremos a esse problema de parsing mais adiante.

As cinco classes e seus multiplicadores de preço, identificadas pelos nomes de campos compatíveis com OpenAI e Anthropic. O valor de 88% corresponde à participação medida do raciocínio no GPT-5.6 no exemplo acima.

Este é o objeto real por trás do título: o GPT-5.6, com a configuração padrão, respondendo à pergunta do teste.

{
  "prompt_tokens": 38,
  "completion_tokens": 81,
  "total_tokens": 119,
  "prompt_tokens_details": { "cached_tokens": 0, "cache_write_tokens": 0 },
  "completion_tokens_details": { "reasoning_tokens": 71 },
  "cost": 0.000524
}

É aqui que está a conta da cobrança. Vale fazê-la explicitamente uma vez. A resposta recebida corresponde a completion_tokens menos reasoning_tokens: 81 − 71 = 10 tokens, ou seja, a palavra “401” e sua formatação. Os outros 71 tokens são chain-of-thought, cobrados pela tarifa integral de saída. Eles representam 88% da cobrança de saída, e no GPT-5.6 você não consegue ler nenhum deles. Todos os valores de “resposta visível” neste post são calculados da mesma forma. Em outros modelos, a proporção é ainda maior: o GLM 5.2 respondeu à mesma pergunta com 217 tokens de conclusão para uma resposta de 4 tokens. Portanto, um modelo de custos que interpreta completion_tokens como “o que o modelo disse” erra por um fator de 8x aqui e 54x ali.

O raciocínio é o orçamento, e pode ser controlado

Enviamos a mesma pergunta de uma linha com todas as configurações de raciocínio aceitas pelas três famílias ajustáveis, usando um único gateway em 2026-07-13/14. As linhas estão ordenadas do menor para o maior uso de raciocínio em cada família; as configurações padrão dos modelos principais das demais famílias aparecem na próxima seção.

A tabela mostra quatro pontos importantes:

• Quando funciona, o ajuste faz muita diferença. reasoning_effort: none respondeu corretamente por $0.000062, 8.5x abaixo do padrão do luna. Em tarefas mais difíceis, medimos uma diferença de 20x no GLM 5.2. A escolha do tier faz parte do mesmo ajuste: o modelo principal do GPT-5.6 respondeu a essa pergunta sem nenhum raciocínio por padrão, como veremos na próxima seção. Assim, um modelo maior que não precisa raciocinar pode sair mais barato que um menor que precisa.
• Em outras famílias, o ajuste quase não produz efeito. A amplitude do controle é uma característica da família: no Sonnet 5, o comportamento foi monotônico, com variação de 5x no custo (84 a 249); no GPT-5.6, o efeito foi pequeno e sem ordenação; no Qwen3.7-max, quase nulo (low ainda consumiu 974 tokens de raciocínio, contra 1,096 no padrão); no DeepSeek V4 Pro, inexistente (267 contra 269).
• Os níveis não são monotônicos, e as configurações padrão não são determinísticas. No GPT-5.6, high consumiu menos tokens que medium neste teste. Em nosso post anterior, low no GLM consumiu mais que high. O Sonnet 5 raciocinou por 114 tokens em uma requisição sem nenhum parâmetro de raciocínio. E a mesma requisição padrão do GLM usou 213 tokens de raciocínio em uma execução e 1,312 em outra, uma diferença de seis vezes. Meça o efeito real do ajuste na sua carga; não confie apenas no nome do nível.
• Baixo custo com resposta errada é um padrão recorrente. As duas famílias testadas sem raciocínio responderam errado: GLM disse 399 e Sonnet 5, 467. A lista completa das cinco famílias aparece na próxima seção. Raciocínio é um orçamento de precisão. Se vale a pena reduzi-lo depende da tarefa, não do modelo.

A regra prática é tratar reasoning_tokens como um item de custo de primeira classe. Ele usa a tarifa de saída, costuma superar em muito o tamanho da resposta visível e responde a parâmetros cujo efeito real precisa ser medido. No GPT-5.6, as regras de preço também mudaram; o guia de custos do GPT-5.6 explica o adicional de gravação e a exigência de uma chave de cache.

É possível ler aquilo pelo qual você pagou?

“Separado da resposta” nem sempre significa oculto. Verificamos o corpo das respostas, não apenas os dados de uso:

• GLM 5.2, DeepSeek, Qwen3.7-max e MiniMax retornam o texto completo do raciocínio em um campo reasoning_content ao lado da resposta: 3,987, 1,604, 2,509 e 581 caracteres, respectivamente, neste teste. O desenvolvedor consegue ler todos os tokens cobrados. O usuário final só os vê se a aplicação os renderizar, o que a maioria não faz.
• O GPT-5.6 não fornece o chain-of-thought bruto; no máximo, retorna um resumo. A resposta pode incluir um reasoning.summary escrito pelo modelo, com 359 caracteres neste caso. Porém, os 91 tokens cobrados correspondem ao texto bruto oculto, não ao resumo. O mais próximo desse conteúdo é reasoning.encrypted_content: um blob criptografado que pode ser reenviado para manter a continuidade entre turnos, mas não pode ser descriptografado. Os tokens pelos quais você pagou estão no corpo da sua própria resposta, mas permanecem ilegíveis.
• No Claude, depende de como a requisição é feita. Nossa chamada ao Sonnet 5 com raciocínio adaptativo retornou um bloco thinking vazio, mas cobrou 114 thinking_tokens: há evidência de que o modelo raciocinou, mas nenhum texto para ler. O Fable 5 se comportou da mesma forma com sua configuração padrão sempre ativa: 59 tokens cobrados e bloco vazio. Já o mesmo Sonnet 5, chamado com um orçamento explícito de raciocínio, retornou o texto real do processo: 73 tokens cobrados, com conteúdo presente. A forma da requisição determina o que você consegue ver.

A cobrança é universal, mas a visibilidade não. Todas as famílias cobram raciocínio pela tarifa de saída. A capacidade de auditar o texto comprado varia entre conteúdo completo, apenas um resumo e um bloco vazio assinado.

Quando o texto é retornado, é possível avaliá-lo mecanicamente. Nossa pergunta tem cinco resultados intermediários fixos (333, 200, 66, 467, 401), e todos os textos de raciocínio retornados continham os cinco. GLM 5.2, DeepSeek V4 Pro, Qwen3.7-max, Kimi K2.7 Code e MiniMax forneceram uma derivação completa, enquanto as variantes de baixo esforço omitiram uma etapa cada. Para quem precisa do processo, e não apenas da resposta, essa é a diferença: com reasoning_content, você pode verificar aquilo pelo qual pagou; com um resumo ou bloco vazio, precisa confiar no modelo. Tokens invisíveis, cobranças visíveis formaliza essa lacuna de responsabilização, e o PALACE estima o raciocínio oculto externamente.

A mesma pergunta no melhor modelo de cada família

A tabela anterior usou tiers específicos para demonstrar os controles. A seguir, temos o modelo principal mais recente de cada família respondendo à mesma pergunta com as configurações padrão:

Tokens de saída cobrados por modelo principal para a mesma pergunta (laranja hachurado = parcela de raciocínio; verde = resposta visível). O asterisco no MiniMax indica que os dados de uso não incluem uma contagem de raciocínio; por isso, a parcela foi reconstruída por subtração e verificada com o texto de raciocínio retornado. A marca no GPT-5.6 sol identifica a única execução correta sem raciocínio; o xis no Gemini 3.5 Flash marca a única resposta errada entre os modelos principais (466).

O gráfico reúne todos os formatos de contabilização:

• Sete dos oito modelos principais responderam corretamente, com custos muito diferentes para o mesmo 401. O Qwen3.7-max consumiu 1,096 tokens de raciocínio, levou 22 segundos e custou $0.0084. O modelo principal do GPT-5.6 não consumiu nenhum token de raciocínio e custou $0.00031. Para a mesma resposta correta, a diferença foi de 27x no custo e 7x na latência. É o orçamento de raciocínio exposto nos números.
• O MiniMax retorna o texto de raciocínio, mas não sua contagem. Foram 260 tokens de conclusão para uma resposta visível de 3 tokens. A resposta inclui a derivação completa em reasoning_content, mas completion_tokens_details não tem uma linha de raciocínio. Quando a contagem não estiver disponível, reconstrua-a por subtração: tokens de conclusão menos tokens visíveis resultam na contagem de saída oculta.
• O Gemini 3.5 Flash é o caso fora da curva: foi o único modelo principal a responder errado (466), com 3 tokens de conclusão e nenhuma contagem de raciocínio. O modelo relacionado 2.5 Flash já levou 12.5 segundos para produzir um 401 de 3 tokens, sem nenhuma indicação na cobrança que explicasse o motivo; em uma nova execução, respondeu 427.
• As respostas erradas aparecem nos tiers menores e com o raciocínio desativado. O GLM sem raciocínio respondeu 399; o Sonnet 5 desativado respondeu 467; o qwen3-max anterior não raciocinou (3 tokens) e respondeu 400; o Kimi K2.5, que não tem canal de raciocínio, raciocinou em voz alta por 144 tokens visíveis cobrados, derivou 401 no próprio texto e concluiu 400. Cinco famílias, cinco respostas erradas diferentes: 399, 400, 427, 466, 467. Apenas o GPT-5.6 acertou sem raciocínio.

Tokens de cache: dois sentidos, com diferença de 12x

O prompt caching divide a entrada em mais duas classes. A diferença de preço entre elas justifica essa separação: no Claude, gravações custam 1.25x a tarifa de entrada, ou 2x para TTL de 1 hora, enquanto leituras custam 0.1x. Em duas chamadas medidas do Opus 4.8 com um system prompt de 1,181 tokens armazenado em cache, a gravação custou $0.01246 e a leitura seguinte, $0.00566. Ambos os valores correspondem aos preços de tabela até a sexta casa decimal, e a cobrança de entrada caiu cerca de 11x entre uma chamada e outra. O ponto aqui é a contabilização: se você agrupar cache_creation_input_tokens e cache_read_input_tokens como simples “tokens de entrada”, não conseguirá verificar o desconto nem perceber quando ele deixa de ser aplicado silenciosamente. Isso acontece com mais frequência do que a documentação sugere. Nossas medições de cache encontraram limites efetivos entre 1.4 e 2.4x acima dos mínimos documentados, e o guia de prompt caching detalha o funcionamento de cada provider.

Por que sua estimativa local nunca bate com a cobrança

É comum estimar o custo no cliente com uma biblioteca de tokenização e tentar reconciliar os valores depois. Há três motivos para os números não coincidirem:

• Cada fornecedor usa tokenizers diferentes. Contar texto destinado ao Claude com um tokenizer da OpenAI equivale a usar a régua errada; a mesma string é tokenizada de forma diferente em cada família.
• A cobrança inclui mais do que sua mensagem. System prompts e schemas de tools contam como tokens de entrada em todas as requisições que os incluem, mas são fáceis de esquecer em uma estimativa local.
• Não é possível prever o raciocínio antes da resposta. Nenhuma contagem feita no cliente consegue antecipar quantos tokens de raciocínio o modelo consumirá. Esse número só aparece no usage retornado.

O objeto usage retornado é o registro de cobrança do próprio upstream. Portanto, a forma mais barata e precisa de contabilizar é parar de estimar e passar a lê-lo. O problema é que cada provider usa um formato diferente: dependendo da família, até os tokens em cache aparecem como cached_tokens, prompt_cache_hit_tokens, total_cached_tokens ou cache_read_input_tokens.

Os objetos de detalhe também não seguem um schema fixo. A referência da OpenAI documenta quatro campos no lado da conclusão: reasoning_tokens, audio_tokens e o par de Predicted Outputs accepted_prediction_tokens / rejected_prediction_tokens. Tokens de previsão rejeitados nunca aparecem na saída, mas ainda são cobrados como tokens de conclusão. No lado do prompt, o mesmo formato adiciona text_tokens, audio_tokens e image_tokens ao lado de cached_tokens; o GPT-5.6 acrescenta cache_write_tokens, e já encontramos video_tokens em produção. Os fornecedores ampliam esse formato livremente: o Kimi K2.7 retornou um completion_tokens_details.text_tokens não documentado, e o Gemini contabiliza separadamente os tokens de raciocínio e de uso de tools, com nomes próprios. Faça o parsing de forma defensiva: campos de detalhe desconhecidos são esperados, e a ausência de um campo nunca deve ser interpretada como zero. Os campos de áudio têm sua própria estrutura de custos: medimos separadamente o custo da transcrição de áudio por minuto de áudio cobrado em sete modelos dedicados de ASR.

É aqui que um gateway mostra seu valor: o Synthorai normaliza todos esses formatos em um único objeto, preenchendo reasoning_tokens e as duas direções de cache para OpenAI, Anthropic, Gemini e famílias open-weight. Assim, um único parser atende a todos os modelos roteados.

De enxergar o custo a impedi-lo

Ler o registro é só metade do trabalho. A outra metade é impedir estouros, em vez de apenas detectá-los. Dashboards mensais mostram a surpresa depois que o dinheiro já foi gasto, e um agente preso em um loop de retries não consulta dashboards. No gateway, cada chave tem uma quota, com used_quota rastreado e um limite de RPM, ambos aplicados no momento da requisição. Quando a chave esgota o orçamento, a próxima requisição recebe um erro explícito, em vez de gerar uma fatura maior três semanas depois. A atribuição por requisição, qual chave, qual modelo, BYOK ou cobrança da plataforma, volta no mesmo envelope da resposta. Assim, calcular o custo por funcionalidade exige apenas um group-by, não um projeto de reconstrução.

A ordem prática indicada pelas medições é simples: antes de otimizar qualquer coisa, leia reasoning_tokens e os campos de cache; configure o nível de raciocínio por tarefa; e imponha uma quota rígida a toda chave cujo modo de falha possa virar um loop. Para calcular quanto uma combinação específica de modelos e classes de tokens custará no seu volume, o otimizador de custos usa as mesmas tarifas por token aplicadas acima.

← Voltar ao blog