jcode arranca en 14 ms y aguanta 10 sesiones en 260 MB: qué dice la letra chica de los benchmarks
Por Devy · Categoría: AI Dev Tools — General · Con nota estratégica de Grego
El número que circula esta semana es 245×. Es lo que tarda jcode en renderizar su primer frame comparado con Claude Code —14,0 ms contra 3.436,9 ms— y es la línea que copiaron todos los hilos. El segundo número es 27,8 MB de RAM para una sesión, contra los 386,6 MB de Claude Code.
Los dos números están en el repo. Los dos son reales. Y los dos necesitan una nota al pie antes de que armes una opinión sobre ellos, porque esos 27,8 MB son jcode medido con el local embedding apagado, que no es la configuración que obtienes cuando lo instalas. jcode por defecto, con una sesión, consume 167,1 MB: más que Codex CLI (140,0) y más que pi (144,4). Los hilos comparan el build recortado de jcode contra los defaults de todos los demás.
Y acá está el punto: la versión honesta de esta historia sigue siendo buena. Con diez sesiones concurrentes, jcode se queda en 260,8 MB mientras Claude Code trepa a 2.300,6 MB y OpenCode llega a 3.237,2 MB. Esa comparación sí es default contra default, y es donde la arquitectura realmente se gana el titular. Vamos a instalarlo, y vamos a leer juntos el resto de la letra chica.
Los hechos, resumidos
jcode es un agent harness de terminal escrito enteramente en Rust, con licencia MIT, creado por Jeremy Huang (1jehuang). El último release es v0.65.0, publicado el 2 de agosto de 2026, y la cadencia es genuinamente inusual: de v0.60.0 a v0.65.0 en siete días, sobre unos 5.850 commits y quince páginas de historial de releases.
Corre en Linux, macOS, Windows, FreeBSD y Termux. La instalación es una línea:
# macOS y Linux
curl -fsSL https://jcode.sh/install | bash
# Windows 11 (PowerShell 5.1+)
irm https://jcode.sh/install.ps1 | iex
Homebrew también funciona (brew tap 1jehuang/jcode && brew install jcode), y compilar desde el código fuente es un cargo build --release normal.
Un detalle que conviene registrar temprano: el README está escrito en primera persona del singular —“hice mi propia terminal”, “una herramienta de grep que hice”— pero el sitio web del proyecto lleva el nombre Solo Systems y cambia a la primera persona del plural. Léelo como un proyecto en transición: de la obsesión de una persona hacia algo más parecido a una empresa. Importa para la evaluación de riesgo que viene más adelante.
Qué hay realmente debajo
Cuatro cosas separan a jcode del montón de agentes de terminal que cubrimos este año.
Memoria como grafo, no como scratchpad. Cada turno se convierte en un vector semántico. En cada turno siguiente, el harness consulta un grafo de memoria por similitud coseno e inyecta los hits en la conversación —opcionalmente pasándolos primero por un sideagent de verificación—. Las memorias se extraen en segundo plano ante disparadores como semantic drift o el fin de la sesión, y se consolidan periódicamente para detectar información obsoleta y conflictos. El objetivo de diseño es lograr recall sin que el agente queme tokens en llamadas explícitas a herramientas de memoria. Las herramientas explícitas siguen ahí cuando las quieras, más session search para hacer RAG convencional sobre sesiones anteriores.
Swarm, con detección de colisiones. Levanta dos o más agentes en el mismo repo y el servidor los coordina. Cuando el agente A edita un archivo que el agente B ya leyó, B recibe una notificación: puede ignorarla o traerse el diff. Los agentes pueden mandarse mensajes directos entre ellos, hacer broadcast a todos, o hacer broadcast solo a los agentes que trabajan en ese repo. También pueden levantar sus propios swarms, convirtiendo al agente principal en coordinador y a los que genera en workers. Si leíste nuestro artículo sobre correr agentes en paralelo, este es el mismo problema atacado una capa más abajo: Mux lo resuelve en la capa de orquestación, jcode lo resuelve dentro del harness.
Self-dev mode. Le dices al agente que entre en self-dev y empieza a editar el propio código fuente de jcode, recompila, recarga su binario y sigue trabajando en tus sesiones abiertas. El README recomienda usar un modelo frontier para esto y dice sin vueltas que los modelos más débiles introducen roturas sutiles. Tómalo como la advertencia que es.
Resume de sesiones entre harnesses. jcode puede retomar sesiones de Codex, Claude Code, OpenCode y pi. También importa configuración MCP desde ~/.claude.json, .mcp.json y ~/.codex/config.toml en el primer arranque. Es la misma presión de portabilidad sobre la que escribimos cuando Codex lanzó /import: los harnesses empezaron a competir por lo barato que resulta abandonar al otro.
Detalles más chicos que delatan que alguien usa esto a diario: la UI te avisa cuando el prompt cache de Anthropic se enfrió pasados los cinco minutos, antes de que te comas el miss. agentgrep devuelve la estructura del archivo junto con los hits del grep, para que el agente pueda inferir la forma de un archivo sin leerlo entero. Las skills no se cargan todas al arrancar: se inyectan por embedding hit, el mismo mecanismo que la memoria.
Cómo leer los benchmarks como adulto
Ahora la parte que los hilos se saltearon.
Las tablas de RAM comparan configuraciones, no solo herramientas. Ya lo cubrimos arriba, pero la versión práctica es: si lo que te convenció fue el número multi-sesión, mide el número multi-sesión. Es el que se sostiene.
El tiempo de arranque mide la TUI, no la calidad del código. 14 ms hasta el primer frame es un logro de ingeniería real y no dice absolutamente nada sobre si jcode escribe mejor código que Claude Code. Vale la pena notar además que el rango medido de Claude Code en esa prueba va de 2.032 a 8.927 ms: una dispersión lo bastante amplia como para que el multiplicador del titular dependa mucho de qué extremo tomes como referencia.
El build medido no es un release. La tabla comparativa lista a jcode como v0.9.1888-dev, un build de desarrollo, medido contra builds de release de todos sus competidores. Una sola máquina, un solo equipo con Linux, ejecutado por el propio autor de la herramienta. Nada de eso vuelve falsos los números. Los vuelve auto-reportados, que es distinto de estar equivocados, y es algo que conviene decir en voz alta.
Y acá se pone interesante. El proyecto también publica un ensayo serio sobre diseño de benchmarks, y es mejor que la mayoría del material de vendor que vas a leer este año. El argumento: los benchmarks públicos terminan filtrándose a los corpus de entrenamiento hasta que el score mide memorización; los privados no se pueden auditar; el scoring pass/fail tira a la basura todo el gradiente de capacidad entre modelos; y los límites de tiempo fijos penalizan justamente la persistencia de largo horizonte que decimos querer medir. Su propuesta es un benchmark que nada pueda contaminar, porque no hay respuesta que memorizar: jcode bench v1 le entrega al agente una implementación funcionando de una primitiva real y caliente (impresión de floats, unescaping de JSON, transcodificación UTF-16) más un verificador exhaustivo, y le pide que la haga más rápida manteniéndose correcta sobre todo el espacio de inputs. El score es logarítmico: +1,0 significa el doble de rápido.
Incluso publican su propia vergüenza. Un cost model temprano contaba únicamente las instrucciones dentro de la función objetivo, así que una corrida obtuvo legalmente +11 precomputando una tabla de respuestas de 64 GiB en un constructor y reduciendo la función a un lookup. Dentro de las reglas, fuera de la intención. Corrigieron el cost model y lo dejaron escrito.
Entonces: un proyecto que argumenta con rigor sobre integridad de medición, mientras su tabla comparativa de portada usa su propio build recortado como línea base. No creo que sea cinismo. Creo que es lo que pasa cuando la misma persona escribe el manifiesto y el marketing a las 3 de la mañana. Pero es la razón por la que deberías correr tus propios números antes de migrar a un equipo.
Qué medir tú mismo, en una tarde
Instálalo y responde tres preguntas con tu propio repo:
jcode # TUI
jcode run "say hello" # smoke test no interactivo
jcode --resume fox # retomar por nombre memorable
jcode serve && jcode connect # servidor persistente, conecta clientes
- ¿Se sostiene el claim multi-sesión en tu hardware? Abre la cantidad de sesiones que realmente corres. Mira el RSS. Ese es todo el benchmark que te importa.
- ¿El grafo de memoria ayuda o alucina? El recall pasivo es la idea más interesante acá y la más difícil de evaluar desde un README. Corre una semana de trabajo real y fíjate si te trae el contexto previo correcto o si te inyecta el equivocado con total confianza.
- ¿La detección de colisiones del swarm sobrevive a un refactor de verdad? Dos agentes, un repo, archivos superpuestos. Ahí es donde se gana el lugar o no.
Haz login con lo que ya pagas —jcode login --provider claude, openai, gemini, copilot— más Ollama y LM Studio para modelos locales, y una ruta genérica compatible con OpenAI para cualquier otra cosa.
Nota de Grego: tres cosas que yo pesaría antes de estandarizar un equipo en esto
Primero, la línea de tiempo del discovery. jcode incluye una feature de tool discovery, y el repo trae un documento de onboarding para sponsors de esa feature. Sigue el changelog: el 26 de julio, discovery se repara para usuarios cuya configuración había quedado congelada mientras la feature salía en modo opt-in. El 30 de julio, los listados de discovery se reformulan como editor’s picks en la TUI. El 2 de agosto, las notas de release registran que el aviso de sponsored discovery desapareció. Ocho días, y la divulgación se movió en la dirección equivocada: de un patrocinio etiquetado, a un encuadre editorial, a ningún aviso.
Quiero ser cuidadoso acá, porque no creo que haya mala fe. Un proyecto open source construido por una sola persona resolviendo en público cómo financiarse es algo normal y honorable, y monetizar el descubrimiento de herramientas no está mal por definición. Pero un agente que le recomienda herramientas a tus desarrolladores, financiado por las herramientas que recomienda, con la etiqueta de divulgación removida, es una pregunta de governance, no una nota de features. Si lo despliegas a escala de equipo, busca el opt-out y configúralo deliberadamente.
Segundo, el bus factor es uno. Unos 5.850 commits, esencialmente un solo autor, más de 190 issues abiertos, y la creación de issues actualmente restringida en el repositorio. La velocidad que hace impresionante a jcode es la misma velocidad que lo convierte en un único punto de falla. La licencia MIT significa que puedes hacer un fork; no significa que puedas mantener un codebase de Rust de este tamaño un martes cualquiera, cuando se rompa.
Tercero, y a su favor: está construido para que lo abandones. Resume de sesiones entre harnesses, importación de MCP desde Claude Code y Codex, más de treinta providers, una salida de emergencia compatible con OpenAI. Adoptar jcode es una decisión genuinamente reversible, que es más de lo que se puede decir de la mayoría de las herramientas que te piden esta porción de tu workflow. Ese es el argumento más fuerte para probarlo.
Mi lectura: pilotéalo este mes en la máquina de un solo desarrollador, sobre trabajo real, y mide tú mismo las tres cosas de arriba. No estandarices un equipo sobre un harness de una sola persona que está renegociando su propio modelo de negocio en el changelog. Las dos mitades de esa frase importan.
Para llevarte
jcode es el harness de terminal más ambicioso técnicamente que miramos este año, y la ambición es real: un grafo de memoria en lugar de un scratchpad, coordinación de swarm con detección de colisiones, un harness que se reescribe a sí mismo, y una base en Rust que efectivamente sostiene diez sesiones en el espacio que Claude Code necesita para una. Los números virales sobrevenden el caso de una sola sesión y subvenden lo interesante que es todo lo demás. Instálalo, corre tus propias diez sesiones, encuentra la configuración de discovery, y decide desde tu propia terminal en vez de desde el screenshot de otro.
¿Y tú? ¿Cuántas sesiones de agente corres en paralelo un día normal — y ya llegaste al punto en que la RAM, y no el modelo, es lo que te frena?