Es hora de release otra vez.

Hace tres semanas, la ronda de mayo puso al día todo el stack en un solo post. Desde entonces las dos herramientas de cara al usuario sacaron cada una una nueva minor — Octocode 0.16.0 y Octobrain 0.8.0, ambas cortadas el 7 de junio — encima del ascenso de Octolib de 0.21.5 a 0.23.0.

Hay un hilo que recorre todo esto, y vale la pena decirlo de entrada: esta ronda va de no tener que configurar nada. Octolib 0.23.0 ganó una manera compartida de mirar un checkout de Git y derivar un project ID estable. Octocode 0.16.0 ahora delega su identificación de proyecto directamente en eso; Octobrain 0.8.0 incorporó el descubrimiento automático de proyecto en el mismo movimiento. El resultado es que las dos herramientas que de verdad apuntas a una base de código simplemente funcionan en cuanto las arrancas, en cualquier repo, sin ningún project ID que poner a mano.

Empecemos por donde más importa.

Octocode 0.16.0 — un servidor, todos los repos, ahora con Swift

github.com/muvon/octocode · 0.15.0 → 0.16.0 · 7 de junio

0.15.0 fue la release local-first — sin API key requerida, hybrid search y reranking activados por defecto. Esa iba de hacer que un solo índice fuera bueno out of the box. 0.16.0 va de lo que pasa cuando tienes más de una base de código que buscar.

Modo servidor multi-repositorio — reemplazando mcp-proxy. El cambio grande. Es un breaking change, pero vale el upgrade. Hasta ahora, servir varios repositorios a través de un solo asistente significaba correr un mcp-proxy delante de una flota de instancias Octocode de un solo repo — más piezas móviles, más cosas que mantener vivas, más que explicar. 0.16.0 borra esa capa. Un solo servidor MCP de Octocode ahora habla multi-repositorio de forma nativa. Te conectas una vez, y tu agente puede buscar en las bases de código que has indexado en vez de quedar encajonado en un solo proyecto por conexión.

Atención: quitar mcp-proxy es el único punto de la lista de breaking changes de 0.16.0. Si tu setup lanza Octocode a través del proxy hoy, esa es la parte que tendrás que cambiar al actualizar.

Identificación de proyecto zero-config. Octocode ya no lleva su propia lógica para averiguar a qué proyecto pertenece un directorio — lo delega en Octolib, que deriva una identidad estable a partir del remote de Git (más sobre por qué importa abajo). El beneficio: es la misma identidad que Octobrain y el resto del stack derivan ahora, así que la memoria y la búsqueda de código coinciden en qué significa "este proyecto" sin que cablees nada.

Swift, de punta a punta. 0.16.0 añade Swift tanto al indexador como al grep estructural. Si trabajas en una base de código de iOS o macOS — y ahora tenemos varias, entre Vext, Timex y TypeTab — los símbolos Swift son de primera clase para búsqueda semántica y pattern matching, no solo texto plano.

Ruta de config personalizada vía una env var. Ahora puedes apuntar Octocode a un archivo de config con una variable de entorno en vez de depender de una ubicación fija. Cambio pequeño, gran victoria de calidad de vida para jobs de CI y máquinas que hacen malabares con varios proyectos con distintos settings.

Hardening de seguridad por debajo. Dos cambios que no verás pero que deberías conocer: las credenciales de las URLs de Git ahora se eliminan durante la normalización, así que un remote con un token incrustado nunca acaba escrito en una URL de proyecto almacenada; y la capa de almacenamiento centraliza los nombres de sus tablas y endurece sus queries SQL.

cargo install octocode --version 0.16.0
# or grab a binary at https://github.com/muvon/octocode/releases

Octobrain 0.8.0 — memoria que se configura sola

github.com/muvon/octobrain · 0.7.0 → 0.8.0 · 7 de junio

0.7.0 fue la ruidosa — consolidación durante el sueño, decay por half-life, memoria anclada a objetivos, recall HyDE activado por defecto. Esa release iba de lo que la memoria de tu IA hace por su cuenta. 0.8.0 va de quitar la última cosa que todavía tenías que hacer a mano: decirle en qué proyecto está.

Descubrimiento automático de proyecto y derivación de ID. El titular en 0.8.0, y la otra mitad del hilo. Octobrain ahora descubre el proyecto y deriva su ID automáticamente — y por debajo cambió sus propias utilidades de git por las de Octolib (la release sube a Octolib 0.23.0), así que la identidad que deriva es la misma que deriva Octocode. Arranca Octobrain dentro de un repo y su memoria se enlaza a ese proyecto por sí sola: sin parámetro de proyecto que pasar, sin ID que copiar entre herramientas, y sin riesgo de que tu búsqueda de código y tu memoria apunten a proyectos distintos. La memoria que ya se automantenía ahora también se autoconfigura.

Ruta de config personalizada vía una env var. La misma victoria de ergonomía que Octocode, por diseño — ambas herramientas incorporaron la misma capacidad esta ronda para comportarse idénticamente en CI y en máquinas multi-proyecto.

Una superficie MCP más esbelta. 0.7.0 estrechó el toolset de 8 herramientas a 5. 0.8.0 afina lo que queda: el listado de herramientas y el proveedor de memoria están optimizados, y el locking de proyecto y de rol ahora están desacoplados — así que dos roles trabajando el mismo proyecto, o un rol entre proyectos, dejan de contender por un único lock.

Las notas de 0.8.0 no listan breaking changes, así que es un upgrade limpio desde 0.7.0 — y en la práctica dejas de pasar el project ID, porque Octobrain ahora lo averigua solo.

cargo install octobrain --version 0.8.0
# or grab a binary at https://github.com/muvon/octobrain/releases

Octolib 0.21.5 → 0.23.0 — la fontanería que hizo posible lo de arriba

github.com/muvon/octolib · 0.21.5 → 0.23.0

Unas cuantas observaciones importantes, porque esta es la capa que hace el trabajo silencioso. Octolib es el motor detrás de cada llamada LLM que hacemos, y últimamente también se ha convertido en el sitio donde viven las utilidades compartidas no-LLM para que las herramientas de arriba no las reinventen cada una.

  • Detección de repo Git y derivación de project ID (0.23.0). Lo que Octocode 0.16.0 delega explícitamente, y a lo que Octobrain 0.8.0 se mudó en la misma release. Pon la lógica de "¿es esto un repo Git, cuál es su remote canónico, cuál es un ID estable para él?" en un solo sitio, y cada herramienta que depende de Octolib obtiene la misma respuesta. Esa es la razón entera de que la identidad de proyecto zero-config sea consistente en todo el stack en vez de tres herramientas cada una ligeramente equivocada a su manera.
  • Validación de response schema (0.23.0). Octolib ahora puede comprobar que la salida de un modelo coincide con un response schema esperado — útil en cualquier sitio donde parsees salida estructurada de vuelta de un LLM.
  • Soporte de Claude Opus 4.8 (0.21.7). El Opus más nuevo está cableado, junto con salida estructurada de OctoHub y soporte de finish-reason para que los callers puedan saber por qué paró una generación, no solo que paró.
  • Minimax M3 y M3-highspeed (0.21.8). Dos modelos más en la lista.
  • Manejo de herramientas en paralelo y timeouts de conexión (0.22.0). Mejor manejo de llamadas a herramientas en paralelo y un timeout de conexión en el cliente HTTP, con el manejo de requests unificado tras un único path send_and_read — menos maneras de que un endpoint lento o atascado bloquee a un agente.
  • Arreglos de contabilidad de tokens (0.21.6). Los tokens cacheados ya no se cuentan doble, y los resúmenes de compresión ya no bloquean el historial de conversación. Si tus números de coste parecían ligeramente altos en sesiones cacheadas largas, esta es la razón — y está arreglado.

Si construyes algo que llama a LLMs desde Rust, esta sigue siendo la capa sobre la que estandarizar: cada proveedor que Octolib ya habla, tras un solo trait, con la misma lógica de reintento y la misma contabilidad de coste.

¿Y Octofs? Aguantando en 0.4.3 — a propósito

github.com/muvon/octofs · 0.4.3 · sin cambios

Octofs sacó 0.4.3 en la ronda de mayo — búsqueda regex, recorrido de archivos en paralelo y un comando delete — y no ha necesitado una release desde entonces. Eso no es abandono; es justo el punto. La capa de filesystem es la pieza del stack que quieres aburrida y predecible, y ahora mismo lo es. Cuando el runtime de encima cambie cómo toca los archivos, Octofs se moverá de nuevo. Hasta entonces, 0.4.3 está haciendo su trabajo.

Octomind 0.30.0 — publicado por separado

El runtime que une todo este stack, Octomind, también sacó 0.30.0 el 3 de junio — archivos de workflow portables, guardrails locales al proyecto y observabilidad de sesión. Tuvo su propio artículo, así que solo te dejamos el enlace: las notas de la release de Octomind 0.30.0 en octomind.run.

Cómo encajan

El stack es el mismo que el mes pasado. Lo que cambió es cuánto menos tienes que pensar en él. Octolib 0.23.0 ahora deriva la identidad de proyecto desde Git una vez, y tanto Octocode 0.16.0 como Octobrain 0.8.0 la leen. Ya no hay proxy que correr delante de Octocode. Ni project ID que copiar entre configs. Ni riesgo de que tu búsqueda de código y tu memoria discrepen sobre a qué proyecto se refieren.

Hace un año, cablear todo esto significaba un proxy, un ID copiado, y la esperanza de que coincidieran. Ese hueco está cerrado ahora. Binarios únicos, Apache-2.0, todos ellos.

Ya empezamos el siguiente. Si algo aquí desbloquea algo que querías construir, abre un issue — features pedidos en junio tienden a salir en julio.

— Don