Quedarse sin cuota es molesto. No saber cuánto queda es peor. Estás en plena fecha de entrega, la última respuesta salió bien y la siguiente te la rechazan: límite alcanzado. ¿Qué límite? ¿El de hoy o el del mes? ¿La allowance de los modelos grandes es un depósito aparte? ¿Cuándo vuelve? Esas respuestas antes vivían en un panel web. El PR #142308, fusionado el 22 de octubre de 2026, las traslada al terminal.

Dos formas distintas de pagar

Hermes se crió con un saldo de credit: recargas, vas gastando y te detienes en cero. Algunas suscripciones, en cambio, funcionan con usage windows: un día, una semana, un mes, más una allowance aparte para los modelos grandes. Eso no es un saldo que se vacía, es una cuota que se rellena.

La diferencia decide la interfaz. Un saldo es un número; una cuota es un conjunto de gauges. Por eso este cambio no modela los planes dentro de Hermes en absoluto: dibuja lo que envía el servidor.

Tantas barras como envíe el servidor

Las allowances llegan desde dos sitios con la misma forma:

• usage_window.gauges en la instantánea de la cuenta del Portal;
• la cabecera de respuesta x-nous-credits-window-gauges, que también viaja en el rechazo 402.

Cada gauge lleva un scope que indica qué bloquea cuando está lleno:

• scope: all: bloquea todos los modelos de pago (día, semana, mes, y cualquier allowance añadida más adelante puede usar este scope);
• scope: top_tier: bloquea solo los modelos que el gateway marca como top tier.

Un modelo gratuito nunca se bloquea: no consume nada de nada. Esa regla está en la cabecera de agent/plan_limits.py, porque la nota de “agotado” del selector, la sugerencia de la tarjeta de límite y el botón de cambio en un solo toque tienen que coincidir: una regla, una fuente.

Un comentario en agent/usage_gauges.py merece citarse tal cual: Hermes solo mantiene sus propias palabras para los ids que conoce (se traducen y se ajustan a cada superficie); cualquier otro id muestra la label del servidor. Una allowance nueva en el servidor no necesita un release de Hermes.

Cómo se ve /usage ahora

/usage ya era el comando de “cuánto me ha costado esta session”: tokens, coste estimado, ventana de contexto, duración y una sección de límites de cuenta cuando el provider la expone. En un plan de ventanas ahora muestra una barra por allowance, con el porcentaje usado y el tiempo hasta el reinicio.

En la app de Desktop los mismos datos aparecen en Settings → Billing como gauges, junto a un interruptor Keep going on credits: cuando una allowance se agota, ¿pueden entrar los credits de recarga? Ese interruptor es el mismo ajuste de cuenta que el toggle Billing → Topup del Portal: el Desktop es solo otra entrada al mismo sitio. Cambiarlo requiere Remote Spending (billing:manage) en ese terminal; sin ese permiso, el clic arranca la propia aprobación, el interruptor se queda en la posición solicitada y el cambio se aplica cuando se aprueba. Sin bucle de rechazar, verificar y volver a hacer clic.

Los selectores de modelo recuperan las etiquetas de precio

En un plan de ventanas todos los modelos listados están incluidos, así que un precio por token sería ruido. En su lugar, cada fila lleva una palabra: Free, Small, Medium, Large. El gateway envía esa palabra por llamador como usage_level en /v1/models; Hermes solo la traduce.

Alrededor de eso:

• Los modelos recomendados van primero; el selector de la CLI divide la lista en “Recommended” y “Other models”, mientras que los selectores de las plataformas de mensajería solo ponen los recomendados por delante;
• Cuando una allowance se agota, el selector lo dice una vez y muestra cuándo se reinicia; los modelos bloqueados se atenúan donde la plataforma permite atenuar;
• Elegir un modelo Large muestra un aviso de una sola vez: consume más de la allowance mensual para modelos grandes.

Cualquier otra cuenta —credit-grant, pago por uso, plan gratuito— no obtiene nada de este módulo. Sus rutas de código no cambian.

Al límite, tres respuestas en vez de una

El rechazo solía ser un genérico “límite de uso alcanzado”. Ahora dice qué allowance se agotó, cuándo se reinicia y qué sigue funcionando: hasta dos modelos de la lista de recomendados del plan que todavía pueden ejecutarse. Las plataformas que ya tienen botones los renderizan como botones; el resto recibe una frase.

Hay una decisión de diseño que merece copiarse en cualquier producto de agentes: Hermes nunca cambia de modelo por su cuenta. Un límite de usage window no recorre la cadena de fallback: la cadena de fallback existe para “este provider está caído”, no para “te pasaste de tu plan”. O eliges un modelo disponible o esperas al reinicio.

Dos detalles específicos por canal: las plataformas de mensajería apuntan al Portal en lugar de a /topup (un botón en un chat podría gastar el dinero del dueño de la sala), y con un pool de credenciales solo se aparta el modelo rechazado hasta el reinicio, no toda la credencial. Los demás modelos de esa key siguen funcionando.

Compatibilidad y límites

Del PR:

• Sin un plan de ventanas, cada ruta de código es igual que antes;
• las cabeceras de respuesta de usage window y los códigos de rechazo solo se respetan en rutas de Nous, así que otro upstream no puede disparar esta UI;
• solo aditivo: no se elimina ningún comportamiento existente de config, API o CLI.

Estado de la versión

El PR #142308 se fusionó en main el 22 de octubre de 2026: más de 200 archivos, entre CLI, TUI, gateway y Desktop. El último release sigue siendo v0.22.4 del 21 de octubre, así que esto solo está en main hasta que el próximo release llegue al canal estable.

Para no confundir vecinos: /usage reset canjea resets de Codex acumulados (ver esa entrada), Resetwatch es un plugin de Desktop de terceros que pone la cuota restante de 14 plataformas en una sola pantalla (ver esa entrada), y este cambio es el soporte oficial para los planes basados en allowance en sí. Para el resto del comportamiento del selector de modelos, la referencia de hermes model cubre los flags.