¿Alguna vez has hecho las cuentas? Cada vez que le pides a Hermes que llame a una herramienta, el modelo tiene que releer «cómo es esa herramienta» desde cero — parámetros, formatos, trampas, todo detallado en una definición JSON que viaja con cada petición. Cuanto más larga es tu sesión y más frecuentes son las llamadas a herramientas, más crece ese overhead fijo. Entre el 27 y el 28 de agosto, los mantenedores fusionaron seis PRs que hacían lo mismo: adelgazar las definiciones JSON de las herramientas. process bajó de 306 a 228 tokens (−25%), todo de 323 a 232 (−28%), read_file de 426 a 244–269, skill_manage de 517 a 427 (−17%), video_generate de ~814 a 458/377, y browser_exec de 803 a 663 (−17%) — con cero cambios de comportamiento en todas ellas.

Por qué merece la pena recortar las definiciones de las herramientas

Construyamos primero un modelo intuitivo. Cuando Hermes llama a una herramienta, la petición debe incluir el JSON schema de esa herramienta: description (qué hace), parameters (nombre, tipo y restricciones de cada parámetro), enums y advertencias. Esa definición viaja con cada petición — no es un coste de una sola vez; se reenvía en cada turno de tu conversación.

Si la definición de la herramienta A ocupa 300 tokens y la llamas 50 veces en una sesión, solo esa definición quema 15.000 tokens. Hermes trae docenas de herramientas integradas, y unas pocas definiciones pesadas (como los 800+ tokens de browser_exec) son un «impuesto oculto» que acecha dentro de cada petición. Esta ola ataca exactamente esas fuentes de impuestos — de forma sistemática, bajo la campaña #95681.

El principio: enseñar cada dato exactamente una vez

La idea central de esta ola se resume en una frase: elimina la enseñanza duplicada, conserva las trampas reales. Desglosado:

1. El enum ES la lista de verbos (#97279 process, 306→228, −25%)

La descripción de process solía volver a listar las 8 acciones (list, kill, submit…) con una frase explicativa cada una. Ahora: los verbos autoevidentes (list, kill) no reciben nada; los mecánicos conservan una cláusula cada uno; y las partes realmente complicadas reciben más énfasis — como la trampa write-vs-submit: «submit añade un Enter — úsalo para responder prompts; write envía bytes crudos, sin newline. En una Windows PTY, un \n suelto no es un terminador de línea; el prompt nunca vuelve, en silencio».

2. Lo que el schema de parámetros ya enseña no se vuelve a enseñar en prosa (#97257 todo, 323→232, −28%)

La descripción de todo solía detallar la estructura de items ({id, content, status}) en prosa — cuatro líneas por encima del JSON schema idéntico. La prosa duplicada ha desaparecido; el schema es la única fuente estructural. Las reglas que sostienen todo sobreviven: enumera cada instancia para tareas de «todos los N items», UN item en in_progress, completed solo tras verificar que está hecho (nunca por intención), y cancel-and-revise ante un fallo.

3. Capacidades anunciadas bajo demanda (#97195 read_file, 426→244–269; #97095 video_generate, ~814→458/377)

La lista de formatos de read_file ahora se genera dinámicamente según la capacidad: que tu instalación tenga o no la extensión anydoc decide qué formatos se anuncian; los formatos ausentes no se anuncian en absoluto, y el mensaje de error te enseña cómo activarlos. video_generate va más lejos: solía mostrar 10 parámetros estáticos en cada sesión, cuatro de los cuales se disculpaban por sí mismos («ignorados por providers que no lo soportan»). Ahora solo se renderizan los parámetros que el backend activo realmente respeta — negative_prompt, audio, seed y upscale solo aparecen en backends que declaran soportarlos.

4. Deduplicación entre herramientas (#97152 skill_manage, 517→427, −17%)

El mecanismo de patch de skill_manage usa la misma semántica fuzzy-find-and-replace que la herramienta patch (unicidad salvo replace_all, contexto para la unicidad, debe diferir) — antes se enseñaba dos veces. Ahora skill_manage dice «misma semántica de coincidencia que la herramienta patch» y conserva solo los datos específicos de las skills (un new_string vacío borra). También corrigió una ambigüedad real: file_path ahora es explícitamente «relativo al propio directorio de la skill, p. ej. “references/api.md” — sin barra inicial, nunca absoluto».

5. Los números hablan (#96300 browser_exec, 803→663, −17%)

La dieta anterior de browser_exec incluyó una verificación A/B: el schema adelgazado logró paridad de precisión con el original ahorrando 140 tokens por llamada.

Por qué te importa esto

• Dinero ahorrado: es una reducción de coste fijo por llamada — cuanto más larga es tu sesión y más llamadas a herramientas haces, más ahorras;
• Más fiable: los schemas más pequeños implican un menor coste de comprensión para el modelo y menos llamadas mal parametrizadas;
• Actualización sin fricción: todos los cambios son «cero cambios de comportamiento», con contract tests que fijan cada enseñanza conservada — nada de «la herramienta se volvió más tonta tras actualizar».

Nota: estos cambios se fusionaron entre el 27 y el 28 de agosto y viven actualmente en main de upstream, todavía sin release tag. En cuanto hagas hermes update a una build que los incluya, se aplican automáticamente — no hay nada que configurar.

Lecturas recomendadas

• ¿Quieres entender cómo cobra y comprime el contexto Hermes? Consulta la guía de reducción de contexto en cuatro capas;
• ¿Te interesa el nuevo valor por defecto de compresión lean-tail? Lee el nuevo valor por defecto de la estrategia de compresión;
• ¿Quieres el panorama completo de las herramientas integradas? Consulta el panorama de los 82 slash commands.