Preços do Kimi K3.1 Pro: tokens, raciocínio e cache

Os preços do Kimi K3.1 Pro separam entrada comum, saída, leituras e escritas no cache. As taxas oficiais Pro da Moonshot são $2 por milhão de tokens de entrada e $10 por milhão de tokens de saída. Leituras em cache custam $0,20 por milhão de tokens; escritas custam $2 na faixa de 5 minutos ou $4 na faixa de 1 hora. Esses preços oficiais foram verificados em 25 de outubro de 2026. Use a tabela atual abaixo para requisições feitas pelo SeedRouter.^[1]

A resposta visível é apenas parte da saída. O Kimi K3.1 Pro sempre raciocina, e esses tokens de raciocínio também contam no uso de saída. No lado da entrada, leituras e escritas no cache são partes do prompt, não cópias extras. Esses dois detalhes explicam por que estimar uma conta pelo tamanho da resposta final pode dar errado.

A página do modelo Kimi K3.1 Pro reúne o Playground, as taxas atuais e exemplos de integração. Este guia explica como ler essas taxas em relação a uma requisição concluída.

Quanto custa o Kimi K3.1 Pro aqui?

Para uma requisição no SeedRouter, use as taxas atuais abaixo. Elas são lidas das configurações ativas de cobrança, em vez de serem copiadas para este artigo.

Mantenha o ID do modelo e a fonte da taxa junto de cada estimativa. O preço oficial de tabela de um modelo e o preço de uma requisição em um serviço específico não precisam ser iguais. Um nome de modelo parecido também não comprova que uma taxa se aplica. O modelo público tratado aqui é kimi-k3.1-pro.

Não há motivo para cobrar um prompt pequeno como se ele preenchesse toda a janela de contexto. O Kimi K3.1 Pro aceita 1.048.576 tokens de contexto; o uso real de entrada é a quantidade aplicada no cálculo. A capacidade de contexto informa quanto material uma requisição comporta. Não é uma compra fixa de um milhão de tokens.^[2]

Quais tokens você deve contar?

O Kimi K3.1 Pro expõe nomes diferentes de uso em seus três formatos nativos. Para Chat Completions, comece por esta divisão:

O restante sem cache é a entrada total menos leituras e escritas no cache. Essas categorias são disjuntas. Multiplicar o prompt inteiro pela taxa comum de entrada e depois adicionar cobranças de cache contaria os mesmos tokens duas vezes.^[3]

Com taxas expressas por milhão de tokens:

uncached input = total input - cache reads - cache writes

cost = (
  uncached input × input rate
  + cache reads × cache-read rate
  + 5-minute writes × 5-minute write rate
  + 1-hour writes × 1-hour write rate
  + output × output rate
) / 1,000,000

Por exemplo, uma requisição ilustrativa com 5.000 tokens de entrada, 1.000 tokens de leitura de cache e 500 tokens de escrita no cache contém 3.500 tokens comuns de entrada. Se ela também usa 2.000 tokens de saída, aplique as cinco quantidades relevantes às taxas atuais. Este é um exemplo de cálculo, não um benchmark declarado ou uma resposta medida.

Por que uma resposta curta do Kimi K3.1 Pro pode custar mais que o esperado?

O orçamento de saída do Kimi K3.1 Pro cobre tanto o raciocínio quanto a resposta visível. O modelo pode gastar tokens trabalhando em um problema antes de produzir uma conclusão breve. Contar somente as palavras que você exibe deixa esse trabalho de fora.

Escolha o nível de raciocínio low, high ou max para a tarefa; o padrão é max. Para uma consulta pequena ou transformação delimitada, avalie se low atende às suas verificações. Para uma tarefa difícil de depuração, um orçamento maior de raciocínio pode ser útil. Meça o resultado por um critério de aceitação, em vez de presumir que uma resposta mais curta ou mais longa seja melhor.^[2]

Um limite muito pequeno de tokens também pode encerrar a geração antes de o modelo produzir uma resposta útil. Confira o motivo de término ou o status terminal da resposta antes de tratar um resultado truncado como completo. Tentativas repetidas fazem parte do custo da sua carga de trabalho, mesmo que o painel mostre cada requisição separadamente.

Solicitar cache de uma hora comprova que ele foi usado?

Não. O Kimi K3.1 Pro pode manter a duração original de um prefixo em cache. Um acerto atualiza essa duração, e o material recém-acrescentado pode continuar sob o mesmo TTL fixado até a entrada existente expirar. Alterar o TTL solicitado não comprova de forma confiável que a escrita atual usou outra taxa.^[4]

Mantenha uma chave de cache e um prefixo de conversa estáveis quando quiser que o contexto repetido continue elegível para cache. Depois confira o uso real. Não suponha que texto idêntico garanta um acerto, nem precifique uma escrita apenas pela configuração enviada.

Os formatos nativos fornecem evidências diferentes. Os cabeçalhos oficiais de uso do Chat distinguem escritas de 5 minutos e de 1 hora. Responses pode retornar as opções de cache realmente aplicadas. Messages fornece contadores separados em usage.cache_creation. Se o registro coletado não tiver essa evidência, marque a estimativa local como incompleta em vez de inventar um TTL.

Como Responses e Messages mudam o cálculo?

Para Responses, usage.input_tokens é o total e input_tokens_details contém as categorias de cache. A saída é usage.output_tokens. O princípio contábil é o mesmo de Chat: subtraia as partes em cache antes de aplicar a taxa comum de entrada.^[5]

Messages usa outra convenção de entrada. Seu usage.input_tokens exclui leituras e escritas no cache. Para recuperar o contexto total, some cache_read_input_tokens e cache_creation_input_tokens. Para o custo, aplique a taxa comum diretamente à entrada sem cache e precifique cada categoria de cache separadamente. Não subtraia as categorias de cache desse valor que já o exclui.^[6]

Essa distinção importa ao comparar SDKs ou mover uma integração entre formatos. Valores de “entrada” com nomes iguais nos logs do aplicativo podem descrever quantidades diferentes. Registre o formato nativo com o objeto original de uso e normalize-o uma vez para os seus relatórios.

Uma primeira verificação útil de custo

Comece com uma tarefa do Kimi K3.1 Pro cujo resultado possa verificar. Defina um limite explícito de saída, registre o nível de raciocínio e preserve todo o uso retornado. Para um fluxo com ferramentas, inclua a requisição seguinte que devolve o resultado da ferramenta; a primeira chamada sozinha não é a tarefa inteira.

Compare o valor calculado dos tokens com o registro de uso da requisição. Mantenha as unidades das taxas consistentes, separe contexto total de entrada sem cache e registre qualquer evidência ausente de duração do cache. Depois que esse caso pequeno conferir, repita o método em um conjunto representativo das suas próprias tarefas.

Use a documentação da API do Kimi K3.1 Pro para campos de requisição e restrições de mídia, ou volte ao Playground para conferir uma resposta nativa. Requisições que falham no SeedRouter não são cobradas.

Perguntas frequentes

Eu pago por todo o limite de saída?

O limite de saída é um teto. A cobrança de tokens usa a saída informada para a requisição concluída, incluindo raciocínio. Um limite de 2.000 tokens não significa que toda resposta consome 2.000 tokens. Mantenha o objeto de uso com a resposta para verificar a quantidade real.

Um acerto no cache é gratuito?

Não. Leituras de cache têm sua própria taxa. Uma requisição também pode conter um prefixo em cache, nova entrada sem cache e saída, cada um com cobrança separada. Use a taxa atual de leitura de cache acima e a contagem retornada de tokens em cache; não trate o prompt inteiro como armazenado só porque parte dele foi reutilizada.

Posso reutilizar uma estimativa de preço do Kimi K3?

Recalcule para kimi-k3.1-pro. Um nome de modelo relacionado não estabelece preços ou campos de uso idênticos. Mantenha o ID do modelo, o formato nativo da requisição e as taxas aplicáveis junto das contagens de tokens, especialmente ao comparar uma integração antiga com uma nova.

Fontes

1. Moonshot: preços de modelos, verificado em 25 de outubro de 2026.
2. Moonshot: início rápido do Kimi K3.1 Pro.
3. Moonshot: Chat Completions.
4. Moonshot: cache de contexto.
5. Moonshot: Responses.
6. Moonshot: Messages.