---

@CanalQb no YouTube

---

Configure Ornith-1 no Kimi Code CLI (Guia 2026)

---

Leitura: ~9 min

TL;DR:

• Ornith-1 não tem API pública: você sobe o modelo localmente (vLLM, SGLang, llama.cpp ou Ollama) e ele vira um endpoint OpenAI-compatible.
• O Kimi Code CLI enxerga qualquer endpoint desse tipo bastando declarar um [providers.x] com type = "openai" e um [models.x] com reasoning_key correto.
• Validar com kimi doctor config antes de sobrescrever o arquivo real evita quebrar sua sessão de CLI no meio de um projeto.

Nota Técnica: Scripts e configurações apresentados têm fins exclusivamente educacionais. Teste sempre em ambiente controlado antes de aplicar em máquinas de produção. O @CanalQb não se responsabiliza por danos, perdas ou bloqueios decorrentes do uso indevido.

A documentação do Kimi Code não fala sobre modelos "sem servidor" — porque eles não existem.

Todo mundo que tenta cadastrar o Ornith-1 direto pela chave de API leva o mesmo erro de conexão recusada. O motivo é simples: o Ornith-1 é peso aberto, sem endpoint hospedado pela DeepReinforce — quem serve o modelo é você.

Isso muda completamente o roteiro de configuração, e é exatamente o ponto que vamos destravar agora: como transformar um checkpoint local em um provider reconhecido pelo config.toml do Kimi Code, sem quebrar o restante da sua configuração já existente.

O que é o Ornith-1 e por que ele exige um servidor próprio?

O Ornith-1 é uma família de modelos open-source para codificação agêntica mantida pela DeepReinforce AI, disponível em checkpoints densos de 9B e MoE de 35B/397B, otimizados conjuntamente no scaffold do agente e nas respostas geradas. Por ser peso aberto, ele não roda em nuvem própria: você precisa servi-lo com vLLM, SGLang, llama.cpp ou Ollama para expor uma API compatível com o padrão OpenAI, que é o que o Kimi Code CLI consegue consumir via type = "openai".

Por que rodar Ornith-1 localmente com o Kimi Code CLI?

Rodar o Ornith-1 localmente elimina custo por token, mantém o código sensível dentro da sua rede e libera contexto de até 262.144 tokens — útil em refatorações grandes. Aqui no @CanalQb, validamos que o checkpoint 9B denso já entrega tool calling estável para tarefas de scripting do dia a dia, sem precisar de cluster.

Passo 1: Escolha o checkpoint certo para o seu hardware

Ação exata: Verifique a VRAM disponível e escolha entre o checkpoint denso Ornith-1.5-9B (cabe em 1 GPU de 80GB) ou os MoE -35B/-397B (exigem --tensor-parallel-size distribuído entre várias GPUs). Para máquinas sem GPU dedicada, existe a versão GGUF para Ollama e llama.cpp.

O que faz: Define o formato de peso que será baixado do Hugging Face e o mecanismo de inferência (vLLM/SGLang para GPU corporativa, GGUF para CPU/GPU de consumo).

Por que é necessário: Subir um MoE de 397B em hardware incompatível resulta em out of memory na primeira requisição — e não em erro de configuração do Kimi Code, o que confunde o diagnóstico.

Resultado esperado: Um checkpoint definido e compatível com a VRAM real da máquina, pronto para o comando de serve.

Erro comum + Correção: Baixar o checkpoint sem sufixo -FP8 em GPUs com pouca VRAM. Correção: usar a variante -FP8 das versões MoE, que reduz o consumo de memória mantendo qualidade próxima do original.

Passo 2: Suba o servidor local com vLLM ou Ollama

Ação exata: Instale o vLLM (pip install vllm) e execute o serve apontando o checkpoint escolhido; ou, para uma alternativa mais leve, use o Ollama com a build GGUF direto do Hugging Face.

vllm serve deepreinforce-ai/Ornith-1.5-9B \
  --served-model-name Ornith-1.5 \
  --host 0.0.0.0 --port 8000 \
  --max-model-len 262144 \
  --enable-auto-tool-choice --tool-call-parser qwen3_xml \
  --reasoning-parser qwen3

# Alternativa sem GPU de servidor (Ollama):
ollama run hf.co/deepreinforce-ai/Ornith-1.0-9B-GGUF

O que faz: Expõe o modelo em http://localhost:8000/v1 (vLLM) ou http://localhost:11434/v1 (Ollama), simulando a mesma API que o Kimi Code já usa para OpenAI, Moonshot ou qualquer outro provider.

Por que é necessário: Sem esse servidor ativo, o base_url cadastrado no config.toml aponta para o vazio e toda tentativa de troca de modelo falha com conexão recusada.

Resultado esperado: Um endpoint local respondendo a requisições OpenAI-compatible, testável com um curl simples antes mesmo de tocar no Kimi Code.

Erro comum + Correção: Esquecer --enable-auto-tool-choice --tool-call-parser qwen3_xml. Sem essas flags, o Ornith-1 responde texto puro em vez de chamadas de ferramenta, e o Kimi Code trata o agente como se não suportasse tool use.

Passo 3: Localize e faça backup do config.toml

Ação exata: Encontre o arquivo em ~/.kimi-code/config.toml (ou C:\Users\SeuUsuario\.kimi-code\config.toml no Windows) e copie-o antes de qualquer edição.

cp config.toml "config.toml.$(date +%Y%m%d-%H%M%S).bak"

O que faz: Cria uma cópia datada do arquivo original, permitindo reverter em um comando caso a nova configuração quebre a sessão do CLI.

Por que é necessário: O config.toml costuma acumular providers já em uso (OpenAI, Anthropic, Moonshot); um erro de sintaxe TOML derruba o carregamento inteiro, não só a seção nova.

Resultado esperado: Um arquivo .bak com timestamp, além do arquivo original intacto para edição em uma cópia de trabalho.

Erro comum + Correção: Editar o config.toml em produção direto, sem cópia. Correção: sempre trabalhar em um arquivo -new.toml e só substituir o original após validação (Passo 6).

Passo 4: Cadastre o provider [providers.ornith]

Ação exata: Adicione um bloco de provider do tipo openai, com base_url apontando para a porta do servidor local e api_key = "EMPTY", já que não há autenticação real em servidor próprio.

[providers.ornith]
type = "openai"
base_url = "http://localhost:8000/v1"
api_key = "EMPTY"

O que faz: Registra um novo protocolo de comunicação que o Kimi Code passa a reconhecer como origem válida de modelos, exatamente como faz com OpenAI ou Moonshot.

Por que é necessário: Sem essa declaração, não existe destino para o [models."ornith/..."] do próximo passo — o TOML rejeita referência a provider inexistente.

Resultado esperado: Uma nova tabela [providers.ornith] visível no arquivo, sem conflito com providers já existentes.

Erro comum + Correção: Usar chave com ponto sem aspas, como [providers.ornith.local], o que o TOML interpreta como tabela aninhada. Correção: usar chaves entre aspas sempre que houver ponto no nome.

Passo 5: Cadastre o modelo com reasoning_key correto

Ação exata: Declare [models."ornith/Ornith-1.5"] vinculado ao provider criado, com max_context_size, capabilities e o campo reasoning_key = "reasoning_content".

[models."ornith/Ornith-1.5"]
provider = "ornith"
model = "Ornith-1.5"
max_context_size = 262144
capabilities = ["thinking", "always_thinking", "tool_use"]
reasoning_key = "reasoning_content"

O que faz: Informa ao Kimi Code que esse modelo é um reasoning model e que o raciocínio (chain-of-thought) chega em um campo específico da resposta, não misturado ao texto final.

Por que é necessário: Sem reasoning_key correto, o Kimi Code exibe o raciocínio bruto do modelo dentro da resposta final, poluindo a saída no terminal.

Resultado esperado: Um modelo selecionável via /model ornith/Ornith-1.5, com o bloco de "Thinking" separado corretamente na interface do CLI.

Erro comum + Correção: Declarar capabilities sem tool_use. Correção: incluir tool_use sempre que o servidor tiver sido iniciado com --enable-auto-tool-choice, senão o Kimi Code ignora chamadas de ferramenta válidas.

Passo 6: Valide com kimi doctor antes de aplicar

Ação exata: Rode kimi doctor config config-new.toml apontando para o arquivo editado, antes de sobrescrever o config.toml real.

O que faz: Verifica a sintaxe TOML, a coerência entre providers e models declarados, e sinaliza referências quebradas.

Por que é necessário: Evita que uma sessão de CLI já aberta caia no meio de um trabalho por causa de um TOML malformado.

Resultado esperado: Saída OK config.toml no terminal, seguida da substituição segura do arquivo original e um /reload (ou nova sessão) para carregar o Ornith-1.

Erro comum + Correção: Trocar o default_model direto para o Ornith-1 sem testar antes. Correção: manter o modelo padrão atual e alternar manualmente com /model ornith/Ornith-1.5 até validar a estabilidade do servidor local.

vLLM ou Ollama: qual servidor local escolher?

Use vLLM quando houver GPU dedicada de pelo menos 80GB e o objetivo for throughput máximo com o checkpoint 9B ou os MoE maiores. Prefira Ollama com o build GGUF quando o hardware for mais modesto ou quando a prioridade for simplicidade de instalação em vez de performance de pico — a troca de porta no base_url (8000 para vLLM, 11434 para Ollama) é a única mudança necessária no provider.

Perguntas Frequentes

Perguntas Frequentes

O Ornith-1 tem API paga como a OpenAI?

Não. O Ornith-1 é peso aberto e não possui endpoint hospedado pela DeepReinforce. Você precisa servi-lo localmente com vLLM, SGLang, llama.cpp ou Ollama para obter um endpoint compatível com o padrão OpenAI. Veja mais sobre LLMs locais aqui no canal.

Qual checkpoint do Ornith-1 escolher sem GPU dedicada?

A versão GGUF do checkpoint 9B, servida via Ollama ou llama.cpp, roda em CPU ou GPUs de consumo com bem menos exigência de memória do que os checkpoints MoE de 35B e 397B, que dependem de tensor parallelism entre várias GPUs.

Por que o Kimi Code não reconhece o Ornith-1 automaticamente?

Porque o Kimi Code não tem integração nativa com modelos self-hosted específicos — ele reconhece protocolos, não marcas de modelo. Ao declarar o provider como type = "openai" apontando para o seu servidor local, qualquer modelo compatível, incluindo o Ornith-1, passa a funcionar. Saiba mais sobre a configuração do Kimi Code CLI.

O que é o reasoning_key e por que ele quebra a saída no terminal?

É o campo da resposta da API onde o modelo devolve seu raciocínio interno, separado da resposta final. Modelos de reasoning como o Ornith-1 usam reasoning_content; se esse campo não for declarado no config.toml, o Kimi Code mistura o raciocínio bruto na saída visível do terminal.

É seguro trocar o config.toml sem validar antes?

Não é recomendado. Um erro de sintaxe TOML pode impedir o carregamento de todos os providers já configurados, não apenas do novo. Rode sempre kimi doctor config em uma cópia do arquivo antes de sobrescrever o original, e mantenha um backup com timestamp para reverter em segundos. Veja mais sobre agentic coding.

📚 Fontes e Referências

• Repositório oficial do Ornith-1 (DeepReinforce AI): github.com/deepreinforce-ai/Ornith-1
• Mirror da comunidade citado pelo usuário: github.com/ornith-ai/Ornith-1
• Documentação oficial — Configuration Files: kimi.com/code/docs — configuration-files
• Documentação oficial — Providers and Models: kimi.com/code/docs — providers
• Repositório do CLI (Moonshot AI): github.com/MoonshotAI/kimi-cli

Testou o Ornith-1 no seu Kimi Code? Conta pra gente nos comentários e confira mais automações no @CanalQb no YouTube.

sssssssssss