Rusty
Agente de código en Rust (CLI + TUI + web)
rusty es un agente de código minimalista escrito en Rust: TUI de streaming, cuatro herramientas (read, bash, edit, write), subagentes en procesos ligeros, persistencia de sesiones en SQLite y un historial de conversación diseñado para gastar pocos tokens. Unos 4k líneas y ~5 MiB de RSS pico. En el benchmark de 200 tareas de código verificadas de forma determinista y ejecutadas en tmux contra el agente pi con el mismo modelo gateway, rusty resolvió las 200 sin timeouts (mediana 6,3 s) frente a 199/200 de pi (mediana 8,0 s), con 41 veces menos uso de memoria (4,3 MiB vs 177 MiB de RSS pico). En el tier difícil posterior — otras 100 tareas más duras que la 200 (intérpretes, compiladores, servidores, WAL/MVCC, git-lite) con deadline de 300 s — ambos resolvieron las 100 y rusty fue un 35% más rápido de mediana (17,6 s vs 27,2 s) con p90 2,8 veces menor y cero timeouts frente a 2 de pi.
Tecnologías utilizadas
Front-end
Tailwind CSSHerramientas
SQLiteFuncionalidades principales
TUI de streaming en la terminal
La interfaz de terminal renderiza texto y razonamiento en streaming con tok/s en vivo a la derecha del prompt, panel de actividad de subagentes, historial con Ctrl+P/Ctrl+N, y un popover de comandos con '/' para cambiar de modelo, reanudar sesiones o limpiar la conversación sin salir del flujo.
Popover de comandos '/'
Escribir '/' despliega la lista de comandos slash inline sobre el input: flechas para mover el resaltado, Tab para autocompletar, Enter para ejecutar y Esc para cerrar. El mismo menú está disponible en la UI web sobre su prompt.
Benchmark de 200 tareas contra pi
Los mismos 200 encargos de código en Python ejecutados por rusty y por pi en tmux con verificación determinista y deadline de 150 s por tarea. rusty resolvió las 200 sin ningún timeout con una mediana de 6,3 s por tarea; pi resolvió 199 con mediana de 8,0 s (1 timeout y 1 fallo). El gráfico muestra la latencia por tarea: rusty por debajo de pi en casi todo el rango, incluida la banda difícil 101-200.
Éxito por banda de dificultad
Las tareas 1-100 mantienen la banda original de mini-encargos y las 101-200 suben en dificultad incremental: formato exacto, multipaquete, con estado, algorítmicas, parsing, código+tests, reparación de bugs, CLIs, concurrencia y capstones. rusty logró el 100% en todas las bandas, incluida la banda de concurrencia donde pi encajó su único timeout.
41 veces menos memoria que pi
En la misma tarea one-shot medida con VmHWM (7 ejecuciones por agente), rusty alcanza un pico de ~4,3 MiB frente a ~177 MiB de pi: 41x menos RAM. Es el resultado del perfil de release (LTO fat, panic=abort, strip), rustls en lugar de OpenSSL y serializar las peticiones directamente desde estado prestado.
Historial de tokens eficiente
El historial de conversación deduplica salidas de herramientas repetidas (−70% a −88% de bytes en el cable), aplica elisión de bloques intermedios sobre el límite de 8 000 caracteres, compacta a partir de 200 000 y solo reenvía el razonamiento del último turno. Frente a v0.3.0, los wire bytes caen entre −16% y −40% en los escenarios con palanca real.
Tier difícil: 100 tareas más duras que la 200
Una segunda pasada independiente con 100 tareas deliberadamente más difíciles y extensas que la tarea 200 del primer benchmark: intérpretes de Brainfuck/Lisp/máquina de Turing, max-flow y Held-Karp, B-trees y segment trees con lazy, una shell virtual y un FAT, servidores TCP/HTTP reales, WAL y MVCC, lexer/parser/typechecker/cálculo lambda, y capstones como un git-lite y un gestor de paquetes. Deadline de 300 s por tarea, verificación determinista. Ambos agentes resolvieron las 100: la separación salió en velocidad y estabilidad.
Barras horizontales: latencia por categoría
El gráfico de barras horizontales compara la mediana y la cola p90 de cada categoría del tier difícil: rusty gana en 9 de las 10 bandas (intérpretes 17,3 s vs 41,2 s, estructuras de datos 13,5 s vs 27,1 s, apps 18,3 s vs 32,5 s) y empata en algoritmos duros. Su mediana global es un 35% menor (17,6 s vs 27,2 s) y su p90 es 2,8 veces menor (32 s vs 91 s).
Cero timeouts en el tier difícil
Con el deadline de 300 s, rusty no alcanzó el límite ni una sola vez; pi lo agotó dos veces (tareas 203 y 222) cuando sus propios bucles de auto-test no terminaban — un JMP 0 en su VM de pila y una lectura en bucle del skiplist. Los programas entregados verificaron tras el kill, pero las ejecuciones cuentan como timeouts. Gráficos independientes del primer benchmark, en horizontal.
Galería de imágenes