Preços da API do Kimi K3, medidos: como desligar o raciocínio 'sempre ativo'

A documentação do Kimi K3 diz que o thinking não pode ser desligado e que reasoning_effort só aceita "max". Nas nossas medições, a API aceita "none" mesmo assim, e funciona: a mesma pergunta trivial que custa US$ 0,00179 com o raciocínio padrão custa US$ 0,000285 sem ele, uma diferença de 6,3x. O K3 foi lançado em 16/07/2026 a US$ 3 por milhão de tokens de entrada e US$ 15 por milhão de saída, o preço de tabela mais caro que um laboratório chinês já lançou e o mesmo valor do Claude Sonnet 5. A esse preço de saída, os tokens de raciocínio que o modelo gasta por padrão são a conta, o que torna o interruptor não documentado algo que vale entender com precisão.

TL;DR

• Nas configurações padrão, o Kimi K3 gasta de 69% a 93% dos tokens de saída em raciocínio; um parágrafo de 120 palavras foi cobrado como 2.289 tokens de saída, US$ 0,0346.
• reasoning_effort: "none" é aceito apesar de a doc dizer o contrário, e reduziu o custo da nossa consulta simples em 6,3x, mas a aritmética de múltiplos passos foi de 3/3 corretas para 0/6.
• O prompt cache do Kimi K3 acerta a partir de cerca de 256 tokens de prefixo, em blocos de 256 tokens, a uma tarifa de leitura de US$ 0,30/M.
• O chinês é a via CJK mais barata do K3: 52 tokens líquidos por 100 caracteres, abaixo dos 58 do GLM-5.2 e do DeepSeek.

Tudo abaixo foi medido em 20/07/2026 contra o kimi-k3, que está no ar no gateway da Synthorai pelos preços de tabela da Moonshot, com prompts repetidos e salgados para derrotar caches de resposta e as afirmações de comportamento verificadas por um segundo caminho de requisição independente. Cada número tem por trás registros brutos de uso.

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

O reasoning domina a conta em todos os formatos de tarefa que testamos, inclusive naqueles que não precisam de reasoning nenhum. Por resposta, com as configurações padrão:

O contraste entre modelos é o que o gráfico mostra: o GPT-5.6 raciocina de forma adaptativa (zero tokens de thinking nas perguntas triviais e factuais, 65-70% em matemática e escrita), o Claude Sonnet 5 vem com o thinking desligado, e o GLM-5.2 raciocina proporcionalmente até mais que o K3. Mas o preço de saída do GLM é $4.40/M e o do K3 é $15/M, então 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 com o tamanho da saída: 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 banal do conjunto. A alíquota é parecida com a de outros modelos de reasoning chineses; o valor da conta não é.

Mais dois fatos do modo padrão que vale considerar no orçamento. Primeiro, o modo thinking injeta um preâmbulo oculto de cerca de 67 tokens em cada requisição: uma mensagem idêntica de uma palavra foi cobrada como 86 tokens de prompt com o reasoning ligado e 19 com ele desligado. É o “system prompt oculto” que os primeiros testadores notaram, e ele desaparece junto com o reasoning. Segundo, o K3 está lento no momento: nossas chamadas de perguntas triviais levaram cerca de 19-24 segundos de ponta a ponta com reasoning ligado e 3-8 segundos com ele desligado, incluindo o atendimento da semana de lançamento. Considere a latência no orçamento, não só os dólares.

Dá pra desligar o reasoning do Kimi K3?

Dá, apesar da documentação. A referência oficial da API diz que o K3 “sempre habilita o thinking” e que reasoning_effort aceita apenas "max". Na prática, o endpoint aceitou "none", "low", "medium" e "high" sem erro, respeitou cada um deles, e confirmamos o mesmo comportamento por um caminho de requisição independente. No problema de raciocínio em múltiplos passos, o controle existe de fato, mas é grosseiro:

Dois pontos chamam atenção. As configurações intermediárias ficam agrupadas: de low até max, a contagem de tokens é parecida e a acurácia é idêntica nessa tarefa, então o único chaveamento que importa é binário. E none tem um penhasco real: forçado a responder um problema aritmético de vários passos de forma seca, o K3 errou seis vezes em seis, com respostas erradas espalhadas em vez de um erro sistemático. Quando não forçamos um formato conciso, o modelo às vezes ignorava a brevidade e resolvia os passos na própria resposta visível: acertava, mas os tokens migravam do campo de reasoning para o campo de texto em vez de desaparecer.

A latência muda menos do que a contagem de tokens sugere. Fazendo streaming do mesmo problema em todos os níveis de esforço, o tempo até o primeiro byte ficou entre 6 e 24 segundos, com os intervalos dos níveis se sobrepondo bastante; até o none, sem nada para pensar, esperou de 12 a 13 segundos, ou seja, o serving domina o tempo até o primeiro token nessa escala de tarefa. O que o controle realmente muda é o intervalo entre o primeiro byte e o primeiro token de resposta, que é a fase de thinking que o usuário fica esperando.

A leitura prática: none é uma alavanca de custo de verdade para tarefas de retrieval, formatação ou de passo único, e uma armadilha para qualquer coisa que precise de passos intermediários. Não há garantia documentada de que esse parâmetro continue funcionando; trate como comportamento medido, verifique nos seus próprios campos usage e espere que ele seja formalizado ou removido quando a documentação for atualizada.

Quando manter o reasoning ligado em cargas de agente?

Rodamos o K3 em cinco cenários no formato de agente duas vezes, com o padrão contra reasoning_effort: "none", usando tarefas simples idênticas que as duas configurações passaram por completo:

A surpresa é a primeira linha: em loops de tool-call, o K3 mal pensa mesmo no padrão (8% de parcela), então há pouco a economizar; o modelo trata a seleção de ferramenta como reflexo, não como deliberação. A economia se concentra onde a parcela de thinking é alta e a tarefa é mecânica (lookups de RAG e extração em lote), que é exatamente onde um imposto fixo sempre ligado menos faz sentido. Para planos de agente genuinamente multipasso, vale o penhasco de acurácia da seção anterior; deixe o reasoning ligado e gaste os tokens.

Em escala, o efeito na latência é real, ainda que chamadas individuais sejam ruidosas: nesses cenários, o primeiro token chegou em 10-19 segundos no padrão e em 8-13 segundos com none, e a geração rodou a uma mediana de 35 tokens por segundo em saídas substanciais. Esses números, já contando o serving da semana de lançamento, se encaixam melhor em formatos assíncronos e em lote do que em qualquer coisa conversacional hoje.

O reasoning que você devolve é cobrado de novo como input?

Sim, token por token. A documentação da Kimi orienta manter o reasoning_content de cada turno do assistant no histórico de mensagens, sem alterações. Medimos quanto isso custa: um segundo turno enviado com o chain of thought do primeiro turno foi cobrado em 599 prompt tokens; a requisição idêntica sem ele foi cobrada em 198. A diferença de 401 tokens bate quase exatamente com os 402 reasoning tokens do primeiro turno, ou seja, o thinking retido volta a entrar em toda requisição subsequente pela tarifa cheia de input de $3/M, e uma conversa longa paga de novo, a cada turno, todo o reasoning acumulado.

Mas descartar isso não é automaticamente mais barato. Sem o chain of thought anterior, o K3 raciocinou o follow-up do zero de novo: os reasoning tokens do segundo turno subiram 31% (de 343 para 449). A $3/M de input contra $15/M de output, manter o CoT saiu mais barato no líquido no nosso teste, o que significa que a recomendação da documentação se sustenta tanto por custo quanto por qualidade. A alavanca que de fato compensa aqui é o prompt cache da próxima seção: o histórico retido é um prefixo estável, e prefixos estáveis deixam de ser cobrados pela tarifa cheia.

O Kimi K3 faz cache de prompts, e a partir de quantos tokens?

O prompt cache do K3 é automático, e o piso é baixo: os hits começaram por volta de 256 tokens de prefixo compartilhado e avançaram em blocos de 256 tokens (um prompt de 303 tokens cacheou 256; um prompt de 153 tokens nunca cacheou nas tentativas repetidas). O input cacheado é cobrado a $0,30/M, um desconto fixo de 90% sobre a tarifa nova de $3/M, sem prêmio de cache-write em nenhuma chamada que fizemos. O warm-up levou de duas a cinco chamadas idênticas até o primeiro hit, então um único retry não prova nada em nenhum dos dois sentidos; meça ao longo de várias chamadas.

Para dar contexto, esse piso é um quarto do mínimo de 1.024 tokens documentado pela OpenAI, e o tamanho do bloco é mais grosseiro que a granularidade de 64 tokens que medimos em outros casos. A duração é best-effort, não um TTL fixo: no nosso teste, as entradas cacheadas sobreviveram a intervalos ociosos de 4 e 15 minutos, enquanto um intervalo de 8 minutos deu miss, então trate a expiração como eviction dependente de carga e verifique o split cacheado em cada chamada. Mais um fato de preço que vale a conta: a janela de contexto de 1M tokens tem preço fixo, sem tier de long-context na tabela. Uma janela no máximo custa $3,00 de input novo por chamada, e $0,30 quando o prefixo está quente, então workloads de contexto grande dependem muito mais do cache do que do preço de tabela. Se o seu tráfego reaproveita um system prompt de mesmo algumas centenas de tokens, o cache do K3 já entra em ação onde o da maioria dos provedores nem teria começado; a mecânica e como verificar os hits pelo usage estão cobertas no nosso guia de prompt caching e no estudo dos mínimos de cache medidos.

O chinês é mesmo mais caro no Kimi K3?

Não. O chinês é justamente onde o tokenizer do K3 é mais eficiente em relação aos concorrentes, o que responde a uma dúvida que apareceu várias vezes nas discussões da semana de lançamento. Tokens líquidos por 100 caracteres em trechos semanticamente alinhados, já descontado o overhead de envelope:

O K3 cobra o chinês a 52 tokens por 100 caracteres, 11% abaixo de GLM-5.2 e DeepSeek e menos da metade do Sonnet 5. Seu ponto fraco é o japonês, onde paga de 16% a 24% a mais que os outros modelos de peso aberto. Também confirmamos que o tokenizer não mudou dentro da família: K3, K2.7-code e K2.5 produziram contagens idênticas em todas as 23 amostras alinhadas, então os budgets por idioma feitos para o K2 continuam válidos. Como a densidade do tokenizer se combina com o preço por token em nove idiomas é o tema do nosso estudo LLM mais barato por idioma.

FAQ

Quando os pesos abertos do Kimi K3 serão liberados?

A Moonshot prometeu pesos completos sob uma licença MIT Modificada até 27 de julho de 2026; até a publicação deste post, o K3 é apenas por API. O enquadramento do “maior modelo de pesos abertos de todos os tempos” é um compromisso, ainda não um link de download. Como o cache se comporta no ecossistema de pesos abertos ao qual esses pesos se juntarão está mapeado em cache de prompt para LLMs de pesos abertos.

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

Na conta, três coisas que medimos: o preço (os $3/$15 do K3 contra os $0.95/$4 do K2.7-code, um salto de 3,2 a 3,75x), o thinking sempre ligado (o K2.5 não raciocina nada, o K2.7-code tem um toggle) e mais nada: o tokenizer é idêntico byte a byte entre K3, K2.7-code e K2.5 nas 23 amostras alinhadas, então os budgets de token da era K2 continuam valendo. Na ficha técnica, segundo a Moonshot: um novo MoE de 2,8T parâmetros (896 experts, 16 ativos por token) com Kimi Delta Attention, uma janela de contexto de 1M tokens contra os 256K do K2.7-code e entrada de imagem nativa. Medimos as afirmações de cobrança, não as de arquitetura.

O Kimi K3 suporta saída estruturada?

Sim. Um response_format com json_schema retornou um objeto válido e conforme ao schema no nosso teste. Vale notar que o raciocínio continua rodando por baixo: 66 dos 97 tokens de saída dessa chamada de extração foram de reasoning, então chamadas com schema pagam o imposto do thinking como qualquer outra, a menos que você também defina reasoning_effort: "none".

Desligar o raciocínio muda o que você consegue ver?

Sim. Nas configurações padrão o K3 retorna toda a cadeia de raciocínio em reasoning_content, e a documentação recomenda devolvê-la sem alterações no histórico de múltiplos turnos. Com reasoning_effort: "none" o campo desaparece por completo, e o preâmbulo de thinking de ~67 tokens some junto da sua conta de prompt.

Medido em 2026-07-20 no kimi-k3 com os preços de tabela da semana de lançamento ($3/M input, $0.30/M cached, $15/M output). Prompts repetidos foram salgados para evitar caches em nível de resposta; as contagens de acurácia usam tarefas com resposta única verificável; as afirmações de comportamento foram reproduzidas em um segundo caminho de requisição independente. Preços e comportamento podem mudar conforme o release amadurece; confira nos seus próprios registros de usage antes de confiar em qualquer número aqui.

← Voltar ao blog