Migrando para o Kimi K3.1 Pro: corrija os erros 400, fique atento ao padrão max de esforço e não digite Highspeed errado

O Kimi K3.1 Pro já está disponível no Kimi Code, na API da Moonshot como kimi-k3.1-pro e no AIHubMix com o mesmo ID. A Moonshot aplica a ele as mesmas restrições de parâmetros do Kimi K3, então o código que já funciona no K3 deve funcionar com a troca do ID do modelo e uma nova sessão. O código escrito para o K2.x agora tem prazo para migrar na plataforma da Moonshot: a partir de 31 October 2026, a Moonshot deixará a série K2 indisponível para novos usuários registrados e planeja descontinuá-la até o fim de dezembro. Esse código também é o mais propenso a falhar, pois costuma enviar um valor de temperatura ou desativar o modo de raciocínio, e nenhum dos dois funciona no K3.1 Pro. E o código que nunca definiu um nível de esforço é executado no máximo, o que consome mais tokens do que você espera e, no Kimi Code, mais cota do que o K3 consumia.

Esta publicação lista o que falha de forma explícita (os erros 400 e um erro 404), o que falha silenciosamente (a conta, o cache e o ID Highspeed) e como configurar o Claude Code e o Codex para o K3.1 Pro pelo AIHubMix. As regras do K3.1 Pro vêm da documentação dos modelos do Kimi Code da Moonshot e de sua referência de parâmetros dos modelos, que atribui aos dois IDs do K3.1 Pro “as mesmas restrições de parâmetros que kimi-k3”. As regras identificadas como sendo do K3 vêm dos guias do K3 da Moonshot e não foram verificadas novamente no K3.1 Pro. Os textos dos erros foram extraídos da documentação, de relatos públicos, do teste do K3 realizado pelo AIHubMix em julho e das verificações do K3.1 Pro feitas pelo AIHubMix em 24 October 2026. Essas verificações abrangeram os IDs principais e os IDs do canal de programação coding-kimi-k3.1-pro e coding-kimi-k3.1-pro-highspeed. Cada afirmação indica sua origem.

Qual caminho você está usando?

Na API da Moonshot e no AIHubMix, os IDs são kimi-k3.1-pro e kimi-k3.1-pro-highspeed. No Kimi Code, são k3.1-pro e k3.1-pro-highspeed. Uma configuração de cliente vista em 21 de outubro mapeava k3 e kimi-for-coding para um modelo k3.1, mas a documentação atual do Kimi Code identifica k3 como K3 e kimi-for-coding como K2.8 Preview; portanto, selecione explicitamente o K3.1 Pro. Seu plano também é importante: no Kimi Code, o K3.1 Pro exige Plus ou superior (Pro para o contexto de 1M), e o Highspeed exige Pro ou superior. Nos planos antigos, é preciso ter Moderato ou superior, e Allegretto para o contexto de 1M e para o Highspeed.

As datas do K2 foram anunciadas pela Moonshot. A partir de 31 October 2026, os modelos da série K2 deixarão de estar disponíveis para novos usuários registrados, e todos devem ser descontinuados até o fim de dezembro de 2026. A Moonshot não anunciou uma data de descontinuação para o K3. Em 24 de outubro, o AIHubMix ainda listava K2.6 e K2.7 Code, sem data de descontinuação.

Falhas explícitas

Raciocínio desativado: HTTP 400 ou nenhuma saída de raciocínio

O que você verá: um HTTP 400 no Kimi Code. A documentação do Kimi Code da Moonshot diz que os modelos K3.1 Pro “só oferecem suporte ao modo de raciocínio. As solicitações com o raciocínio desativado são rejeitadas.” A documentação não cita o corpo do erro. Na API da Moonshot, o K3.1 Pro segue as restrições do K3, que sempre raciocina. Pelo AIHubMix, não há erro 400: em 24 de outubro, thinking: {"type": "disabled"} retornou 200 nos dois IDs principais, tanto pelo Chat Completions quanto pelo Messages, sem raciocínio na resposta. Nesse caso, a falha é silenciosa; portanto, verifique se as respostas estão sem raciocínio.

De onde vem: código para K2.x que desativava o raciocínio para responder mais rápido, por exemplo com extra_body={"thinking": {"type": "disabled"}}, e ferramentas que enviam um nível de esforço off, none ou disabled (próxima seção).

Correção: remova essa opção. Para manter o raciocínio curto, envie reasoning_effort: "low".

Um bloco "enabled" que sobrou é um caso diferente. Na verificação do AIHubMix em 24 de outubro, foi enviado ao K3.1 Pro o valor thinking: {"type": "enabled"}, usado no K2.x, e a resposta foi 200, tanto nos IDs principais quanto no canal de programação. A documentação da Moonshot classifica thinking como “um parâmetro de solicitação exclusivo do K2.x”, e um guia de solução de problemas de terceiros aponta um bloco residual como causa de erros 400 após a migração do K2.x para o K3; portanto, remova-o mesmo assim.

Se você mantiver o K2.7 Code como nível alternativo até a descontinuação, deixe o raciocínio ativado. O guia da Moonshot para Claude Code documenta o erro 400 invalid thinking: only type=enabled is allowed for this model para o K2.7 Code com o raciocínio desativado.

Valores de esforço: off, none e valores desconhecidos retornam 400

O que você verá: um HTTP 400 quando o esforço for off, none, disabled ou um valor que o Kimi Code não reconheça. O K3.1 Pro tem três níveis: low, high e max. A documentação do Kimi Code da Moonshot mapeia para eles os valores enviados por ferramentas de terceiros:

A API da Moonshot documenta apenas low, high e max para o K3.1 Pro, com max como padrão, e não descreve nenhum mapeamento. No AIHubMix, low, medium, high, max e xhigh retornaram 200 em todos os quatro IDs do K3.1 Pro em 24 de outubro. No kimi-k3.1-pro, off e um valor desconhecido também retornaram 200, com raciocínio, enquanto none retornou 200 sem raciocínio algum. No AIHubMix, esses casos falham silenciosamente, não com um erro 400.

A falha silenciosa: não há um nível médio. Uma ferramenta configurada como medium usa high, e uma configurada como xhigh usa max, o nível mais caro.

Correção: envie explicitamente low, high ou max e confira o que sua ferramenta realmente envia pela rede.

"temperatura inválida: apenas 1 é permitido para este modelo"

O que você verá: 400 invalid temperature: only 1 is allowed for this model. Na verificação do AIHubMix em 24 de outubro, esse erro foi retornado exatamente pelo kimi-k3.1-pro e pelo kimi-k3.1-pro-highspeed ao receberem temperature: 0.2. O mesmo texto havia sido relatado na API da Moonshot para o K3 em 3 de outubro de 2026 e no endpoint do Kimi Code para o k3 em 21 de outubro.

Por quê: a referência de parâmetros da Moonshot aplica ao K3.1 Pro as restrições do K3: temperature fixada em 1.0, top_p em 0.95, n em 1 e ambas as penalidades em 0; outros valores retornam um erro. O K2.6 também tinha um valor fixo: 0.6 com o raciocínio desativado. Por isso, o código que ainda envia 0.6 costuma ser o culpado.

A exceção que esconde o problema: o canal de programação do AIHubMix aceitou temperature: 0.2 na mesma verificação. O código testado somente nesse canal ainda pode falhar nos IDs principais ou na API da Moonshot.

A armadilha que esconde ainda mais o problema: muitas estruturas de desenvolvimento identificam os modelos Kimi pelo prefixo kimi- e removem o parâmetro temperature nesses casos. Os IDs do Kimi Code k3.1-pro e k3.1-pro-highspeed não têm esse prefixo, assim como os IDs do canal de programação do AIHubMix, que começam com coding-. Um problema no Hermes Agent encontrou exatamente isso no K3. O caminho principal de chat não enviava temperature, mas uma chamada auxiliar para k3 ainda enviava esse parâmetro e sempre recebia o erro 400.

Correção: não envie temperature, top_p, n, presence_penalty nem frequency_penalty. Identifique a família do modelo, não um prefixo no nome.

Para verificar uma rota, envie uma solicitação com temperature:

curl https://aihubmix.com/v1/chat/completions \
  -H "Authorization: Bearer $AIHUBMIX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "kimi-k3.1-pro", "temperature": 0.2, "messages": [{"role": "user", "content": "hi"}]}'

Em 24 de outubro, isso retornou o erro 400 acima. Execute o teste em cada ID de modelo usado pelo seu código: o canal de programação respondeu 200 à mesma solicitação.

Codex pelo AIHubMix: erro 404 na API Responses

O que você verá: um HTTP 404 com a mensagem The model kimi-k3.1-pro is not available on this endpoint. Na verificação do AIHubMix em 24 de outubro, o erro foi retornado pela API Responses para os dois IDs principais, enquanto o Chat Completions e o Messages responderam normalmente.

Correção: o Codex só funciona com a API Responses; por isso, use coding-kimi-k3.1-pro, que respondeu às solicitações da API Responses na mesma verificação. O AIHubMix classifica o canal de programação como uma versão de prévia para avaliação, não recomendada para produção, e algumas solicitações retornaram um erro 404 temporário, “The requested resource was not found”. Portanto, tente novamente uma vez antes de investigar o problema. Use esse canal até o AIHubMix adicionar suporte à API Responses para os IDs principais. O Claude Code usa o Messages e funciona com os IDs principais.

Limites de stop

O que você verá: o teste do K3 realizado pelo AIHubMix em julho retornou estas duas mensagens:

• Invalid request: stop array too long. Expected an array with maximum length 5, but got an array with length 6 instead
• Invalid request: stop sequence must not be longer than 32, but got 33 instead

Por quê: o K3 aceita no máximo cinco sequências stop, cada uma com até 32 bytes, e a API Messages aplica as mesmas verificações a stop_sequences. A Moonshot atribui ao K3.1 Pro as mesmas restrições de parâmetros; portanto, espere os mesmos limites.

Correção: reduza a lista. Observe que 32 bytes correspondem a menos de 32 caracteres em chinês ou japonês.

Codex na API da Moonshot: “web_search.search_context_size is not supported” (guia do K3)

O que você verá: 400 web_search.search_context_size is not supported, citado no guia do Codex da Moonshot, escrito para o K3. Pelo canal de programação do AIHubMix, uma solicitação à API Responses com esse campo retornou 200 em 24 de outubro; portanto, esse erro vem do próprio endpoint da Moonshot.

Correção: remova search_context_size da configuração ou da definição da ferramenta do Codex. O Codex não o envia por padrão.

Falhas silenciosas

Esses casos não retornam erros. Eles aparecem depois, na conta, na cota do seu plano ou na qualidade da saída.

Esforço e sessões

• O padrão é max, e isso é uma novidade no Kimi Code. O padrão do K3.1 Pro é max. No Kimi Code, o padrão do K3 era high; assim, uma sessão que nunca define um nível de esforço agora raciocina mais, usa mais tokens e consome a cota mais rapidamente. Na API da Moonshot, tanto o K3 quanto o K3.1 Pro têm max como padrão. O raciocínio é cobrado como saída: no teste de criação de um jogo com um único prompt no K3, realizado pelo AIHubMix em julho, 73% dos 74,994 tokens de conclusão foram usados para raciocínio.
• Um nível baixo ainda pode significar milhares de tokens de raciocínio. Em uma verificação pontual no AIHubMix, em 24 de outubro, um prompt que pedia uma explicação de 600 palavras fez o K3.1 Pro raciocinar por 5,561 a 7,356 tokens em low antes de responder, e uma execução atingiu o limite de 8,192 tokens. O K3 raciocinou por 3,013 a 7,051 tokens no mesmo prompt, então isso não é novidade no K3.1 Pro, mas low não é um modo barato em nenhum dos dois; deixe max_completion_tokens generoso. Foi um único prompt e três execuções por modelo nos IDs principais do AIHubMix, então faça medições com sua própria carga de trabalho.
• Mudar para o K3.1 Pro dentro de uma sessão antiga reduz a qualidade. A documentação do Kimi Code da Moonshot desaconselha mudar para os novos modelos “dentro de uma sessão existente da série K3, do K2.8 Preview ou do K2.7 Code Highspeed”: isso degrada a qualidade das respostas e reduz os acertos de cache. Inicie uma nova sessão.
• Mudar o modelo ou o nível de esforço invalida o cache. A documentação do Kimi Code da Moonshot diz isso sobre ambos, e a documentação do K3 dizia que mudar o nível de esforço “invalida os acertos do cache de prefixo”. Escolha o modelo e o nível no início da sessão.

Highspeed

• Digitar errado um ID Highspeed faz você usar um modelo mais lento. No Kimi Code, um ID Highspeed incorreto “volta silenciosamente para o K2.8 Preview, sem raciocínio — nenhum ganho de velocidade”. Copie o ID exatamente e confira qual modelo aparece nos seus logs.
• O Highspeed só acelera a geração de saída do modelo. A Moonshot estima o K3.1 Pro Highspeed em cerca de 2–3× a velocidade do K3.1 Pro, com recursos idênticos. Na verificação pontual do AIHubMix, a geração de saída foi cerca de 1.6–1.8× mais rápida que a do Pro. Chamadas de ferramentas e scripts não ficam mais rápidos, então o ganho é pequeno em uma rodada dominada pela leitura de arquivos e execução de testes, enquanto os planos do Kimi Code contam cerca de duas vezes mais para a cota.

Protocolos

• Os proxies podem alterar o comportamento. A documentação do Kimi Code da Moonshot alerta: “A tradução de protocolo por ferramentas de proxy pode fazer o comportamento do modelo variar.” Use em cada ferramenta o protocolo que ela entende: Messages para o Claude Code e Responses para o Codex. Em 24 de outubro, o AIHubMix respondeu a Chat Completions e Messages nos quatro IDs do K3.1 Pro, incluindo o raciocínio como reasoning_content e em blocos thinking. Responses funcionou no canal de programação, com um item reasoning, e retornou o erro 404 mencionado acima nos IDs principais.
• A saída estruturada na API Messages melhorou. No teste de julho do AIHubMix com o K3, /v1/messages ignorou um esquema e retornou texto livre. Em 24 de outubro, uma solicitação semelhante ao K3.1 Pro, com um esquema JSON em output_config.format e um prompt que não pedia JSON, retornou {"city":"Paris"} nos quatro IDs. Esse esquema tem um único campo, então valide a saída antes de passar JSON de volta para Messages. A outra peculiaridade de Messages observada em julho — um acionamento da sequência de parada retornado como end_turn com stop_sequence: null — não foi testada novamente.

Solicitações longas

• Timeouts curtos falham até mesmo com solicitações moderadas. Na verificação pontual, as respostas completas do K3.1 Pro em low levaram de 80 a 99 segundos. Um cliente sem streaming com timeout de 60 segundos teria falhado em todas as execuções, e uma nova tentativa pagaria novamente pelo mesmo raciocínio. Na API da Moonshot, o limite de saída padrão do K3.1 Pro é de 131,072 tokens, podendo chegar a 1,048,576, e uma compilação de jogo do AIHubMix em julho, usando K3, levou 2,541 segundos em uma única solicitação. Use streaming e configure timeouts em minutos.

Recomendações herdadas dos guias do K3

Estas recomendações vêm dos guias do K3:

• Descartar reasoning_content degrada a qualidade em várias rodadas. A mensagem completa do assistente, incluindo reasoning_content e tool_calls, precisa ser enviada de volta sem alterações. O código que mantém apenas content continua funcionando, mas a Moonshot alerta que a qualidade das respostas pode ficar instável.
• As ferramentas dinâmicas desaparecem se você descartar a mensagem delas. O K3 permite carregar ferramentas no meio da conversa por meio de uma mensagem de sistema sem conteúdo. O servidor não a mantém, então ela precisa ser reenviada em cada solicitação. No AIHubMix, isso funciona com Chat Completions: em 24 de outubro, kimi-k3.1-pro chamou uma ferramenta injetada dessa forma. No teste do K3 feito pelo AIHubMix em julho, a API Messages ignorou uma ferramenta injetada.

Regras de cobrança fáceis de deixar passar

Os preços abaixo são do AIHubMix, extraídos das páginas dos modelos, por milhão de tokens:

No AIHubMix, o K3.1 Pro custa 30% menos que o K3 para entrada e entrada em cache, e 26% menos para saída. O Highspeed custa o dobro do Pro para entrada e saída, com a mesma tarifa para cache. O ID do canal de programação tem preços separados: $0.88 para entrada, $3.23 para saída e $0.132 para entrada em cache.

Uma tarifa menor não garante uma conta menor. Considere a compilação de jogo com um único prompt feita pelo AIHubMix em julho usando o K3: 74,994 tokens de saída, supondo 5,000 tokens de entrada. Com as mesmas contagens de tokens, o custo é de cerca de $1.08 no K3, cerca de $0.80 no K3.1 Pro (5,000 × $2.00 + 74,994 × $10.50, por milhão) e cerca de $1.59 no Highspeed. A contagem de tokens varia conforme o prompt (na verificação pontual, o K3.1 Pro e o K3 ficaram na mesma faixa em low), então faça medições antes de definir o orçamento.

A documentação da API da Moonshot cobra as gravações no cache do K3.1 Pro por TTL, de 5 minutos ou 1 hora, como no K3. As tarifas publicadas para o K3, no guia de cache de contexto da Moonshot, mostram como a estrutura funciona:

A Moonshot diz que separar as gravações em cache não aumentou o custo total do K3: o custo da gravação já fazia parte do preço de entrada, então as solicitações com o TTL padrão de 5 minutos custam o mesmo que antes.

Estas são as tarifas diretas da Moonshot. As páginas de modelos do AIHubMix listam apenas os preços de entrada, saída e entrada em cache, sem uma tarifa separada para gravação em cache, e não informam como é cobrada uma gravação com TTL de 1 hora. O AIHubMix repassa o TTL: em 24 de outubro, uma solicitação Messages com um TTL cache_control em 1h no nível superior informou a gravação como tokens de cache de 1 hora, e uma solicitação Chat Completions com prompt_cache_options foi aceita.

• O cache é automático. No K3, o TTL padrão é de 5 minutos. Nas verificações do AIHubMix em 24 de outubro, um prompt repetido de 93 tokens voltou totalmente em cache no canal de programação, mas não nos IDs principais. Com um prompt de 7,658 tokens, a segunda chamada para kimi-k3.1-pro voltou com 7,424 tokens em cache, tanto com Chat Completions quanto com Messages.
• O TTL de 1 hora, na API da Moonshot, custa $3.00 a mais por milhão de tokens para gravação, com as tarifas do K3. Cada acerto economiza $2.70, então, segundo os próprios cálculos da Moonshot, compensa a partir do segundo acerto.
• O TTL fica definido na primeira gravação (K3). Não é possível aumentar o TTL de uma entrada de 5 minutos para 1 hora. É preciso esperar que ela expire primeiro.
• Os painéis de custos precisam de um novo campo (K3). As gravações em cache aparecem como prompt_tokens_details.cache_write_tokens em Chat Completions, input_tokens_details.cache_write_tokens em Responses e cache_creation_input_tokens em Messages.
• O raciocínio é contabilizado como saída. No K3, os tokens de raciocínio são cobrados pela tarifa de saída em todos os níveis de esforço. O AIHubMix não lista um preço separado para raciocínio no K3.1 Pro.

Medidas para reduzir a conta:

1. Defina reasoning_effort conforme a carga de trabalho, em vez de herdar max. Experimente low para consultas e classificação, e high para tarefas rotineiras de programação.
2. Mantenha o modelo e o nível de esforço fixos durante cada sessão e inicie uma nova sessão quando mudar qualquer um deles.
3. Coloque primeiro as partes estáveis: prompt de sistema, definições de ferramentas e contexto do repositório. Em seguida, a rodada variável.
4. Use o Highspeed quando a geração de saída do modelo for o gargalo, não em ciclos dominados por chamadas de ferramentas.
5. Monitore a proporção de raciocínio nos tokens de conclusão. Se continuar acima da metade em tarefas simples, reduza o nível de esforço.

Agentes com permissões reais

O problema no Hermes Agent mostra como um bug de migração pode se tornar uma falha de segurança. O classificador de “aprovação inteligente” chamava k3 com uma temperatura, e todas as chamadas retornavam 400. Nas palavras de quem relatou o problema, o classificador “escalona (falha aberta) em todas as chamadas”: a verificação de segurança deixou de cumprir sua função, sem que nada parecesse errado na conversa principal.

O K3.1 Pro mantém esse gatilho e acrescenta outro. As chamadas de classificação são justamente aquelas que as equipes tentam tornar rápidas e baratas definindo uma temperatura baixa ou desativando o raciocínio, e no K3.1 Pro nenhuma dessas opções funciona: uma temperatura pode retornar 400 em todas as chamadas e, no AIHubMix, uma solicitação com o raciocínio desativado voltou sem raciocínio. Se uma verificação de segurança usar o K3.1 Pro, use reasoning_effort: "low" para ganhar velocidade, decida como lidar com um erro da API e faça o sistema falhar de forma segura.

Alguns outros pontos são importantes para agentes que atuam por conta própria:

• Chamadas forçadas de ferramentas funcionam. O K3.1 Pro oferece suporte a tool_choice: "required", que o K2.x rejeitava, então é possível eliminar uma solução alternativa do K2.x para forçar uma chamada de ferramenta.
• A busca na Web integrada ainda não está pronta para produção (K3). O guia do K3 da Moonshot diz que a busca na Web “está sendo atualizada e não é recomendada para fluxos de trabalho de produção no futuro próximo”. Trate-a da mesma forma no K3.1 Pro até que a Moonshot informe o contrário. Pelo AIHubMix, um ciclo de busca com o K3.1 Pro não foi concluído em 24 de outubro: o modelo solicitou $web_search, e enviar o resultado de volta retornou 400 Invalid request: tokenization failed.
• As imagens de entrada precisam estar em base64. O K3 não busca imagens em URLs públicas e, em 24 de outubro, o kimi-k3.1-pro no AIHubMix rejeitou uma delas com 400 Invalid request: unsupported image url, então um agente que passe links para capturas de tela recebe um erro. A outra opção da Moonshot, um ID de arquivo obtido por upload no próprio serviço, não é disponibilizada pelo AIHubMix: uma referência ms:// retornou 404. Uma imagem em base64 funcionou. O K3.1 Pro também aceita entrada de vídeo no Kimi Code.

Ferramentas de programação: Claude Code e Codex

O Claude Code usa a API Anthropic Messages, à qual os IDs principais do AIHubMix responderam em 24 de outubro. O Codex usa a API Responses, à qual apenas o canal de programação respondeu. Os guias permanentes do AIHubMix cobrem a instalação e a configuração básica. Abaixo está apenas o que muda no K3.1 Pro.

A coluna Codex usa o ID do canal de programação até que os IDs principais respondam na Responses API. Qualquer valor de effort enviado por uma ferramenta além desses três é mapeado conforme a tabela de effort acima.

Claude Code

Siga o guia do settings.json do Claude Code. Em seguida, defina todos os níveis de modelo, não apenas o principal:

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://aihubmix.com",
    "ANTHROPIC_AUTH_TOKEN": "sk-your-aihubmix-key",
    "ANTHROPIC_MODEL": "kimi-k3.1-pro",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "kimi-k3.1-pro",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "kimi-k3.1-pro",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "kimi-k3.1-pro",
    "ANTHROPIC_DEFAULT_FABLE_MODEL": "kimi-k3.1-pro",
    "CLAUDE_CODE_SUBAGENT_MODEL": "kimi-k3.1-pro"
  }
}

Problemas conhecidos, de acordo com a documentação do Kimi Code da Moonshot, o guia do Claude Code (escrito para o K3) e os testes da AIHubMix:

• Inicie uma nova sessão. Não mude uma sessão K3 em andamento para K3.1 Pro. Abra uma nova para que o cache e a qualidade das respostas comecem do zero.
• Níveis não configurados falham silenciosamente. O Claude Code usa níveis diferentes para o chat principal, os resumos e os subagentes. A Moonshot alerta que configurar apenas alguns faz com que os demais "falhem silenciosamente". Você pode apontar o nível Haiku para um modelo mais barato para tarefas em segundo plano.
• Configurações antigas prevalecem. Valores antigos no bloco env de ~/.claude/settings.json substituem as variáveis exportadas no shell.
• Contexto de 1M. O guia do K3 da Moonshot usa kimi-k3[1m] para que o Claude Code trate a janela como 1M. kimi-k3.1-pro[1m] funciona da mesma forma pela AIHubMix: o Claude Code remove o sufixo antes de enviar, e a AIHubMix respondeu à solicitação resultante, incluindo o cabeçalho de contexto de 1M, em 24 de outubro. Só o Claude Code entende o sufixo. Enviado como ID de modelo por qualquer outro cliente, kimi-k3.1-pro[1m] retorna um 400.
• Effort. O K3.1 Pro já usa max por padrão, o nível que o guia do K3 da Moonshot recomendava com CLAUDE_CODE_EFFORT_LEVEL=max. Para tarefas rotineiras, high consome menos tokens. Seja qual for o nível enviado pelo Claude Code, ele é mapeado conforme a tabela de effort, e a AIHubMix aceitou os cinco valores testados.
• Níveis Highspeed. Se você apontar um nível para kimi-k3.1-pro-highspeed, copie o ID exatamente. No Kimi Code, um erro de digitação faz o sistema voltar silenciosamente ao modelo padrão; na AIHubMix, um ID digitado incorretamente retorna um 400.

Codex

O Codex só aceita a Responses API, então wire_api = "responses" é obrigatório. O guia do config.toml do Codex explica o restante. Para K3.1 Pro:

# At launch (24 October 2026), the main ID kimi-k3.1-pro returned 404 on the Responses API.
# Use the coding-channel ID until AIHubMix adds it. AIHubMix labels the
# coding channel an evaluation preview, not for production.
model = "coding-kimi-k3.1-pro"
model_provider = "aihubmix"
model_context_window = 1048576
model_reasoning_effort = "high"

[model_providers.aihubmix]
name = "AIHubMix"
base_url = "https://aihubmix.com/v1"
env_key = "AIHUBMIX_API_KEY"
wire_api = "responses"

• Declare a janela de contexto. Sem model_context_window, o Codex recorre aos metadados padrão de um modelo que não conhece. O guia do Codex da Moonshot, escrito para o K3, diz que o aviso resultante Model metadata for kimi-k3 not found é esperado e inofensivo.
• Effort. Os níveis próprios do Codex incluem medium e xhigh. De acordo com o mapeamento do Kimi Code, eles são executados como high e max, e a AIHubMix aceitou ambos em 24 de outubro. Defina low, high ou max para saber qual nível está pagando.
• Os canais são diferentes. O canal de programação aceitou uma temperatura que os IDs principais rejeitaram. Quando os IDs principais começarem a responder na Responses, execute o teste rápido novamente antes de migrar.
• Sem search_context_size. Se sua configuração o definir, remova-o (consulte as falhas explícitas).
• Reinicie após editar. O Codex lê o config.toml apenas na inicialização. Se o CC Switch gerenciar sua configuração do Codex, ele poderá sobrescrever suas alterações.

Um teste rápido de 15 minutos

Execute-o uma vez em cada ferramenta, em um repositório pequeno com uma suíte de testes:

1. Inicie uma sessão nova no K3.1 Pro. Não continue uma sessão que tenha sido executada no K3 ou em outro modelo.
2. Peça: "Adicione um teste unitário para uma função deste repositório, execute os testes e corrija o que falhar."
3. O sucesso se parece com isto: o modelo lê arquivos e executa os testes (as chamadas de ferramentas funcionam). Ele continua após ver os resultados, o que mostra que o raciocínio e os resultados das ferramentas estão sendo enviados de volta. Termina com os testes aprovados, sem nenhum 400 ou 404 na sessão.
4. No registro de uso da AIHubMix, confira se o ID do modelo é o que você definiu e se as solicitações seguintes mostram tokens de entrada em cache para o prefixo estável. Se isso nunca acontecer, algo no seu prefixo muda a cada turno.
5. Anote o tempo por turno e os tokens de conclusão. Eles são sua referência para escolher um nível de effort e avaliar se o Highspeed vale a pena.

Lista de verificação da migração

• Use o ID do K3.1 Pro: kimi-k3.1-pro na API da Moonshot e na AIHubMix, k3.1-pro no Kimi Code; para o Codex via AIHubMix, por enquanto, coding-kimi-k3.1-pro.
• Migre o código do K2.x antes que a Moonshot encerre a série K2 no fim de dezembro de 2026; novas contas da Moonshot perderão o acesso ao K2 a partir de 31 de outubro.
• Inicie uma nova sessão para o K3.1 Pro em vez de mudar uma sessão antiga.
• Remova temperature, top_p, n e ambas as penalidades de todos os caminhos de chamada, inclusive das chamadas auxiliares.
• Remova todos os controles para desativar o thinking, inclusive os valores de effort off, none e disabled, e exclua os blocos de thinking do K2.x que sobraram.
• Envie effort como low, high ou max; medium é executado como high, e xhigh como max.
• Mantenha o modelo e o effort fixos durante toda a sessão.
• Copie exatamente o ID do Highspeed e confira o modelo no registro de uso.
• Limite as listas de stop a cinco entradas de 32 bytes ou menos.
• Envie de volta a mensagem completa do assistente, incluindo reasoning_content e tool_calls, e reenvie as mensagens dinâmicas das ferramentas.
• Transmita solicitações longas em streaming e defina tempos limite em minutos.
• Valide a saída estruturada antes de transferir o JSON de volta para a Messages API.
• Atualize o acompanhamento de custos para incluir o campo separado de gravação em cache.
• Configure as verificações de segurança para falharem de forma segura em caso de erros da API.
• Execute o teste rápido em cada ferramenta de programação.

Perguntas frequentes

Por que o K3.1 Pro retorna HTTP 400?
As causas mais comuns são uma temperatura diferente de 1, o thinking desativado ou um valor de effort igual a off, none, disabled ou desconhecido. A primeira decorre das regras de amostragem fixas do K3, mantidas pelo K3.1 Pro; as demais estão documentadas na documentação do Kimi Code da Moonshot. Nos IDs principais da AIHubMix, apenas a temperatura retornou um 400 em 24 de outubro; os demais retornaram 200, e as opções thinking off ou none vieram sem raciocínio.

Posso desativar o thinking?
Não. O K3.1 Pro só funciona no modo thinking. Defina reasoning_effort como low para manter o thinking curto.

A temperatura ainda é rejeitada?
Sim, na API da Moonshot e nos IDs principais da AIHubMix, que retornaram "invalid temperature: only 1 is allowed for this model" em 24 de outubro de 2026. O canal de programação da AIHubMix aceitou uma temperatura de 0.2 no mesmo teste. Não inclua temperature em nenhuma rota.

Quando os modelos K2 deixarão de estar disponíveis?
A partir de 31 de outubro de 2026, usuários recém-registrados na Moonshot não poderão usar os modelos da série K2, e a Moonshot planeja descontinuar todos eles até o fim de dezembro de 2026. Em 24 de outubro, a AIHubMix ainda listava K2.6 e K2.7 Code, sem data de descontinuação.

Por que minha cota do Kimi Code está acabando mais rápido?
O K3.1 Pro usa max effort por padrão, enquanto o K3 usava high no Kimi Code; além disso, o Highspeed consome cerca de duas vezes a cota do modelo normal. Defina um nível de effort mais baixo para tarefas rotineiras e mantenha-o fixo durante toda a sessão.

Por que o Highspeed não está mais rápido?
Talvez o ID tenha sido digitado incorretamente, caso em que o Kimi Code volta silenciosamente para o K2.8 Preview sem thinking, ou talvez as chamadas de ferramentas dominem o turno. O Highspeed só acelera a geração do modelo.

Qual ID de modelo da AIHubMix o Codex deve usar?
Por enquanto, coding-kimi-k3.1-pro, na Responses API em aihubmix.com/v1, com wire_api definido como responses. Em 24 de outubro, os IDs principais retornaram 404 na Responses API. A AIHubMix classifica o canal de programação como uma prévia de avaliação, não destinada à produção.

Continue lendo: a série Kimi K3.1 Pro

• Antes de migrar, veja se a atualização realmente vale a pena, desde o que mudou até quanto custa uma tarefa real: Kimi K3.1 Pro vs K3: o que mudou, quanto custa e quem deve migrar
• Se a migração está fazendo você considerar alternativas, veja aqui o K3.1 Pro comparado ao Qwen 4 e ao Claude Fable 5.5, incluindo o custo de uma construção de front-end em cada um: Kimi K3.1 Pro vs Qwen 4 vs Claude Fable 5.5: qualidade de front-end, custo por tarefa e uma análise sem exageros
• Se a cota e o preço do Highspeed fazem você questionar se a variante rápida compensa, a questão da velocidade versus preço ganha um artigo próprio: Kimi K3.1 Pro vs K3.1 Pro Highspeed: vale a pena pagar 2× o preço por 2–3× mais velocidade?

Fontes

• Kimi Code: configuração de modelos
• Moonshot AI: referência de parâmetros de modelo
• AIHubMix: página do modelo Kimi K3.1 Pro
• AIHubMix: guia prático do Kimi K3
• Problema #142365 do Hermes Agent: divergência no perfil do endpoint do Kimi Code