Seguro que te ha pasado: conectas un servidor local de vLLM a Hermes y, al cabo de unas pocas interacciones, te anuncia «contexto completo» — aunque tu modelo maneje sin problema 8K o 128K de tokens. O cambias a un modelo recién publicado que claramente tiene visión, y Hermes insiste en que «este modelo no admite imágenes». Normalmente el problema no es el modelo: la imagen que Hermes tiene de él procede de un catálogo de modelos, y el tuyo no aparece en él, o su entrada está desactualizada. La buena noticia: desde la v0.20.1 puedes corregir todo eso directamente en config.yaml con model_overrides y decirle a Hermes exactamente qué modelo es el tuyo.

Por qué ocurre: los puntos ciegos del catálogo de modelos

Hermes decide lo que un modelo puede hacer —la longitud de su ventana de contexto, si admite herramientas, visión o razonamiento— basándose principalmente en models.dev, un catálogo público de modelos, además de algunas reglas de respaldo integradas. Eso cubre bien los modelos cloud más habituales, pero siempre hay huecos:

• Modelos locales: tu servidor de vLLM, Ollama o llama.cpp usa IDs de modelo que tú has inventado; no están en el catálogo;
• Modelos recién publicados: acaban de salir de un proveedor y aún no están catalogados;
• Entradas desactualizadas: la ventana de contexto figura como demasiado pequeña, las capacidades son incorrectas o el proveedor lanzó una actualización que el catálogo aún no ha reflejado.

En esos casos, Hermes recurre a «valores por defecto seguros»: los modelos desconocidos reciben una estimación de contexto de 200K, la llamada a herramientas activada, pero la visión y el razonamiento desactivados. Cuando la suposición es errónea, aparece exactamente el comportamiento extraño del principio: capacidades que existen se tratan como si no estuvieran, y el contexto por el que pagaste se desperdicia.

La solución: model_overrides en config.yaml

model_overrides es una nueva sección de configuración de nivel superior que llegó en la v0.20.1 (PR #85560). Su función es sencilla: para un modelo concreto dentro de un provider concreto, declaras los metadatos a mano y anulan los del catálogo. Así:

model_overrides:
  custom:my-local-vllm:        # provider name, then the model ID
    my-llava-model:
      context_window: 8192     # this model's real context is 8K
      supports_vision: true    # it does accept images
    my-llama-model:
      context_window: 32768
      supports_tools: false    # tool calls are flaky here — turn them off
  upstage:                     # you can also fix cloud models
    solar-pro4:
      context_window: 524288   # not in the catalog; actually 512K

Reinicia Hermes después de guardar (edita con hermes config edit y reinicia la sesión) y las anulaciones surtirán efecto. Escribe únicamente los campos que el catálogo tenga mal o le falten: todo lo que dejes fuera conserva el valor del catálogo, de modo que no puedes romper otros ajustes por accidente.

Los tres campos que usarás más a menudo

Rara vez los necesitas todos. En el día a día suele ser uno de estos:

• context_window: la longitud de contexto del modelo en tokens. Si lo fijas demasiado bajo, las conversaciones se cortan pronto; si lo fijas demasiado alto, el modelo divaga sobre un contexto sobredimensionado — busca el número real siempre que puedas.
• supports_vision: si el modelo acepta imágenes como entrada. Es la trampa más habitual con los modelos de visión locales (estilo LLaVA): sin esta declaración, Hermes nunca te ofrece la opción de enviar imágenes.
• supports_tools: si el modelo puede hacer tool calling (llamada a herramientas). Si un modelo no es fiable usando herramientas, es mejor desactivarlo aquí explícitamente que verlo fallar una y otra vez.

La lista completa de campos

model_overrides admite todos estos campos, con el mismo significado que los metadatos de modelo:

Field	Meaning
context_window	Longitud de contexto en tokens
max_output_tokens	Máximo de tokens de salida por respuesta
supports_tools	Soporte de llamada a herramientas (true por defecto para modelos desconocidos)
supports_vision	Soporte de entrada de imágenes (false por defecto)
supports_reasoning	Soporte del modo razonamiento (false por defecto)
model_family	Identificador de familia de modelo usado por el emparejamiento de respaldo

_default: una red de seguridad para modelos no catalogados

Escribir cada modelo a mano es tedioso. Puedes definir un _default por provider —o a nivel global— como respaldo para los modelos que el catálogo no conoce:

model_overrides:
  custom:my-vllm:
    _default:                  # applies only to uncataloged models
      context_window: 32768
  _default:                    # global fallback, gap-filling only
    context_window: 128000

_default rellena huecos por diseño: solo se aplica a los modelos que el catálogo no conoce y nunca sustituye los datos del catálogo para los conocidos. Así, un valor por defecto global no puede limitar por accidente todos los modelos de un provider: los modelos conocidos conservan sus valores del catálogo.

Dos escenarios reales

Escenario uno: un modelo de visión local. Estás sirviendo un modelo con ID personalizado a través de vLLM y sí acepta imágenes. Sin configuración, Hermes asume que no tiene visión en absoluto:

model_overrides:
  custom:my-vllm:
    my-llava-model:
      context_window: 8192
      supports_vision: true

Escenario dos: un modelo cloud recién publicado. El solar-pro4 de Upstage no estaba en el catálogo cuando se lanzó, así que la regla de respaldo lo trataba como si tuviera 256K de contexto cuando en realidad tiene 512K. Decláralo y podrás usar la ventana completa:

model_overrides:
  upstage:
    solar-pro4:
      context_window: 524288

Cosas que debes saber

• Los nombres de provider admiten ambas grafías: el ID de provider de Hermes (p. ej. custom:my-vllm) o el ID de models.dev (p. ej. github-copilot) — ambos se reconocen.
• Los IDs de modelo se comparan sin distinguir mayúsculas, igual que la búsqueda en el catálogo.
• Los valores incorrectos avisan, nunca rompen nada: un valor mal formado (por ejemplo, context_window: "512k") registra una advertencia y los campos válidos se siguen aplicando.
• Precedencia: las entradas explícitas ganan a los valores por defecto de models.dev, OpenRouter y los integrados; un context_length por modelo definido en custom_providers tiene prioridad sobre todo, así que nunca se ve pisado.
• Esto combina a la perfección con custom_providers (endpoints de API personalizados): los servidores locales, las pasarelas proxy y los modelos internos funcionan todos con la misma combinación.

Resumen

Los metadatos de modelo incorrectos son una de las trampas más traicioneras para quienes usan modelos locales o recién publicados: la capacidad está ahí, solo que Hermes no la conoce. model_overrides existe precisamente para eso — sin cambios de código, sin esperar a que el catálogo se actualice; declara unas pocas líneas en config.yaml y Hermes por fin conocerá tu modelo. Si todavía no has explorado la configuración de modelos personalizados, la guía de instalación explica cómo configurar providers, y los providers de modelo instalados con pip muestran una forma complementaria de presentarle a Hermes nuevos modelos.