Alternativas ao Mistral Vibe: escolha pelo fluxo de trabalho e pelo controle da API

O ponto de partida honesto para as alternativas ao Mistral Vibe é que o Vibe CLI não vai desaparecer: mistralai/mistral-vibe usa Apache-2.0, não está arquivado, lançou a versão v2.25.5 em 18 de setembro de 2026 e recebeu seu último push em 21 de setembro de 2026. As pessoas o substituem por quatro motivos específicos — chamadas em segundo plano que ainda chegam à Mistral, recursos de fala sem caminho de terceiros, padrões que podem ser alterados remotamente e um ritmo de lançamentos rápido o bastante para quebrar uma configuração funcional — e cada um desses pontos indica uma substituição diferente. Esta página é a árvore de decisão, além do que uma troca realmente custa em arquivos.

Primeiro, uma desambiguação, porque ela determina quais preços são relevantes. A Mistral renomeou o Le Chat para Vibe em 28 de maio de 2026: "Le Chat agora é Vibe", um agente e uma licença para trabalho e código. Portanto, "Mistral Vibe" agora nomeia tanto um assistente para consumidores quanto um agente de programação, e todo valor de assinatura que você encontrar com esse nome compra o assistente. O CLI é o pacote mistral-vibe, Apache-2.0, $0. Um terceiro produto, Mistral Code Enterprise, é um plugin separado e obsoleto: "obsoleto em favor do Mistral Vibe", funcionando até março de 2027, somente com licença empresarial. E vale nomear duas colisões: vibe.us vende hardware de colaboração para salas de reunião, e as listas de "vibe coding" sobre Replit, Bolt e Lovable tratam de uma metodologia, não de substituir um agente de terminal.

Por que as pessoas deixam o Vibe CLI

Nem toda solicitação vai para o provedor que você declarou. Na v2.25.5, o módulo de conclusão de utilitários define um modelo Mistral rápido, mistral-vibe-cli-fast, e sua docstring afirma que ele é preferido sempre que um provedor Mistral estiver utilizável "mesmo quando o provedor ativo da sessão for outro" — e os padrões integrados sempre configuram um. Os chamadores são conveniências em segundo plano, não seus turnos de programação: títulos de sessão, nomes de worktrees do git, o loop do agente e o runtime do servidor do aplicativo. Existem três alternativas de saída documentadas no mesmo arquivo: nenhum provedor Mistral utilizável, uma lista de permissões allowed_models que exclui o alias mistral-small ou uma MISTRAL_API_KEY não resolvível. Se o motivo para sair é "todo o tráfego deve atingir um único endpoint", comece por aí antes de migrar — talvez isso já possa ser resolvido no local.

A fala está vinculada ao próprio protocolo de áudio da Mistral. Nessa versão, TranscribeClient e TTSClient são enums de string cujo único membro é Mistral, e os padrões fornecidos apontam para wss://api.mistral.ai e https://api.mistral.ai, ambos baseados em MISTRAL_API_KEY. Um bloco [[transcribe_providers]] ou [[tts_providers]] permite alterar api_base e a variável da chave — o que ele não pode alterar é o client, portanto, seja qual for o destino, ele ainda precisa falar a própria API de áudio da Mistral. A Kunavo também não oferece nenhum modelo de conversão de fala em texto, conversão de texto em fala ou embeddings, portanto trocar clientes ou gateways não resolve um requisito de fala — essa etapa precisa de um provedor que ofereça esse serviço, e esta página não vai fingir o contrário.

Alguns padrões são definidos remotamente. O esquema de configuração 2.25.5 inclui ExperimentsConfig com enable = True apontando para https://experiments.mistral.services/, e enable_telemetry tem True como valor padrão. Essa camada pode fornecer routed_default_model, routed_model_config e routed_extra_models em tempo de execução, e condiciona o modo Smart Approve a dois sinalizadores de experimento que permanecem desativados a menos que uma implantação os ative. Essa última parte acrescenta uma ressalva à nossa própria página Vibe CLI versus Claude Code, que descreve o classificador do Smart Approve sendo executado no modelo Mistral rápido: na versão 2.25.5, ambos os sinalizadores ficam desativados por padrão e o modo fica oculto até que uma implantação o exponha, portanto esse roteamento só chega até você quando o Smart Approve é efetivamente oferecido. O roteamento do modelo de utilitário acima continua válido para títulos e nomes de worktrees.

O ritmo é rápido o suficiente para quebrar uma configuração funcional. O changelog da 2.25.5 registra uma correção para provedores configurados sem uma variável de ambiente de chave de API — servidores de modelos locais ou auto-hospedados — que "voltam a funcionar no Unified Harness em vez de falhar a cada turno com um erro de MISTRAL_API_KEY ausente". Isso significa que um provedor local sem chave estava falhando no Unified Harness em pelo menos uma versão anterior; o changelog não informa a partir de qual versão, portanto verifique isso em relação à versão que você instalar. A mesma versão remove o rótulo "experimental" desse harness e nomeia --legacy-harness como alternativa, e a 2.25.4 lista cinco identificadores CVE corrigidos na verificação de permissões do shell (IDs conforme impressos no changelog, não verificados separadamente em um banco de dados de CVEs). Fixe a versão em qualquer runbook que você escrever.

Qual alternativa corresponde a qual motivo de saída

Os números do repositório, do lançamento e do marketplace foram obtidos da API do GitHub, do PyPI, do Visual Studio Marketplace e da documentação própria de cada projeto em 21 de setembro de 2026. Três deles agora respondem sob um proprietário diferente daquele indicado pela URL que a maioria dos guias ainda imprime. Os redirecionamentos do GitHub comprovam o novo proprietário, mas não foi encontrada nenhuma declaração datada para qualquer um deles; portanto, leia-os como renomeações registradas, não como aquisições. Uma limitação da primeira linha: o que foi verificado foi a configuração de provedor personalizado de cada projeto, não o tráfego em segundo plano; portanto, se o requisito real for "toda chamada alcança meu endpoint", confirme isso com um log de proxy na sua própria configuração. Comparações mais aprofundadas estão em Alternativas ao OpenCode, Alternativas ao Aider e Crush versus OpenCode.

Verifique o tráfego antes de escolher

Esta é a parte que uma tabela de recursos não mostra, e ela determina se sua chave existente funciona de fato. Cada cliente aceita um conjunto diferente de protocolos para um endpoint personalizado, e um deles rejeita o formato servido pela maioria dos gateways.

Três detalhes que custam uma tarde cada. Para os estilos no formato OpenAI do Vibe, api_base deve ser a raiz /v1, porque o adaptador OpenAI acrescenta /chat/completions por conta própria — enquanto o adaptador anthropic acrescenta /v1/messages, portanto esse requer a raiz do host. A configuração do Crush mudou: na v0.96.1, crushrc é o local documentado para adicionar um provedor, enquanto crush.json permanece em $HOME/.local/share/crush/, então um tutorial que adiciona um provedor ao arquivo JSON descreve um formato antigo — e o README alerta que ambos os arquivos são código confiável, pois crushrc é executado em um shell completo. E a barreira do Codex CLI encerra as migrações antecipadamente: uma chave de chat-completions não é um provedor do Codex CLI nesta versão.

Para a mudança mais comum — do Vibe CLI para o OpenCode, mantendo uma chave — a declaração no destino é um arquivo, não um assistente:

{
  "provider": {
    "kunavo": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Kunavo",
      "options": {
        "baseURL": "https://api.kunavo.com/v1",
        "apiKey": "{env:KUNAVO_API_KEY}"
      },
      "models": {
        "claude-sonnet-4-6": { "name": "Claude Sonnet 4.6" }
      }
    }
  }
}

O equivalente no Crush é uma linha crushrc — provider add kunavo --type openai-compat --base-url "https://api.kunavo.com/v1" --api-key "$KUNAVO_API_KEY" — seguida por um model add para cada modelo que você deseja listar, que é o formato usado pelo próprio exemplo de provedor personalizado do README. Ambos são formatos de configuração publicados, lidos na documentação própria de cada projeto, não testes em tempo de execução: a Kunavo não executou nenhum dos dois clientes contra seu endpoint. As referências de configuração estão em integração com o OpenCode, integração com o Crush e integração com o Mistral Vibe.

O que migra, o que não migra e como reverter

É transportado como uma cópia de arquivo: AGENTS.md. O Vibe CLI 2.25.5 define AGENTS_MD_FILENAME = "AGENTS.md", a documentação do OpenCode orienta você a versionar o AGENTS.md do seu projeto no Git, e o Crush v0.96.1 lê ~/.config/AGENTS.md e oferece uma opção initialize-as AGENTS.md. Mesmo nome de arquivo, portanto esta parte é portátil — embora cada cliente interprete o conteúdo à sua maneira; leia-o uma vez na nova ferramenta em vez de presumir um comportamento idêntico.

Não é transportado: ferramentas, skills, plugins e subagentes. O Vibe mantém esses itens em um diretório de projeto .vibe/ com os subdiretórios tools/, skills/, plugins/ e agents/, além de um diretório .agents/skills, com equivalentes globais em ~/.vibe. Nenhum outro cliente aqui lê esse layout, portanto reserve tempo para redeclará-los manualmente. As chaves também não são transportadas: o fluxo de configuração do Vibe as grava em ~/.vibe/.env, as variáveis de ambiente têm precedência, e cada cliente de destino nomeia sua própria variável.

O histórico não é transportado de forma alguma. As sessões do Vibe são arquivos locais em ~/.vibe/logs/session — um .session_index.json, depois um meta.json e um messages.jsonl por sessão. A versão 2.25.5 inclui três scripts de console (vibe, vibe-acp, vibe-app-server) e expõe --continue e --resume; nenhum comando de exportação foi encontrado nela. Desde a 2.25.5, esse diretório pertence exclusivamente ao proprietário em sistemas não Windows. Mantenha-o, em vez de planejar importá-lo.

Uma migração que não deixará você sem saída, em ordem: copie AGENTS.md para a raiz do projeto do novo cliente; declare o provedor no próprio arquivo desse cliente usando o protocolo da tabela acima; exporte a variável de chave que ele nomeia; execute uma tarefa limitada — uma edição de arquivo único e, depois, uma investigação em vários arquivos — em ambos os clientes; leia o que sua conta de provedor registrou para cada um. Configure a reversão antes de começar: o Vibe CLI é um pacote Python comum, portanto reinstalar a versão que você usava (uv tool install mistral-vibe==2.25.5) restaura o cliente, e deixar ~/.vibe intacto durante o teste preserva sua configuração e seu arquivo de chave.

O que a mudança faz com sua conta

Quase nada, e esse é o objetivo: em uma rota de uso da sua própria chave, o cliente é software livre e o modelo determina a conta. Estes valores são cálculos ilustrativos de tokens, não custos medidos de tarefas nem um teto de cobrança. Suponha uma sessão enviando 200.000 tokens de entrada não armazenados em cache e recebendo 12.000 tokens de saída. A primeira linha é a tarifa publicada pela própria Mistral para o modelo padrão do Vibe CLI, mostrada para comparação — a Kunavo não vende modelos Mistral. As demais são tarifas atuais do catálogo da Kunavo por milhão de tokens.

O valor da Mistral foi consultado em sua lista de preços da API em 21 de setembro de 2026, e a configuração distribuída do Vibe declara os mesmos dois números para mistral-vibe-cli-latest. O que a tabela não pode informar: a menor tarifa listada e o menor custo para concluir a tarefa são afirmações diferentes, e um modelo que exige três tentativas pode custar mais do que um mais caro que conclui em uma única passagem. Dimensione pelos seus próprios números de sessões por dia antes de tratar qualquer valor como orçamento.

O valor do catálogo da Kunavo é um piso de cobrança, não um limite: quando o upstream informa sua cobrança, o valor faturado é o maior entre o custo do catálogo e o custo do upstream multiplicado pelo markup aplicável. As cobranças de cache e as ferramentas externas ficam fora deste exemplo. A recarga mínima é $10 em crédito pré-pago, que financia um saldo em vez de comprar um plano — consulte detalhes de cobrança e crie uma conta Kunavo quando estiver pronto para financiar uma chave para qualquer cliente que escolher.

Ainda está decidindo entre ficar e mudar? Mistral Vibe versus Claude Code aborda como manter o CLI e apontá-lo para outro lugar, a melhor API para o OpenCode aborda a questão do provedor no destino mais comum, e alternativas ao Claude Code amplia o conjunto se o terminal não for a restrição.

Perguntas frequentes

Verificado em 21 de setembro de 2026: a API do GitHub para mistral-vibe, opencode, goose, OpenHands, Roo-Code, crush, codex, cline e kilocode; o PyPI para mistral-vibe 2.25.5; as listagens do Visual Studio Marketplace e do JetBrains Marketplace mencionadas acima; o código-fonte, o changelog e o README do wheel v2.25.5; as páginas de configuração do CLI e de chaves de API de docs.mistral.ai; mistral.ai/pricing, mistral.ai/pricing/api e o anúncio da renomeação do Vibe; opencode.ai, goose-docs.ai, roomote.dev, o README do Crush v0.96.1 e a referência de configuração do Codex da OpenAI. Nenhum cliente foi instalado ou executado contra a Kunavo, portanto nada aqui é um teste de compatibilidade, e todo valor em dólares é um cálculo ilustrativo de tokens, não um custo de tarefa medido.