1 puntos por GN⁺ 4 시간 전 | 1 comentarios | Compartir por WhatsApp
  • zerostack es un agente de programación minimalista escrito en Rust, con soporte para varios proveedores de LLM y proveedores personalizados
  • Ofrece lectura, escritura y edición de archivos, grep, búsqueda de archivos, listado de directorios, ejecución de Bash con compuerta de permisos, MCP y herramientas web de Exa
  • Tiene alrededor de 7 mil LoC, un binario de 8.9 MB, y usa cerca de 8 MB de RAM en una sesión vacía y 12 MB durante el trabajo; el CPU en reposo se midió en 0.0%
  • El proveedor predeterminado es OpenRouter, se instala con cargo install zerostack, y para usar aislamiento de Bash con --sandbox se necesita bubblewrap
  • Incluye prompts integrados como code, plan y review, 4 modos de permisos, reanudación de sesiones, bucle iterativo e integración con Git worktrees

Resumen de zerostack

  • zerostack es un agente de programación minimalista escrito en Rust e inspirado en pi y opencode
  • Tiene una arquitectura multi-proveedor compatible con OpenRouter, OpenAI, Anthropic, Gemini, Ollama y proveedores personalizados
  • Ofrece herramientas de archivos como lectura, escritura y edición de archivos, grep, búsqueda de archivos y listado de directorios, además de ejecución de Bash con compuerta de permisos
  • Incluye guardado, carga y reanudación de sesiones, compresión automática para mantener la ventana de contexto, una UI de terminal basada en crossterm, conexión a servidores MCP y herramientas WebFetch y WebSearch basadas en Exa
  • Permite moverse entre Git worktrees con /worktree y también integra un bucle iterativo para trabajos de larga duración

Rendimiento e instalación

  • zerostack tiene unas 7 mil LoC y un tamaño de binario de 8.9 MB
  • El uso de RAM es de alrededor de 8 MB en una sesión vacía y de 12 MB durante el trabajo, frente a unos 300 MB de opencode u otros agentes de programación basados en JS
  • El uso de CPU se midió en 0.0% en reposo y cerca de 1.5% durante el uso de herramientas; en un Intel i5 de 7.ª generación, opencode se comparó con cerca de 2% en reposo y 20% durante el trabajo
  • Para instalarlo se necesitan Cargo y git, y se usa el siguiente comando
    cargo install zerostack  
    
  • Si se usa --sandbox, es necesario instalar bubblewrap para ejecutar todos los comandos Bash en un entorno aislado
    # Debian/Ubuntu  
    apt install bubblewrap  
    
    # Fedora  
    dnf install bubblewrap  
    
    # Arch  
    pacman -S bubblewrap  
    

Inicio rápido

  • El proveedor predeterminado es OpenRouter y la clave API se configura como variable de entorno
    export OPENROUTER_API_KEY="[api_key]"  
    
  • La sesión interactiva se ejecuta con el prompt predeterminado code
    zerostack  
    
  • El modo de ejecución única pasa el prompt con -p
    zerostack -p "Explain this project"  
    
  • La última sesión se reanuda con -c
    zerostack -c  
    
  • Se puede especificar el proveedor y el modelo
    zerostack --provider openrouter --model deepseek/deepseek-v4-flash  
    

Sistema de prompts

  • zerostack incluye un conjunto de prompts de sistema integrados que cambian el comportamiento y el tono del agente
  • El objetivo es crear una familia de prompts que pueda reemplazar a superpower o las skills oficiales de Claude
  • Con /prompt se pueden listar los prompts registrados o cambiar a otro prompt
  • Prompts integrados

    • code es el valor predeterminado y es un modo de programación con acceso completo a archivos y herramientas de Bash, usando un flujo TDD
    • plan es un modo exclusivo de planificación que explora y luego crea un plan sin escribir código
    • review es un modo de revisión de código que evalúa exactitud, diseño, pruebas e impacto
    • debug es un modo de depuración que busca la causa raíz antes de proponer una corrección
    • ask es un modo de solo lectura y solo permite read, grep y glob, sin escritura ni Bash
    • brainstorm es un modo exclusivo de diseño para explorar ideas y proponer diseños sin escribir código
    • frontend-design es un modo de diseño frontend para UI distintivas y listas para producción
    • review-security es un modo de revisión de seguridad para encontrar vulnerabilidades explotables
    • simplify es un modo de simplificación de código que mejora la claridad sin cambiar el comportamiento
    • write-prompt es un modo de redacción de prompts para crear y optimizar prompts de agente
    • Los prompts personalizados pueden crearse colocando archivos Markdown en $XDG_CONFIG_HOME/zerostack/prompts/ y referenciándolos por nombre
    • Lee automáticamente AGENTS.md o CLAUDE.md en la raíz del proyecto o en directorios superiores y los inserta en el prompt del sistema; esto puede desactivarse con -n o --no-context-files

Sistema de permisos

  • zerostack ofrece 4 modos de permisos, desde el más seguro hasta el más permisivo
  • Modos de permisos

    • restrictive o -R solicita aprobación para cada acción de herramienta que no esté permitida explícitamente en la configuración
    • standard es el valor predeterminado; aprueba automáticamente comandos seguros como ls, cd, git log y cargo check, y pide confirmación para escritura y operaciones destructivas
    • accept-all o --accept-all aprueba automáticamente todas las operaciones dentro del directorio de trabajo y pide confirmación para rutas externas
    • yolo o --yolo aprueba automáticamente todas las operaciones sin prompts
    • En el archivo de configuración se pueden especificar patrones glob por herramienta para ajustar los permisos de forma granular
    • Por ejemplo, se puede permitir automáticamente write **.rs mientras que la escritura en otros archivos siempre requiere confirmación
    • La lista de permisos de sesión conserva las decisiones aprobadas durante la sesión para no volver a confirmar la misma acción
    • Si la misma llamada de herramienta se repite 3 veces o más, la detección de doom-loop muestra un prompt de advertencia o la rechaza según la configuración, para evitar que el agente repita operaciones destructivas

Comandos slash y gestión de sesiones

  • Los principales comandos slash controlan el modelo, el nivel de razonamiento, la conversación, la sesión, el bucle, los prompts y el modo de permisos
  • /model cambia el modelo y /thinking establece el nivel de razonamiento
  • /clear limpia la conversación y /session lista, guarda y carga sesiones
  • /loop programa un prompt iterativo y /prompt lista o cambia los prompts del agente
  • /mode configura el modo del sistema de permisos y los comandos completos pueden verse con /help
  • Las sesiones se guardan en $XDG_DATA_HOME/zerostack/sessions/
  • -c reanuda la sesión más reciente, -r permite explorar y elegir una sesión, y --session <id> carga una sesión específica

Bucle iterativo

  • zerostack incluye un bucle iterativo de programación para trabajos de larga duración
  • El agente lee repetidamente la tarea, elige elementos del plan, realiza el trabajo, ejecuta pruebas, actualiza el plan y continúa el bucle hasta completar la tarea o alcanzar el límite de iteraciones
  • El sistema de bucles es una función experimental
  • Cómo usar el bucle

    • /loop Implement the user authentication system inicia un bucle con el prompt especificado
    • /loop stop detiene el bucle activo
    • /loop status muestra el estado actual del bucle
    • Cada iteración incluye la tarea original, el archivo cambiante LOOP_PLAN.md, el resumen de iteraciones anteriores y la salida de verificación
    • Mientras el bucle está activo, se bloquea toda entrada que no sea un comando slash
  • Bucle headless basado en CLI

    • Se puede ejecutar un bucle headless con el siguiente comando
      zerostack --loop --loop-prompt "Refactor the API" --loop-max 10 --loop-run "cargo test"  
      
    • --loop activa el modo de bucle headless
    • --loop-prompt <text> especifica el prompt que se usará en cada iteración
    • --loop-plan <path> especifica la ruta de un archivo de plan personalizado; el valor predeterminado es LOOP_PLAN.md
    • --loop-max <N> especifica el número máximo de iteraciones; el valor predeterminado es sin límite
    • --loop-run <cmd> especifica el comando de verificación que se ejecutará después de cada iteración

Integración con Git worktrees

  • zerostack ofrece un flujo de trabajo de trabajo por rama con git worktrees
  • Se pueden crear worktrees, trabajar dentro de ellos, hacer merge y salir, todo desde la UI del chat
  • La integración con Git worktrees es una función experimental
  • Comandos de worktree

    • /worktree <name> crea un git worktree en la rama <name> y se mueve allí; si ya existe, omite la creación
    • /wt-merge [branch] fusiona la rama del worktree en [branch], hace push, limpia y luego vuelve al repositorio principal
    • /wt-exit vuelve al repositorio principal sin hacer merge
  • Flujo de trabajo de ejemplo

    • /worktree feature-x crea una nueva rama y un directorio worktree, y luego se mueve allí
    • Después, se puede usar zerostack como de costumbre y los cambios quedarán en la rama feature
    • /wt-merge hace que el agente fusione la rama, haga push, limpie y vuelva al repositorio principal
    • /wt-exit vuelve de inmediato al repositorio principal sin fusionar

Proveedores compatibles y licencia

  • El proveedor predeterminado es OpenRouter
  • Compatible con proveedores tipo OpenAI como vLLM y LiteLLM
  • Compatible con Anthropic, Gemini y Ollama
  • Los proveedores personalizados pueden configurarse en $XDG_CONFIG_HOME/zerostack/config.json con cualquier base URL y una variable de entorno para la clave API
  • La licencia es GPL-3.0-only

1 comentarios

 
GN⁺ 4 시간 전
Opiniones de Hacker News
  • No conozco muy bien estas herramientas, pero me da curiosidad saber qué ventajas tiene frente a modelos/herramientas como Claude Code

  • Yo estaba haciendo algo parecido por mi cuenta en mi tiempo libre, con la idea de entender más a fondo los agentes y de paso aprender Rust
    Eso sí, quería mantener la configurabilidad de pi. Me parece muy útil la capacidad de modificarse a sí mismo y crear nuevas herramientas, y porque creo que este tipo de herramientas no debería tener permisos para ejecutar código arbitrario mediante bash
    Claro, si tiene acceso a edit y cargo run, igual todavía puede ejecutar código arbitrario, pero cuando aparece algo que un agente sin bash necesita hacer, prefiero crear herramientas sobre la marcha

    • Pensé en ese problema, pero Pi está basado en TypeScript, así que puede tener una especie de entorno de scripting, mientras que Rust es un lenguaje compilado, así que tiene limitaciones
      Por eso decidí permitir la personalización de otra manera. La biblioteca de prompts en ~/.config/hypernova/prompts/ es una alternativa simple a Skills, y los prompts integrados deberían reemplazar superpowers y frontend-design de Claude
      Las funciones que podrían volver pesado al agente se pueden desactivar al compilar mediante feature flags, y como el código es corto y fácil de leer, si hace falta puedes correr zerostack sobre el propio código fuente de zerostack para crear un fork personalizado
      En cuanto al modelo de permisos, después de pensarlo bastante, como se ve en el README, lo hice en 4 niveles: desde “Restrictive”, sin comandos, hasta “YOLO”, donde el agente hace lo que quiera, y también se pueden definir regex de permitir/preguntar/rechazar para llamadas a bash. En ese caso, basta con ejecutar zerostack -R para forzar que todas las herramientas pidan permiso
      También estoy trabajando en funciones de agente programable, pero todavía no están listas para anunciarlas
    • Yo también estoy haciendo algo igual en Zig
  • Hace poco hice una, medio en broma y medio en serio, de menos de 200 líneas: https://github.com/pnegahdar/nano
    Tiene REPL, sesiones, ejecución no interactiva, aprobaciones y cosas así. A medida que los modelos se vuelven más inteligentes, creo que la importancia del harness baja, salvo por la experiencia de desarrollo
    Algún día quizá la corra en SWE-bench

    • Está increíble que la hayas hecho en 200 líneas, bueno, en realidad 190
      Yo también hice una por diversión y aprendizaje la semana pasada, y hasta funciona con integración a mcpServers configurados, como la mayoría de los agentes de código
      Dejé anotado qué hace falta y por qué, paso por paso: https://nb1t.sh/building-a-real-agent-step-by-step/
  • “RAM footprint: ~8MB on an empty session, ~12MB when working”
    Esa parte me encanta. Claude Code usa varios GB y eso en laptops de bajos recursos es bastante desesperante

    • Estoy haciendo un framework de agentes en Go y es súper ligero
      Arranca en menos de 0.5 segundos y el uso de RAM también es bajísimo. Corre sin volverse lento incluso en una laptop de 12 años
      Algo que en esencia se parece más a un motor de concatenación de strings no debería ir lento en ningún equipo, incluyendo hardware viejo
    • Estoy intentando pasarme a Zed y el Agent Client Protocol se ve bastante bien. Me pregunto cuánto bajaría la presión de memoria si Claude Code pasara por ese enfoque
      1: https://zed.dev/acp
    • Sí. Solo ese hecho probablemente va a hacer que mucha gente lo pruebe
    • El uso de memoria es excelente, así que ahora ya se pueden correr agentes de código incluso en instancias muy pequeñas como la x1 de shellbox.dev
    • Habría que revisar que no haya algo como un plugin de LSP corriendo también
  • Voy a probarlo cuando llegue a casa. Las herramientas ligeras y rápidas hacen una gran diferencia en la experiencia de programar
    Me da curiosidad cómo funciona el enfoque de prompts en la práctica comparado con la combinación típica de skills y subagentes. Yo suelo mezclarlo mucho: si falla el build, ejecuto una skill /fix-ci, y hago que un subagente saque los mensajes de error, el stack trace y los logs relevantes para resolver el problema
    Si en una prueba de integración aparece un problema con consultas a la base de datos, el agente —o yo dándole un pequeño empujón— también puede invocar una skill de acceso de solo lectura a la BD para investigar
    Cuando hay que escarbar mucho y por bastante tiempo, digo cosas como “usa un subagente Sonnet y dile que depure este comportamiento con la skill de consultas a la BD”
    Las skills agregan capacidades sobre la marcha, y los subagentes aíslan contexto para evitar que se infle demasiado. Supongo que si el agente se ejecuta a sí mismo con bash y otro prompt se podría lograr algo parecido, aunque quizá sería un poco menos fluido; tendría que probarlo

    • En su mayoría se usa como skills, pero conviene pensarlo como un entorno más que como un “comando”
      Por ejemplo, uno de los prompts integrados, /prompt debug, abre un agente enfocado en depuración, y desde ahí puedes seguir conversando como con un agente normal y luego volver al agente estándar de código con /prompt code
      Los subagentes todavía no están soportados porque por ahora todo el agente corre dentro de un solo buffer de contexto y quiero mantenerlo liviano. Pero como las tareas con mucha exploración suelen inflar la ventana de contexto con frecuencia, es bastante probable que se agreguen subagentes
  • Yo también hice que Claude Code me armara algo así, y para la edición incluso le metí el hashing por líneas de Dirac
    Lo hice en Rust, y pensé en permitir autorreparación con hooks vía plugins, pero al final lo dejé en que generara un archivo aparte con información detallada sobre mejoras, actualizara el código fuente y luego recompilara
    Como la ubicación del código fuente es fija, el agente puede reescribirse y volver a compilarse a sí mismo. Lo uso corriendo DeepSeek 4 Flash en 2x RTX 6000 Pro y me da más o menos 138 tok/s
    La verdad, básicamente le copié a Pi, Dirac y OpenCode. ¿Hay alguna técnica nueva aquí que valga la pena robarse?

    • Además de ser ligero, como funciones interesantes le puse biblioteca de prompts, integración con Git worktree e integración con el bucle Ralph Wiggum
    • Me da curiosidad si está público en GitHub
  • Lo probé un rato y de verdad se sintió bastante rápido
    También me da curiosidad si estás buscando colaboradores o si lo estás haciendo como herramienta personal
    Eso sí, me topé con algunos problemas al intentar usar otros modelos. En Azure, gpt-5.5 no funciona aunque use un endpoint compatible con OpenAI, porque max_tokens cambió a max_completion_tokens
    Tampoco parece haber forma de pasar headers personalizados, así que no pude especificar reasoning_effort para modelos de DeepSeek

    • Sí acepto PRs
      Lo que mencionas son bugs bastante claros del codebase, así que si puedes, estaría bueno que abras issues separados en GitHub para cada bug
  • Claude Code y Opencode me funcionan bien en mi entorno
    Es un poco chistoso que los agentes de código corran en datacenters consumiendo más de 1000W y más de 2TB de memoria, y que aun así la gente se enfoque en los últimos watts y los últimos cientos de MB de RAM de su laptop
    Igual, comparado con el costo energético de compilar código, termina siendo menor, pero aun así no está mal hacerlos más rápidos y ligeros

    • Los datacenters funcionan con líneas eléctricas dedicadas, pero mi laptop funciona con batería
      Cuando uso agentes de código ahora, la batería se agota bastante rápido, y eso sorprende considerando que la mayor parte del trabajo ni siquiera pasa en mi laptop
      Optimizar la eficiencia de los agentes de código del lado cliente no es para salvar el clima, es para alargar la jornada de trabajo. De hecho, en la práctica hasta podría ser peor para el clima
    • Obvio que la gente se enfoca en el software que corre en su propia computadora
      El software que corre en la computadora de otro no es mi problema. No puedo controlar qué corre en servidores ajenos, y aunque pudiera, no soy yo quien paga ese costo de RAM, así que no me importa
      En cambio, la RAM de mi equipo sí la pago yo. Si una TUI que muestra menos de 1KB de texto ocupa varios GB de memoria y termina matando otras apps por OOM en Windows, o hace swap al HDD en Linux y congela toda la máquina, claro que me va a importar
      En un momento en que el precio de la RAM subió de verdad 5 veces, y el de otros componentes entre 2 y 3 veces, evitar el desperdicio de memoria es especialmente importante
    • Eso es una simplificación excesiva
      Sí, el modelo es enorme y consume muchos recursos, pero el harness puede influir muchísimo en cuánto se usa el modelo
      Por ejemplo, si el harness tiene un conjunto de herramientas potente, el modelo puede trabajar de forma mucho más eficiente
  • Como el codebase es pequeño, lo pasé a DeepSeek v4 Flash dentro de Pi para que revisara si había algo peligroso, y no encontró nada especialmente preocupante. Está bien hecho

    • Como el OP dijo que buena parte del código la generó DeepSeek V4 Flash, revisé si había dependencias desactualizadas
      En proyectos Rust, si no le dices al modelo que no edite Cargo.toml directamente y que use cargo add, mi experiencia es que hasta Claude 4.7 Opus casi siempre mete dependencias viejas
      Revisé manualmente las dependencias de este proyecto y todas estaban en sus versiones más recientes, lo cual estuvo bien. Claro, eso no significa que no haya algún problema escondido en las dependencias transitivas
      El tema de usar LLM para revisión de código puede volverse una discusión de gustos muy rápido. Por ejemplo, viendo el código, hubo algunos métodos que convierten entre strings y enums donde pensé “¿esto no se habría resuelto con un solo #[derive] de strum?” y provider.rs podría quedar mucho más conciso a cambio de agregar un crate sin dependencias
      Por diversión hice que DeepSeek V4 Pro con Max thinking “auditara” el codebase, y dijo que no había señales claras de telemetría oculta. Eso sí, señaló que el proyecto configura el panic handler como abort, y sobre eso sí tengo una opinión fuerte
      Supongo que fue para evitar enlazar libunwind y ahorrar unos KB en el tamaño del binario, pero eso hace que ante un crash el binario se aborte al instante sin darle stack trace al usuario. Yo preferiría que el binario pesara unos 50KiB más si eso significa obtener información de depuración útil en caso de panic
      Además, si hay un panic en una tarea asíncrona, no se puede recuperar para mostrar un mensaje de error normal; se cae todo el proceso de inmediato
    • Una parte bastante grande del código la escribió DeepSeek v4 Flash, y algunas partes de la lógica de la TUI las escribí yo
      Eso fue porque DeepSeek seguía fallando en cierta lógica de movimiento del cursor. Todo el proceso de optimización de memoria lo manejé yo mismo y, como comenté en otra respuesta, combiné optimizaciones del compilador con el uso de crates de Rust para aprovechar estructuras de datos más eficientes
    • ¿No es un análisis bastante endeble eso de “se lo pasé a DeepSeek v4 Flash dentro de Pi para que revisara si había algo peligroso”, considerando la inyección de prompts?
  • Da risa que justo haya salido hoy. Yo también estaba a punto de empezar a escribir uno en Rust
    Es sorprendente ver cómo opencode va filtrando memoria lentamente en proyectos grandes hasta subir a 6GB y ponerse cada vez más lento
    Le voy a echar un vistazo. Se ve muy bien

    • Sí. De hecho, este proyecto empezó después de que en una laptop vieja se activara el OOM killer por tener Firefox y más de 2 instancias de opencode abiertas al mismo tiempo