El verano pasado abrí cinco cuentas de proveedores LLM en un mes. OpenAI, Anthropic, OpenRouter, Fireworks, Together. Para octubre no tenía ni idea de qué tarjeta de crédito estaba pagando qué. En diciembre, uno de ellos cambió sus precios sin avisar, y me enteré tres semanas después cuando llegó la factura.
Esta es la verdad poco glamurosa de correr cualquier cosa sobre LLMs en 2026: el zoo de proveedores es una condición permanente. Cada semana aparecen modelos nuevos. Los precios se mueven. Las tiers gratuitas se reordenan. Un modelo que era estado del arte en marzo es una nota al pie en mayo. Si tu framework de agentes elige un proveedor por ti en el momento de la instalación, te estás apuntando a reconstruir tu configuración cada par de meses.
Hermes Agent lleva apostando en la dirección contraria desde el primer día. El proveedor es un valor de configuración, no una elección que la arquitectura toma por ti. Tres funcionalidades se apilan una sobre otra para que esto realmente funcione.
El router central (v0.2.0)
La base es un único punto de llamada. En el lanzamiento de la v0.2.0, el proyecto introdujo un router centralizado de proveedores — una función call_llm() / async_call_llm() por la que pasa todo lo que llama al LLM dentro del agente. Visión, resumen, compresión, guardado de trayectorias, el bucle de chat principal. Todo va por el mismo camino de código.
Suena a detalle de refactorización hasta que intentas cambiar de proveedor en un agente que no lo tiene. En la mayoría de frameworks, hay once sitios que llaman al LLM, y cada uno lee las credenciales de forma ligeramente distinta. Cambias uno, te olvidas de otro, las cosas se rompen de formas difíciles de notar. Hermes lo hizo imposible haciendo que solo haya un sitio.
La cadena de fallback (v0.6.0)
Dos semanas después, la v0.6.0 añadió la siguiente capa: cadenas de fallback ordenadas entre proveedores. Listas los proveedores en config.yaml, y cuando el principal falla — un 429 de rate limit, un 500 transitorio, un endpoint inalcanzable — Hermes automáticamente prueba con el siguiente de la cadena.
Es importante que sea ordenada, no round-robin. Tú eliges una preferencia y un respaldo. Una configuración típica es OpenRouter como opción barata por defecto, Anthropic directo como respaldo fiable, y la tier gratuita de Nous Portal como último recurso de emergencia. Si el de arriba de la cadena está teniendo un mal día, ni te enteras. La versión v0.6.0 corrigió al mismo tiempo un bug sutil: cambiar de proveedor con hermes model ahora limpia el api_mode obsoleto en vez de dejarlo fijo en chat_completions, así que los endpoints compatibles con Anthropic dejan de devolver 404 crípticos después de un cambio.
Pools de credenciales (v0.7.0)
La versión de resiliencia añadió la tercera capa: pools de credenciales del mismo proveedor. La idea aquí es que "mi proveedor principal" y "la clave API concreta que tengo con ese proveedor" son cosas distintas. Puedes tener tres claves de Anthropic — personal, de equipo y una de respaldo en una segunda cuenta — y querer que Hermes use la que esté menos ocupada.
Las configuras a través del asistente de configuración o un bloque credential_pool, y Hermes elige la clave least_used por defecto. Si una clave devuelve 401, el pool rota automáticamente a la siguiente y marca la caída para una ventana de reinicio. La implementación thread-safe permite ejecutar el CLI, un gateway de Telegram y un cron job contra el mismo pool sin que se pisen entre sí. La v0.7.0 también se aseguró de que el estado del pool sobreviva a los cambios por fallback de proveedor, así que un 429 en tu proveedor principal no borra lo que el pool sabe sobre qué claves están agotadas.
Por qué importa el sistema de capas
Cada una de estas funcionalidades resuelve un problema concreto, pero la razón por la que se sienten potentes es que se componen sin solaparse:
- •El router te permite cambiar qué proveedor en un solo sitio.
- •La cadena de fallback te permite gestionar fallos a nivel de proveedor sin reiniciar.
- •El pool de credenciales te permite gestionar fallos y carga a nivel de clave dentro de un proveedor.
Y desde el CLI, hermes model te permite reconfigurar cualquiera de estas capas sin editar archivos a mano. El resultado neto es que cuando aparece un modelo nuevo — da igual cuál sea, quién lo lance, cuánto cueste — el coste de migrar es "editar una línea de configuración". No "rediseñar mi asistente". Para un proyecto que va a vivir a través de muchas generaciones de modelos, probablemente sea la única decisión arquitectónica que realmente importa.