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

Faça uma pergunta de matemática de uma linha ao GPT-5.6 e 88% da cobrança de output é reasoning que você nunca vai ver: 10 tokens visíveis, 81 cobrados. E o GPT-5.6 é o caso mais brando. A mesma pergunta cobrou 217 tokens de completion para uma resposta de 4 tokens no GLM 5.2, e 1.104 para a mesma resposta no Qwen3.7-max. Isso não é anomalia; é assim que os modelos de reasoning cobram por design, e é apenas a primeira de várias classes de token que a maioria dos dashboards de custo nunca separa. Este post disseca um objeto usage real, classe por classe, com os números medidos.

TL;DR

• O default do GPT-5.6 cobrou 81 tokens para uma resposta de 10 tokens, 88% de reasoning; o GLM 5.2 chegou a 98% e o Qwen3.7-max a 99,3%.
• O Claude Sonnet 5 cobrou 114 tokens de thinking numa resposta de 5 tokens sem nenhum parâmetro de thinking enviado.
• Cinco famílias responderam errado sem thinking (399, 400, 427, 466, 467); só o GPT-5.6 acertou sem ele, e todas as execuções com reasoning disseram 401.
• Uma escrita de cache de 1.181 tokens no Claude seguida de leitura custou $0,01246 e $0,00566, batendo exatamente com os preços de tabela.

Com o que testamos

Todas as medições deste post usam o mesmo prompt de turno único, enviado a cada modelo nas configurações default, exceto quando uma 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 (333 múltiplos de 3, mais 200 múltiplos de 5, menos 66 contados duas vezes, dá 467; tire os 66 múltiplos de 15 e sobram 401). Escolhemos de propósito: a resposta visível é minúscula e fixa em 3-4 tokens em qualquer tokenizer, há exatamente uma resposta certa, então dá para verificar se “o thinking valeu a pena”, e é difícil o suficiente para que os modelos queiram pensar, que é justamente o comportamento sob análise.

As cinco classes de token na sua fatura

Uma completion moderna cobra até cinco classes diferentes de token, a quatro taxas distintas. Um único número achatado de “tokens usados” esconde tudo isso.

Os nomes de campo acima seguem o formato compatível com OpenAI. O Claude carrega as mesmas cinco classes sob nomes próprios: input_tokens e output_tokens, com o thinking reportado em output_tokens_details.thinking_tokens e cobrado como output, e o cache write ainda dividido por TTL em um objeto cache_creation (ephemeral_5m_input_tokens a 1.25x, ephemeral_1h_input_tokens a 2x). Mesma anatomia, rótulos diferentes: esse problema de parsing volta numa seção mais adiante.

As cinco classes e seus multiplicadores de preço, rotulados com os nomes de campo compatíveis com OpenAI e com os do Anthropic. Os 88% são a fatia de reasoning medida do GPT-5.6 no exemplo acima.

Este é o objeto real por trás do número da manchete, o GPT-5.6 na configuração padrão respondendo à pergunta de 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 mora a aritmética da cobrança, e vale fazê-la uma vez de forma explícita. A resposta que você recebeu é completion_tokens menos reasoning_tokens: 81 − 71 = 10 tokens, a palavra “401” e sua formatação. Os outros 71 tokens são chain-of-thought cobrados à taxa cheia de output, 88% da cobrança de output, e no GPT-5.6 você não consegue ler um único deles. Todos os números de “resposta visível” deste post são calculados do mesmo jeito. Em outros lugares a proporção só piora: o GLM 5.2 respondeu à mesma pergunta com 217 completion tokens para uma resposta de 4 tokens, então um modelo de custo que lê completion_tokens como “o que o modelo disse” erra por 8x aqui e 54x lá.

Reasoning é o orçamento, e dá para controlá-lo

A mesma pergunta de uma linha em cada configuração de thinking que as três famílias controláveis aceitam, um único gateway, 2026-07-13/14 (as linhas vão de menos para mais reasoning dentro de cada família; os defaults dos flagships das demais famílias estão na próxima seção):

Quatro coisas que vale a pena ler dessa tabela com honestidade:

• A alavanca é grande onde ela funciona. reasoning_effort: none respondeu certo por $0.000062, 8,5x abaixo do default do luna, e em tarefas mais difíceis já medimos 20x no GLM 5.2. A escolha do tier faz parte da mesma alavanca: o flagship do GPT-5.6 respondeu essa pergunta com zero reasoning por default (próxima seção), então um modelo maior que não precisa pensar sai mais barato do que um menor que precisa.
• E quase inerte onde não funciona. Quanto o dial gira é uma característica de cada família: monotônico com uma variação de custo de 5x no Sonnet 5 (84 a 249), fraco e sem ordem no GPT-5.6, quase inerte no Qwen3.7-max (low ainda gastou 974 tokens de reasoning contra os 1.096 do default), morto no DeepSeek V4 Pro (267 contra 269).
• Os labels não são monotônicos e os defaults não são determinísticos. O high do GPT-5.6 gastou menos tokens que o medium aqui; o low do GLM gastou mais que o high no nosso post anterior; o Sonnet 5 pensou por 114 tokens numa requisição que não enviou parâmetro de thinking nenhum; e a mesma requisição default do GLM gastou 213 tokens de reasoning numa execução e 1.312 em outra, uma diferença de seis vezes. Meça o efeito real do dial no seu workload; não o deduza a partir do label.
• Barato e errado é a falha recorrente. As duas famílias que responderam sem pensar aqui responderam errado (GLM 399, Sonnet 5 467); a lista completa das cinco famílias está na próxima seção. Reasoning é um orçamento de correção, e se cortá-lo compensa depende da tarefa, não do modelo.

A regra prática: trate reasoning_tokens como um item de custo de primeira classe. Ele é cobrado na taxa de output, costuma superar em muito a resposta visível e responde a parâmetros cujo efeito real você precisa medir. No GPT-5.6, note que as regras de preço também mudaram; o guia de custos do GPT-5.6 cobre o prêmio de escrita e a exigência da cache-key.

Você realmente consegue ler aquilo que pagou?

“Separado da resposta” nem sempre significa oculto, e vale a pena ser preciso quanto a essa diferença. Verificamos os corpos das respostas, não só o usage:

• GLM 5.2, DeepSeek, Qwen3.7-max e MiniMax devolvem o texto completo do reasoning num campo reasoning_content ao lado da resposta (3.987, 1.604, 2.509 e 581 caracteres, respectivamente). Um desenvolvedor consegue ler cada token cobrado; os usuários finais só o veem se você renderizar isso, e a maioria das aplicações não faz isso.
• O GPT-5.6 retém a cadeia de raciocínio bruta; um resumo é tudo que você consegue. A resposta pode trazer um reasoning.summary escrito pelo modelo (359 caracteres aqui), mas os 91 tokens cobrados são o texto bruto oculto, não o resumo. O mais próximo desse texto é reasoning.encrypted_content: um blob criptografado que você pode devolver para manter a continuidade em múltiplos turnos, mas nunca descriptografar. Os tokens que você pagou ficam no seu próprio corpo de resposta, ilegíveis.
• O Claude depende de como você pergunta. Nossa chamada ao Sonnet 5 com adaptive thinking devolveu um bloco thinking cujo texto estava vazio, enquanto thinking_tokens cobrou 114: prova de que pensou, mas nada para ler. O Fable 5 se comportou do mesmo jeito no seu padrão always-on (59 cobrados, bloco vazio). Já o mesmo Sonnet 5, chamado com um orçamento de reasoning explícito, devolveu o texto real do raciocínio (73 tokens cobrados, texto presente). Como você pergunta decide o que você consegue ver.

Ou seja, a fatura é universal, a visibilidade não: toda família cobra o texto de reasoning na taxa de output, e a possibilidade de auditar o texto que você comprou vai de “completo”, passando por “só resumo”, até “um bloco vazio assinado”.

Quando o texto volta, dá para avaliá-lo de forma mecânica. Nossa pergunta tem cinco resultados intermediários fixos (333, 200, 66, 467, 401), e todo texto de reasoning devolvido continha todos eles: GLM 5.2, DeepSeek V4 Pro, Qwen3.7-max, Kimi K2.7 Code e MiniMax M3 entregaram uma derivação completa cada um, enquanto as variantes de baixo esforço deixaram cair um passo cada. Para quem precisa do processo e não só da resposta, essa é a divisão: com reasoning_content você verifica o que pagou; com um resumo ou um bloco vazio você aceita na fé. Invisible Tokens, Visible Bills formaliza essa lacuna de accountability, e PALACE estima o raciocínio oculto a partir de fora.

A mesma pergunta no melhor modelo de cada família

A tabela de steering usou tiers específicos para mostrar os controles. Aqui está o flagship mais recente de cada família na mesma pergunta, com configurações padrão:

Tokens de saída faturados por modelo principal para a mesma pergunta (laranja tracejado = parcela de raciocínio; verde = a resposta visível). O asterisco no MiniMax: seu uso não carrega contagem de raciocínio, então a parcela é reconstruída por subtração, verificada em relação ao texto de raciocínio que ele retorna. A marca de verificação no GPT-5.6 sol marca a única execução correta com zero raciocínio; a cruz no Gemini 3.5 Flash marca a única resposta principal errada (466).

Cada estilo de reporte em um gráfico:

• Sete dos oito flagships responderam corretamente, com preços muito diferentes para o mesmo 401. O Qwen3.7-max gastou 1.096 tokens de reasoning, 22 segundos e $0.0084; o flagship da GPT-5.6 gastou zero tokens de reasoning e $0.00031. Uma diferença de custo de 27x e de latência de 7x para uma resposta idêntica e correta é o orçamento de reasoning tornado visível.
• O MiniMax retorna o texto do reasoning, mas nenhuma contagem. São 260 tokens de completion para uma resposta visível de 3 tokens: a resposta carrega a derivação completa em reasoning_content, mas completion_tokens_details não tem linha de reasoning. Quando falta a contagem, reconstrua por subtração: completion menos os tokens visíveis é a sua contagem de saída oculta.
• O Gemini 3.5 Flash é o outlier: o único flagship a responder errado (466), com 3 tokens de completion e nenhuma contagem de reasoning em lugar nenhum. Seu irmão 2.5 Flash gastou certa vez 12,5 segundos para produzir um 401 de 3 tokens sem nada na fatura explicando o porquê, e uma execução repetida respondeu 427.
• É nos tiers menores e no thinking desligado que aparecem as respostas erradas. O GLM com thinking desligado disse 399; o Sonnet 5 desabilitado disse 467; o qwen3-max mais antigo não pensou nada (3 tokens) e disse 400; o Kimi K2.5, que não tem canal de reasoning, raciocinou em voz alta por 144 tokens visíveis faturados, derivou 401 dentro da própria prosa e concluiu 400. Cinco famílias, cinco respostas erradas diferentes: 399, 400, 427, 466, 467; só o GPT-5.6 acertou sem reasoning.

Cache tokens: dois sentidos, com 12x de diferença

O prompt caching divide o input em duas outras categorias, e a razão de ser dessa divisão é a diferença de preço entre elas: writes são cobrados a 1,25x da taxa de input no Claude (2x no TTL de 1 hora), reads a 0,1x. Um par de chamadas medidas no Opus 4.8, com um system prompt de 1.181 tokens em cache, custou $0,01246 (write) e depois $0,00566 (read), ambos batendo com os preços de tabela até a sexta casa decimal, e a cobrança do lado do input caindo cerca de 11x de uma chamada para a outra. O ponto deste post é a contabilidade: se você joga cache_creation_input_tokens e cache_read_input_tokens no mesmo balaio de “input tokens”, não consegue verificar o desconto nem perceber quando ele para de acontecer sem avisar. E isso para mais vezes do que a documentação sugere: nossas medições de caching encontraram thresholds efetivos de 1,4 a 2,4x acima dos mínimos documentados, e o guia de prompt caching detalha a mecânica de cada provider.

Por que sua estimativa local nunca bate com a fatura

Um padrão comum é estimar o custo no client com uma biblioteca de tokenizer e reconciliar depois. Três motivos para os números não baterem:

• Cada fornecedor usa um tokenizer diferente. Contar texto destinado ao Claude com um tokenizer da OpenAI é medir com a régua errada; a mesma string tokeniza de forma diferente em cada família.
• Você paga por mais do que sua mensagem. System prompts e schemas de tools são input tokens em toda requisição que os carrega, e é fácil esquecê-los na estimativa local.
• Reasoning é imprevisível até a resposta chegar. Nenhuma contagem no client consegue prever quantos thinking tokens um modelo vai gastar; você só descobre no usage retornado.

O objeto usage retornado é o próprio registro de cobrança do upstream, então o contador exato mais barato é parar de estimar e simplesmente lê-lo. O problema é que cada provider dá um formato diferente a ele: os tokens em cache aparecem como cached_tokens, prompt_cache_hit_tokens, total_cached_tokens ou cache_read_input_tokens, dependendo da família.

Os objetos de detalhe também não seguem um schema fixo. A referência da OpenAI documenta quatro campos do lado da completion: reasoning_tokens, audio_tokens e o par de Predicted Outputs accepted_prediction_tokens / rejected_prediction_tokens; os rejected prediction tokens nunca aparecem no output, mas ainda assim são cobrados como completion tokens. Do lado do prompt, o mesmo formato acrescenta text_tokens, audio_tokens e image_tokens ao lado de cached_tokens; o GPT-5.6 adiciona cache_write_tokens, e já vimos video_tokens na prática. Os fornecedores estendem o objeto à vontade: o Kimi K2.7 retornou um completion_tokens_details.text_tokens não documentado, e o Gemini conta thinking tokens e tool-use tokens separadamente sob nomes próprios. Faça parsing defensivo: trate campos de detalhe desconhecidos como algo esperado, e nunca assuma que um campo ausente significa zero.

É aqui que um gateway mostra seu valor: a Synthorai normaliza tudo isso em um único objeto, com reasoning_tokens e os dois sentidos de cache preenchidos em OpenAI, Anthropic, Gemini e nas famílias open-weight, de modo que um único parser cobre todos os modelos para os quais você faz roteamento.

De ver para impedir

Ler o extrato é metade do trabalho; a outra metade é tornar os estouros impossíveis, não apenas visíveis. Os dashboards de fim de mês relatam a surpresa depois que o dinheiro já foi embora, e um agente preso num loop de retry não lê dashboards. No gateway, toda key tem uma quota com used_quota rastreado e um teto de RPM, aplicado no momento da requisição: uma key que esgota o orçamento recebe um erro explícito na próxima requisição, e não uma fatura maior três semanas depois. A atribuição por requisição (qual key, qual model, BYOK ou billing da plataforma) volta no mesmo envelope de resposta, então custo por feature é um group-by, não um projeto de reconstrução.

A ordem das operações que decorre dessas medições: leia os reasoning_tokens e os campos de cache antes de otimizar qualquer coisa, ajuste o dial de reasoning por tarefa e coloque uma quota rígida em toda key cujo modo de falha seja um loop. Para ver quanto custa um mix específico de models e classes de token no seu volume, o cost optimizer calcula o preço a partir das mesmas taxas por token usadas acima.

← Voltar ao blog