Um agente alojado corre na cloud de um fornecedor. Dá-lhe uma cópia dos seus repositórios e um conjunto de credenciais, e ele trabalha a partir daí. Um agente local-first corre na sua própria máquina, que já tem o runtime, a subscrição, os ficheiros e as chaves, e apenas a conversa sai de lá.
Ambos são modelos legítimos. Colocam o seu código, a sua identidade e a sua fatura em sítios diferentes, e as diferenças tornam-se mais importantes assim que começa a partilhar o agente com outras pessoas.
O que a abordagem alojada faz bem, e o que custa
Os exemplos concretos em 2026 são o Claude Code on the web e as tarefas na cloud do Codex da OpenAI. Ambos executam o agente na sandbox do fornecedor sobre um clone do seu repositório e autenticam-se no git com tokens emitidos para o fornecedor através da integração OAuth do GitHub, para que o agente nunca tenha acesso às suas credenciais locais, chaves SSH ou variáveis de ambiente. Trata-se de uma propriedade de segurança real: um portátil de programador comprometido não afeta o ambiente do agente, e uma tarefa com âmbito mal definido não consegue tocar em ficheiros fora da sandbox.
Um agente alojado está sempre ativo. Não há nenhum portátil para manter acordado nem nada para instalar. Para frotas não supervisionadas que operam 24 horas por dia, isso é decisivo.
Os custos são estruturais e não corrigíveis.
- Uma segunda cópia de tudo. O fornecedor mantém os seus repositórios e, frequentemente, o seu ambiente para que o agente possa trabalhar. Essa cópia tem os seus próprios controlos de acesso, retenção e superfície de ataque.
- Um segundo conjunto de credenciais. Os tokens para o GitHub, contas de cloud e APIs internas são emitidos para o fornecedor. Fazer a rotação das credenciais significa fazê-lo lá também.
- Uma segunda fatura. Paga pelo runtime alojado além da, ou em vez da, subscrição que já tem.
- A escolha de modelos de terceiros. O fornecedor decide que modelos estão disponíveis e quando mudam.
O que a abordagem local-first faz bem, e o que custa
Um agente local-first utiliza o que já está na sua máquina: a subscrição do Claude Code ou Codex que já paga, os repositórios de que já fez checkout, as chaves que já tem no porta-chaves. Nada é copiado para lado nenhum. Quando partilha o agente, a outra pessoa pode fazer perguntas; a sua máquina continua a fazer o trabalho.
O custo é a disponibilidade. Se a máquina estiver a dormir, o agente está a dormir.
As mitigações são práticas em vez de arquiteturais: registe o daemon como um serviço para que arranque ao iniciar sessão e reinicie após uma falha, mantenha a máquina ativa durante o horário de trabalho e enfileire pedidos numa caixa de entrada para que nada se perca enquanto estiver offline. Os pedidos são executados por ordem assim que voltar.
Dois locais para colocar o limite de confiança: em torno da sandbox do fornecedor ou em torno da sua própria máquina com uma sala exterior.
O quão fina pode ser a camada de cloud
O muti é local-first, e a questão de design interessante era perceber o que a cloud pode guardar. A resposta é: a sala, e nada que permitisse à sala fazer-se passar pela máquina.
Três mecanismos garantem isto.
Apenas de saída. O daemon na sua máquina faz polling por trabalho através de uma ligação de saída. Não há nenhuma porta aberta, nenhum túnel e nenhum caminho de entrada. Se a cloud do muti ficasse comprometida, o atacante poderia enfileirar pedidos que as suas regras de permissão e aprovações continuariam a controlar; não conseguiria aceder aos seus ficheiros.
Eventos, não ficheiros. O daemon emite eventos de timeline a descrever o que aconteceu. Não faz o upload da árvore de trabalho e nunca lê variáveis de ambiente ou ficheiros de chaves para enviar para onde quer que seja.
Aprovações pelo meio. Como a máquina é sua, os quatro tipos de ações perigosas fazem uma pausa para aguardar por si em cada pedido vindo de outra pessoa. Um agente alojado com as suas credenciais não tem a quem perguntar.
Tabela de decisão
Por que razão o muti não aloja runtimes
Seria fácil adicionar um botão "executar na nossa cloud". Não o fizemos, e é deliberadamente um não-objetivo. No momento em que o runtime muda de sítio, as credenciais e os repositórios vão atrás, e o proprietário deixa de ser quem aprova. Todas as garantias em as quatro ações que pedem sempre autorização dependem de a máquina pertencer ao proprietário.
O muti aloja salas. O seu agente fica onde está.
Perguntas frequentes
"Local-first" é o mesmo que "offline"? Não. O agente precisa da rede para contactar o fornecedor do modelo, e o muti precisa dela para entregar mensagens. Local-first descreve onde residem o trabalho e os segredos, não se a máquina está ligada à rede.
Posso alojar a cloud do muti por minha conta? O alojamento próprio da camada de salas está no roadmap como um modo individual com capacidade offline. O daemon e a cloud já comunicam através de uma API simples.
E se eu tiver várias máquinas? Ligue cada uma delas. Os agentes estão associados a uma máquina e a um diretório de trabalho, e pode distinguir as suas máquinas pelos endereços reportados pelo daemon.
Se já paga por um bom agente e o quer manter onde está, dê-lhe uma sala.
Publicado a · Atualizado a