JARVIS/verde/NOTAS.md

Notas del carril verde

Lo medido, lo resuelto y lo que queda abierto.

Fechas: 15 de agosto de 2026 (instalación, en frío) y 16 de agosto (primer arranque real). Lo de la primera fecha salía de leer código y mirar el disco; lo de la segunda está ejecutado.

EL SUELO DE 64k: el tope que invalidó la medida anterior (16 ago)

(Esto va primero porque cambia la conclusión de la sección siguiente.)

arrancar.sh midió bien: 24576 era el mayor contexto que cabía en la GPU con las 32 capas en la tarjeta, 3301 MiB, y con eso el modelo emitía tool_calls válidos. Todo correcto y todo inútil, porque al abrir Hermes:

Model qwen3.5:4b-verde has a context window of 24,576 tokens, which is below
the minimum 64,000 required by Hermes Agent.

Es un tope duro del arnés, no un aviso: agent/model_metadata.py:405, MINIMUM_CONTEXT_LENGTH = 64_000, comprobado en agent/agent_init.py:2656. No se ve en frío — hermes prompt-size no lo menciona — y solo salta al construir el agente.

Las dos salidas que se descartaron, y por qué

1. La puerta de atrás de lmstudio. El mismo if se salta si provider == "lmstudio" y context_length está puesto a mano. No se usa: ese proveedor llama a {server}/api/v1/models, la API nativa de LM Studio, que ollama no tiene, y además intenta precargar el modelo por su cuenta (ensure_lmstudio_model_loaded). Fingir ser otro servidor rompería más adelante y de forma más confusa.
2. Mentir en el config.yaml poniendo 64000 con el modelo a 24576. Es la peor de las tres: Hermes creería tener 64k, no comprimiría hasta acercarse, y ollama iría tirando los tokens más viejos — que son el prompt de sistema y los esquemas de las 19 herramientas. El síntoma sería que el agente deja de llamar herramientas a mitad de sesión, sin un solo error en el log.

Lo que se hizo: subir el contexto de verdad y pagar capas

Con num_ctx 65536 fijo, medido el 16 de agosto:

num_gpu	Resultado	En tarjeta	Total
32	cudaMalloc failed	—	—
24	cudaMalloc failed	—	—
16	carga	2795 MiB	5784 MiB
8	carga	1772 MiB	5784 MiB
0	carga	0 MiB	5368 MiB

O sea que 64k sí cabe en esta máquina, pero con la mitad de la red en la CPU y unos 3 GB en RAM. Lo que eso cuesta en tiempo está más abajo, en "Cuánto tarda de verdad".

La palanca para recuperar capas —OLLAMA_FLASH_ATTENTION=1 + OLLAMA_KV_CACHE_TYPE=q8_0, que parte el KV caché por la mitad— sigue sin aplicarse: es del servicio de ollama, no del modelo, y afectaría también al naranja. Esa decisión es del usuario.

Lección de método, que es la misma que ya aparece dos veces en este fichero: se midió a fondo el límite de la máquina y no se comprobó el límite del software que iba encima. Los dos son topes; solo uno se estaba mirando.

Cuánto tarda de verdad (16 ago)

Medido con hermes -z, que es una pregunta y a callar, contra el modelo a num_ctx 65536 con 16 de 32 capas en GPU.

Escalón	Vueltas	Tiempo
1 · "hola, ¿quién eres?" — en frío	0 herramientas	2 min 38 s
2 · "¿cuánto espacio libre queda?"	1 herramienta	48,6 s
3 · "lee verde/README.md y resúmelo"	4 (dos fallidas + recuperación)	3 min 29 s
3 bis · igual, con terminal.cwd arreglado	1	1 min 58 s
3 ter · igual, ya con AGENTS.md	2 (una fallida + recuperación)	4 min 54 s
4 · "cuál de los .md de verde/ es el más largo"	4 encadenadas	3 min 54 s
5 · "un cartel en arte ascii que ponga JARVIS"	3 (una salió a la red)	4 min 58 s
6 · "di en voz alta…"	1 (text_to_speech)	3 min 37 s
(pwd suelto, caché caliente, una llamada)	1	13,2 s

Esa diferencia de tres veces no es ruido, y es lo más útil que se midió. El primer turno paga el prefill entero de los ~20.500 tokens del prompt fijo con media red en la CPU. A partir de ahí, ollama cachea el prefijo y las vueltas siguientes solo procesan lo nuevo — y eso que la 2 hace dos llamadas al modelo (pedir la herramienta y redactar con su resultado) y aun así tarda un tercio.

O sea que la cifra que importa para decidir si esto se usa no es la del primer arranque. Es la de régimen. Igual que la primera transcripción de whisper tarda ~4 s por arrancar el servidor y luego se queda en ~930 ms.

El escalón 2 acertó, además: 663G libres de 1,9T al 63 %, que es exactamente lo que dice df -h /.

Y el 3 enseñó algo que no se estaba buscando. Falló dos veces seguidas — partió mal la frase y pidió cat ~/lee-verde/README.md, que no existe— y en vez de inventarse una respuesta cambió de estrategia: search_files para localizar el fichero, y read_file con la ruta absoluta ya correcta. El resumen final es fiel al README.

Eso es exactamente lo que se venía a probar de este carril: recuperarse de una herramienta que devuelve error. El núcleo naranja, con sus acciones rápidas, o acierta a la primera o no hay segunda. Las dos vueltas de más son las que explican los 3 min 29 s.

El punto flaco del 4B: las rutas relativas

Con terminal.cwd ya arreglado se repitió el escalón 3, y salió peor: 1 min 58 s y una sola llamada, read_file sobre COFRE/CODERS/JARVIS/README.md. Se comió el verde/. Resumió el README de la raíz —el del proyecto entero— con un "JARVES" de propina y la frase cortada a medias.

La comparación entre las dos pasadas es lo interesante:

	Ruta base	Qué hizo	Resultado
Con cwd en $HOME	mal	falló, buscó, se corrigió	acertó
Con cwd en el repo	bien	fue directo a una ruta plausible	falló

O sea: cuando la herramienta le devuelve un error, se recupera; cuando le devuelve un fichero que existe pero no es el pedido, no tiene forma de notarlo y lo resume tan campante. Es el mismo patrón del error de ~/README.md, y la razón de que estos fallos no se vean: no hay error que mirar.

Lo que apunta a la mejora obvia si este carril sigue adelante: un AGENTS.md en la raíz del repo describiendo la disposición de carpetas. Hermes ya carga ficheros de contexto, así que el sitio está.

Escrito el AGENTS.md, el escalón 3 pasa — pero no por lo que parece

Se escribió (<raíz>/AGENTS.md: los tres carriles, el árbol de carpetas y la regla de que las rutas relativas salen de la raíz del repo). Cuesta 2.490 B del prompt fijo, que sube a 84.740 B ≈ 21.185 tokens de los 65.536: quedan 44.351 para conversar.

Tercera pasada del escalón 3, 4 min 54 s, y el resumen es del fichero correcto por fin. Recoge incluso el aviso de la fuga a internet que se añadió hoy al README.

Pero el modelo volvió a alucinar la ruta. Su primera llamada fue

read_file ~/COFRE/CODERS/JARVIS-verde/zapier-connection.py

que no existe y no se parece a nada de lo pedido. Recibió File not found y entonces acertó con JARVIS/verde/README.md.

O sea que el AGENTS.md no evitó el disparate; le dio con qué recuperarse. Es la tercera vez que sale el mismo patrón en esta sesión y ya no es anécdota:

Lo que recibe la herramienta	Qué hace el 4B
Un error	cambia de estrategia y suele acertar
Un fichero que existe pero no es	lo resume tan contento

La lección práctica para este carril: más vale una ruta que falle que una que acierte por accidente. Y en la prosa sigue descuidado — aquí se inventó un "98 % local", llamó API de terceros a pyfiglet (que es una librería local; la API era asciified.thelicato.io) y le dio la vuelta a la frase del objetivo.

El escalón 4, que era el que decidía: pasa

"dime cuál de los .md de la carpeta verde/ es el más largo" — 3 min 54 s, cuatro llamadas encadenadas, respuesta correcta:

#	Llamada	Qué pasó
1	search_files con pattern: "*.md"	rg: regex parse error
2	search_files con pattern: "\\.md$"	corrigió el patrón él solo
3	terminal: find … -name "*.md"	los cinco ficheros
4	terminal: bucle con wc -l sobre cada uno	las cinco cifras

Y concluyó: verde/NOTAS.md con 625 líneas. Es el correcto.

Esto es lo que justificaba el carril entero. No hay una herramienta que conteste esa pregunta: hay que listar, medir y razonar sobre el resultado de la vuelta anterior, y saber cuándo parar. El núcleo naranja no puede hacerlo — sus 150 acciones rápidas o aciertan a la primera o no hay segunda.

La letra pequeña, que no cambia el veredicto pero conviene tener escrita: al enumerar los ficheros los ordenó mal (puso PLAN-ARRANQUE con 181 por encima de ESCALERA con 208) y etiquetó el README de verde/ como "categoría raíz". O sea que el razonamiento de la cadena es bueno y la prosa de alrededor es descuidada. Para una orden hablada da igual; para un informe, no.

EL BLOQUEO DEL ARRANQUE: no cabe la pregunta

(15 ago, tarde. Esto es lo más importante del fichero.)

Se preparó el primer arranque y apareció un tope que no era el que se anticipaba. No es que qwen3.5:4b no sepa llamar herramientas: es que no le cabe la pregunta. Medido con hermes prompt-size:

Prompt de sistema de Hermes	26.281 B
Esquemas de las 19 herramientas	55.978 B
Fijo, antes de decir nada	82.259 B ≈ 20.500 tokens
num_ctx de qwen3.5:4b-jarvis	4.096

Cinco veces por encima. Y hay un segundo tope escondido: num_predict 300, que el naranja hereda del modelo BASE (no lo pone su Modelfile). 300 tokens cortan el JSON de una llamada a herramienta por la mitad.

Los dos están bien puestos para el naranja —respuestas habladas cortas, VRAM para whisper— y son justo lo contrario de lo que pide un arnés agéntico.

Y encima, la trampa que avisaba la documentación: /api/show reporta qwen35.context_length = 262144, el máximo del modelo, no los 4096 configurados. Hermes se habría creído que tenía 262k. El síntoma habría sido respuestas truncadas y llamadas rotas, y la conclusión natural —"el 4B no vale para esto"— habría sido falsa.

La variante verde, ya creada

verde/qwen3.5-4b-verde.Modelfile → ollama create qwen3.5:4b-verde. qwen3.5:4b-jarvis no se tocó.

Parámetro	Valor	Por qué
num_gpu	32	todas las capas, con el naranja cerrado
num_ctx	24576	32768 no cabe (ver abajo)
num_predict	4096	300 cortaría una tool call
temperature	0.2	emitir JSON no es escribir prosa

Trampa del Modelfile: ollama no admite comentarios en la misma línea que un PARAMETER. Esto falla:

PARAMETER num_gpu 32          # todas las capas
→ Error: invalid int value [32          # todas las capas]

Los comentarios van en su propia línea.

Lo medido de VRAM

Configuración	Resultado
num_ctx 32768, 32 capas	cudaMalloc failed: out of memory
num_ctx 24576, 32 capas	pendiente: hay que medirlo con la tarjeta libre

Escalera si 24576 tampoco entra, en orden de menos a más invasivo: num_ctx 16384 (el suelo: por debajo no cabe el prompt fijo con holgura) → num_gpu 24 → OLLAMA_FLASH_ATTENTION=1 + OLLAMA_KV_CACHE_TYPE=q8_0.

Cuidado con el último: OLLAMA_KV_CACHE_TYPE es del servicio, no del modelo. Se pone en el systemd de ollama y afectaría también al naranja la próxima vez que arranque. Si se usa, hay que anotarlo aquí y en el Modelfile del naranja.

Desde dónde se lanza importa, y mucho

Directorio de arranque	Prompt de sistema
~/COFRE/CODERS/JARVIS	26.281 B
~/.hermes/hermes-agent	55.261 B

La diferencia son 30 KB: el AGENTS.md de 81 KB del propio repo de Hermes, que se cuela como fichero de contexto y encima sale truncado con un aviso. A mano es fácil olvidarlo y sacar medidas que no comparan nada.

Y el cd NO basta (16 ago)

Esto se descubrió subiendo la escalera y es peor que lo anterior, porque no deja ni un error. verde-launcher.sh hacía cd "$RAIZ" antes de llamar a Hermes, que parece suficiente y no lo es: Hermes restaura el directorio de trabajo apuntado en la sesión y se salta aquel desde el que lo lanzas.

El síntoma: se le pide "lee verde/README.md y resúmelo en una línea" y devuelve

Gitleaks es una herramienta SAST diseñada para detectar y prevenir secretos codificados a mano en repositorios git.

Parece el modelo alucinando de manera espectacular. No lo es. En la base de sesiones se ve la llamada real:

terminal  {"command": "cat ~/README.md | head -50"}

Resolvió verde/README.md contra ~, ahí hay un README.md que es el de Gitleaks, lo leyó entero y lo resumió bien. La herramienta funcionó, el modelo entendió, el resumen es correcto — y la respuesta es inútil.

Lo que NO lo arregla, probado

--in DIR no vale en modo -z. Parece la bandera exacta —entra en el directorio y se salta la restauración, mientras que --no-restore-cwd solo hace lo segundo— y con ella el fallo se repitió igual. El motivo está en hermes_cli/main.py:11324: el modo de una sola pregunta sale por _run_and_exit_oneshot(...) y termina el proceso ahí, sin llegar nunca a cmd_chat, que es la única función donde se atiende --in. Se ignora en silencio. En el TUI sí funciona, y por eso verde-launcher.sh la pasa.

Un cd delante tampoco. Comprobado del modo más directo posible:

pwd del shell : ~/COFRE/CODERS/JARVIS
pwd del agente : ~

Y no es que el modelo se lo invente: el ls -d */ que ejecutó por su cuenta devolvió BIKEPARK/ COFRE/ ctf/ Downloads/…, o sea el $HOME de verdad.

Lo que sí lo arregla

terminal.cwd en ~/.hermes/config.yaml, que de fábrica viene como "." y que su propia documentación describe como "el directorio actual donde ejecutas hermes". No lo es.

terminal:
  cwd: "~/COFRE/CODERS/JARVIS"

Verificado: con eso el prompt de sistema pasa a decir working directory: ~/COFRE/CODERS/JARVIS. Está replicado en verde/config.yaml y lo comprueba pruebas/03_config.sh.

Ojo, que esto ATA el carril a este repositorio. Es lo correcto para un banco de pruebas que se compara contra el naranja, y es una limitación real si algún día se quiere que el verde mire ~/BIKEPARK o ~/oasis. Con la raíz en $HOME además se ahoga: un search_files de *.md devolvía sobre todo site-packages/ de los venv de entrena/.

Cómo se diagnosticó, que es reutilizable: -z imprime solo el texto final, sin las llamadas a herramienta, así que desde fuera no se ve nada. Todo queda en ~/.hermes/state.db, tabla messages, columnas tool_calls y content:

python3 -c "
import sqlite3
c = sqlite3.connect('file:$HOME/.hermes/state.db?mode=ro', uri=True)
for r in c.execute('SELECT role, tool_name, tool_calls, content FROM messages ORDER BY rowid DESC LIMIT 10'):
    print(r)
"

Sin mirar ahí, este fallo se atribuye al modelo y se acaba cambiando de modelo para nada.

Por qué se paró: dataset.py

El arranque en GPU quedó aplazado, no descartado. La gráfica la tiene un trabajo tuyo: JARVIS/entrena/dataset.py, que genera pares pregunta-respuesta de COFRE con qwen3.5:4b-jarvis. Son 7-10 horas (tu propio README lo dice) y va por 100/2261 fragmentos.

Detalle que confunde y conviene tener escrito: mientras ese script corra, ollama stop qwen3.5:4b-jarvis parece no funcionar. Sí funciona — descarga el modelo — pero la siguiente petición del script lo vuelve a cargar en segundos. No es un fallo de ollama.

Comprobado que los ollama stop no rompieron la generación: siguió de 199 a 224 ejemplos en 75 s.

Retomar cuando termine

# 1. confirmar que dataset.py acabó y la tarjeta está libre
pgrep -f 'entrena/dataset.py' || echo "terminado"
nvidia-smi --query-gpu=memory.used --format=csv,noheader     # ~140 MiB

# 2. medir si 24576 cabe
curl -s http://127.0.0.1:11434/v1/chat/completions -H 'Content-Type: application/json' \
  -d '{"model":"qwen3.5:4b-verde","messages":[{"role":"user","content":"ok"}],"max_tokens":5}'
curl -s http://127.0.0.1:11434/api/ps | python3 -m json.tool | grep -E 'size_vram|context_length'

# 3. decirle a Hermes el contexto REAL (si no, cree que son 262144)
#    en ~/.hermes/config.yaml, bloque model:, en las lineas canonicas (~82/~95)
#      default: "qwen3.5:4b-verde"
#      context_length: 24576

# 4. LA PRUEBA DECISIVA, antes de abrir el TUI: ¿emite tool_calls?
curl -s http://127.0.0.1:11434/v1/chat/completions -H 'Content-Type: application/json' -d '{
  "model":"qwen3.5:4b-verde",
  "messages":[{"role":"user","content":"¿Cuánto espacio libre queda en el disco?"}],
  "tools":[{"type":"function","function":{"name":"ejecuta_comando",
    "description":"Ejecuta un comando de shell",
    "parameters":{"type":"object","properties":{"comando":{"type":"string"}},"required":["comando"]}}}]}' \
  | python3 -m json.tool

El paso 4 separa dos preguntas que juntas se contestan mal: ¿sabe el modelo emitir una llamada? y ¿funciona Hermes?. Si sale tool_calls con JSON válido, lo que falle después es de Hermes. Si contesta en prosa, abrir el TUI solo daría un fallo más confuso.

Después, la escalera del plan: "hola" → una herramienta → ficheros → varias vueltas encadenadas (el escalón que separa un chatbot de un agente) → skills. La voz al final, y la escucha la última de todas: los 839 MiB de pico de whisper contra una tarjeta que tendrá el modelo casi entero.

Estado de la gráfica

	VRAM	Quién
Antes de instalar	878 MiB de 4096	tres whisper-server tuyos, del naranja
Después de instalar	127 MiB de 4096	nadie; tus whisper acabaron solos

Instalar no cargó nada en la tarjeta. Comprobado con nvidia-smi --query-compute-apps y con /api/ps de Ollama, que devolvió {"models": []} en todo momento.

De paso, un dato que puede interesarte del naranja: llegaste a tener tres whisper-server a la vez, ~880 MiB cada uno, 2648 MiB en total sobre una tarjeta de 4096. Es el escenario exacto del CUDA error: out of memory que documenta el README. No hice nada al respecto —es tu desarrollo en marcha— pero queda anotado.

Verificación en frío, ejecutada

Comprobación	Resultado
hermes en PATH	~/.local/bin/hermes
Tamaño de ~/.hermes	2,2 GB
Caché de Playwright	622 MB
Credenciales con valor en .env	0
Tokens de mensajería	0 (por eso el gateway nunca arrancó)
URLs de nube activas en config.yaml	0
Puertos fuera de loopback	ninguno
Modelos cargados en Ollama	ninguno
Puente de voz	funciona: 0,34 s para 3,2 s de audio, 22050 Hz mono

Las 11 líneas con contenido del .env no son claves: son TERMINAL_TIMEOUT, BROWSER_SESSION_TIMEOUT, banderas de depuración y similares.

Trampa: claves YAML duplicadas en config.yaml

Esto casi cuela y merece quedar escrito. El config.yaml que genera el instalador declara provider y base_url dos veces dentro del bloque model:: una arriba, junto a default, y otra ~45 líneas más abajo. En YAML la última repetición gana.

Al configurar Ollama arriba, el fichero parecía correcto leyéndolo, y al parsearlo salía esto:

model.provider: auto
model.base_url: https://openrouter.ai/api/v1

Es decir: el carril habría salido por OpenRouter creyendo yo que iba a localhost. Se arregló dejando los valores solo en las líneas de abajo, las canónicas.

La lección, que vale para todo este fichero: con 1890 líneas y 121 activas, no basta con leerlo. Hay que parsearlo:

python3 -c "import yaml;d=yaml.safe_load(open('$HOME/.hermes/config.yaml'));print(d['model'])"

Trampa: la instalación de Chromium se cuelga

Le pasa a más gente (issue #35166 del repo). El zip se descarga entero y la extracción se queda parada: 50 minutos de reloj con 1 segundo de CPU y cero crecimiento en ~/.cache/ms-playwright/. El timeout del instalador mata al padre y deja procesos huérfanos reteniendo un __dirlock, así que el reintento también falla.

Se resolvió a mano, y si vuelve a pasar tras un hermes update, esta es la receta:

pkill -f oopDownloadBrowserMain; pkill -f 'playwright install'
rm -rf ~/.cache/ms-playwright/chromium-1208 ~/.cache/ms-playwright/__dirlock
mkdir -p ~/.cache/ms-playwright/chromium-1208
unzip -q /tmp/playwright-download-*/playwright-download-chromium-*.zip \
      -d ~/.cache/ms-playwright/chromium-1208/
touch ~/.cache/ms-playwright/chromium-1208/INSTALLATION_COMPLETE

El INSTALLATION_COMPLETE es lo que Playwright mira para dar el navegador por bueno (lib/server/registry/index.js:1345). Sin él lo reinstala cada vez.

Quedaron los tres componentes, verificados con playwright install --dry-run:

	Tamaño
chromium-1208	364 MB
chromium_headless_shell-1208	254 MB
ffmpeg-1011	4,9 MB

El binario responde: Google Chrome for Testing 145.0.7632.6.

Resuelto: tu voz afinada SÍ se puede reutilizar

Era la pregunta abierta del plan, y salió el mejor de los tres desenlaces.

Hermes tiene un proveedor de TTS por comando que no está documentado en su web. Está en tools/tts_tool.py, bloque "Custom command providers":

tts:
  provider: mi-voz
  providers:
    mi-voz:
      type: command
      command: "... {output_path} {input_path}"
      output_format: wav

Marcadores: {input_path}, {text_path}, {output_path}, {format}, {voice}, {model}, {speed}. Ejecuta con shell=True.

Eso permite llamar al mismo config/jarvis-piper.sh que usa el naranja, así que el verde suena exactamente igual: mismo binario Piper 1.2.0, mismo .onnx, misma cadena de audio. Sin esto la comparación de voz entre carriles no habría valido nada.

Dos detalles que obligaron a escribir voz-verde.sh en vez de meter el comando directo en el YAML:

1. El entorno se limpia. _run_command_tts llama a hermes_subprocess_env(inherit_credentials=False), así que JARVIS_PIPER_VOZ y JARVIS_PIPER_TONO no llegarían. Se ponen dentro del adaptador.
2. Las interfaces no encajan. jarvis-piper.sh quiere el texto como argumento; Hermes entrega un fichero. El adaptador hace de puente.

Qué voz, y ojo con el README

voz-verde.sh usa davefx a tono 1.0, que es lo que tiene el núcleo hoy (nucleo/boca/voz.py: POR_DEFECTO = "davefx", JARVIS_PIPER_TONO = "1.0").

El README.md del repo describe sharvard + 0,86 = 106 Hz como "la puesta". Eso era el JARVIS sobre Newelle. El verde copia al núcleo, que es contra quien se va a comparar, no al README. Si algún día el núcleo vuelve a sharvard, hay que cambiarlo aquí también.

De paso: el Piper de Hermes es el GPL, no el tuyo

El proveedor piper de serie usa OHF-Voice/piper1-gpl (GPL-3.0). El tuyo es el original rhasspy/piper 1.2.0, MIT, archivado en octubre de 2025. Los dos son software libre; no son el mismo paquete. Como usamos el comando y no el proveedor de serie, el verde habla con tu Piper MIT.

El cerebro: lo que hay que vigilar

Configurado como proveedor custom contra http://127.0.0.1:11434/v1 con qwen3.5:4b-jarvis. Ollama ya habla OpenAI, no hace falta puente.

Pero la propia guía de Hermes avisa de algo que hay que probar. Su tabla de modelos locales dice, literalmente, que para trabajo agéntico completo hace falta gemma4:31b, y marca sin tool calling a todo lo de 9B para abajo:

Modelo (su tabla)	Tool calling
gemma4:31b	Sí
gemma2:27b	No
gemma2:9b	No
llama3.2:3b	No

Su tabla no lista qwen3.5, que sí hace tool calling — el commit "nucleo: el cerebro con tool calling nativo" lo demuestra. Pero lo demuestra en tu arnés, no en el de Hermes, que inyecta muchas más definiciones de herramientas por vuelta. Así que:

• Es lo primero que hay que comprobar al arrancar: si el 4B llama herramientas bien dentro de Hermes o se atraganta.
• Si se atraganta, esta máquina tiene 62 GB de RAM: un modelo grande cabe, aunque iría por CPU (~2-5 tok/s según su guía, 30-120 s por respuesta). Para eso está HERMES_API_TIMEOUT=1800 documentado en env.ejemplo.
• qwen3.5:9b (6,14 GB) es el escalón intermedio, y solo con el naranja cerrado.

Aviso de contexto: si se define num_ctx propio en Ollama, hay que poner el mismo en Hermes. Su /api/show reporta el contexto máximo del modelo, no el configurado, así que Hermes puede creer que tiene más sitio del que hay.

Antes de comparar los dos carriles: no midas peras y manzanas

El naranja tiene 150 acciones rápidas que se saltan el modelo: "¿cuánto espacio queda?" es un df, no una inferencia. Hermes no tiene ese atajo — allí toda orden pasa por el cerebro, con las herramientas, las skills y la memoria en contexto en cada vuelta.

El verde va a medir más lento, y no será culpa del modelo. Para comparar de verdad hay que usar solo las frases que hoy no encajan en el catálogo y acaban en el cerebro: son las únicas donde los dos hacen lo mismo. Las hay anotadas en config/jarvis-sin-accion.jsonl.

Pendiente: dependencias de sistema de Playwright

El instalador pidió sudo para las librerías de sistema de Chromium, se declinó (no hay sudo sin contraseña) y degradó solo: instaló el binario en la caché del usuario. Chromium arrancará si las librerías ya están; si se queja, esto es lo que hay que correr una vez:

cd ~/.hermes/hermes-agent && sudo npx playwright install-deps chromium

Qué se descargará el primer día que arranques

Nada de esto ha pasado todavía. Que no sorprenda:

	Cuándo	Cuánto
Modelo de whisper small	primera transcripción	~500 MB en disco, 839 MiB de pico en GPU
Modelo de Ollama	ninguno — 4b-jarvis ya está	0
Voces de Piper	ninguna — usamos las tuyas	0

stt.local.unload_after_idle_seconds: 300 está puesto justo por los 839 MiB: suelta whisper tras cinco minutos de silencio y le devuelve el hueco al modelo. Cuesta una recarga en la frase siguiente.

Se instaló también el driver de Computer Use

Va en la instalación completa. Es el que permitiría a un agente controlar ratón y teclado del escritorio, no solo el navegador. Instalado no es lo mismo que activo — hoy no hay nada que lo invoque — pero conviene saber que está antes de dar permisos a algo. Si se quiere fuera: --skip-computer-use.

Dato que sí importa en esta máquina: ese driver no viene de Nous. El instalador lo trae con un curl | bash contra terceros:

https://raw.githubusercontent.com/trycua/cua/main/libs/cua-driver/scripts/install.sh

O sea que el envoltorio instalar.sh audita el instalador de Hermes, pero ese instalador se descarga y ejecuta otro script de otro repo sin que nadie lo mire. Con COFRE en esta máquina, merece una lectura antes del próximo hermes update. Está en ~/.hermes/hermes-agent, y el binario resultante también.

Las 104 pruebas del naranja: NO se ejecutaron

El plan decía correr pruebas/ejecutar.sh para comprobar que el naranja seguía dando el mismo número. No se hizo, y a propósito: esa suite abre la aplicación y carga el modelo, que es exactamente lo que se pidió no hacer mientras el naranja estaba en desarrollo.

Queda pendiente para cuando pares de desarrollar:

cd ~/COFRE/CODERS/JARVIS/pruebas && ./ejecutar.sh

En su lugar se comprobó lo que sí se podía en frío: que la gráfica quedó libre y que el verde no escribió fuera de su sitio. Todo lo suyo vive en verde/, en ~/.hermes/, más tres ficheros de escritorio (~/.local/share/icons/jarvis-verde.png, ~/.local/share/applications/jarvis-verde.desktop) y la caché de Playwright.

Los 13 ficheros que git status da por modificados son todos anteriores a esta sesión: el más reciente es config/set_persona.py a las 13:22 y esto empezó a las 16:09. Y los ficheros nuevos que aparecen en nucleo/ después de esa hora —arranca.sh, estado.py, ventana.sh, pruebas/prueba_cara.py…— son tu desarrollo del naranja de esta tarde: no existían cuando se listó esa carpeta al empezar.

La duda del 4B: resuelta, y a favor (16 ago)

Era la pregunta abierta del carril — la guía de Hermes marca sin tool calling todo lo de 9B para abajo y recomienda gemma4:31b para trabajo agéntico.

qwen3.5:4b llama herramientas bien dentro de Hermes. Comprobado primero contra el endpoint pelado (pruebas/04_tool_calling.sh, tres casos) y después en el arnés completo, con las 19 herramientas en contexto:

Caso	Resultado
Pide herramienta cuando hace falta	terminal {"command": "df -h ."}
Acierta la herramienta y sus dos argumentos	escribe_fichero {"ruta": …, "contenido": …}
No llama cuando no hace falta ("¿cuánto son dos más dos?")	contesta 4 en prosa

El tercero importa tanto como los otros: un modelo que llama siempre es tan inútil como uno que no llama nunca, y con una sola pregunta no se distinguen.

El escalón 6: habla, y con la voz del naranja (16 ago)

text_to_speech → proveedor jarvis-piper → voz-verde.sh → config/jarvis-piper.sh. Comparado el WAV que salió de Hermes con el que genera la prueba 07_voz.sh llamando al adaptador a pelo:

	Hermes	Directo
Frecuencia	22050 Hz	22050 Hz
Canales	1	1
Bits	16	16

Idénticos, que era el objetivo: mismo binario Piper 1.2.0 MIT, mismo .onnx, mismo tono. La comparación de voz entre los dos carriles vale, que es para lo que se montó el adaptador.

De propina, sin que nadie se lo pidiera contestó "Perfecto, señor" y "Todos mis sistemas están listos para sus órdenes". El registro de JARVIS sale del SOUL.md de Hermes, no de la persona del naranja, y aun así coincide.

Queda el juicio que no es medible: si suena bien. El fichero está en ~/.hermes/cache/audio/.

EL ESCALÓN 5 ROMPIÓ LA PREMISA: el agente se fue a internet solo (16 ago)

Esto es lo más serio de la sesión de estreno y hay que leerlo antes que nada.

Se le pidió "hazme un cartel en arte ascii que ponga JARVIS" — a propósito sin nombrar ninguna skill, que es lo que medía el escalón. Lo que hizo:

#	Llamada	Resultado
1	skill_view {"name": "ascii-art"}	eligió la skill sola ✓
2	python3 -m pyfiglet "JARVIS" --font slant	No module named pyfiglet
3	curl https://asciified.thelicato.io/api/v2/ascii?text=JARVIS	salió a internet

Nadie le dijo que podía. La skill menciona pyfiglet, pyfiglet no está instalado, y el modelo resolvió el hueco buscando el servicio equivalente en la web y mandándole el texto a un tercero.

Por qué no lo cazaba nada

pruebas/06_privacidad.sh pasa, y seguirá pasando: comprueba configuración —cero credenciales, cero URLs de nube en el YAML, nada escuchando fuera de loopback— y esto no es configuración, es conducta en marcha. El agente tiene una terminal y la terminal tiene curl. No hay ajuste que lo impidiera.

Es una diferencia de fondo con el naranja, y conviene que quede escrita: el naranja ejecuta un catálogo cerrado de 150 acciones. El verde decide qué ejecutar, y ese es justo su valor y justo su riesgo. No se puede tener lo uno sin lo otro.

Lo que se puede hacer, por orden de menos a más invasivo

1. Instalar lo que las skills dan por hecho (pip install pyfiglet). Quita el motivo, no la capacidad. Es parche, no solución.
2. Apagar las skills que tiran de red: hermes skills disable <nombre>.
3. Recortar herramientas en platform_toolsets del config.yaml, que ya estaba apuntado como palanca para el contexto y sirve para esto también.
4. Cortar por debajo: regla de cortafuegos para el proceso, o terminal en contenedor sin red. hermes egress no vale para esto — es iron-proxy, un proxy que INYECTA credenciales en las salidas, no un bloqueo.

No he aplicado ninguna. Cualquiera de ellas cambia lo que el carril sabe hacer, y eso es una decisión del usuario, no una corrección técnica.

Y el cartel salió mal

Aparte de todo lo anterior: el banner que curl devolvió era correcto, y al copiarlo a su respuesta final el modelo lo destrozó. Mismo patrón que la lista de ficheros del escalón 4: el 4B razona bien la cadena y es descuidado reproduciendo texto literal largo. 4 min 58 s en total.

El escalón 7 (la escucha) cabe, y por un motivo que sorprende (16 ago)

El plan lo dejaba para el final temiendo un CUDA error: out of memory: whisper small pide 839 MiB en el pico de la transcripción y la tarjeta son 4096. Medido con el verde cargado y trabajando:

	MiB
Tarjeta	4096
Ocupado por el modelo verde (65536 ctx, 16 capas)	2902
Libre	1062
Pico de whisper small	839
Margen	223

Cabe. Y lo que sorprende es que el verde deja más sitio que el naranja: 2902 MiB contra los 2941 del reparto automático de ollama para qwen3.5:4b-jarvis. Bajar 16 capas a la CPU libera tarjeta, así que el precio que se paga en velocidad se cobra en VRAM.

Sigue siendo justo —223 MiB— y falta la prueba de verdad, que necesita micrófono. Pero la aritmética que hacía temer el escalón ya no dice lo que decía.

Para probar cuando arranques

• Tema del panel web. dashboard.theme acepta default, midnight, ember, mono, cyberpunk, rose. No he podido ver sus paletas (el panel va empaquetado), pero cyberpunk o mono son los candidatos a pegar con el verde. El TUI no tiene tema: ahí el color lo pone verde-launcher.sh con secuencias OSC.
• Los escalones 5, 6 y 7 de ESCALERA.md: una skill, la voz dentro de Hermes y la escucha por micrófono. Los tres piden criterio u oído, o el micrófono, así que no se automatizan.
• Si merece la pena la palanca del KV caché. OLLAMA_FLASH_ATTENTION=1 + OLLAMA_KV_CACHE_TYPE=q8_0 partiría el caché por la mitad y devolvería capas a la tarjeta, que es justo lo que hoy cuesta el tiempo de respuesta. No se ha aplicado: es del servicio de ollama y afectaría también al naranja.

Noche del 16-17 ago: voz de entrada, RAG y frontal a nivel del naranja

Encargo: subir el verde al nivel del naranja en voz, RAG y frontal. Todo local, nada a gitea (pendiente de revisión).

La escucha, resuelta y en local (escalón 7 cerrado sin micro)

El TUI de Hermes no tiene micrófono, y su STT nativo (stt: del config) es para notas de voz de mensajería — saldrían de la máquina. Así que se puentea:

• verde/escucha_transcribe.py — WAV → texto con faster-whisper small (el mismo que declara el config), en CPU a propósito: el 4B ocupa la tarjeta y el margen es de 223 MiB; whisper en CPU tarda ~12 s por frase y no arriesga OOM. No llama a ninguna API.
• verde/escucha-verde.sh — pulsar-para-hablar: graba (pw-record/arecord/parec) → transcribe → hermes chat --reasoning none -q → responde; --habla lo dice con la voz del verde, --seguido encadena turnos.
• verde/pruebas/08_escucha.sh — 8/8. Bucle TTS→STT sin micro: genera voz con el 07, la transcribe y comprueba que vuelven las palabras clave. Mide y verifica que el transcriptor no referencia APIs remotas.

Medido: "hola jarvis verde cuanto espacio libre queda en el disco" → "¿Cuánto espacio libre queda en el disco?" (solo pierde "jarvis"→"harvis", nombre raro).

Latencia honesta: la ESCUCHA va bien (~12 s CPU). El cuello es el 4B (minutos por turno). El puente sirve para PROBAR que el verde oye, no como diario.

RAG del naranja, disponible en el verde

El agente ya puede consultar el mismo índice que el núcleo (14.949 entradas):

• nucleo/saber/busca_cli.py — CLI sobre saber.busca (texto o --json).
• Skill local ~/.hermes/skills/research/buscar-en-apuntes/ — le dice al agente cuándo y cómo buscar (herramienta de terminal, local). hermes skills list: buscar-en-apuntes · research · local · enabled.

Skills de ECC (el ganador del hackathon de Claude)

Instaladas 4 por hermes skills install (escaneadas SAFE): security-review, git-workflow, python-testing, coding-standards. Total 82 skills. El prompt fijo apenas sube (29 KB, lejos de 64k). Probada security-review con el 4B: checklist correcto, 4 min 30 s en frío.

Noche: expansión del RAG + reentrenamiento (auto mode, local, sin gitea)

Contenido añadido al índice PERSONAL (nunca al público sin revisar licencias):

• Strix (usestrix/strix, agente IA de pentesting) clonado en CODERS; sus docs (README, docs/, AGENTS, benchmarks) indexados → 49 fragmentos.
• 6 awesome lists más: sysadmin, cli-apps, security, pentest, shell, linux (catálogo pasa de 385 a 740 fragmentos). En awesome.py, publico=False.
• Apps instaladas de esta máquina: nucleo/saber/instalado.py lee los .desktop (146 apps) + apt-mark showmanual (22 fragmentos). Personal por definición.
• Índice personal: ~49 MB. Reindex raw hecho; contenido recuperable ya.

Reentrenamiento nocturno: nucleo/saber/enriquece/reentrena_noche.sh encadena síntesis de ganchos del contenido nuevo → reindex → eval → refresco COFRE (cosecha+sintetiza) → reindex final. Corre detached, log en datos/reentrena_noche.log.

Pendiente de revisar por la mañana: licencias de las 6 awesome nuevas antes de subir nada; y decidir qué de todo esto va al índice público / gitea.

Cierre de la noche (07:52) — números y decisiones

Dos rondas de reentrenamiento. Índice final: 64 MB, 19.578 entradas (12.260 preguntas-gancho, 1.383 catálogo, 168 apps, 459 metodología incl. strix).

Retrieval (eval_set ampliado a 57 casos = 45 pentest + 12 amplitud):

• Ronda 1: hit@1 77%, hit@5 96%
• Ronda 2 (+osint/devops/docker/go/python): hit@1 75%, hit@5 96%
• Amplitud sola (apps/self-hosted/cli/linux/strix): hit@1 75%, hit@5 100%

Intercambio medido: pentest puro pasó de 82% (antes de la noche) a ~75% de hit@1; hit@5 se mantiene 95-96%. Es el precio de la amplitud. Las listas gigantes (awesome-go, 3197 items → 322 fragmentos; osint con algún artefacto de TOC) son las que más ruido meten y menos aporta a consultas por voz.

Decisiones para la mañana:

1. Licencias de las 12 awesome lists antes de publicar nada (ahora todas publico=False = solo índice personal).
2. Si se prioriza precisión pentest: quitar awesome-go (y quizá awesome-python) recuperaría 1-2 pts de hit@1 sin perder casi cobertura útil.
3. Qué del contenido nuevo va al índice público / gitea (hoy: nada subido).