Kimi K3.1 Pro

Use o ID público do modelo kimi-k3.1-pro. A página do modelo oferece o Playground e os preços atuais. Baixe a especificação OpenAPI para obter os esquemas aninhados completos de requisição e resposta.

Início rápido

curl https://api.seedrouter.ai/v1/chat/completions \
  -H "Authorization: Bearer $SEEDROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model":"kimi-k3.1-pro",
    "messages":[{"role":"user","content":"How can an idempotency key prevent a duplicate payment?"}],
    "max_completion_tokens":2048,
    "reasoning_effort":"low"
  }'

Formatos nativos

Use Authorization: Bearer $SEEDROUTER_API_KEY. Messages também usa anthropic-version: 2023-06-01. Cada formato retorna JSON nativo ou eventos SSE. Responses não mantém estado: reenvie o histórico completo; previous_response_id não é um campo de requisição compatível.

Parâmetros da requisição

Campos vazios do Playground são omitidos. Valores explícitos false e zero são preservados quando válidos. Omitido não significa que aceita null. Extensões desconhecidas de nível superior são descartadas; campos oficiais inválidos são rejeitados. Os esquemas aninhados de ferramentas e o histórico retornado permanecem intactos.

Chat Completions

Responses

Messages

Chat tem 22 campos de nível superior: model, cinco campos fixos de amostragem e 16 entradas variáveis. Responses tem model e 12 entradas; Messages tem model e 10 entradas. O Playground oculta o modelo fixo e os controles fixos de amostragem.

Raciocínio e limites de saída

O raciocínio está sempre ativo. Chat reasoning_effort, Responses reasoning.effort e Messages output_config.effort aceitam low, high ou max; o padrão é max. Todos os limites de saída incluem raciocínio. Chat e Responses usam 131.072 tokens de saída por padrão, com máximo de 1.048.576. Messages exige max_tokens positivo. Chat aceita o campo obsoleto max_tokens; prefira max_completion_tokens nas novas integrações.

A janela de contexto é de 1.048.576 tokens. A própria entrada precisa caber nela. Quando a entrada mais o orçamento de geração excede a janela, o serviço pode reduzir o orçamento ao espaço restante. Um limite pequeno de saída pode encerrar a geração antes de aparecer qualquer resposta visível.

A amostragem do Chat é fixa: temperature:1, top_p:0.95, n:1, frequency_penalty:0, presence_penalty:0. Outros valores são inválidos. Sequências de parada correspondem ao texto exato e são excluídas da resposta. O limite de 32 bytes conta bytes UTF-8, não caracteres.

Saída estruturada e previsões

Chat aceita response_format.type como text, json_object ou json_schema. O modo JSON também precisa de um prompt que peça JSON. JSON Schema exige json_schema.name e json_schema.schema; strict é true por padrão.

Responses usa text.format com type:json_schema, schema e os opcionais name e strict. Messages usa output_config.format com type:json_schema e schema. Siga o Moonshot Flavored JSON Schema; não suponha que toda extensão geral do JSON Schema seja aplicada. Valide a saída concluída no aplicativo.

A saída prevista do Chat usa prediction:{type:"content",content:...}. O conteúdo é uma string ou partes apenas de texto. Use em saídas majoritariamente conhecidas, como um arquivo que recebe uma pequena edição.

Ferramentas e histórico preservado da conversa

As ferramentas do Chat usam type:function com function.name e function.parameters. Os campos opcionais incluem description e strict (true por padrão). Os nomes correspondem a ^[a-zA-Z_][a-zA-Z0-9-_]{0,127}$. A escolha de ferramenta aceita auto, none e required; required precisa de pelo menos uma ferramenta disponível. Forçar uma função nomeada entra em conflito com o raciocínio sempre ativo.

Uma mensagem dinâmica de ferramentas do Chat é {role:"system",tools:[...]} sem content. Mantenha essas mensagens na conversa. Acrescente a resposta completa do assistente, incluindo reasoning_content e tool_calls, e retorne cada resultado de ferramenta como mensagem role:tool com o tool_call_id correspondente. Respostas do assistente com ferramentas podem ter content null. Outros papéis de mensagem continuam exigindo content.

Responses aceita definições nativas de ferramentas function, namespace, apply_patch personalizada e web_search com tool_choice:"auto". Retorne itens function_call_output ou custom_tool_call_output com os IDs de chamada correspondentes. Os valores de include web_search_call.results e web_search_call.action.sources afetam apenas a saída de busca na web.

Messages aceita definições nativas de ferramentas e objetos de escolha com type auto, any ou none. Preserve os blocos de raciocínio do assistente e suas assinaturas. Retorne blocos de resultados de ferramentas dentro das mensagens do usuário. Seu aplicativo valida argumentos, executa funções personalizadas e controla ações externas.

O Chat Partial Mode define partial:true apenas na mensagem final do assistente. Messages continua diretamente uma mensagem final do assistente. Não reconstrua o histórico somente a partir do texto visível da resposta.

Restrições de mídia

Chat aceita blocos de conteúdo text, image_url e video_url. Use data URLs em base64 ou referências ms:// aceitas; URLs públicas arbitrárias de mídia não são compatíveis. Formatos de imagem: JPEG, PNG, GIF, WebP, BMP, HEIC e HEIF. Formatos de vídeo: MP4, MPEG, MOV, AVI, FLV, MPG, WebM, WMV e 3GPP. O guia oficial especifica um limite total de 100M para o corpo da requisição, sem limite separado de quantidade de imagens. Imagens 4K e vídeos Full HD são recomendações, não limites obrigatórios.

Responses usa input_image.image_url com uma data URL. Messages usa uma fonte de imagem como {type:"base64",media_type:"image/png",data:"..."}, ou type url com uma referência ms:// aceita. Os tipos de imagem inline de Messages são JPEG, PNG, GIF e WebP. Esses formatos não herdam implicitamente o bloco de vídeo do Chat; use seus esquemas específicos.

O Playground anexa imagens inline. Use campos nativos de conversa ou o editor JSON para blocos de vídeo e referências de arquivos. Upload e gerenciamento de arquivos ficam fora destes endpoints de geração. Um ID de arquivo criado com outra conta não é necessariamente utilizável.

Cache e uso

Chat e Responses usam prompt_cache_key e prompt_cache_options:{mode:"implicit",ttl:"5m"}. TTL aceita 5m ou 1h, com padrão de 5 minutos. Messages usa cache_control:{type:"ephemeral",ttl:"5m"} no nível superior e metadata.user_id opcional. Marcadores aninhados de cache-control em Messages são ignorados. prompt_cache_breakpoint no nível do conteúdo é inválido.

Um prefixo já em cache mantém o TTL original quando atualizado. Solicitar outra duração não comprova que ela foi aplicada. Os cabeçalhos oficiais de escrita no cache do Chat informam as contagens reais de 5 minutos e 1 hora. Responses pode retornar o prompt_cache_options aplicado; Messages informa os dois contadores de TTL em usage.cache_creation.

Os totais de entrada de Chat e Responses já incluem leituras e escritas no cache. Essas categorias e o restante sem cache são disjuntos; não some os tokens de cache duas vezes. A saída inclui raciocínio. Messages separa escritas em ephemeral_5m_input_tokens e ephemeral_1h_input_tokens. Veja as taxas atuais; respostas públicas de geração não contêm cobranças monetárias.

Streaming e conclusão

Defina stream:true. Chat emite blocos de dados e [DONE]; stream_options.include_usage:true solicita o bloco final de uso. Responses usa eventos nomeados como response.output_text.delta, response.completed e response.incomplete. Messages usa message_start, eventos de blocos de conteúdo, message_delta e message_stop.

Uma conexão fechada, por si só, não comprova a conclusão. Confira os motivos nativos de término e o status terminal. Um stream interrompido pode não trazer o uso final. Parar o leitor não garante o cancelamento da geração.

Referências oficiais

Verificado em 25 de outubro de 2026: guia do Kimi K3.1 Pro, Chat, Responses, Messages, visão e cache.