Tudo em local — construindo um workspace de IA offline

• Como montar um workspace de IA usando execução de LLM local e ambiente de sandbox de código, sem depender da nuvem
• Com Ollama para executar um LLM local, executar código em uma VM isolada com Apple Container e habilitar automação e acesso à internet via navegador headless com Playwright
• Baseado em assistant-ui, implementei um ambiente de execução de código seguro com menu suspenso de seleção de modelo e integração com ai-sdk e MCP (Model Context Protocol)
• No VM Coderunner conectada por MCP é possível executar servidor Jupyter e navegador para lidar com criação de gráficos, edição de imagem/vídeo, instalação de ferramentas do GitHub e busca web em modo de proteção de privacidade
• No momento, é exclusivo para Apple Silicon, e os próximos passos incluem melhorias de UI, evasão de detecção de navegador e melhoria do gerenciamento de ferramentas

---

Requisitos e contexto

• Objetivo: executar tudo localmente, sem execução de código em nuvem ou remoto
• Apps de chat com LLM existentes (como ChatGPT, Claude) oferecem chat de LLM baseado em nuvem, execução de código em nuvem/local e acesso à internet
• Com o crescimento do uso de LLMs open source, surgiu a dúvida se todas essas funções poderiam ser realizadas totalmente de forma local
• Como o LLM local sozinho é insuficiente, é necessário que o código seja executado em ambiente isolado e que haja acesso a conteúdos por meio de navegador

Ideia

• Executar LLMs em ambiente completamente local
• Processar a execução de código apenas dentro de VMs leves para bloquear riscos no sistema host
• Adicionar navegador headless para suportar automação, descoberta de novas informações e de ferramentas
• Montar um fluxo de trabalho com foco em proteção de privacidade, no qual do planejamento da IA à execução de código tudo acontece localmente
• Realizar múltiplas tarefas, como edição de fotos e vídeos, localmente sem enviar dados para serviços externos

Stack tecnológica

• LLM: Ollama (suporte a modelos locais e alguns modelos externos)
• UI: assistant-ui + ai-sdk (com recurso de seleção de modelo)
• Runtime de VM: Apple container (fornece ambiente de VM isolado)
• Orquestração: instavm/coderunner (conexão com servidor Jupyter via MCP)
• Automação de navegador: Playwright (exposto como ferramenta MCP)

Tentativa e transição no app Mac

• Tentou-se desenvolver um app nativo para Mac com a0.dev, mas houve dificuldade por ser voltado para iOS
• Também foi tentado envolver Electron + NextJS, mas foi abandonado por questões de complexidade
• A migração final foi para assistant-ui local baseado na web

Customização do Assistant-UI

• A expectativa era oferecer suporte a múltiplos LLMs com menu suspenso de seleção de modelo, mas ela era limitada
• Com base em exemplos, a seleção de múltiplos modelos foi implementada diretamente via ai-sdk
• No início, também houve suporte a modelos cloud como OpenAI/Anthropic, com estratégia de migração gradual para o local

Desafios de suporte a modelos e tool-calling

• Era necessário um modelo com suporte a tool-calling, porém alguns, como Ollama, não suportam na prática
• Mesmo quando a documentação oficial indica suporte a ferramentas, a implementação real é frequentemente insuficiente
• A rápida mudança da ecologia open source traz alta volatilidade em status de suporte a ferramentas e preços de token

Execução de código isolada com base em container

• Usando a ferramenta Container da Apple, que oferece isolamento total da VM para cada container em comparação ao Docker, o código gerado por IA pode ser executado com mais segurança
• O ambiente VM é implantado com servidor Jupyter e exposto via MCP, permitindo uso imediato em várias ferramentas (Claude Desktop, Gemini CLI etc.)
• O código do servidor MCP coderunner foi aberto com exemplos de integração com ferramentas externas
• A ferramenta Apple Container ainda é instável, exigindo reinícios repetidos quando surgem problemas de build/imagem
• Em testes práticos de edição de vídeo, foi verificado o funcionamento correto da combinação UI + LLM + coderunner

Integração de navegador headless

• Implantado navegador headless baseado em Playwright dentro do container e exposto como ferramenta MCP
• Espera-se uso para descoberta de novas ferramentas/informações, busca de uso do GitHub e automação de pesquisa
• Fluxo básico concluído: combinação de LLM local + execução de código em sandbox + navegador headless

Exemplos de tarefas possíveis

• Pesquisa e resumo de temas específicos
• Criação e renderização de gráficos CSV por comandos em linguagem natural
• Edição de vídeo com ffmpeg (corte de trechos etc.)
• Redimensionar, recortar e converter formato de imagem
• Instalação no container de ferramentas do GitHub
• Rastreamento e resumo de páginas web com navegador headless, entre outros

Montagem de volumes de arquivos e isolamento

• Mapear ~/.coderunner/assets do host para /app/uploads do container, com arquivos armazenados com segurança em espaço compartilhado
• O código em execução não consegue acessar diretamente o sistema host, garantindo segurança

Limitações e próximos passos

• Funciona apenas em ambiente Apple Silicon, e macOS 26 é opcional
• Melhorias em UI, como gerenciamento de ferramentas e streaming de saída, ainda são necessárias
• Há bloqueio em alguns sites por detecção de bot no navegador headless

Conclusão

• Este projeto é mais do que um experimento e é um modelo com foco em soberania computacional e proteção de privacidade
• Oferece uma experiência de processamento seguro de dados em uma máquina local pessoal sem dependência de nuvem ou servidor remoto
• Mesmo que os melhores LLMs permaneçam nos grandes clouds, o objetivo é avançar ferramentas de IA local que preservem a privacidade individual

• O projeto open source coderunner-ui está disponível no GitHub; feedback e colaboração são bem-vindos

Recursos relacionados

• assistant-ui
• instavm/coderunner
• Apple/container
• instavm/coderunner-ui

[wedding]

Concordo com a opinião de que isso é quase um hobby divertido. Mesmo depois de arrumar e personalizar de várias formas, não consegui alcançar a praticidade e a velocidade de uma solução comercial.

[GN⁺]

Opinião do Hacker News

• Sempre me atraiu esse ideal de “fazer tudo localmente”, mas, no fim das contas, com o desempenho dos modelos que tenho acesso e o custo de rodar na nuvem sob demanda, parece mais um hobby divertido do que uma estratégia prática. Como o hardware segue evoluindo rápido, comprar equipamento de segunda mão também cai de valor com a mesma velocidade, então sinto que investir em hardware não se justifica. Além disso, a performance dos pesos que rodam localmente também cai bastante, então não vale a pena agora. Espero que a situação mude algum dia e fico esperançoso em investir numa stack de inferência local quando bons pesos forem disponibilizados. Até lá, só fico “brincando” com um ativo caro que perde valor muito rápido.

  • Ultimamente eu estou curtindo muito o ecossistema de LLM local e o que as pessoas estão fazendo. Mas toda vez que executo LLMs locais no meu MacBook Pro com RAM absurda, sinto claramente a diferença em relação aos modelos frontier (SaaS LLM de ponta). Com cerca de US$20 por mês, paga-se por token e ganha-se acesso a diversos modelos de alta performance, com vantagem grande de velocidade e qualidade em relação ao local. Pelos gráficos de benchmark essa lacuna não fica tão óbvia, mas na prática os modelos frontier são claramente melhores. Mesmo os modelos da OpenAI e da Anthropic às vezes parecem lentos e com muitos erros, e isso só piora no local. É ótimo para hobbies ou experimentos em que privacidade importa, mas acho melhor esperar até sair um hardware melhor de verdade, como um Mac com 128GB de RAM, para mim.

  • Acredito que os modelos por trás de APIs, assim que começarem a ganhar dinheiro com as saídas, vão ter qualidade cada vez pior. Isso vai acontecer com o tempo.

  • Fiquei curioso sobre a justificativa de que “como o hardware muda rápido, não adianta comprar até usado, pois o valor despenca”. Em alguns casos, modelos podem continuar funcionando sem ter a configuração mais rápida possível. No fundo, é aquele clássico debate opex (despesas operacionais) versus capex (capital), e financeiramente a nuvem costuma ser vantajosa apenas em cenários bem específicos (quando precisa subir infraestrutura rápido e não dá para prever demanda). Para LLM isso não se aplica muito. O autor disse que investiu uns US$600, que equivale ao preço de cerca de três meses de EC2. Isso me deixou curioso se é possível sustentar o argumento dele com números.

  • Também estou no time de quem espera uma mudança. Tenho usado cada vez mais ferramentas como Claude Code no trabalho e não quero depender da empresa 24/7 para minhas tarefas de código. A preocupação com limites de plano, custo de API, pagar US$100–200 por mês e o medo de que todos os meus dados sejam coletados ou monitorados por uma empresa de IA é desagradável. Em casa inteligente, uso apenas produtos com controle local; quando preciso acessar de fora, configuro o próprio software para rodar no meu servidor. Não quero ficar preso a algo que pode ser desativado, ficar mais caro do dia para a noite ou até usar meus dados. Ainda assim, hoje não tenho motivação, custo, conhecimento ou manutenção para instalar LLM no meu hardware ou em VPS. Estou satisfeito em pagar US$20/mês à Anthropic, e os modelos abertos atuais estão muito abaixo dos SaaS frontier. Mesmo assim, espero que uma mudança venha.

  • Acho que essa situação não vai mudar nunca. Mesmo que em dois anos exista uma opção local no nível do GPT-5, também vão surgir opções muito melhores na nuvem e vamos estar discutindo o mesmo assunto novamente.

• Eu acho esse trabalho, que foca em execução local com camadas sandbox, uma peça grande do quebra-cabeça para construir um espaço de trabalho de IA privado. A ferramenta coderunner parece super útil. Mas também tem o outro desafio: a “camada de conhecimento” que faz a IA reconhecer e-mails, notas e arquivos pessoais. Com RAG, tratar alguns anos de e-mail já passa fácil de 50 GB apenas de armazenamento em banco vetorial. (Apenas como contexto: sou parte de uma equipe em Berkeley que trabalha para resolver esse problema.) Criamos um índice vetorial chamado LEANN e conseguimos reduzir o armazenamento em cerca de 97% sem armazenar os próprios embeddings. Isso fez com que seja realmente possível indexar toda a vida digital localmente. Combinar esse índice de conhecimento ultraleve com um engine de execução local parece o caminho para um verdadeiro “Jarvis local”. Código: https://github.com/yichuan-w/LEANN Artigo: https://arxiv.org/abs/2405.08051

  • Em 2025, 50 GB de banco de vetores para vários anos de e-mails parece uma exigência até modesta.

  • Obrigado por compartilhar as informações do LEANN. Tenho interesse em usar RAG como camada de conhecimento em agentes LLM, pipelines e engines de execução. Fiquei curioso se é possível integrar com codebases grandes, e espero porque já existe integração de soluções RAG com o Claude Code, o que abaixa bastante a barreira de teste. Queria perguntar se alguém já trabalhou com codebases grandes combinando RAG e LLM. Para o modelo LM de frontend, pretendo começar usando cloud e depois testar por conta própria. Referência: https://github.com/yichuan-w/LEANN/blob/main/packages/leann-mcp/README.md

  • Quase não entendo de embeddings ou estrutura de armazenamento vetorial. Fiquei curioso se existe algum projeto que aplica “pruned graph” também em embeddings de nuvem.

  • O fato de o índice ficar maior que os dados originais me parece estranho. Sempre achei que o índice existiria em formato mais eficiente para acesso rápido, então esse tamanho me parece estranho demais.

• Um dos motivos pelos quais, mesmo com um dos melhores LLMs, não fica tão fluido quanto esperado é que esses modelos pulam etapas, ignoram especificidades de plataforma e até pioram as coisas com alucinações. Isso demonstra a escassez de dados de treinamento para desenvolvimento de apps nativos. Há poucos posts longos sobre design de aplicativos nativos em blogs ou Medium, e o número de projetos open source de desktop é muito menor que o de mobile/web. Nos anos 90, a Microsoft contratava autores especializados e lançou ótimos livros de programação Windows (como os de Charles Petzold), mas essa indústria especializada praticamente desapareceu. Isso só amplia a lacuna de dados de treinamento no futuro. Isso é parecido com a tendência geral de engenharia de software: poucas pessoas querem construir apps nativos de desktop, e em termos de carreira é uma espécie de beco sem saída. Nos anos 90, ser desenvolvedor de app desktop Windows era garantia de vida de classe média e a barreira de entrada era alta (C/C++ era difícil, aprender Windows API era complexo e a MS injetava muito dinheiro em educação), mas isso mudou bastante. Hoje, exceto fornecedores de OS (Microsoft, Apple) ou alguns vendors legados (como Adobe, Autodesk), a demanda por apps desktop é mínima.

  • Fora áreas de computação de alto desempenho (HPC), o navegador funciona como uma VM universal a ponto de nem precisar criar apps desktop separados.

• Testei o app da Ollama para macOS de forma experimental e vi que, ao iniciar, ele tentou conectar com um domínio do Google. Isso torna difícil acreditar em “privacidade total”. https://imgur.com/a/7wVHnBA

  • Isso acontece por causa da checagem de atualização automática. https://github.com/ollama/ollama/blob/main/docs/faq.md

  • O fato de essas chamadas de rede serem auditáveis até ajuda na confiança. Basta rastrear automaticamente as chamadas de rede a cada atualização e isso é gerenciável.

  • No VSCode vi o mesmo com os plugins cline e copilot. Configurei para usar apenas o ollama local e, ao bloquear conexões outbound, nada funcionava. Mesmo com telemetria desativada nas configurações, o cline continuou tentando comunicação externa, o que foi decepcionante.

• Eu lembro disso mais vezes do que imaginava. Sinto que garantir privacidade envolve muita fricção e dificuldade.

  • Não acho que esse post tenha ajudado muito em resolver ou aliviar na prática essas preocupações.

• Eu ainda prefiro a abordagem local, porque a maior parte do tempo a inferência de IA é lenta ou não difere tanto do local. Depois de usar cerebras (e ouviu-se falar do groq também), experimentar uma velocidade da ordem de 1000 tokens/segundo mudou totalmente meu limiar de paciência com espera. Eles dizem que não registram dados; espero que você acredite que não tenho nenhum vínculo de patrocínio com eles (na verdade, queria que tivesse). Acho que é um serviço muito bom. Ainda assim, espero um avanço realmente significativo também em velocidade. Arquiteturas de modelo de difusão parecem ser especialmente rápidas.

  • Na minha visão, agora quem limita não é tanto software, mas hardware. Para rodar LLMs locais úteis, precisa de pelo menos US$2000 em hardware (ex.: Strix Halo, AI Max 395). Espero que fique bem mais fácil se o Strix Halo receber mais alguns upgrades.

    • Essas mudanças estão acontecendo muito rápido. https://simonwillison.net/2025/Jul/29/space-invaders/

    • Mesmo montando hardware nessa faixa de preço, ainda acho muito ambígua a definição do que é “útil”. Para a tecnologia fazer sentido de verdade, a experiência precisa funcionar instantaneamente, como se fosse mágica. Se você fica mexendo em configuração enquanto recebe resultados lentos e ambíguos, quase todo o valor já se perde. Modelos locais melhoraram bastante, mas em habilidade de programação ainda não batem modelos como Claude. Testei recentemente os modelos Qwen e GLM mais recentes do OpenRouter no cline e senti como se estivessem perto de um Claude 3.0. Acho que benchmarks não representam bem a realidade.

• A marca do produto e os posts do blog soam um pouco confusos. No site parece que rodam VM na nuvem (tipo Firecracker), mas no post de blog parece leitura de VM local dedicada ao Mac. Como eu tinha criado o primeiro cenário, fico com vontade de testar o segundo formato com o novo gpt-oss.

• Ao OP, deixei aqui que o link https://github.com/assistant-ui/assistant-ui está quebrado.

• Achei o projeto realmente legal e bem desenhado. Também estou construindo algo parecido, e o ponto central é facilitar a troca entre nuvem e ambiente totalmente local com uma tecla. Todos os dados, configurações e prompts ficam armazenados apenas localmente, e as chamadas de API são roteadas direto para o provedor, sem passar pelo nosso próprio servidor. Hoje já rodo inferência totalmente local no navegador com mlc-llm (o Qwen3-1.7b funciona muito bem). https://hypersonic.chat/