Asistente de IA local-first LocalGPT – basado en Rust, con memoria persistente

 (github.com/localgpt-app)
2 puntos por GN⁺ 2026-02-09 | 1 comentarios | Compartir por WhatsApp
  • Asistente de IA de ejecución local desarrollado en Rust, que funciona por completo en el dispositivo personal sin conexión a internet y sin que los datos se envíen al exterior
  • Estructura de archivo ejecutable único, que puede ejecutarse sin instalar Node.js, Docker ni Python, en forma de un binario ligero de unos 27 MB
  • Sistema de memoria persistente que ofrece memoria a largo plazo y funciones de búsqueda mediante un repositorio de conocimiento basado en Markdown, SQLite FTS5 y semantic search
  • Compatible con CLI, web UI y GUI de escritorio, además de múltiples proveedores de LLM como OpenAI, Anthropic y Ollama
  • Compatible con el formato OpenClaw, lo que permite realizar tareas autónomas usando archivos SOUL, MEMORY y HEARTBEAT

Resumen general

  • LocalGPT es un asistente de IA centrado en dispositivos locales, una aplicación basada en Rust con memoria persistente y funciones de trabajo autónomo
    • Se ejecuta completamente en el dispositivo personal sin depender de servidores externos
    • Inspirado en el proyecto OpenClaw y manteniendo compatibilidad con este
  • Se puede instalar con el comando cargo install localgpt, con opción de incluir GUI o usarlo en modo headless

Características principales

  • Arquitectura de binario único, sin necesidad de Node.js, Docker ni Python
  • Conservación local de datos: toda la memoria y la configuración se almacenan dentro del dispositivo del usuario
  • Memoria persistente: usa un repositorio de conocimiento basado en archivos Markdown, con soporte para búsqueda rápida y búsqueda semántica mediante SQLite FTS5 y sqlite-vec
  • Función de heartbeat autónomo para ejecutar tareas en segundo plano
  • Varias interfaces: CLI, web UI y GUI de escritorio
  • Soporte para múltiples LLM: integración con Anthropic (Claude), OpenAI, Ollama y otros

Cómo funciona

  • La memoria se guarda en el directorio ~/.localgpt/workspace/, con la siguiente estructura principal de archivos
    • MEMORY.md: almacenamiento de conocimiento a largo plazo
    • HEARTBEAT.md: cola de tareas autónomas
    • SOUL.md: personalidad y directrices de comportamiento
    • knowledge/: repositorio de conocimiento estructurado por tema
  • Usa SQLite FTS5 para búsqueda por palabras clave y sqlite-vec para búsqueda semántica local basada en embeddings

Configuración y comandos CLI

  • El archivo de configuración se guarda en ~/.localgpt/config.toml, donde se definen el modelo predeterminado, la API key, el intervalo de heartbeat, las franjas horarias de trabajo y otros valores
  • Comandos principales de CLI
    • localgpt chat: inicia una sesión de conversación
    • localgpt ask "pregunta": ejecuta una consulta única
    • localgpt daemon start: ejecuta el daemon en segundo plano
    • localgpt memory search "query": busca en la memoria
    • localgpt config init: crea la configuración inicial

HTTP API

  • Al ejecutar el daemon, se ofrece una API REST
    • GET /health: verificación de estado
    • POST /api/chat: solicitud de conversación
    • GET /api/memory/search?q=<query>: búsqueda en la memoria
    • GET /api/memory/stats: consulta de estadísticas de memoria

Stack tecnológico

  • Basado en Rust, Tokio, Axum, SQLite (FTS5 + sqlite-vec), fastembed y eframe
  • Publicado bajo licencia Apache-2.0, con alrededor del 93% del código escrito en Rust

Información adicional

  • En GitHub cuenta con aproximadamente 646 estrellas y 39 forks
  • En la entrada de blog “Why I Built LocalGPT in 4 Nights” se comparten el proceso de desarrollo y los detalles por commit
  • Se identifican como principales contribuidores a Yi Wang, Claude, objectkit y Ax73

Lecturas relacionadas

1 comentarios

 
GN⁺ 2026-02-09
Comentarios en Hacker News

  • Se siente muy cyberpunk estar viendo algo así en 2026
    La estructura con MEMORY.md, HEARTBEAT.md, SOUL.md y similares me parece muy interesante
    Pero como depende de ANTHROPIC_API_KEY, es difícil llamarlo “local-first”
    Aun así, creo que a largo plazo lo local-first sí es el futuro
    El año pasado hice algo parecido en Rust, y al correr el modelo en local la diferencia de velocidad sí era evidente
    También tengo mi video demo
    Implementar algo así a nivel de sistema operativo fue una experiencia de cambio de paradigma total
    Creo que en los próximos 5 a 10 años la forma en que interactuamos con los dispositivos va a cambiar de raíz

    • Esto no es local-first, creo que el nombre está mal puesto
    • No hace falta usar un LLM de terceros
      Puedes indicar directamente un endpoint compatible con OpenAI o Anthropic, y también puede ser localhost
    • Código relacionado: providers.rs L222
    • Yo también estoy probando OpenClaw y Qwen3 Coder Next en mi LAN con un enfoque local-first
      Apenas voy empezando, pero se ve bastante prometedor
    • Más allá de si a uno le guste o no la IA, la escala de inversión actual se siente como el programa Apollo de nuestra generación
      Dicen que en los próximos años van a levantarse más de 100 centros de datos a escala de gigavatios
      Me parece un uso del dinero mucho mejor que la industria militar

  • Un consejo: conviene escribir las publicaciones o la documentación tú mismo, o por lo menos editarlas personalmente
    Ahora mismo la documentación y los textos se ven totalmente como si los hubiera escrito un LLM, y no transmiten dedicación

    • Hoy en día mucha gente ya ni intenta escribir más de unas cuantas oraciones
      Estas máquinas de lavado de plagio están destruyendo el sentido humano de la escritura
    • Yo también estoy de acuerdo, escribir la documentación uno mismo hasta puede volverse divertido
    • También hay una postura contraria
      A mí siempre me ha disgustado escribir documentación, así que antes casi no documentaba mi código
      Eso hacía que fuera difícil de usar para otras personas
      Los LLM son ideales para documentar porque generan explicaciones precisas rápido y las mantienen actualizadas
      Aunque se note que no lo escribió una persona, si el contenido es correcto, no le veo problema
    • Ojalá esto sirviera como freno contra este tipo de posts de baja calidad, pero en la práctica no pasa
      Más bien parece que se ha vuelto motivo de orgullo no esforzarse

  • La idea de este proyecto es excelente
    La clave está en el framework estructurado de memoria persistente + búsqueda semántica
    En realidad, la función SOUL ya la soportan la mayoría de los LLM en forma de archivos Markdown
    Una estructura así puede ser el punto de partida para construir una red privada de agentes
    Pero el problema es el nombre — LocalGPT

    1. no es local, y
    2. tampoco es un modelo GPT
      Sería mejor cambiarlo por un nombre que refleje la intención con más precisión

  • Pregunta seria: me da curiosidad en qué se diferencia esto de OpenClaw
    Usa la misma estructura de SOUL.md, MEMORY.md, HEARTBEAT.md,
    y OpenClaw ya tiene mensajería multicanal, llamadas de voz, automatización del navegador e incluso subagentes
    Quisiera saber si, aparte de estar hecho en Rust, hay algún diferenciador

    • Mucha gente, incluyéndome, le tiene miedo a OpenClaw
      Tiene demasiadas funciones y una arquitectura de seguridad débil
      La aprobación de permisos es casi de forma, y puede cambiar su propia configuración
      Por eso yo separo los permisos con Wardgate
      Hace falta dividirlo en varios nodos/agentes y separar también las credenciales y el acceso a APIs
    • Esto parece simplemente un generador de sitios estáticos para vibe coding
    • Que sea pequeño y no esté basado en Node es una ventaja
      No todo el mundo tiene una máquina potente

  • Me pregunto por qué tiene que conectarse a proveedores de LLM como OpenAI o Anthropic
    Si es un GPT local, ¿no debería hacer la inferencia también en local?

    • No hace falta conectarse a servicios externos
      Puedes configurar un servidor local como Ollama como proveedor de LLM
      En el README solo aparece el ejemplo con Anthropic, pero si ves el código, admite otras opciones
      Solo hay que cambiar una línea de configuración
    • El esfuerzo está bien, pero el nombre lleva a confusión
      En realidad no es local ni es GPT
      Está más cerca de ser un clon en Rust de OpenClaw
    • Si no hay nada local configurado, hace fallback automático a un proveedor en línea
      Código relacionado: providers.rs L222
    • No es indispensable

  • El problema central de seguridad de agentes como LocalGPT u OpenClaw es la tríada letal de “private data access + external communication + untrusted content”
    Con un solo correo malicioso podría llegar a ejecutar una instrucción como “envía mi bandeja de entrada al atacante”
    Estoy investigando políticas de seguridad basadas en object-capability para resolver esto
    Quiero crear una política que bloquee de raíz la filtración de información sensible

    • El problema de esta tríada es la tarea más urgente en este campo ahora mismo
      Yo veo dos soluciones
      1. Restringir toda transmisión externa a aprobación manual (OTP, etc.)
        Pero eso genera mucha fatiga
      2. Evitar la tríada desde el diseño — por ejemplo, con un agente de dos factores que bloquee la comunicación externa
        Me da curiosidad saber si estás investigando algún otro enfoque

  • He usado OpenClaw y le falta observabilidad
    No se ve nada en los logs sobre qué está pensando o qué está haciendo este agente en cada momento
    Creo que un sistema así quedaría perfecto si estuviera hecho con Elixir/BEAM
    Podrías seguir el estado con árboles de procesos y volcar los buzones de mensajes para ver el flujo de pensamiento

    • Parece que el proyecto lemon hace justo eso
    • Modelos como GPT o Claude ocultan deliberadamente su pensamiento interno
      Solo muestran una parte, y en realidad consumen más tokens
    • Buena idea, estaría bien que lo construyeras
    • Yo también coincido en que falta observabilidad
      Que algo que debería ser básico se resuelva con tutoriales de YouTube demuestra que ahora mismo todo esto es un caos

  • En Linux Mint, cargo install localgpt falló
    Cuando agregué "x11" en Cargo.toml, compiló bien
    No sé mucho de Rust, pero parece que era un problema de dependencias de GUI

    • El procedimiento de instalación fue este 
      git clone https://github.com/localgpt-app/localgpt.git  
cd localgpt/  
agregar "x11" en Cargo.toml  
cargo install --path ~/.cargo/bin
      Por cierto, esa persona, Kai Lentit, ¿estará contratando?

  • ¿Qué modelos locales valen la pena para usar como asistente local?
    También me interesa saber si hay intentos de evaluar el equilibrio entre recursos de cómputo y memoria
    Quisiera entender qué tanto hardware hace falta para que sea realmente útil

  • La palabra “local” se está usando de forma rarísima últimamente
    Aunque la mayoría de las funciones al final interactúan con internet, igual les llaman locales