Buda vs Crush: quem mantém o terminal e quem aceita a entrega?
Compare a liberdade de configurar modelos e ferramentas com um workspace persistente para outras funções.

Buda vs Crush: quem mantém o terminal e quem aceita a entrega?
Crush, da Charm, é um Agent de programação no terminal. O README atual descreve troca de modelos preservando contexto, sessões por projeto, LSP e MCP. Buscar uma alternativa não justifica ignorar essas capacidades.
A comparação com o Buda começa quando o trabalho sai do repositório e chega a suporte, conteúdo ou operações. Quem mantém o ambiente? Quem conserva materiais e aceita o resultado? É uma decisão de responsabilidade, não um ranking de geração de código.
Configure o que vale a pena manter
Crush aceita diversos provedores, APIs compatíveis e configurações de modelos locais. O seletor permite trocar o modelo durante a sessão preservando contexto; LSP acrescenta informações de código e MCP estende ferramentas via stdio, HTTP e SSE. Para quem conhece essa combinação, a liberdade de configuração é uma vantagem.
O crushrc atual é baseado em shell e tem escopos de projeto e global. O README alerta que a configuração é código confiável. Antes de abrir um projeto desconhecido, revise configuração, expansão de segredos e permissões. Copiar a configuração de uma pessoa não equivale a validar a operação de uma equipe.
Reconheça o contexto do backend compartilhado
No backend compartilhado, clientes são agrupados pelo diretório de trabalho e compartilham sessões, mensagens, filas de permissão, LSP e MCP. Cada execução começa com nova sessão por padrão; o usuário pode selecionar uma anterior. Não é correto dizer que Crush não tem continuidade.
Teste quem opera o backend, quem pode conectar e quem fixa as opções. O primeiro cliente determina flags de processo como yolo e debug. A decisão é se esse compartilhamento por diretório corresponde aos papéis e limites da equipe.

Siga uma entrega para fora do repositório
Uma alteração aprovada pode exigir explicação ao cliente, checklist de suporte e material de treinamento. Todos usam o diff, mas têm entradas e revisores distintos. Poder gerar os três não significa que o desenvolvedor deve operar todo o contexto.
No Buda, cada Agent tem computador em nuvem persistente e vistas de arquivos, terminal, navegador e Git. Uma função de negócio conserva seus materiais e revisões. Isso não estabelece integração nativa com Crush. Transfira o diff aprovado, limitações, fontes e critérios de aceite explicitamente.
Meça manutenção e revisão separadamente
No terminal, registre provedores, modelos, LSP, autenticação MCP, revisão da configuração e permissões; depois verifique diff e testes de uma tarefa pequena. No workspace gerenciado, teste persistência, continuidade, execução visível e se o revisor consegue localizar o rascunho e as fontes.
Preço por token não captura assinatura, ambiente, configuração e correções. Não há vantagem fixa de custo nem equivalência de recursos estabelecida aqui. Cada ensaio deve corresponder ao trabalho acumulado de verdade.
Preserve o terminal quando a configuração é a vantagem
Um ambiente já bem mantido não precisa ser substituído apenas para uniformizar a interface. Continue o trabalho de código nele e teste entregas recorrentes de negócio em outro workspace. Não amplie permissões para tornar uma demonstração mais fluida.
No Buda, forneça uma mudança aprovada e peça uma explicação com fontes, perguntas em aberto e checklist. Se o processo se repetir, pesquise e instale um Skill adequado no Marketplace do Buda AI. O resultado importante é uma entrega aceita por uma pessoa responsável, não uma promessa de compatibilidade automática.

Perguntas frequentes
Crush tem MCP e troca de modelo?
Sim. O README documenta ambos, incluindo preservação de contexto na troca.
O workspace pode ser compartilhado?
Um backend compartilhado reúne estado por diretório. Valide acesso e operação, sem presumir governança pronta.
Buda importa a configuração automaticamente?
As fontes não comprovam essa compatibilidade. Passe materiais e instruções aprovados explicitamente.
Qual é o primeiro teste de compra?
Identifique se o gargalo é manter o ambiente de código ou entregar materiais a revisores de negócio, e teste essa etapa.