Hermes reasoning effort: sesión, nivel global y ajustes por modelo

Usar siempre el nivel máximo de reasoning en Hermes no mejora todas las tareas, y ver thinking en pantalla tampoco demuestra que la solicitud haya usado el nivel elegido. Un método más fiable consiste en mantener un valor global razonable, elevarlo solo para trabajos difíciles, añadir valores por modelo cuando existan pruebas repetibles y confirmar el resultado con una tarea verificable y los registros reales del proveedor.

Regla práctica: empieza por medium

Hermes acepta none, minimal, low, medium, high, xhigh, max y ultra. Si no defines un valor, resuelve medium. Un modelo o una ruta puede admitir solo parte de la escala; el nivel puede reducirse, traducirse, ignorarse o rechazarse. Consulta la documentación de configuración de Hermes y el registro de la solicitud en tu proveedor.

Tipo de tarea	Punto de partida	Cuándo cambiar
Formato, extracción de campos o reescritura determinista	low; prueba minimal o none solo si la ruta lo admite	Sube a medium si faltan campos o se rompe el formato
Cambio pequeño de código, pregunta habitual o depuración bien delimitada	medium	Prueba low tras varios aciertos; usa high si se omiten restricciones
Revisión con muchas condiciones, diagnóstico entre archivos o análisis de alternativas	high	Prueba xhigh o max únicamente si la mejora se repite y la espera es aceptable
Planificación excepcionalmente difícil	Compara primero high y xhigh	Mantén max o ultra solo si una prueba controlada muestra una ventaja útil

ultra es un escalón interno de Hermes. La ruta lo transforma en el valor más alto que pueda enviar, por lo que no conviene convertirlo en valor global sin medirlo.

Mostrar thinking no es lo mismo que cambiar el effort

Estos comandos modifican el reasoning effort de la sesión actual:

/reasoning high
/reasoning none

Estos otros solo controlan la visualización de thinking:

/reasoning show
/reasoning hide

Ocultar thinking no impide que la solicitud trabaje con high. Mostrarlo tampoco prueba que el nivel sea alto. Ejecuta /reasoning sin argumentos para ver por separado el effort actual y el estado de visualización.

Cuándo usar sesión, configuración global o ajuste por modelo

Sesión: una tarea difícil concreta

Dentro de una sesión activa, ejecuta:

/reasoning high

Por defecto, el cambio se limita a esa sesión. Es la forma más segura de aumentar el esfuerzo para una depuración o decisión puntual sin alterar las conversaciones futuras.

Para solicitar reasoning desactivado en la sesión:

/reasoning none

Solo funcionará si el modelo y la ruta permiten desactivarlo. El proveedor puede exigir reasoning, interpretar el valor de otra forma o rechazarlo, así que debes revisar la solicitud real.

Global: el valor cotidiano

Añade --global para guardar el valor de las sesiones nuevas:

/reasoning medium --global

Hermes lo persiste como agent.reasoning_effort. Para una carga variada, medium suele ser una base más segura que el máximo; eleva solo las sesiones que realmente lo necesiten.

Comprueba la configuración desde el terminal:

hermes config path
hermes config get agent.reasoning_effort
hermes config check

Que config get devuelva el valor demuestra que Hermes lo resolvió, no que el proveedor lo haya aceptado o aplicado sin cambios.

Por modelo: valores estables al alternar rutas

Si cambias con frecuencia entre un modelo rápido y otro de razonamiento profundo, edita config.yaml:

agent:
  reasoning_effort: "medium"
  reasoning_overrides:
    "custom/example-fast-model": "low"
    "custom/example-deep-model": "high"

Una coincidencia en reasoning_overrides tiene prioridad sobre el valor global. Usa preferiblemente el model ID exacto configurado en Hermes. Después de editar, inicia una sesión nueva, selecciona el modelo y vuelve a ejecutar /reasoning.

Para leer el mapa:

hermes config get agent.reasoning_overrides --json

Los model ID suelen contener puntos y barras. Editar YAML directamente es sencillo; si creas una clave con puntos mediante hermes config set, sigue las reglas de escape de puntos literales de la referencia de CLI.

Prioridad: por qué un cambio global puede parecer ineficaz

Para el modelo seleccionado, piensa en este orden:

1. elección temporal de /reasoning en la sesión;
2. entrada coincidente de agent.reasoning_overrides;
3. agent.reasoning_effort global;
4. valor predeterminado del modelo o proveedor.

Si el valor global es low pero /reasoning muestra high, busca primero un ajuste activo de sesión o una regla por modelo. Compruébalo de nuevo después de /model, porque el nuevo modelo puede coincidir con otra regla.

Compara siempre la misma tarea verificable

No pruebes un nivel con una reescritura trivial y otro con un bug complejo: estarías midiendo tareas distintas. Este ejemplo tiene una respuesta comprobable y no necesita herramientas:

La función debe unir intervalos enteros cerrados que se solapen o se toquen, sin reducir una cobertura ya existente.
Encuentra un contraejemplo mínimo, indica la salida esperada y la real, propone el cambio de código más pequeño y añade tres pruebas de regresión.
No uses herramientas. Devuelve únicamente JSON con las claves counterexample, expected, actual, fix y tests.

def merge_ranges(ranges):
    ranges = sorted(ranges)
    merged = []
    for start, end in ranges:
        if not merged or start > merged[-1][1] + 1:
            merged.append([start, end])
        else:
            merged[-1][1] = end
    return merged

El fallo aparece cuando un intervalo posterior queda contenido en el actual: asignar un final menor reduce la cobertura. Puntúa cinco criterios objetivos, no el estilo:

1. JSON válido sin texto adicional;
2. contraejemplo de intervalo contenido que active el fallo;
3. valores expected y actual correctos;
4. arreglo mínimo que conserve el extremo mayor;
5. pruebas para intervalos contenidos, contiguos y separados.

Comparación manual

Abre una sesión nueva para cada nivel. Mantén constantes el model ID, el proveedor, el directorio, el contexto, las herramientas, el texto y el formato de salida. Una ejecución sirve como filtro; si vas a cambiar un valor de uso frecuente, repite al menos tres veces cada finalista para no confundir una variación aleatoria con una mejora estable.

Registra:

Campo	Cómo medirlo
Effort	Ejecuta /reasoning antes de la tarea y guarda el nivel mostrado
Calidad	Usa la escala objetiva de 0 a 5
Latencia	Tiempo real desde el envío hasta la respuesta final
Modelo y proveedor	Confirma el estado de Hermes y el registro del proveedor
Uso real	Usa el registro de la API o el detalle de facturación del proveedor
Anomalías	Marca timeout, retry, fallback, error o cambio de modelo

No mezcles una ejecución con retry o fallback con ejecuciones limpias. Puede cambiar a la vez el modelo, el número de llamadas, la latencia y los Token, por lo que no sirve para aislar el efecto del effort.

Informe local con --usage-file

Para una comparación procesable, cambia temporalmente el nivel global y ejecuta la misma tarea one-shot:

hermes config set agent.reasoning_effort low
hermes -z "Review the supplied merge_ranges function and return the requested JSON only." --usage-file ./hermes-low-usage.json > ./hermes-low-output.txt

hermes config set agent.reasoning_effort medium
hermes -z "Review the supplied merge_ranges function and return the requested JSON only." --usage-file ./hermes-medium-usage.json > ./hermes-medium-output.txt

hermes config set agent.reasoning_effort high
hermes -z "Review the supplied merge_ranges function and return the requested JSON only." --usage-file ./hermes-high-usage.json > ./hermes-high-output.txt

En la prueba real, pasa el mismo texto completo en las tres ejecuciones. Antes de empezar, confirma que no exista un ajuste por modelo que oculte el valor global. Después restaura el valor original. Si antes no estaba definido:

hermes config unset agent.reasoning_effort

Si tenía un valor explícito, vuelve a configurarlo.

El JSON de Hermes puede incluir input_tokens, output_tokens, cache_read_tokens, cache_write_tokens, reasoning_tokens, total_tokens, api_calls, model, provider y estimated_cost_usd. Los contadores superiores cubren el main agent loop. Las llamadas auxiliares, como generación de títulos, vision o compression, aparecen en auxiliary; el total local combinado está en total_including_auxiliary.

Mantén claras tres fronteras:

• estimated_cost_usd es una estimación local, no la factura del proveedor;
• si el proveedor no devuelve una categoría de Token, un campo ausente no demuestra consumo cero;
• si hay retry o fallback, verifica las llamadas y modelos reales en el registro del proveedor.

Separa cuatro tipos de evidencia

Una verificación útil registra cuatro cosas distintas:

1. Lectura de configuración: hermes config get y config.yaml contienen el valor deseado. Esto demuestra lo que Hermes guardó y resolvió, no lo que aceptó el proveedor.
2. Effort realmente enviado o mapeado: tras elegir el modelo, ejecuta /reasoning. Si el estado muestra sends ... on this route o la ruta expone un trace de la solicitud saliente, comprueba que el valor enviado a la API coincide con el mapeo esperado. La visibilidad de thinking sigue siendo un ajuste de pantalla independiente.
3. Recepción, aceptación o ejecución del proveedor: usa un registro de solicitud del lado del servidor, un valor reflejado o una confirmación explícita de aceptación/ejecución solo cuando la ruta o el proveedor lo expongan. La señal de éxito es que el parámetro registrado por el servidor coincida con el valor enviado/mapeado y que no aparezcan rechazo, retry, fallback ni otra reducción. Un payload trace demuestra recepción, no ejecución; no exijas campos que el proveedor no ofrece.
4. Uso y resultado: registra el modelo real, la calidad de salida, la latencia, las categorías de Token, las llamadas API y el coste cobrado o estimado. Estos datos pueden verificar la ruta y el uso real, pero no el effort aceptado por el proveedor; la cantidad de reasoning Token no permite reconstruir el nivel.

Estos tipos de evidencia no se sustituyen entre sí. Si el registro del proveedor solo muestra modelo, Token, número de llamadas o gasto y no expone effort, la conclusión defendible es que comparaste salida, latencia y uso real bajo las configuraciones registradas, pero no pudiste confirmar el nivel aceptado por el proveedor.

Si none parece no guardarse

Un issue público de GitHub del 5 de octubre de 2026 informó de que, en los commits de main citados por su autor, hermes config set agent.reasoning_effort none podía guardar YAML null, mientras /reasoning none --global guardaba la cadena none. Es un informe de usuario limitado a versiones concretas: no demuestra que tu versión actual siga afectada ni que una posterior lo haya corregido.

Comprueba en este orden:

1. ejecuta /reasoning none --global;
2. ejecuta hermes config get agent.reasoning_effort;
3. abre el archivo indicado por hermes config path y confirma que contiene la cadena none, no un valor vacío o null;
4. inicia una sesión nueva y vuelve a ejecutar /reasoning;
5. si la ruta o el proveedor expone un registro server-side, un valor reflejado o una confirmación explícita, compara el valor enviado/mapeado con el recibido o aceptado; si el registro solo contiene modelo, Token o gasto, anota que no se puede confirmar el effort aceptado en vez de inferirlo.

Si el modelo obliga a usar reasoning, no podrás desactivarlo. Usa el nivel más bajo que admita la ruta en vez de cambiar repetidamente la visualización.

Proveedor personalizado compatible con OpenAI

El comportamiento efectivo depende de Hermes, el modelo y el proveedor. Por ejemplo, la guía de BetterToken para Hermes indica configurar una API Key propia, la Base URL https://www.bettertoken.ai/v1 y el model ID exacto del catálogo, y verificar primero la conexión con una solicitud corta. BetterToken no garantiza que todos los modelos admitan todos los niveles ni que un nivel mayor mejore cada tarea.

Con cualquier proveedor, guarda el model ID, la solicitud y el uso real en la misma tabla. De lo contrario, un cambio inadvertido de modelo, ruta o facturación puede parecer un efecto del reasoning effort.

Elige el nivel más bajo que supere tu umbral de calidad

Mantén medium como base global, usa el scope de sesión para tareas difíciles ocasionales y añade high, xhigh o un nivel superior por modelo solo cuando varias comparaciones de la misma tarea muestren una mejora estable. Para trabajo mecánico, baja a low, minimal o none únicamente si la calidad se mantiene y la latencia medida o el uso real mejoran como esperabas. Verifica el mapeo sends o la aceptación/ejecución del proveedor cuando la ruta lo exponga; si no, declara el límite de la evidencia y no trates los Token o el gasto como prueba del nivel aceptado.

El mejor valor predeterminado no es el teóricamente más potente, sino el mínimo que alcanza de forma constante tu objetivo de calidad con una latencia y un uso real aceptables.