Todo en local: cómo construir un espacio de trabajo de IA offline

• Con ejecución local de LLM y entorno de sandbox de código se puede armar un workspace de IA sin dependencia de la nube
• Ejecuta un LLM local con Ollama, corre código en una VM aislada con Apple Container y habilita automatización y acceso a internet mediante un navegador headless con Playwright
• La UI se basa en assistant-ui, implementa selector desplegable de modelo e integración con ai-sdk, y crea un entorno de ejecución segura mediante MCP (Model Context Protocol)
• Dentro de la VM de Coderunner conectada por MCP se ejecutan Jupyter y un navegador para procesar generación de gráficos, edición de imágenes/video, instalación de herramientas de GitHub y búsquedas web con protección de privacidad
• Hoy solo funciona en Apple Silicon, y, como próximos pasos, se priorizan mejoras de UI, evasión de detección del navegador y fortalecimiento de la gestión de herramientas

---

Requisitos y contexto

• Objetivo: ejecutar todo de forma local, sin ejecución de código en la nube ni servicios remotos
• Las apps de chat de LLM existentes (por ejemplo, ChatGPT, Claude) ofrecen chat con LLM en la nube, ejecución de código en la nube/local y acceso a internet
• Con la expansión del uso de LLM de código abierto apareció la duda de si era posible hacer todo esto completamente en local
• Solo con un LLM local no basta, porque el código debe ejecutarse en un entorno aislado y se necesita acceso a contenido por navegador

Idea de diseño

• Ejecutar LLMs en un entorno completamente local
• Limitar la ejecución de código a una VM ligera para aislarla y evitar riesgos al sistema host
• Añadir un navegador headless para apoyar automatización y exploración de información y herramientas nuevas
• Construir un flujo de trabajo centrado en privacidad donde desde la planificación de IA hasta la ejecución de código se realiza localmente
• Ejecutar desde local tareas de edición de fotos, videos y otras sin entregar datos a servicios externos

Stack tecnológico

• LLM: Ollama (soporte de modelos locales y algunos modelos externos)
• UI: assistant-ui + ai-sdk (con soporte adicional para selección de modelo)
• VM runtime: Apple container (proporciona entorno VM aislado)
• Orquestación: instavm/coderunner (conexión del servidor Jupyter mediante MCP)
• Automatización de navegador: Playwright (expuesto como herramienta MCP)

Intento y cambio hacia app de Mac

• Se intentó desarrollar una app nativa de Mac con a0.dev, pero al estar enfocada en iOS se presentaron dificultades
• También se probó envolverla con Electron + NextJS, pero se descartó por complejidad
• Finalmente se migró a un assistant-ui web local

Personalización de Assistant-UI

• Se esperaba que ofreciera funciones como selector de modelo en desplegable y soporte de múltiples LLM, pero fue limitado
• Tras revisar ejemplos, se implementó la selección múltiple de modelos directamente con ai-sdk
• Al inicio también se contempló soportar modelos cloud como OpenAI/Anthropic, con una estrategia gradual de migración a local

Tool-calling y soporte de modelos

• Se necesitaba un modelo que soportara tool-calling, pero algunos como Ollama en la práctica no lo hacen
• Aunque la documentación oficial indique soporte de herramientas, muchas veces la implementación real queda corta
• La rápida evolución del ecosistema open source hace que haya mucha variación en soporte de tools y en precio de tokens

Ejecución de código aislada basada en contenedores

• Se usa la herramienta Container de Apple; a diferencia de Docker, al ofrecer una VM completamente aislada por contenedor se puede ejecutar con más seguridad código generado por IA
• Se despliega un servidor Jupyter en el entorno VM y se expone con Model Context Protocol (MCP), listo para ser consumido desde herramientas como Claude Desktop, Gemini CLI, entre otras
• Se publicaron los códigos del servidor MCP de coderunner y ejemplos de integración con herramientas externas
• La herramienta Apple Container todavía es inestable, por lo que ante problemas de build o imágenes se necesitan reinicios repetidos
• Se verificó funcionamiento correcto del combo UI + LLM + Coderunner en pruebas reales, como edición de video

Integración de navegador headless

• Se despliega un navegador headless basado en Playwright dentro del contenedor y se expone como herramienta MCP
• Se espera usarlo para explorar herramientas e información nueva, buscar cómo usar GitHub y automatizar investigación
• Flujo base completado: combinación de LLM local + ejecución sandbox de código + navegador headless

Casos de uso posibles

• Investigación y resumen de temas específicos
• Generación y renderizado de gráficos CSV con comandos en lenguaje natural
• Edición de video con ffmpeg (recorte de segmentos, etc.)
• Redimensionado, recorte y conversión de formato de imágenes
• Instalación de herramientas de GitHub dentro del contenedor
• Extracción y resumen de páginas web con navegador headless, entre otros

Montaje de volúmenes de archivos y aislamiento

• Se mapea ~/.coderunner/assets del host a /app/uploads en el contenedor, guardando los archivos en un espacio compartido seguro
• La ejecución de código no tiene acceso directo al sistema host, reforzando la seguridad

Limitaciones y próximos pasos

• Solo funciona en entornos Apple Silicon, con macOS 26 como opción
• Se requieren mejoras de UI para la gestión de herramientas y streaming de salida
• El navegador headless puede ser bloqueado en algunos sitios por detección de bots

Conclusión

• Este proyecto va más allá de un experimento y apuesta por un modelo centrado en soberanía computacional y protección de privacidad
• Entrega una experiencia de procesamiento seguro de datos en la máquina personal, sin depender de nube ni servidores remotos
• Aunque los mejores LLM puedan quedarse en grandes proveedores cloud, se orienta al desarrollo de herramientas de IA local que permitan proteger la privacidad personal

• coderunner-ui es open source y está disponible en GitHub; se reciben aportes y colaboración

Recursos relacionados

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

[wedding]

Estoy de acuerdo con la opinión de HN de que esto es más bien un pasatiempo divertido.
Aunque lo acomodes y arregles de mil formas, no logro igualar la comodidad y la velocidad de una solución comercial.

[GN⁺]

Comentarios de Hacker News

• Siempre me ha atraído ese idealismo de este tipo de experiencia, pero al final, considerando el rendimiento de los modelos a los que puedo acceder y el costo de ejecutar en la nube bajo demanda, me parece más un pasatiempo divertido que una estrategia realmente práctica.
  Como el hardware evoluciona tan rápido, incluso comprar equipos de segunda mano pierde valor a la misma velocidad, así que no se justifica invertir en hardware de forma seria.
  Además, el rendimiento de los pesos que corren en local cae bastante, así que hoy no tiene mucho sentido.
  Espero que la situación cambie algún día y tengo ilusión de invertir en una pila de inferencia local cuando se publiquen buenos pesos.
  Hasta entonces, terminarás entreteniendo activos caros que pierden valor rápidamente.

  • Yo últimamente disfruto mucho ver qué está pasando en el ecosistema de LLM locales y lo que la gente está haciendo.
    Pero cada vez que corro un LLM local directamente en mi MacBook Pro con RAM enorme, siento con más claridad la brecha con los frontier models (LLM SaaS más recientes).
    Con unos US$20 al mes pagas por token y puedes usar muchos modelos de alto rendimiento, pero en velocidad y calidad la diferencia con un modelo local sigue siendo grande.
    En las gráficas de benchmark esa brecha no se ve tan bien, pero en la práctica el modelo FRONTIER se siente mucho mejor.
    A veces también siento que modelos de OpenAI o Anthropic son lentos y tienen muchos errores, y al pasarte a local esa sensación se acentúa.
    Puede ser útil para hobbies o experimentos donde la privacidad importa, pero para mí mejor esperar a que salga hardware real, tipo 128 GB de RAM en el próximo MacBook.

  • Creo que cuando los modelos detrás de una API empiecen a ganar dinero con los resultados, la calidad de salida terminará empeorando cada vez más.
    Eso, en mi opinión, es solo cuestión de tiempo.

  • Me deja con dudas el argumento de que, como el hardware cambia rápido, sea inútil comprar algo sea de segunda mano o no.
    Pienso que hay casos donde un modelo puede seguir corriendo incluso sin la configuración más rápida.
    Al final, esto es el clásico debate de opex (costos operativos) vs capex (inversión de capital).
    Financiera y prácticamente, la nube suele ser ventajosa solo en escenarios muy puntuales (cuando necesitas subir infraestructura rápido y no tienes claridad de la demanda).
    En LLM, eso no encaja mucho.
    La OP dice que invirtió alrededor de US$600, pero eso equivaldría a tres meses de EC2.
    Con eso en mente, me pregunto si esas afirmaciones de la OP se pueden sustentar con números.

  • Yo también estoy en el lado de que esto cambiará.
    Últimamente estoy usando más cosas como Claude Code, y no quiero depender de la empresa para mis tareas de programación todos los días.
    No me gusta el límite de plan, el costo de API, el pagar $100–200 mensuales, o el riesgo de que toda la data que uso sea recopilada o vigilada por una compañía de IA.
    Con productos de smart home, solo uso los que tengan control local, y si necesito acceso externo lo configuro con mi propio software en mi servidor.
    No quiero quedarme atado a algo que un día pueda apagarse, subir precio o usar mis datos.
    Aún así, hoy no tengo motivación, presupuesto, conocimiento ni ganas para instalar un LLM en mi hardware o en un VPS.
    Me siento cómodo pagando US$20 mensuales por Anthropic, y los modelos abiertos actuales no alcanzan a los SaaS de nivel frontier.
    De todos modos, sigo con la esperanza de que haya un cambio en el futuro.

  • Yo creo que esta situación no va a cambiar nunca.
    Aunque aparezca en dos años una opción local al nivel de GPT-5, para ese momento habrá opciones mucho mejores del lado de la nube, y seguiríamos con la misma preocupación.

• Creo que este trabajo, al enfocarse en una capa de ejecución local y aislada, es una gran pieza para armar un workspace de IA privado de verdad.
  La herramienta coderunner se ve súper útil.
  Sin embargo, otro reto es la 'capa de conocimiento', que permita que la IA reconozca datos personales como mi correo, notas y archivos.
  Con RAG, para manejar varios años de email se superan fácilmente 50 GB de almacenamiento en una base vectorial.
  (Por cierto, yo soy parte de un equipo en Berkeley que trabaja en resolver este problema).
  Construimos un índice vectorial llamado LEANN y logramos no almacenar ni siquiera los embeddings, ahorrando hasta un 97% de almacenamiento.
  Eso hizo que indexar toda mi vida digital localmente sea realmente posible.
  Combinar ese índice de conocimiento ultraligero con un motor de ejecución local se siente como el camino hacia un “Jarvis local” de verdad.
  Código: https://github.com/yichuan-w/LEANN
  Paper: https://arxiv.org/abs/2405.08051

  • Para 2025, unos 50 GB de base vectorial para varios años de correo me parece, más bien, una demanda bastante modesta.

  • Gracias por compartir información de LEANN.
    Me interesa especialmente usar RAG como capa de conocimiento para agentes LLM, pipelines y motores de ejecución.
    Tenía curiosidad de si es posible integrar LLM con una base de código grande, y me anima saber que la solución de RAG ya se integra con Claude Code, porque reduce la barrera para hacer pruebas.
    Me gustaría saber si alguien aquí ya trabajó con LLM + RAG en una base de código grande.
    Por ahora voy a empezar usando modelos frontend (LM) en la nube, y planeo probarlo yo mismo.
    Referencia relacionada: https://github.com/yichuan-w/LEANN/blob/main/packages/leann-mcp/README.md

  • No sé mucho de embeddings ni de la estructura de almacenamiento vectorial.
    Tengo curiosidad si existe algún proyecto que aplique este tipo de enfoque de “pruned graph” en embeddings de la nube.

  • Me suena raro que el índice termine siendo más grande que los datos originales.
    Uno suele pensar que el índice existe en un formato más eficiente para acceso rápido, así que que llegue a este punto me resulta extraño.

• Uno de los motivos por los que, incluso con una “LLM top”, no se siente tan fluido es que esos modelos omiten pasos, ignoran particularidades por plataforma y en lugar de resolver, amplifican el problema con alucinaciones.
  Eso demuestra bien que hay pocos datos de entrenamiento para el desarrollo de apps nativas.
  Hay muy pocos artículos largos en blogs o Medium sobre diseño de apps nativas, y también hay muy pocos proyectos de código abierto de apps de escritorio comparados con mobile/web.
  En los 90, MS publicaba libros excelentes sobre programación en Windows (con autores como Charles Petzold), pero esa industria especializada prácticamente desapareció.
  Creo que ese hueco en datos de entrenamiento seguirá creciendo.
  Al final, se parece al flujo general de ingeniería de software: hay poca gente intentando hacer apps nativas de escritorio y, para una carrera, se ve como un callejón sin salida.
  En los 90, incluso aunque el desarrollador de apps de escritorio de Windows podía vivir cómodamente en clase media y aunque la barrera de entrada era alta (C/C++ es difícil y aprender la API de Windows también), Microsoft invertía muchísimo en educación; hoy la situación cambió bastante.
  Hoy, salvo proveedores de OS (Microsoft, Apple) y algunas compañías legacy de software (Adobe, Autodesk), la demanda por apps de escritorio es mínima.

  • Fuera de HPC, en general no hace falta hacer apps de escritorio por separado, porque el navegador ya actúa como la VM más universal.

• Probé la app de Ollama para macOS y al arrancar vi que intentaba conectarse a un dominio de Google de inmediato.
  Eso hace difícil creer en la “privacidad total”.
  https://imgur.com/a/7wVHnBA

  • Es por el chequeo de actualizaciones automáticas.
    https://github.com/ollama/ollama/blob/main/docs/faq.md

  • Esas llamadas de red me parecen más confiables justamente porque se pueden auditar.
    Es totalmente manejable si rastreas esas llamadas de red automáticamente en cada actualización.

  • También vi lo mismo con los plugins cline y copilot en VSCode.
    Si configuras para usar solo ollama local y bloqueas conexiones salientes, deja de funcionar por completo.
    Me decepcionó que incluso con telemetry apagada en la configuración, cline siga intentando comunicarse hacia afuera.

• De verdad, este tema se me cruza en la cabeza más seguido de lo esperado.
  Siento que asegurar privacidad trae mucha fricción y dificultad.

  • No creo que este post ayude mucho a aportar una solución concreta para esas preocupaciones.

• Aún así prefiero seguir con el enfoque local, porque siento que la mayoría del tiempo la inferencia de IA es lenta o no difiere tanto de local.
  Habiendo probado cerebras (y también escuché de groq) y experimentado velocidades como 1000 tokens/segundo, mi umbral de paciencia para esperar cambió por completo.
  cerebras dice que no retiene datos y espero que confíes en que no tengo ninguna relación de patrocinio con ellos (de hecho, me encantaría que sí la hubiera).
  Realmente creo que es un servicio muy bueno.
  De todos modos, espero que haya mejoras reales y significativas también en velocidad.
  Las arquitecturas de modelos de difusión se sienten especialmente rápidas.

• Creo que ahora mismo el límite está más en el hardware que en el software.
  Para ejecutar LLMs útiles en local, se necesita al menos alrededor de US$2000 en hardware (por ejemplo, Strix Halo, AI Max 395).
  Creo que será mucho más fácil cuando Strix Halo reciba unas cuantas actualizaciones más.

  • De hecho, este cambio está pasando muy rápido.
    https://simonwillison.net/2025/Jul/29/space-invaders/

  • Incluso con hardware de ese precio, me parece ambiguo qué cuenta como “útil”.
    Para que esta tecnología sea realmente valiosa, la experiencia tiene que funcionar como por arte de magia, al instante.
    Si te pasa el tiempo ajustando cosas y recibiendo resultados lentos y ambiguos, prácticamente todo el valor desaparece.
    Los modelos locales han mejorado bastante, pero en capacidad de código todavía no llegan al nivel de modelos como Claude.
    Probé recientemente OpenRouter con los modelos más recientes de Qwen y GLM en cline y sentí que estaban en un nivel similar al de Claude 3.0.
    Sigo pensando que los benchmarks no reflejan bien la realidad.

• La forma en que se presenta la marca del producto y lo que dice el blog me confunde un poco.
  En la web se da a entender que levantan una VM en la nube (como Firecracker),
  pero en el blog se interpreta como que ejecutan una VM local solo para Mac.
  Desde el lado de alguien que hizo la primera opción, me gustaría experimentar la segunda con la nueva apuesta gpt-oss.

• Le aviso al OP que el enlace https://github.com/assistant-ui/assistant-ui no funciona.

• Creo que es un proyecto súper bien diseñado y realmente bonito.
  También estoy construyendo algo parecido, y la clave es que sea fácil moverse entre nube y entorno totalmente local con una sola tecla.
  Todos los datos/configuraciones/prompts se guardan solo en local, y las llamadas a API se enrutan directamente al proveedor sin pasar por nuestro servidor.
  Actualmente usamos inferencia totalmente local en navegador con mlc-llm (Qwen3-1.7b funciona muy bien).
  https://hypersonic.chat/