Preço da API do Kimi K3, medido: desative o raciocínio sempre ativo

A documentação do Kimi K3 afirma que não é possível desativar o raciocínio e que reasoning_effort aceita apenas "max". Nas nossas medições, porém, a API também aceita "none", e a opção funciona. A mesma pergunta trivial que custa $0.00179 com o raciocínio padrão sai por $0.000285 sem ele, uma diferença de 6.3x. O K3 foi lançado em 2026-07-16 por $3 por milhão de tokens de entrada e $15 por milhão de tokens de saída. É o maior preço de tabela já cobrado por um laboratório chinês e igual ao do Claude Sonnet 5. Com esse preço de saída, os tokens de raciocínio gerados por padrão representam a maior parte da conta. Por isso, vale entender exatamente como funciona essa opção não documentada para desativá-los.

TL;DR

• Nas configurações padrão, o Kimi K3 gasta 69-93% dos tokens de saída com raciocínio; um parágrafo de 120 palavras contabilizou 2,289 tokens de saída e custou $0.0346.
• reasoning_effort: "none" é aceito apesar do que diz a documentação e reduziu em 6.3x o custo das nossas consultas simples, mas a precisão em aritmética com várias etapas caiu de 3/3 para 0/6.
• O prompt cache do Kimi K3 começa a registrar hits com cerca de 256 tokens de prefixo, em blocos de 256 tokens, a uma tarifa de leitura de $0.30/M.
• O chinês é o idioma CJK mais barato no K3: 52 tokens líquidos por 100 caracteres, abaixo dos 58 do GLM-5.2 e do DeepSeek.

Todas as medições abaixo foram feitas em 2026-07-20 com o kimi-k3, disponível no gateway da Synthorai pelos preços de tabela da Moonshot. Adicionamos salt aos prompts repetidos para evitar caches de resposta e validamos as observações comportamentais por um segundo caminho de requisição independente. Todos os números têm como base registros brutos de uso.

Quanto custa cada resposta do Kimi K3 por padrão?

O raciocínio domina a conta em todos os tipos de tarefa que testamos, inclusive nas que não exigem raciocínio algum. Por resposta, com as configurações padrão:

O gráfico destaca a diferença entre os modelos. O GPT-5.6 raciocina de forma adaptativa: usa zero token de raciocínio nas perguntas triviais e factuais e 65-70% em matemática e redação. O Claude Sonnet 5 vem com o raciocínio desativado, enquanto o GLM-5.2 dedica proporcionalmente ainda mais tokens a ele do que o K3. Mas a saída do GLM custa $4.40/M, contra $15/M no K3. Assim, a mesma resposta para 17×23 custou $0.00078 no GLM-5.2, $0.00027 no GPT-5.6, $0.0001 no Sonnet 5 e $0.0018 no K3. A diferença aumenta conforme a saída cresce: o mesmo parágrafo de 120 palavras custou $0.0346 no K3, contra $0.0186 no GLM-5.2, $0.0072 no GPT-5.6 e $0.0024 no Sonnet 5. É uma variação de 15x na tarefa mais comum do conjunto. A proporção de tokens gastos com raciocínio é comparável à de outros modelos chineses; o valor cobrado por eles, não.

Há outros dois fatos do modo padrão que precisam entrar no orçamento. Primeiro, o modo de raciocínio injeta um preâmbulo oculto de cerca de 67 tokens em cada requisição: uma mensagem idêntica de uma única palavra contabilizou 86 tokens de prompt com o raciocínio ativado e 19 com ele desativado. Esse é o “prompt de sistema oculto” observado pelos primeiros testadores, e ele desaparece junto com o raciocínio. Segundo, o K3 está lento neste momento: nossas chamadas com perguntas triviais levaram cerca de 19-24 segundos de ponta a ponta com o raciocínio ativado e 3-8 segundos sem ele, já considerando a infraestrutura da semana de lançamento. Dimensione a latência, não apenas o custo.

É possível desativar o raciocínio do Kimi K3?

Sim, apesar da documentação. A referência da API oficial afirma que o K3 “sempre ativa o raciocínio” e que reasoning_effort aceita apenas "max". Na prática, o endpoint aceitou "none", "low", "medium" e "high" sem erro, aplicou cada configuração e apresentou o mesmo comportamento em um caminho de requisição independente. No problema textual com várias etapas, o controle funciona, mas tem pouca granularidade:

Dois pontos chamam atenção. As configurações intermediárias ficam próximas: de low a max, a quantidade de tokens foi semelhante e a precisão nessa tarefa foi idêntica. Na prática, a escolha relevante é binária. Além disso, none provoca uma queda abrupta: obrigado a responder de forma concisa a um problema aritmético com várias etapas, o K3 errou todas as seis tentativas. As respostas incorretas variaram, sem indicar um único erro sistemático. Quando não exigimos uma resposta curta, o modelo às vezes ignorou a instrução de concisão e desenvolveu os cálculos na resposta visível. A resposta ficou correta, mas os tokens apenas migraram do campo de raciocínio para o campo de texto, em vez de desaparecer.

A latência varia menos do que a contagem de tokens sugere. Ao transmitir o mesmo problema por streaming em todos os níveis de esforço, o tempo até o primeiro byte ficou entre 6-24 segundos, com grande sobreposição entre as faixas. Mesmo com none, sem nada para raciocinar, a espera foi de 12-13 segundos. Para uma tarefa desse tamanho, o tempo até o primeiro token é dominado pela infraestrutura. O controle altera principalmente o intervalo entre o primeiro byte e o primeiro token da resposta, que corresponde à fase de raciocínio durante a qual o usuário espera.

Na prática, none reduz de fato o custo em tarefas de recuperação, formatação ou etapa única, mas é perigoso quando há etapas intermediárias. Não existe garantia documentada de que esse parâmetro continuará funcionando. Trate-o como comportamento observado, confirme-o nos seus próprios campos de usage e considere que ele pode ser oficializado ou removido quando a documentação for atualizada.

Quando o raciocínio deve continuar ativado em workloads de agentes?

Executamos cinco cenários típicos de agentes duas vezes no K3, comparando o padrão com reasoning_effort: "none". Usamos as mesmas tarefas simples, concluídas integralmente nas duas configurações:

O primeiro resultado surpreende: em loops de chamadas de ferramentas, o K3 quase não raciocina mesmo com as configurações padrão, com uma parcela de apenas 8%. Portanto, há pouco a economizar. O modelo trata a seleção de ferramentas como uma reação direta, não como uma deliberação. A economia se concentra onde a parcela de raciocínio é alta e a tarefa é mecânica, como consultas RAG e extração em lote. São justamente os casos em que uma cobrança fixa e sempre ativa faz menos sentido. Em planos de agentes que realmente exigem várias etapas, aplica-se a queda de precisão descrita na seção anterior: mantenha o raciocínio ativado e arque com os tokens.

Em escala, o efeito na latência é real, embora chamadas isoladas variem bastante. Nesses cenários, os primeiros tokens chegaram em 10-19 segundos com as configurações padrão e em 8-13 segundos com none. Nas saídas substanciais, a geração teve mediana de 35 tokens por segundo. Já considerando a infraestrutura da semana de lançamento, esses números se encaixam melhor em workloads assíncronos e em lote do que em experiências conversacionais.

O raciocínio reenviado é cobrado novamente como entrada?

Sim, token por token. A documentação da Kimi orienta a manter o reasoning_content de cada turno do assistente inalterado no histórico de mensagens. Medimos o custo disso: um segundo turno que incluía a cadeia de raciocínio do primeiro contabilizou 599 tokens de prompt; a requisição idêntica sem ela contabilizou 198. A diferença de 401 tokens praticamente coincide com os 402 tokens de raciocínio do primeiro turno. Portanto, o raciocínio preservado volta a entrar em todas as requisições seguintes pela tarifa integral de entrada de $3/M, e uma conversa longa paga novamente pelo raciocínio acumulado a cada turno.

Removê-lo, porém, nem sempre reduz o custo. Sem a cadeia de raciocínio anterior, o K3 raciocinou novamente sobre o follow-up desde o início: os tokens de raciocínio do segundo turno aumentaram 31%, de 343 para 449. Com a entrada a $3/M e a saída a $15/M, manter o CoT foi a opção de menor custo líquido no nosso teste. A recomendação da documentação, portanto, faz sentido tanto em termos de custo quanto de qualidade. O mecanismo que realmente gera economia aqui é o prompt cache abordado na próxima seção: o histórico preservado forma um prefixo estável, e prefixos estáveis deixam de ser cobrados pelo preço integral.

O Kimi K3 faz cache de prompts? A partir de quantos tokens?

O prompt cache do K3 é automático e tem um piso baixo: os hits começaram com cerca de 256 tokens de prefixo compartilhado e avançaram em blocos de 256 tokens. Um prompt de 303 tokens colocou 256 em cache; um prompt de 153 tokens nunca entrou no cache nas tentativas repetidas. A entrada em cache custa $0.30/M, um desconto fixo de 90% em relação aos $3/M da entrada nova. Nenhuma das chamadas que fizemos teve cobrança adicional pela gravação no cache. O aquecimento exigiu de duas a cinco chamadas idênticas até o primeiro hit. Portanto, uma única repetição não comprova que o cache funciona ou não; meça várias.

Para efeito de comparação, esse piso corresponde a um quarto do mínimo documentado pela OpenAI, de 1,024 tokens, e o tamanho do bloco é maior que a granularidade de 64 tokens que medimos em outros provedores. A duração é baseada em best effort, não em um TTL fixo: no nosso teste, entradas sobreviveram a períodos ociosos de 4 e 15 minutos, enquanto uma após 8 minutos não registrou hit. Trate a expiração como uma remoção dependente da carga e confira a divisão de tokens em cache a cada chamada. Outro dado relevante para o cálculo de custos: a janela de contexto de 1M tokens tem preço único, sem uma faixa específica para contextos longos na tabela. Uma janela inteira custa $3.00 de entrada nova por chamada e $0.30 depois que o prefixo aquece. Em workloads com contexto grande, o cache pesa muito mais que o preço de tabela. Se o tráfego reutiliza um prompt de sistema com apenas algumas centenas de tokens, o cache do K3 já entra em ação quando o da maioria dos provedores ainda nem teria começado. Explicamos o funcionamento e como verificar hits em usage no nosso guia de prompt caching e no estudo sobre mínimos de cache medidos.

O chinês realmente custa mais no Kimi K3?

Não. Em comparação com os concorrentes, o tokenizer do K3 é mais eficiente justamente em chinês, uma dúvida recorrente nas discussões da semana de lançamento. Tokens líquidos por 100 caracteres em trechos semanticamente alinhados, descontando o overhead do envelope:

O K3 contabiliza 52 tokens por 100 caracteres em chinês, 11% abaixo do GLM-5.2 e do DeepSeek e menos da metade do Sonnet 5. Seu ponto fraco é o japonês, no qual consome 16-24% mais tokens que os outros modelos de pesos abertos. Também confirmamos que o tokenizer não mudou dentro da família: K3, K2.7-code e K2.5 produziram contagens idênticas nas 23 amostras alinhadas. Assim, os orçamentos por idioma criados para o K2 continuam válidos. Nosso estudo sobre o LLM mais barato por idioma analisa como a densidade do tokenizer se combina com o preço por token em nove idiomas.

Perguntas frequentes

Quando os pesos abertos do Kimi K3 serão lançados?

A Moonshot prometeu disponibilizar os pesos completos sob uma licença Modified MIT até 27 de julho de 2026. Na data desta publicação, o K3 ainda está disponível apenas via API. A descrição de “maior modelo de pesos abertos já criado” é, por enquanto, um compromisso, não um link para download. O comportamento do cache no ecossistema de pesos abertos do qual o modelo fará parte está mapeado em prompt caching para LLMs de pesos abertos.

O que realmente mudou no K3 em relação à família K2?

Na cobrança, medimos três pontos: o preço, $3/$15 no K3 contra $0.95/$4 no K2.7-code, um aumento de 3.2-3.75x, o raciocínio sempre ativado, o K2.5 não raciocina e o K2.7-code oferece um controle, e nada mais. O tokenizer é idêntico byte a byte no K3, no K2.7-code e no K2.5 em todas as nossas 23 amostras alinhadas. Portanto, os orçamentos de tokens da época do K2 continuam válidos. Segundo as especificações da Moonshot, há um novo MoE de 2.8T parâmetros, com 896 especialistas e 16 ativos por token, Kimi Delta Attention, janela de contexto de 1M tokens contra 256K no K2.7-code e entrada nativa de imagens. Medimos as alegações de cobrança, não as de arquitetura.

O Kimi K3 aceita saída estruturada?

Sim. Um response_format com json_schema retornou um objeto válido e compatível com o schema no nosso teste. O raciocínio continua sendo executado internamente: 66 dos 97 tokens de saída dessa chamada de extração foram de raciocínio. Portanto, chamadas com schema também pagam esse custo, a menos que você defina reasoning_effort: "none".

Desativar o raciocínio muda o que fica visível?

Sim. Com as configurações padrão, o K3 retorna toda a cadeia de raciocínio em reasoning_content, e a documentação recomenda reenviá-la sem alterações no histórico de vários turnos. Com reasoning_effort: "none", o campo desaparece por completo. O preâmbulo de raciocínio de cerca de 67 tokens também deixa de entrar na cobrança do prompt.

Medido em 2026-07-20 no kimi-k3, com os preços de tabela da semana de lançamento ($3/M de entrada, $0.30/M em cache e $15/M de saída). Adicionamos salt aos prompts repetidos para evitar caches no nível de resposta; as contagens de precisão usam tarefas com uma única resposta verificável; as observações comportamentais foram reproduzidas por um segundo caminho de requisição independente. Preços e comportamento podem mudar conforme o lançamento amadurece. Confirme todos os números nos seus próprios registros de usage antes de usá-los como referência.

← Voltar ao blog