Pelo que você realmente paga

Por que a saída custa cerca de 5x a entrada

É por isso também que tokens de raciocínio são cobrados como saída. O modelo os gera da mesma forma que gera uma resposta visível, uma passagem direta sequencial por vez, portanto custam o mesmo, mesmo quando a interface nunca os exibe para você.

Entrada significa tudo o que o modelo vê

Modelos são stateless. Eles não lembram de nada entre chamadas, então cada turno reenvia todo o histórico. O turno 20 paga para ler os turnos 1 a 19 novamente. A entrada cresce linearmente com o número do turno e o total acumulado cresce de forma aproximadamente quadrática, o que é a maior surpresa na maioria das faturas.

Os dois descontos que valem o esforço de engenharia

A mesma frase custa mais no seu idioma

Uma frase, o mesmo significado, em 20 idiomas. Estas são contagens reais do tokenizer, calculadas quando esta página foi renderizada, não estimativas.

Conte tokens do seu próprio código

Esta página roda em um endpoint público que você também pode chamar. Não precisa de API key, pois executa uma passagem de tokenizer local e nunca toca em um modelo.

curl https://dreamprompting.com/api/v1/tokenize \
  -H "Content-Type: application/json" \
  -d '{"text": "Mkulima alikagua shamba la mahindi jana asubuhi", "split": true}'

{
  "count": 15,
  "words": 7,
  "chars": 47,
  "exact": true,
  "encoding": "o200k_base",
  "heuristic_count": 12,
  "tokens": ["M", "kul", "ima", " al", "ik", "agua", ...]
}

Envie uma requisição completa em vez de uma string passando um array de mensagens no formato OpenAI, que conta cada role da maneira como o modelo a lerá:

-d '{"messages": [{"role": "system", "content": "..."},
                 {"role": "user", "content": "..."}]}'

Uma ressalva honesta: estes são vocabulários BPE da OpenAI. Llama, Gemini, Qwen e Mistral possuem seus próprios tokenizers, então trate a contagem como uma estimativa próxima para eles, em vez de um valor exato. A relação entre os idiomas se mantém em todos eles. Pronto para gastar os tokens? Obter uma chave gratuita ou leia a documentação da API.

O que é um token, na verdade

Um token não é uma palavra, uma sílaba ou um caractere. É uma entrada em uma tabela de consulta fixa que foi construída uma vez, antes do treinamento, mesclando repetidamente os pares de caracteres adjacentes mais comuns em uma pilha gigante de texto até que a tabela atingisse seu tamanho alvo. Isso é tudo sobre byte pair encoding. A tabela fica congelada para sempre depois disso, e é por isso que a tokenização é determinística: os mesmos bytes sempre produzem os mesmos tokens, em cada requisição, durante toda a vida do modelo.

A consequência que as pessoas acham mais difícil de acreditar é que o espaço inicial faz parte do token. O texto em inglês é composto principalmente por palavras precedidas por espaços, então o processo de mesclagem aprendeu formas prefixadas por espaço e nunca se preocupou em aprender muitas formas isoladas. A palavra unbelievable com um espaço inicial é um token. As mesmas letras sem espaço inicial são três: un, bel, ievable. Nada sobre o significado mudou. Apenas a posição na frase.

Cada contagem naquela tabela veio do mesmo tokenizer que a caixa no topo desta página usa. Cole qualquer um deles e observe a divisão. O padrão é consistente: o que era frequente no corpus de treinamento é barato, o que era raro é reconstruído a partir de fragmentos toda vez que você o envia. Gritar custa mais do que falar. A ortografia britânica às vezes custa mais do que a americana, embora nem sempre: organisation e organization são ambos um único token, enquanto tokeniser custa o dobro do que tokenizer. Não há regra aqui, apenas frequência.

Isso também explica por que a regra de quatro caracteres por token não é confiável em ambas as direções. Medido na prosa desta seção, o inglês tem cerca de cinco caracteres por token, então a regra superestima em aproximadamente um quarto. Medido no Amárico, não chega nem perto: a mesma frase que leva 8 tokens em inglês leva 55 em Amárico, com mal meio caractere por token.

As strings que silenciosamente custam mais caro

Prosa é o caso para o qual os tokenizers foram otimizados, e a prosa se comporta bem. Todo o resto em um payload de aplicação real não se comporta. Identificadores, timestamps, moeda, coordenadas e JSON formatado (pretty-printed) são sequências que o processo de merge nunca viu o suficiente para comprimir, então eles se fragmentam quase ao nível de caractere. Estas são contagens reais, calculadas com o mesmo tokenizer:

O formato de serialização é uma decisão de precificação

O hábito mais caro em código de LLM em produção é passar JSON formatado (pretty-printed). Pegue 200 linhas dos mesmos três campos, um id numérico, um nome e um booleano, e serialize-os de três maneiras. JSON formatado: 5.500 tokens. JSON minificado: 3.100 tokens. CSV com uma única linha de cabeçalho: 1.432 tokens. Mesmos dados, mesma informação, uma redução de 74 por cento. Cada aspa, cada nome de chave repetido e cada recuo de indentação é um token pelo qual você pagou.

O código-fonte se comporta melhor do que você imagina, porque o código foi fortemente representado no treinamento. Uma função recursiva de Fibonacci de uma linha tem 23 tokens para 54 caracteres, e sequências de indentação se fundem em tokens únicos em vez de um por espaço. A parte cara de um prompt de código quase nunca é o código. São os identificadores, os hashes, os caminhos de arquivo e os blobs JSON que você envolveu nele.

A janela de contexto anunciada e a que você pode usar

A janela de contexto é o número total de tokens que o modelo pode conter em uma passagem direta (forward pass), e em quase todos os provedores é um orçamento compartilhado, não uma permissão de entrada. Entrada mais saída devem caber juntas. Uma janela de 128.000 tokens com uma resposta de 4.000 tokens deixa você com 124.000 tokens de prompt, não 128.000. Se você também estiver executando um modelo de raciocínio, os tokens de pensamento ocultos saem do mesmo orçamento antes que sua resposta visível comece, e é por isso que um prompt longo mais raciocínio profundo pode truncar uma resposta que teria sido concluída normalmente em um prompt mais curto.

Em prosa em inglês, medido em vez de estimado, 128.000 tokens equivalem a aproximadamente 106.000 palavras, o que é um romance de tamanho razoável. Esse número depende do idioma exatamente da maneira que a tabela acima prevê. O mesmo conteúdo em suaíli preenche a janela cerca de 1,9 vezes mais rápido, e em amárico quase 7 vezes mais rápido. Uma janela é uma promessa sobre tokens, nunca sobre significado.

A disciplina prática é tratar a janela como um orçamento que você aloca deliberadamente, em vez de um contêiner que você preenche. Decida antecipadamente quantos tokens vão para instruções, quantos para evidências recuperadas, quantos para o histórico da conversa e quantos você está reservando para a resposta. Aplique essas alocações no código com uma contagem real de tokens, não uma estimativa de caracteres, porque a estimativa de caracteres é o que fará você exceder silenciosamente.

O que realmente reduz a conta, ordenado por impacto

Tudo abaixo é medido em relação a um cenário base: uma conversa de 20 turnos com um prompt de sistema de 1.500 tokens, mensagens de usuário de 60 tokens e respostas de 200 tokens, precificado no nível intermediário. Essa base custa US$ 0,3018. Cada alavanca é aplicada individualmente para que os números sejam comparáveis.

Duas coisas se destacam. A primeira é que a escolha do modelo domina todo o resto por uma margem ampla, e é a alavanca que as equipes usam por último. A segunda é que nada nesta lista envolve reescrever sua prosa. Cortar frases educadas, remover por favor e obrigado, ou colapsar espaços em branco altera o número em uma fração de um por cento. Sequências de espaços já são mescladas em tokens únicos, e um espaço inicial é absorvido pela palavra seguinte. O conselho de encurtamento de prompt que circula online está otimizando o menor termo da equação.

Um aviso sobre a linha combinada: aplicar todas as alavancas de uma vez é como você entrega um produto que é 91 por cento mais barato e visivelmente pior. Mude uma coisa, meça a qualidade em relação a um conjunto de avaliação fixo, depois mude a próxima. A ordem acima é uma boa ordem para experimentá-las justamente porque as maiores economias estão no topo e o risco de qualidade é mais fácil de detectar lá.

Por que um prompt longo parece lento e uma resposta longa parece mais lenta

O tempo de resposta se divide em dois números que se comportam de maneira completamente diferente, e confundi-los é o motivo pelo qual tanto ajuste de latência não leva a lugar nenhum. Time to first token é quanto tempo você espera antes que algo apareça. Tokens per second é a rapidez com que o texto chega assim que começa. O comprimento da entrada impulsiona o primeiro. O comprimento da saída impulsiona o segundo. Eles são botões quase independentes.

Essa divisão oferece um diagnóstico claro. Se sua aplicação parece lenta antes que algo apareça, o problema é o tamanho do prompt: reduza o contexto recuperado, faça cache do prefixo estável ou corte o histórico. Se aparece rapidamente e depois fica lento, o problema é o tamanho da resposta: limite a saída, peça respostas estruturadas ou concisas, ou mude para um modelo menor e mais rápido. Streaming não torna nada mais rápido, apenas antecipa o primeiro token visível, o que é uma vitória real na experiência do usuário e nenhuma economia na conta.

A penalidade multilíngue também se aplica aqui, e esta é a parte que ninguém orça. Tokens per second é uma taxa sobre tokens, não sobre significado. Se o suaíli precisa de 1,9 vezes mais tokens para dizer a mesma coisa, a mesma frase leva 1,9 vezes mais tempo para fazer streaming em uma taxa idêntica de tokens per second. Usuários escrevendo em um idioma sub-representado esperam mais pela mesma resposta, no mesmo hardware, na mesma velocidade anunciada.

Estimando uma conta mensal a partir de princípios básicos

A maioria das surpresas de custo vem de estimar com médias em vez de construir o número a partir do formato da solicitação. Aqui está a aritmética completa para um produto plausível: um assistente de suporte baseado em recuperação. Cada valor é calculado, não arredondado de memória.

Trabalhe primeiro com uma conversa. O turno 1 cobra 3.045 tokens de entrada: o system prompt de 900 tokens, 2.100 tokens de evidência recuperada e a pergunta de 45 tokens. O turno 2 cobra tudo isso novamente mais os 225 tokens que o turno 1 adicionou à transcrição. No turno 4, a entrada cresceu para 3.720 tokens. Ao longo dos quatro turnos, a conversa cobra 13.530 tokens de entrada e 720 tokens de saída, o que no tier intermediário custa $0,0514. Multiplique por 6.000 conversas e a conta mensal é de $308,34.

Agora aplique as alavancas e observe quais realmente importam neste formato. Fazer cache apenas do system prompt economiza 19 por cento, porque o system prompt é uma pequena fração do total. Fazer cache do system prompt e dos blocos recuperados juntos, o que requer colocar a recuperação antes da pergunta e manter a ordem dos blocos estável, economiza 63 por cento e reduz a conta para $113,94. Cortar respostas de 180 para 110 tokens economiza cerca de 11 por cento. Recuperar um bloco em vez de três economiza 33 por cento. Executar o mesmo design no tier pequeno custa $82,22, e no tier pequeno com um prefixo em cache, $30,38. No tier frontier, o mesmo produto custa $1.541,70.

A variação do topo à base dessa tabela é um fator de 50, no mesmo produto, atendendo aos mesmos usuários, respondendo às mesmas perguntas. Essa é a verdadeira lição da cobrança por token: a fatura é um resultado de design, não um preço de mercado que lhe é imposto.

Dois ajustes antes de confiar em uma estimativa como esta. Multiplique por aproximadamente 2 se uma parte significativa do seu tráfego estiver em um idioma sub-representado, pois toda contagem de tokens de entrada e saída acima escala com a taxa de fragmentação. E adicione uma margem de segurança para conversas longas: as médias escondem a cauda e, como o custo cresce quadraticamente com o número de turnos, os 5 por cento das conversas que chegam a 20 turnos podem facilmente representar um terço da fatura.

Cada família de modelos conta de forma diferente

Não existe um token universal. Um tokenizer é treinado junto com uma família de modelos, no corpus dessa família, no tamanho de vocabulário que a equipe escolheu, e é distribuído congelado com os pesos. Dois modelos podem ler a mesma string e cobrar números diferentes de tokens. Os dois vocabulários nesta página tornam isso concreto: as mesmas doze frases são contadas por ambos, e alternar o seletor acima altera várias linhas drasticamente.

O hindi é o caso mais claro. No vocabulário antigo de 100k, a frase de exemplo custa 42 tokens. No vocabulário mais novo de 200k, a mesma frase custa 15. Isso é um corte de preço de 64 por cento obtido apenas por uma tabela de consulta maior. O árabe cai de 21 para 11. O amárico cai de 74 para 55, o que é uma melhoria real, mas ainda o deixa quase sete vezes mais caro que o inglês. O inglês em si não muda nada, porque nunca foi o idioma que pagou a penalidade.

As consequências práticas merecem ser levadas a sério se você roteia entre provedores. Um prompt projetado para caber exatamente dentro de uma janela de contexto em um modelo pode exceder em outro. Um modelo de custo calibrado em uma família precificará incorretamente outra, em qualquer direção. Limites de taxa expressos em tokens por minuto não são comparáveis entre fornecedores. E um cache de prompt é vinculado a um provedor e a um prefixo exato, portanto, trocar de modelo o descarta silenciosamente e seus custos voltam à taxa cheia sem nenhum erro para lhe dizer o porquê.

O hábito seguro é contar com o tokenizer pertencente ao modelo que você está realmente chamando, manter uma pequena margem em vez de preencher a janela até o último token e tratar qualquer número entre famílias como uma estimativa. As contagens nesta página usam vocabulários OpenAI BPE. Para Llama, Gemini, Qwen ou Mistral, elas serão próximas, mas não exatas. O que se transfere entre todas as famílias é a forma do problema: prosa é barata, identificadores são caros e idiomas sub-representados pagam um multiplicador.

A penalidade multilíngue não é principalmente um problema de custo

O dinheiro extra é a parte mais fácil de ver e a menos importante. Para mensagens curtas de suporte, a diferença absoluta é de frações de centavo. Três outros efeitos prejudicam mais, e nenhum deles aparece em uma fatura.

Existe uma dimensão de qualidade subjacente aos três. Uma palavra cortada em seis fragmentos genéricos carrega menos significado coerente para o modelo do que uma palavra com sua própria entrada dedicada, então idiomas fortemente fragmentados tendem a obter resultados mais fracos, além de serem mais caros. O tokenizer é a primeira camada do modelo e foi ajustado a um corpus que, em sua maioria, não era sobre você.

Se você está desenvolvendo para esses usuários, as mitigações são simples e eficazes: orce o contexto em tokens medidos em texto de amostra real no idioma de destino em vez de inglês, defina limites de saída por idioma em vez de globalmente, teste regras de corte de histórico em transcrições não inglesas e prefira vocabulários mais novos quando tiver a opção. A linha de hindi nesta página é uma economia de 64 por cento disponível gratuitamente para qualquer pessoa que verifique qual tokenizer está usando.

Perguntas que as pessoas realmente fazem

A regra de quatro caracteres por token é útil?

Apenas para prosa em inglês, e mesmo assim é imprecisa. Ela superestima frases curtas em inglês e subestima gravemente scripts não latinos. Use o tokenizer em vez de estimar sempre que o número for importante.

Eu pago pelo system prompt em cada turno?

Sim, a menos que esteja em cache. Ele é reenviado a cada solicitação porque o modelo não mantém estado entre as chamadas. Um system prompt estável é o melhor candidato a cache que você tem.

Eu pago por tokens de raciocínio que nunca vejo?

Sim, e eles são cobrados na taxa de saída, porque o modelo os gera exatamente da mesma forma que gera texto visível.

Remover espaços em branco ou pontuação economiza dinheiro?

Quase nada. Espaços iniciais geralmente são absorvidos no token seguinte. Cortar o histórico de conversas, armazenar em cache um prefixo estável e pedir respostas mais curtas valem ordens de magnitude a mais.

Posso evitar tudo isso?

Você pode transferir a fatura em vez de removê-la. Executar um modelo de pesos abertos em sua própria GPU troca o custo por token pelo hardware que você precisa comprar e manter ocupado. O Calculadora de VRAM mostra como esse hardware deve ser. Ou roteie através deste gateway, que agrupa os níveis gratuitos dos provedores e não custa nada.

Por que uma palavra custa mais quando inicia uma frase?

Porque o espaço inicial faz parte do token. O tokenizer aprendeu formas com prefixo de espaço a partir de prosa comum, então a palavra unbelievable com um espaço na frente é um único token, enquanto as mesmas letras sem nada na frente se dividem em três. A capitalização tem o mesmo efeito por um motivo diferente: Hello é um token e HELLO são dois, já que gritar é mais raro nos dados de treinamento do que o caso normal.

Números são realmente tão caros?

Sim, e a formatação piora as coisas. Dígitos se agrupam em sequências de até três, então 255 é um token, mas 1000 são dois. Adicionar separadores cobra cada separador: 1000000 são três tokens, enquanto 1,000,000 são cinco, e $1,250.00 são seis. Uma data ISO como 2026-08-03 custa seis tokens, em cada linha de cada tabela que você colar.

Quão caro é um UUID?

Um UUID padrão de 36 caracteres tem 18 tokens, mais do que uma frase completa em inglês. Hashes hexadecimais curtos são piores por caractere: a3f9c2b1 resulta em exatamente um token por caractere. Se você estiver passando identificadores para um prompt em escala, substituí-los por rótulos sequenciais curtos e mapeá-los de volta depois é uma das poucas vitórias genuinamente grandes de redução de prompt disponíveis.

Devo enviar JSON ou CSV para o modelo?

CSV, sempre que os dados forem tabulares. Duzentas linhas de três campos custam 5.500 tokens como JSON formatado, 3.100 minificado e 1.432 como CSV com uma única linha de cabeçalho. Isso é uma redução de 74 por cento para informações idênticas, porque o JSON repete cada nome de chave em cada registro e paga por cada aspa e cada sequência de indentação.

A janela de contexto inclui a resposta?

Em praticamente todos os provedores, sim. Entrada e saída compartilham um único orçamento, então uma janela de 128.000 tokens com uma resposta de 4.000 tokens lhe dá 124.000 tokens de prompt. Os tokens de raciocínio saem do mesmo pool antes que a resposta visível comece, que é como um prompt longo em um modelo de raciocínio pode truncar uma resposta que teria sido concluída normalmente em um modelo mais curto.

O que acontece se eu exceder a janela de contexto?

Uma API bem comportada rejeita a requisição com um erro de tamanho de contexto e não cobra nada. O caso perigoso é uma biblioteca cliente que trunca silenciosamente o meio da sua transcrição ou descarta os turnos mais antigos e retorna uma resposta confiante baseada em um prompt que você nunca enviou. Conte os tokens antes de enviar, em vez de descobrir depois.

Quantas palavras cabem em uma janela de contexto de 128k?

Cerca de 106.000 palavras de prosa em inglês, medidas em texto real em vez de suposições. Esse número depende do idioma, assim como tudo o mais: o mesmo conteúdo em suaíli preenche a janela cerca de 1,9 vezes mais rápido e em amárico quase 7 vezes mais rápido.

O streaming torna as respostas mais baratas ou mais rápidas?

Nenhum dos dois. O streaming mostra o primeiro token mais cedo, o que é uma melhoria genuína na experiência do usuário, mas o tempo total de geração e a contagem total de tokens permanecem inalterados. Custa exatamente o mesmo que a requisição idêntica sem streaming.

Um prompt mais longo torna a geração mais lenta?

Isso aumenta a espera antes do primeiro token, porque o prefill escala com o comprimento do prompt. Isso quase não afeta a velocidade com que o texto chega depois disso, que é definida pelo tamanho do modelo e pela carga do provedor. Portanto, se seu aplicativo está lento antes de qualquer coisa aparecer, reduza o prompt. Se ele aparece rápido e depois fica lento, limite a saída.

Qual é a maior alavanca de custo?

A escolha do modelo, por uma margem ampla, e geralmente é a última coisa que as equipes tentam. Na base de 20 turnos usada nesta página, mudar do nível médio para o nível pequeno reduz o custo em 73 por cento. O batching reduz 50 por cento, uma janela de histórico de 4 turnos 31 por cento e o cache do system prompt 27 por cento. Reescrever seu prompt para ser mais conciso vale uma fração de um por cento.

Modelos diferentes contam o mesmo texto como o mesmo número de tokens?

Não. Cada família traz seu próprio tokenizer, congelado com os pesos. Mesmo entre dois vocabulários do mesmo fornecedor, a diferença é grande: a amostra em hindi nesta página custa 42 tokens no vocabulário mais antigo de 100k e 15 no mais novo de 200k. Conte com o tokenizer pertencente ao modelo que você está realmente chamando e deixe uma margem em vez de preencher a janela exatamente.

Por que meu cache de prompt parou de funcionar?

Quase sempre porque o prefixo deixou de ser byte-idêntico. Um timestamp, um id de sessão, uma saudação aleatória, um conjunto reordenado de chunks recuperados ou um modelo alterado invalidam o cache, e nenhum deles gera um erro. Coloque tudo o que for estável primeiro, mantenha estável e coloque as partes variáveis no final.

Posso corrigir a penalidade multilíngue no meu próprio código?

Você não pode alterar o tokenizer, mas pode evitar que seus próprios limites o agravem. Faça o orçamento do contexto usando contagens de tokens medidas em texto de amostra real no idioma de destino, defina limites de saída por idioma em vez de um número global, teste sua regra de corte de histórico em transcrições que não sejam em inglês e escolha o vocabulário mais novo quando tiver essa opção. Traduzir para o inglês, chamar o modelo e depois traduzir de volta é ocasionalmente mais barato, mas geralmente perde mais em qualidade do que economiza.

Vale a pena contar tokens antes de cada requisição?

Para qualquer coisa voltada ao usuário, sim. Tokenizar localmente não precisa de API key nem de chamada de rede, e é a única maneira confiável de aplicar um orçamento de contexto, rejeitar uploads grandes demais precocemente e mostrar uma estimativa de custo real em vez de um palpite baseado em caracteres. O endpoint documentado acima faz exatamente isso e é gratuito.