Kimi K2.6 no Kimi Code via Ollama Cloud (2026)
- O endereço correto da API é https://ollama.com/v1 e não ollama.cloud; o modelo se chama kimi-k2.6 na API direta e kimi-k2.6:cloud no app local da Ollama.
- O guia original não define o modelo padrão e declara só a capacidade thinking; sem tool_use o Kimi Code perde o uso de ferramentas.
- O plano gratuito da Ollama tem uso leve, com limites que renovam a cada 5 horas e a cada 7 dias; confirme em ollama.com/settings/usage antes de depender dele.
Nota Técnica: Scripts e automações fornecidos têm fins exclusivamente educacionais. Teste sempre em ambiente controlado. @CanalQb não se responsabiliza por danos, perdas ou bloqueios decorrentes do uso indevido. Os valores deste post foram conferidos na documentação oficial em 31/10/2026; os comandos descritos seguem a documentação, e a execução na sua máquina continua sendo a prova final.
O guia que você baixou aponta para um domínio que a Ollama não usa.
O arquivo INSTALL_KIMI_K2.6.md promete ligar o Kimi K2.6 ao Kimi Code em cinco passos curtos. A ideia está certa, só que ao cruzar cada valor com a documentação oficial da Ollama e da Moonshot, vários campos não batem: o endereço da API, a chave, o contexto e as capacidades do modelo.
Aqui em @CanalQb a regra é publicar só o que foi conferido na fonte. Nas próximas seções você corrige cada divergência, monta um config.toml que a documentação sustenta e descobre, perto do fim, se vale mais a pena este caminho manual ou o comando ollama launch.
Quais são as soluções rápidas para os problemas mais comuns?
Cinco falhas respondem pela maior parte dos travamentos nesta instalação: endereço de API errado, chave vazia, nome de modelo com sufixo indevido, modelo padrão não definido e capacidades incompletas. Cada item traz a correção em uma ou duas frases e aponta para o catálogo completo de erros no fim do post.
- Endereço errado: troque https://ollama.cloud/v1 por https://ollama.com/v1, o único domínio que aparece na documentação oficial. ver passo completo
- Erro 401: crie uma chave em ollama.com/settings/keys e use api_key_env = "OLLAMA_API_KEY", removendo a linha api_key = "". ver passo completo
- Erro 404 de modelo: na API direta use o nome que /api/tags devolve (kimi-k2.6); o sufixo :cloud pertence ao app local. ver passo completo
- Modelo não vira padrão: default_model precisa ficar no topo do arquivo, antes de qualquer tabela entre colchetes. ver passo completo
- Agente sem ferramentas: declare capabilities = ["thinking", "tool_use", "image_in"] no bloco do modelo. ver passo completo
O que é o Kimi K2.6 no Ollama Cloud e o que o guia original errou?
O Kimi K2.6 é um modelo multimodal de código aberto da Moonshot, com cerca de 1 trilhão de parâmetros, que a Ollama serve apenas na nuvem. Você não baixa pesos: envia requisições autenticadas para https://ollama.com. O guia original acerta a ideia, mas erra o domínio, omite o modelo padrão e declara capacidades de menos.
A página oficial do modelo na biblioteca da Ollama mostra um único item, kimi-k2.6:cloud, marcado com as etiquetas vision, tools, thinking e cloud. Ela informa 1,04 trilhão de parâmetros, janela de 256K tokens e entrada de texto e imagem. Como o modelo não existe em versão local, tudo o que você faz é enviar requisições para a infraestrutura da Ollama; nenhum arquivo de vários gigabytes desce para o computador. Isso muda o raciocínio da instalação: você não instala um modelo, você registra um endereço, uma chave e um nome de modelo no Kimi Code.
Ao comparar o arquivo INSTALL_KIMI_K2.6.md com as fontes oficiais, aparecem cinco divergências que justificam este post. A tabela abaixo mostra o que o guia diz, o que a documentação mostra e qual falha cada diferença provoca na prática.
| Item | Guia original | Documentação (conferida em 31/10/2026) | Falha provocada |
|---|---|---|---|
| Endereço da API | https://ollama.cloud/v1 | https://ollama.com/v1 (compatível com OpenAI) | Erro de conexão ou DNS |
| Autenticação | api_key vazio, "pode ficar vazio" | Chave criada em ollama.com/settings/keys, enviada como Bearer | Erro 401 |
| Nome do modelo | kimi-k2.6 | kimi-k2.6 na API direta; kimi-k2.6:cloud no app e CLI da Ollama | Erro 404 se os dois forem misturados |
| Contexto | 131000 tokens | 256K tokens na página oficial; 131.000 em diretório de terceiros | Contexto subaproveitado |
| Capacidades | Somente thinking | Thinking, tools e vision | Agente sem ferramentas e sem imagem |
Nada disso indica má-fé: guias de instalação envelhecem rápido, e este citava um diretório de terceiros como fonte única. Por isso, ao longo do post, cada valor chega com a origem ao lado, e a lista completa de fontes fica na última seção para você conferir por conta própria.
O que preparar antes de editar o config.toml?
Você precisa de quatro coisas: o Kimi Code CLI instalado e executado ao menos uma vez, uma conta gratuita na Ollama, um terminal com acesso ao arquivo ~/.kimi-code/config.toml e uma cópia de segurança desse arquivo. Sem a primeira execução, o arquivo ainda não existe, e qualquer edição acontece no lugar errado.
O primeiro ponto merece atenção porque o guia original mistura duas ferramentas diferentes. O Kimi Code é o agente de terminal da Moonshot, publicado em github.com/MoonshotAI/kimi-code, e guarda a configuração em ~/.kimi-code/config.toml (no Windows, em C:\Users\<seu-usuario>\.kimi-code\config.toml). Já o opencode é outro programa, com banco de dados e preferências próprios. A seção "Arquivos envolvidos" do guia lista um opencode.db, e isso pertence ao opencode, não ao Kimi Code. A própria Moonshot mantém páginas separadas na documentação para cada um, o que confirma que são caminhos independentes.
Para confirmar a instalação, rode kimi --version no terminal; se o comando responder com um número de versão, o binário está no PATH. Se o arquivo config.toml não existir, abra o kimi uma vez e feche: a documentação diz que ele é criado automaticamente na primeira execução. Caso você tenha movido a pasta de dados com a variável KIMI_CODE_HOME, o caminho vira $KIMI_CODE_HOME/config.toml; o nome do arquivo nunca muda.
Esse cuidado evita um erro silencioso: editar um config.toml de outra pasta, reiniciar o agente e não ver nenhuma mudança. Antes de seguir, marque a lista de verificação abaixo.
- kimi --version responde com um número de versão.
- O arquivo ~/.kimi-code/config.toml existe (ou $KIMI_CODE_HOME/config.toml).
- Você tem uma conta em ollama.com e acesso à página de chaves.
- Você sabe qual terminal vai abrir o kimi, pois a variável de ambiente da chave precisa existir nele.
Como criar a chave de API e testar o endpoint antes de mexer no Kimi Code?
Crie a chave em ollama.com/settings/keys, guarde-a na variável OLLAMA_API_KEY e faça uma chamada de teste com curl para https://ollama.com/v1/chat/completions. Se a resposta vier em JSON, o endereço, a chave e o nome do modelo estão corretos, e o problema, caso apareça depois, estará só no config.toml.
Testar fora do agente separa as causas. Quando o Kimi Code falha, você não sabe se o erro vem da chave, do endereço, do nome do modelo ou do arquivo de configuração. Com o curl você elimina três dessas quatro hipóteses em um minuto. A documentação da Ollama pede exatamente isto: criar a chave, exportá-la como OLLAMA_API_KEY e enviar a requisição com o cabeçalho Authorization: Bearer.
No Git Bash, Linux ou macOS, defina a variável e liste os modelos de nuvem. A listagem /api/tags é a forma oficial de descobrir o nome que a API direta aceita:
export OLLAMA_API_KEY="cole_sua_chave_aqui"
curl https://ollama.com/api/tagsProcure kimi-k2.6 na lista devolvida. A documentação orienta usar, nas requisições para ollama.com, o nome que essa lista retorna; o formato kimi-k2.6:cloud serve para o app ou a CLI da Ollama instalados na sua máquina. Em seguida, envie uma pergunta mínima pelo endpoint compatível com OpenAI, que é o mesmo que o Kimi Code usará:
curl https://ollama.com/v1/chat/completions \
-H "Authorization: Bearer $OLLAMA_API_KEY" \
-H "Content-Type: application/json" \
-d '{"model":"kimi-k2.6","messages":[{"role":"user","content":"Responda apenas: ok"}]}'O resultado esperado é um JSON no formato OpenAI, com o texto da resposta dentro de choices, na posição message.content. No PowerShell, troque a primeira linha por $env:OLLAMA_API_KEY = "cole_sua_chave_aqui" e use curl.exe para não cair no apelido do Invoke-WebRequest. Erro comum: receber 401 ou uma mensagem de autenticação significa chave ausente, expirada ou colada com espaços; gere outra e repita. Nunca coloque a chave em código de navegador, capturas de tela ou repositórios públicos.
Como fazer backup e entender a estrutura do config.toml?
Copie o config.toml para config.toml.bak antes de qualquer edição e aprenda uma regra de TOML: valores soltos, como default_model, ficam no topo do arquivo; tudo que vem depois de um cabeçalho entre colchetes pertence àquela tabela. Aliases com ponto no nome precisam de aspas.
O backup é um comando só e custa nada. No Git Bash, Linux ou macOS use o primeiro bloco; no PowerShell, o segundo. Se a edição quebrar o arquivo, basta restaurar a cópia e recomeçar, sem reinstalar o agente.
# Git Bash, Linux, macOS
cp ~/.kimi-code/config.toml ~/.kimi-code/config.toml.bak
# PowerShell
Copy-Item "$HOME\.kimi-code\config.toml" "$HOME\.kimi-code\config.toml.bak"Agora a estrutura. O config.toml do Kimi Code usa nomes em snake_case e se divide em campos de topo, como default_model, e em tabelas, como providers, models e thinking. A documentação alerta que, se uma chave contém ponto, ela precisa estar entre aspas; por isso o alias do modelo é escrito [models."ollama-cloud/kimi-k2.6"] e nunca sem aspas. A ordem entre tabelas não importa para o TOML, e o guia original acerta ao dizer que dá para inserir os blocos antes de outras seções. O que importa é a posição dos campos de topo: no TOML, uma linha como default_model = "..." colocada depois de um cabeçalho [tabela] passa a pertencer a essa tabela e deixa de valer como configuração global.
Esse detalhe explica por que o guia original não define o modelo padrão com segurança: ele manda "inserir antes de [thinking]", e quem seguir a instrução à risca e adicionar default_model junto, ao fim do arquivo, o escreve dentro de uma tabela. Mais adiante você coloca essa linha no lugar correto. Vale saber também que a documentação informa que o CLI observa mudanças no config.toml por padrão (a tabela watch vem ativada), o que dispensa reinicializações na maioria dos casos.
Como adicionar o provedor ollama-cloud corretamente?
Adicione uma tabela [providers."ollama-cloud"] com type = "openai", base_url = "https://ollama.com/v1" e api_key_env = "OLLAMA_API_KEY". O tipo openai usa o protocolo de chat completions, a variável mantém a chave fora do arquivo, e remover a linha api_key vazia evita conflito entre os dois campos.
Cole o bloco abaixo no config.toml, em qualquer ponto depois dos campos de topo. Ele substitui o provedor do guia original, que usava o domínio ollama.cloud e uma chave em branco:
[providers."ollama-cloud"]
type = "openai"
base_url = "https://ollama.com/v1"
api_key_env = "OLLAMA_API_KEY"Cada linha tem um motivo. O campo type escolhe a implementação do protocolo; entre as opções documentadas (kimi, anthropic, openai, openai_responses, google-genai e vertexai), o tipo openai é o correto porque a Ollama diz que sua API em nuvem não oferece Responses com estado nem repetição de chamadas de ferramenta em formato livre, o que descarta o openai_responses. O base_url aponta para a rota /v1, a de compatibilidade com OpenAI. O api_key_env faz o CLI ler a chave da variável de ambiente a cada requisição, e esse mecanismo existe porque a documentação do Kimi Code afirma que o CLI não recorre sozinho às variáveis do shell: ou você escreve a chave no arquivo, ou aponta o nome da variável.
A documentação também define api_key e api_key_env como alternativas mutuamente exclusivas, então a linha api_key = "" do guia original deve sair. Se você preferir texto puro, use só api_key = "sua_chave", sabendo que ela fica legível em disco. O resultado esperado desta etapa é nenhuma mensagem: a configuração só é exercitada quando você pedir uma resposta. Erro comum: se a variável estiver vazia ou inexistente no terminal que abriu o kimi, a requisição falha com um erro que cita o nome da variável, e a correção é exportá-la naquele mesmo terminal. No Windows, o comando setx grava a variável apenas para terminais abertos depois dele, então feche e abra o terminal.
Como declarar o modelo kimi-k2.6 com as capacidades certas?
Crie [models."ollama-cloud/kimi-k2.6"] ligando o provedor ao nome kimi-k2.6, com max_context_size = 262144 e capabilities = ["thinking", "tool_use", "image_in"]. Essas três capacidades correspondem às etiquetas thinking, tools e vision que a Ollama exibe na página do modelo.
O bloco do modelo é onde o guia original mais perde informação. Veja a versão corrigida:
[models."ollama-cloud/kimi-k2.6"]
provider = "ollama-cloud"
model = "kimi-k2.6"
max_context_size = 262144
display_name = "Kimi K2.6 (Ollama Cloud)"
capabilities = ["thinking", "tool_use", "image_in"]Os campos provider e model são obrigatórios: o primeiro precisa coincidir com a tabela de provedor criada antes, e o segundo é o identificador enviado ao servidor. O max_context_size também é obrigatório e deve ser inteiro. A página oficial da Ollama indica 256K tokens, valor que a documentação do Kimi Code costuma escrever como 262144; já o 131000 do guia original vem de um diretório de terceiros, verificado em junho de 2026. Se o seu uso mostrar instabilidade em contextos grandes, não edite o campo principal: crie [models."ollama-cloud/kimi-k2.6".overrides] com um valor menor, pois a documentação reserva as sobrescritas para ajustes do usuário que sobrevivem a atualizações do catálogo.
Capacidades são etiquetas que você adiciona explicitamente, nunca removidas automaticamente. A tabela abaixo liga cada etiqueta da Ollama ao campo do Kimi Code e ao efeito prático da omissão.
| Etiqueta na Ollama | Capacidade no Kimi Code | O que acontece se faltar |
|---|---|---|
| thinking | thinking | O raciocínio estendido não é tratado como tal pela interface |
| tools | tool_use | O agente deixa de oferecer ferramentas como leitura e edição de arquivos ao modelo |
| vision | image_in | Imagens coladas na conversa não são enviadas |
Uma omissão consciente: o guia original traz support_efforts = ["low", "high", "max"] e default_effort = "low". A Ollama não documenta níveis de esforço para este modelo, e o campo support_efforts serve para declarar o que o modelo aceita. Como não encontrei confirmação, comece sem essas duas linhas e inclua-as apenas depois de testar. O CLI trata esforço não suportado com fallback para o padrão do modelo.
Como definir o modelo padrão e recarregar a configuração sem reiniciar?
Escreva default_model = "ollama-cloud/kimi-k2.6" na primeira linha do config.toml, antes de qualquer tabela entre colchetes, e rode /reload dentro do kimi. O valor precisa coincidir com o alias criado em [models.], e não com o nome enviado ao servidor.
Este é o passo ausente do guia original. A documentação define default_model como o alias do modelo padrão e exige que ele esteja definido em models. Se o campo não existir, o Kimi Code continua usando o modelo antigo, e o Kimi K2.6 só aparece quando você o escolhe manualmente. Veja o formato certo e o formato que parece certo mas falha:
# CERTO: no topo, antes de qualquer [tabela]
default_model = "ollama-cloud/kimi-k2.6"
[providers."ollama-cloud"]
type = "openai"
# ... restante do arquivo
# ERRADO: depois de uma tabela, vira campo dela
[thinking]
enabled = true
default_model = "ollama-cloud/kimi-k2.6"No segundo formato, o TOML é válido e nenhum erro aparece, o que torna a falha traiçoeira: o campo simplesmente pertence a [thinking] e é ignorado como padrão global. Depois de salvar, execute /reload na interface do kimi; a documentação diz que esse comando recarrega config.toml e tui.toml. Como o CLI também observa o arquivo por padrão, a mudança costuma ser aplicada sozinha, mas o /reload remove a dúvida.
Há ainda uma via temporária que não toca no arquivo. A documentação informa que o alias pode ser escolhido com a opção -m na linha de comando, e que variáveis KIMI_MODEL_ criam um provedor temporário apenas na memória. Para testar sem alterar o padrão, rode kimi -m ollama-cloud/kimi-k2.6. Use essa abordagem quando quiser comparar o Kimi K2.6 com o modelo gerenciado da Moonshot sem reescrever configurações a cada comparação.
Como validar que o Kimi K2.6 está respondendo no Kimi Code?
Valide em três camadas: abra o kimi e confira o nome do modelo na interface, envie uma pergunta simples, e peça uma tarefa que exija ferramenta, como listar arquivos. A terceira camada prova que a capacidade tool_use está ativa, e é a que o guia original nunca testa.
Primeira camada: abra o terminal onde a variável OLLAMA_API_KEY está definida e rode kimi. Dentro da interface, o comando /models atualiza e lista os modelos, e a linha de status pode exibir o modelo ativo, já que o slot model faz parte do rodapé padrão. Se aparecer "Kimi K2.6 (Ollama Cloud)", o alias foi lido. Segunda camada: envie um pedido curto, como "responda apenas ok", e confirme que a resposta chega sem erro de autenticação.
Terceira camada, a decisiva: peça "liste os arquivos da pasta atual e diga quantos existem". Para responder, o agente precisa chamar uma ferramenta de leitura de diretório; se o modelo responder inventando nomes de arquivos sem pedir permissão, a capacidade tool_use não chegou ao modelo e vale revisar o bloco de capabilities. Para automatizar o teste, use o modo não interativo descrito na documentação:
kimi -p "Liste os arquivos da pasta atual e diga quantos existem" -m ollama-cloud/kimi-k2.6O guia original sugere kimi models list e kimi model get kimi-k2.6. Não encontrei esses subcomandos na documentação oficial consultada; os mecanismos documentados são o /models dentro da interface e, em shell, o comando kimi provider para gerenciar provedores. Prefira esses. Se houver erro, o Kimi Code só repete automaticamente falhas transitórias, como timeouts, 429 e erros 5xx; um 429 causado por cota esgotada não é repetido e falha na hora, o que é útil saber ao interpretar a mensagem no plano gratuito. Para investigar uma falha, volte ao curl da seção da chave e compare: se o curl funciona e o kimi não, o defeito está no config.toml.
O plano gratuito da Ollama aguenta o Kimi K2.6 no dia a dia?
Aguenta testes e tarefas leves, mas não um uso contínuo de agente. A Ollama descreve o plano gratuito como uso leve, com limites de sessão que renovam a cada 5 horas e limites semanais que renovam a cada 7 dias. A medição segue o tempo de GPU, e não o número de tokens.
O guia original apresenta o modelo como "API gratuita, sem cartão de crédito", afirmação tirada de um diretório de terceiros que lista o campo "verificado em junho de 2026". A página oficial do próprio modelo, no entanto, exibe preços por milhão de tokens: 0,95 dólar de entrada, 0,16 dólar de entrada em cache e 4,00 dólares de saída. Além disso, relatos de usuários na comunidade dizem que o plano gratuito pode não incluir modelos de fronteira, e comparativos recentes falam em "créditos iniciais" em vez de cota fixa. As fontes divergem, e o honesto é declarar isso: verifique seu acesso real em ollama.com/settings/usage e no catálogo de nuvem com a sua conta antes de planejar qualquer fluxo em cima do gratuito.
| Plano | Preço | Uso de nuvem | Modelos de nuvem simultâneos |
|---|---|---|---|
| Free | 0 dólar | Uso leve | 1 |
| Pro | 20 dólares por mês | 50 vezes o do Free | 3 |
| Max | 100 dólares por mês | 5 vezes o do Pro | 10 |
Na prática, um agente de código consome muito mais que um chat: cada passo do loop gera nova requisição com o contexto acumulado. Se você usa subagentes em paralelo, lembre que a Ollama limita os modelos de nuvem simultâneos (uma fonte de terceiros fala em requisições simultâneas, então monitore). A Ollama envia um e-mail de aviso quando você chega a 90 por cento do limite do plano, e a página de uso mostra o quanto restou. Uma estratégia segura é reservar o Kimi K2.6 para tarefas difíceis e deixar as rotineiras para um modelo mais barato, definido no pool de subagentes por meio da seção secondary_model do config.toml.
Quando usar ollama launch, a API da Moonshot ou este caminho manual?
Use o caminho manual quando quiser o Kimi K2.6 via Ollama dentro de um config.toml com vários provedores. Use ollama launch para zero configuração, se o app da Ollama estiver logado. Use o login gerenciado da Moonshot se o objetivo é só ter o Kimi no Kimi Code com a menor manutenção.
O primeiro caminho alternativo é o comando ollama launch kimi --model kimi-k2.6:cloud, descrito em um artigo de terceiros sobre uma versão recente da Ollama; ele instala e abre a CLI da Kimi por meio do app da Ollama, que cuida do login. A vantagem é não editar nada; o custo é depender do app instalado e da conta conectada, e eu não consegui confirmar o comando na documentação oficial, só em fonte secundária, então teste antes de padronizar em equipe.
O segundo é o login gerenciado do próprio Kimi Code. A documentação diz que o serviço gerenciado usa OAuth: depois do /login, o CLI escreve e renova as credenciais sozinho, sem nada manual no config.toml. Ele também reserva modelos próprios, como kimi-for-coding, com 262144 tokens de contexto. Nossa posição, aqui, é direta: se você só quer usar o Kimi em código com o mínimo de manutenção, esse caminho é mais simples e previsível do que passar pela Ollama. O caminho manual desta aula vale quando a Ollama já é a sua fonte de modelos, quando você quer um único arquivo com vários provedores, ou quando precisa controlar a chave por variável de ambiente em máquinas de equipe.
Existe ainda a hospedagem própria, a partir dos pesos publicados em huggingface.co/moonshotai/Kimi-K2.6, servidos com vLLM ou SGLang. É a única rota com autonomia total e a mais cara: um modelo de 1 trilhão de parâmetros exige servidores com várias GPUs. Sobre privacidade, a Ollama afirma que processa prompts e respostas de nuvem apenas para atender às requisições e que não os usa para treinar modelos; leia a política atual antes de enviar código proprietário, porque termos mudam.
Dá para deixar o próprio agente fazer a instalação com segurança?
Dá, desde que o agente trabalhe sobre uma cópia, nunca receba a chave em texto na conversa e mostre o resultado antes de salvar. O Kimi Code também oferece o comando /provider para adicionar provedores sem editar o TOML à mão, quando o catálogo cobre o serviço desejado.
A seção de instalação automática do guia original diz apenas "ative o modo de edição e salve". Falta o essencial: salvaguardas. Peça ao agente três coisas explícitas. Primeiro, que faça o backup antes de editar. Segundo, que use api_key_env e nunca o valor da chave no texto da conversa, que pode ficar registrado no histórico de sessões. Terceiro, que exiba o trecho que pretende gravar e espere sua aprovação. O Kimi Code já ajuda com isso: o modo de permissão padrão é manual, e as regras [[permission.rules]] permitem negar escritas em caminhos sensíveis.
Depois da edição, valide a sintaxe sem abrir o agente. Se você tiver Python 3.11 ou superior, a biblioteca tomllib já faz parte da instalação:
python3 -c "import tomllib,os; tomllib.load(open(os.path.expanduser('~/.kimi-code/config.toml'),'rb')); print('TOML valido')"Se a saída for "TOML valido", a sintaxe está íntegra; qualquer exceção indica linha e coluna do problema, geralmente aspas faltando em alias com ponto. Para quem prefere interface, o /provider abre um gerenciador que, segundo a documentação, busca o catálogo de provedores conhecidos no models.dev, pede a chave e deixa escolher o modelo padrão. Não confirmei se a Ollama Cloud consta nesse catálogo; se ela aparecer, é o caminho mais curto, e se não aparecer, você mantém o bloco manual desta aula. Nos dois casos, finalize com o teste de ferramenta da seção de validação, porque ele prova que o resultado funciona no agente real.
Perguntas frequentes sobre o Kimi K2.6 no Kimi Code
O Kimi K2.6 do Ollama Cloud é realmente gratuito?
Preciso do app da Ollama instalado para usar o Kimi K2.6 no Kimi Code?
Qual é a diferença entre kimi-k2.6 e kimi-k2.6:cloud?
Posso guardar a chave da Ollama direto no config.toml?
O Kimi Code e o opencode usam o mesmo arquivo de configuração?
O que fazer se a cota do plano gratuito acabar no meio do trabalho?
{Erros e Soluções}
Os erros mais frequentes nesta instalação vêm de cinco origens: domínio errado, chave ausente, nome do modelo, posição do default_model e capacidades incompletas. Os cartões abaixo trazem o sintoma, a causa técnica, a correção copiável e o jeito de evitar a repetição.
Falha de conexão ou DNS ao chamar https://ollama.cloud/v1
Causa: o domínio ollama.cloud não aparece em nenhuma documentação oficial da Ollama; o endereço correto da API em nuvem é ollama.com. O texto exato da mensagem varia conforme o sistema, mas costuma citar que o nome do servidor não foi encontrado.
Solução: edite o provedor e deixe base_url = "https://ollama.com/v1"; depois rode /reload no kimi e repita o teste.
Prevenção: sempre faça o teste com curl no mesmo endereço antes de colocá-lo no config.toml, e desconfie de guias que citam diretórios de terceiros como fonte única.
401 Unauthorized ao enviar a primeira mensagem
Causa: a API em nuvem exige uma chave enviada como Bearer. Com api_key = "" ou variável de ambiente inexistente, a requisição sai sem credencial válida. Se a variável de api_key_env estiver vazia, o CLI informa o nome dela na mensagem de erro.
Solução: crie uma chave em ollama.com/settings/keys, exporte OLLAMA_API_KEY no terminal que abre o kimi, mantenha api_key_env = "OLLAMA_API_KEY" e apague a linha api_key = "".
Prevenção: no Windows, lembre que setx só vale para terminais novos; feche e abra o terminal depois de gravar a variável.
404 model not found para kimi-k2.6
Causa: o nome do modelo não bate com o que o servidor reconhece. Na API direta vale o nome devolvido por https://ollama.com/api/tags; o formato kimi-k2.6:cloud pertence ao app e à CLI instalados localmente. Outra causa possível é o modelo não estar liberado no seu plano.
Solução: rode curl https://ollama.com/api/tags, copie o nome exato e use-o no campo model do bloco [models.]; confirme também seu acesso em ollama.com/settings/usage.
Prevenção: copie o nome da listagem, não de blogs, porque catálogos de nuvem mudam e modelos recebem datas de retirada.
O Kimi K2.6 aparece na lista, mas o agente continua usando o modelo antigo
Causa: falta default_model ou ele foi escrito depois de uma tabela entre colchetes, onde o TOML o trata como campo da tabela e não como configuração global. O arquivo continua sendo válido, por isso não há mensagem de erro.
Solução: mova default_model = "ollama-cloud/kimi-k2.6" para a primeira linha do arquivo, antes de qualquer cabeçalho, e execute /reload. Para um teste isolado, use kimi -m ollama-cloud/kimi-k2.6.
Prevenção: mantenha os campos de topo agrupados no início do arquivo e valide a sintaxe com tomllib depois de cada edição.
O agente responde, mas não lê nem edita arquivos e ignora imagens
Causa: o bloco do modelo declara só capabilities = ["thinking"]. Sem tool_use, as ferramentas não são oferecidas ao modelo; sem image_in, imagens não são enviadas. A Ollama marca o Kimi K2.6 com tools e vision, então a falha está na declaração, não no modelo.
Solução: troque a linha por capabilities = ["thinking", "tool_use", "image_in"] e rode /reload. Depois repita o teste de listar arquivos.
Prevenção: derive as capacidades das etiquetas da página oficial do modelo, tabela por tabela, em vez de copiar blocos prontos.
429 Too Many Requests e a sessão falha na hora
Causa: a cota do plano acabou ou a concorrência permitida foi excedida. O Kimi Code repete falhas transitórias, mas não repete um 429 causado por cota esgotada, porque ele só se resolve com renovação ou recarga da conta.
Solução: consulte ollama.com/settings/usage, espere a renovação da sessão (5 horas) ou da semana (7 dias), reduza o paralelismo de subagentes ou troque de modelo com -m.
Prevenção: acompanhe o consumo antes de tarefas longas; o aviso por e-mail chega aos 90 por cento do limite.
Caracteres estranhos no texto de raciocínio
Causa: há relatos isolados de usuários da comunidade com saída ilegível durante o modo thinking neste modelo. Não é um comportamento documentado, e a causa pode estar no serviço ou no formato do campo de raciocínio devolvido pelo gateway.
Solução: desative o raciocínio temporariamente com enabled = false na tabela [thinking] e compare. Se o problema sumir, teste outro esforço; se a resposta vier em campo não padrão, a documentação prevê o campo reasoning_key no bloco do modelo.
Prevenção: registre a data, o alias e o trecho do erro para reportar, e mantenha um segundo modelo configurado como alternativa.
Gostou deste passo a passo?
Veja mais automações, scripts e ferramentas práticas no canal @CanalQb no YouTube e continue explorando o arquivo do blog.
Conformidade Global: As informações refletem a documentação vigente na data da verificação. Termos de uso, preços e leis de privacidade variam por jurisdição e mudam com frequência. Consulte as autoridades locais de proteção de dados e o IAPP Global Privacy Directory. Este conteúdo não constitui aconselhamento jurídico.
Fontes e Referências
Fontes consultadas em 31/10/2026. As oficiais aparecem primeiro; as demais são usadas para comparar divergências.
- Ollama: página oficial do modelo kimi-k2.6 (etiquetas, contexto, preços, exemplos de API).
- Ollama Docs: Cloud (chave de API, nomes de modelo, uso e tratamento de dados).
- Ollama Docs: compatibilidade com a API OpenAI (https://ollama.com/v1 e limitações).
- Kimi Code Docs: Configuration files (providers, models, capabilities, overrides, watch).
- Kimi Code Docs: Providers and models (tipos de provedor, /provider, login gerenciado).
- GitHub: MoonshotAI/kimi-code (repositório do Kimi Code CLI).
- Ollama: planos e preços (citada pela documentação oficial para comparar planos).
- DevToolHub: limites do Ollama Cloud Free e Pro (fonte independente: medição por tempo de GPU).
- OpenClaw Docs: provedor ollama-cloud (fonte independente: base URL e chave).
- AvenChat: como usar o Kimi K2.6 no Ollama (fonte independente: modelo apenas em nuvem e alternativas).
- AyAutomate: Kimi K2.6 by Ollama Cloud (fonte citada pelo guia original; contexto de 131.000 tokens e acesso gratuito divergem das fontes oficiais).
Feito com Master Rules Claude v9.2
