Ilustração gerada com image2. Não é uma captura do produto.
Cada vez que surge um modelo com o preço por token mais baixo, alguém propõe migrar. A proposta costuma se apoiar em uma planilha com duas colunas e uma subtração. O problema é que essa subtração não é a que aparece na fatura.
Kimi K3.1 Pro é anunciado a 2 dólares por milhão de tokens de entrada e 10 por milhão de saída, contra 3 e 15 do modelo anterior, kimi-k3. Um terço mais barato em ambos os lados. Com essa informação, a decisão parece óbvia.
Não é. Em sete tarefas medidas com a mesma conta e no mesmo dia, o modelo novo venceu cinco e perdeu duas, e as duas derrotas foram em trabalho que se executa diariamente.
De onde vem a diferença
A fatura não cobra por token publicado, cobra por token gerado. E esses modelos faturam o raciocínio interno como token de saída.
Um modelo que pensa mais antes de responder produz mais tokens faturáveis ainda que a resposta visível tenha o mesmo tamanho. Na tarefa de reparar código, o modelo novo gerou 1.545 tokens de saída, dos quais 1.468 foram raciocínio. O anterior gerou 328. A resposta visível foi idêntica em ambos os casos: 77 tokens.
Aí está o desajuste. Cinco dólares de desconto por milhão não compensam mil quatrocentos tokens de pensamento.
O que foi medido
Sete tarefas, dois modelos, um dia. Mesmo enunciado para ambos, mesmos documentos, sem ajustar o prompt por modelo. O objetivo era comparar o custo de migrar em condições equivalentes, não obter a melhor resposta possível de cada um.
Os tamanhos de entrada foram de 181 a 61.576 tokens. O custo total do experimento, quatorze chamadas, foi de 1,14 dólar.
| Tarefa | Entrada | Saída kimi-k3 | Saída K3.1 Pro | Custo kimi-k3 | Custo K3.1 Pro |
|---|---|---|---|---|---|
| Buscar em documento de 55k | 61.567 | 279 | 240 | $0,189 | $0,126 |
| Reparar código | 181 | 328 | 1.545 | $0,0055 | $0,0160 |
| Chamada a ferramenta e cálculo | 540 | 197 | 101 | $0,0046 | $0,0021 |
| Resumir documento de 55k | 61.576 | 4.102 | 6.098 | $0,246 | $0,184 |
| Buscar em documento de 12k | 11.786 | 1.048 | 2.000 | $0,0511 | $0,0436 |
| Resumir documento de 12k | 11.773 | 2.530 | 8.000 | $0,0733 | $0,1035 |
| Responder email de 12k | 11.789 | 882 | 2.258 | $0,0486 | $0,0462 |
Cada linha normalizada ao seu valor máximo. Medição de 26-10-2026.
O que significa cada número
Os três dados não valem a mesma coisa e convém não misturá-los.
A entrada é o único número estável: depende do documento e do tokenizador, não do modelo. Se você trocar de modelo e o mesmo texto passar de 11.000 a 14.000 tokens, essa diferença é do tokenizador e há que medi-la, não calculá-la.
A saída é o número que decide. Inclui a resposta e o raciocínio, e por isso quase nunca se parece ao tamanho do texto que você vê na tela.
O raciocínio é o número que ninguém olha. Nessas tarefas representou entre 45 e 95 por cento da saída conforme o tipo de trabalho, e é a razão pela qual dois modelos com o mesmo preço podem faturar o triplo.
A regra que sai daqui
As duas listas de preços se reduzem a duas expressões, com entrada e saída em milhões de tokens:
-
kimi-k3: 3 × entrada + 15 × saída
-
K3.1 Pro: 2 × entrada + 10 × saída
O modelo novo convém quando a segunda é menor que a primeira. Ao subtrair, parte do termo de entrada se cancela:
10 × saída de K3.1 Pro − 15 × saída de kimi-k3 < entrada
Os dois lados são contagens de tokens, então se comparam diretamente. Se o lado esquerdo é negativo, o modelo novo ganha independentemente de quanto se envie.
Essa desigualdade acertou o sinal do resultado nas sete tarefas, incluindo as duas que ficaram perto do limite: o resumo de 55k com −550 contra 61.576 de entrada, e a resposta de 12k com 9.350 contra 11.789.
Como replicá-lo em uma hora
Não é preciso montar nada especial. Quatro passos e um documento próprio.
Escolha um documento longo do seu trabalho, não um exemplo de artigo: o tamanho e a densidade mudam a contagem de tokens.
Defina quatro formas de tarefa: buscar dentro desse documento, reparar um fragmento de código, chamar uma ferramenta com cálculo, e resumir o mesmo documento. Essas quatro cobrem quase todo o trabalho real.
Envie o mesmo enunciado aos dois modelos, sem retocá-lo para cada um. O que se compara é o custo em condições equivalentes.
Por fim, leia o bloco de uso da resposta, não o texto: entrada, saída e quanto dessa saída foi raciocínio. Multiplique pelas tarifas publicadas e subtraia.
O custo em escala
Os números por tarefa parecem pequenos até que se multiplicam.
Com 200 documentos longos por dia, 22 dias por mês, o modelo anterior custa cerca de 1.082 dólares e o novo cerca de 810. A diferença são 272 dólares por mês, uns 3.260 por ano. Para esse volume, mudar o fluxo de trabalho faz sentido.
Com 20 reparações de código por dia, os mesmos 22 dias, o anterior custa 7 dólares e o novo 2,4. A diferença não chega a 5 dólares por mês. Aí a decisão deve ser tomada pela qualidade das respostas, não pelo preço.
A conclusão não é que o modelo novo seja mais barato nem mais caro. É que a pergunta pelo preço só faz sentido depois de saber quantas vezes a tarefa é executada.
Onde o modelo novo falhou
Resposta vazia com fatura completa. Com um limite de saída de 8.000 tokens, a tarefa de resumo consumiu 7.997 em raciocínio, devolveu conteúdo vazio, terminou com motivo length e cobrou 0,1035 dólar após 229,6 segundos. Aumentar o limite a 16.000 completou a mesma tarefa em 150,8 segundos por 0,184 dólar.
O relevante não é a falha, mas que não gera erro. A combinação de conteúdo vazio e motivo length é o único sinal; um painel que só monitora códigos de estado segue em verde.
O parâmetro temperature é rejeitado. A mesma requisição com temperature 0 ou 0,6 devolve HTTP 400, e a mensagem não indica qual campo sobra. Removê-lo restaura a resposta correta.
Limites deste teste
Quatro coisas não estão verificadas aqui e convém não as dar por certas:
-
A vantagem de velocidade da variante highspeed.
-
O comportamento com um milhão de tokens de contexto realmente ocupados.
-
Como as imagens de entrada são tokenizadas.
-
A queda de alucinação de 23,4 a 8,3 por cento, que é uma cifra interna sem replicação independente.
Ademais, os dados vêm de um único dia e uma única conta. As contagens de raciocínio mudam com o prompt e com as atualizações do modelo, então a conclusão se sustenta no método, não nos números exatos.
Para discutir
O que me interessa da thread não é se o modelo é bom, mas como está distribuído o trabalho de cada um.
Se sua carga se parece mais com buscar dentro de documentos longos, a regra diz que você migre: a entrada domina e o preço de entrada é um terço menor. Se se parece mais com reparar código ou resumir textos medianos, a regra diz que você fique, e a economia desaparece no raciocínio.
Alguém mediu a proporção de tokens de raciocínio sobre o total em seus próprios prompts? Nesses testes variou entre 45 e 95 por cento conforme o tipo de tarefa, uma dispersão muito maior do que a que sugerem os números de apresentação.
E para quem já usa os dois modelos: dividiu as tarefas ou manteve um único por simplicidade? A aritmética favorece dividir; a operação favorece ter menos peças.
Ambos os modelos estão disponíveis no mesmo endpoint; os preços e a disponibilidade atual figuram no catálogo de modelos.
Preços e especificações conforme a publicação de 26 de outubro de 2026; contagens de tokens e custos medidos nesse mesmo dia.