Kimi K3: o que é e por que custa o mesmo que o Claude Sonnet 5

Por LW Forge — mantenedora do LLM Scout · Atualizado em 17 de agosto de 2026

Modelo de pesos abertos deveria ser a opção barata. O Kimi K3 não é. A Moonshot AI lançou o modelo em 16 de julho de 2026 como o primeiro aberto a chegar a 2,8 trilhões de parâmetros e colocou a API hospedada a US$ 3,00 por milhão de tokens de entrada e US$ 15,00 por milhão de saída — a tarifa de tabela do Claude Sonnet 5, ao centavo. Essa coincidência é a história inteira: o K3 não disputa preço com o resto do campo aberto, disputa capacidade com os modelos fechados de fronteira — e cobra por isso.

As tarifas, em 4 de agosto de 2026

Repare que até a tarifa de cache bate com a do Sonnet — US$ 0,30, exatos 90% de desconto sobre a entrada, a mesma estrutura que a Anthropic usa. E, diferente do Gemini, o K3 cobra a mesma tarifa em toda a janela de um milhão de tokens; não há sobretaxa de contexto longo esperando na marca dos 200 mil.

O que a diferença de preço compra

A mesma carga usada no post irmão desta dupla: 300 milhões de tokens de entrada e 40 milhões de saída por mês, mais ou menos um assistente agêntico de porte médio.

Três coisas saltam dessa tabela. Contra o Opus 4.8, o K3 economiza US$ 1.000 por mês — 40%, número relevante se o K3 passar na sua barra de qualidade. Contra o Sonnet 5 de tabela, a economia é exatamente zero: não existe argumento de custo, só argumento de capacidade e portabilidade. E, até 31 de agosto de 2026, a promoção de lançamento do Sonnet 5 a US$ 2/US$ 10 deixa o cavalo de batalha da Anthropic mais barato que o modelo aberto — US$ 1.000 contra US$ 1.500 do K3. Precifique os seus volumes na calculadora de custos do Claude lembrando que a promoção acaba e a carga de trabalho não.

A janela de 1M vale o que cobra?

O Claude para em 200 mil tokens; o K3 aceita 1 milhão. O instinto diz que isso economiza dinheiro em documento longo. Na maior parte das vezes não economiza, e vale entender por quê.

Suponha que você precise raciocinar sobre um corpus de 900 mil tokens. No K3 é uma chamada só: 900 mil × US$ 3/M = US$ 2,70 de entrada. No Claude você fatia — cinco passadas de 180 mil, cada uma carregando o mesmo prefixo de 30 mil tokens com instrução e schema. São 900 mil de documento mais 150 mil de prefixo repetido, e depois uma passada de redução sobre os cinco resumos. Dá cerca de 1,06 milhão de tokens de entrada, algo como US$ 3,20 no Sonnet. A versão de chamada única sai mais barata, mas em 15%, não em uma ordem de grandeza — e o cache de prompt sobre o prefixo repetido apaga quase toda essa diferença.

O argumento real da janela de 1M não é a fatura, é o que a versão fatiada não consegue fazer: perceber que uma cláusula da página 40 contradiz uma tabela da página 380. Map-reduce perde referência cruzada por construção, e nenhuma engenharia de prompt devolve isso. Se a sua tarefa realmente exige raciocínio sobre o corpus inteiro, a janela vale o preço; se é "resuma cada seção", não vale. Meça o que os seus documentos ocupam de fato na calculadora de janela de contexto antes de supor que precisa do espaço extra — a maioria das cargas que parecem enormes fica abaixo de 200 mil.

Onde o K3 justifica o premium — e onde não justifica

O argumento honesto a favor do K3 sobre o Sonnet 5, ao mesmo preço, é portabilidade. Os pesos são públicos sob licença MIT modificada, então a API hospedada é conveniência, não dependência. Dá para trocar de host, rodar inferência própria numa carga que não pode sair da sua infraestrutura ou continuar servindo uma versão congelada depois que o fornecedor a descontinuar. Nada disso está disponível no Claude a preço nenhum. Se o que trava o seu projeto é cláusula de residência de dados ou análise de risco de fornecedor, isso vale zero de diferença de preço e muito trabalho destravado.

O argumento contra é o imposto habitual dos pesos abertos: maturidade de SDK, casos de borda em saída estruturada, integração com observabilidade e o fato de que, em agregador, o host que atende a sua requisição pode rodar uma quantização diferente da que você testou. A API hospedada da Moonshot também opera sob jurisdição chinesa — questão de governança que os pesos abertos só resolvem se você realmente rodar por conta própria.

Contra o Opus 4.8 a conta muda: você paga 40% menos por um modelo que troca o raciocínio de ponta do Opus por uma janela 5× maior e por pesos abertos. Se é bom negócio depende de com que frequência o seu tráfego cai nos 10% de tarefas mais difíceis, onde o modelo de fronteira ainda vence comparações mensuráveis. Opus vs Sonnet vs Haiku mostra como classificar esse tráfego, e a lógica de roteamento de Sonnet 5 vs Haiku 4.5 vale aqui também: rode o tier barato primeiro e escale só o que falhar numa autoverificação.

Como decidir em uma tarde

Separe 200 requisições reais. Rode no K3, no Sonnet 5 e no Opus 4.8 com instruções e limites de saída idênticos. Pontue a correção do jeito que você já pontua e calcule o custo por tarefa bem-sucedida, cobrando as tentativas repetidas do modelo que as causou. Se o K3 empatar com o Sonnet, o fator decisivo é portabilidade, não preço — e essa escolha merece ser deliberada, não por inércia. Se o K3 empatar com o Opus, você achou seus US$ 1.000 por mês.

Duas alavancas antes de concluir qualquer coisa: cacheie o prefixo estável a 10% da entrada nos três modelos (cache de prompt) e verifique se o raciocínio sempre ligado do K3 está inflando a sua contagem de tokens de saída, já que saída custa 5× a entrada em todos os modelos desta tabela. Se US$ 3/US$ 15 for mais do que a sua tarefa precisa, o GLM-5.2 a US$ 1,40/US$ 4,40 é a mesma aposta em pesos abertos por menos da metade do preço.