Ohne Kontingent dazustehen ist ärgerlich. Nicht zu wissen, wie viel übrig ist, ist schlimmer. Du bist mitten in einer Deadline, die letzte Antwort war in Ordnung, und die nächste wird abgelehnt: Limit erreicht. Welches Limit? Das von heute oder das vom Monat? Ist die Allowance für große Modelle ein eigener Topf? Wann kommt sie zurück? Diese Antworten lagen früher in einem Web-Dashboard. PR #142308, am 22. Oktober 2026 gemerged, holt sie ins Terminal.

Zwei verschiedene Arten zu zahlen

Hermes ist mit einem Credit-Guthaben groß geworden: aufladen, verbrauchen, bei null stoppen. Manche Abos laufen stattdessen über usage windows – ein Tag, eine Woche, ein Monat, plus eine separate Allowance für große Modelle. Das ist kein Guthaben, das man leert, sondern ein Kontingent, das sich wieder auffüllt.

Der Unterschied entscheidet die Oberfläche. Ein Guthaben ist eine Zahl, ein Kontingent ist ein Satz von Gauges. Deshalb modelliert diese Änderung Pläne in Hermes überhaupt nicht. Sie zeichnet, was der Server schickt.

So viele Balken, wie der Server schickt

Allowances kommen von zwei Stellen mit derselben Form:

• usage_window.gauges im Konto-Snapshot des Portals;
• der Response-Header x-nous-credits-window-gauges, der auch auf der 402-Ablehnung mitkommt.

Jeder gauge trägt ein scope, das sagt, was ein voller gauge blockiert:

• scope: all – blockiert jedes bezahlte Modell (Tag, Woche, Monat und jede später ergänzte Allowance kann diesen scope nutzen);
• scope: top_tier – blockiert nur die Modelle, die das Gateway als top tier markiert.

Ein kostenloses Modell wird nie blockiert; es zieht von nichts. Diese Regel steht ganz oben in agent/plan_limits.py, weil der „Aufgebraucht“-Hinweis im Picker, der Vorschlag auf der Limit-Karte und der Ein-Tipp-Wechselbutton alle übereinstimmen müssen – eine Regel, eine Quelle.

Ein Kommentar in agent/usage_gauges.py ist es wert, zitiert zu werden: Hermes behält eigene Worte nur für ids, die es kennt (sie werden übersetzt und an jede Oberfläche angepasst); jede andere id zeigt das label des Servers. Eine neue Allowance auf dem Server braucht kein Hermes-Release.

Wie /usage jetzt aussieht

/usage war schon der Befehl für „was hat diese session gekostet“ – tokens, geschätzte Kosten, Kontextfenster, Dauer und, wenn der provider es anbietet, einen Abschnitt zu Konto-Limits. Bei einem Window-Plan zeigt er jetzt einen Balken pro Allowance, mit genutztem Prozentwert und Zeit bis zum Reset.

In der Desktop-App erscheinen dieselben Daten unter Settings → Billing als gauges, neben einem Schalter Keep going on credits: Dürfen aufgeladene credits übernehmen, wenn eine Allowance aufgebraucht ist? Dieser Schalter ist dieselbe Konto-Einstellung wie der Toggle Billing → Topup im Portal – der Desktop ist nur ein weiterer Eingang dazu. Ihn zu ändern braucht Remote Spending (billing:manage) auf diesem terminal; ohne das startet der Klick die Freigabe selbst, der Schalter bleibt in der beantragten Position, und die Änderung greift, sobald sie genehmigt ist. Keine Schleife aus Ablehnen, Prüfen, nochmal Klicken.

Die Modell-Picker bekommen ihre Preisschilder zurück

Bei einem Window-Plan ist jedes gelistete Modell enthalten, ein Preis pro token wäre also Rauschen. Stattdessen trägt jede Zeile ein Wort: Free, Small, Medium, Large. Das Gateway schickt das Wort pro Aufrufer als usage_level auf /v1/models; Hermes übersetzt es nur.

Drumherum:

• Empfohlene Modelle kommen zuerst; der CLI-Picker teilt die Liste in „Recommended“ und „Other models“, während Picker in Messaging-Plattformen die empfohlenen nur nach vorne sortieren;
• Ist eine Allowance aufgebraucht, sagt der Picker es einmal und zeigt, wann sie zurückkommt; blockierte Modelle werden gedimmt, wo die Plattform Dimmen unterstützt;
• Wer ein Large-Modell wählt, bekommt einen einmaligen Hinweis, dass es mehr von der monatlichen Allowance für große Modelle verbraucht.

Jedes andere Konto – credit-grant, pay-as-you-go, free tier – bekommt von diesem Modul nichts. Seine Codepfade bleiben unverändert.

Am Limit: drei Antworten statt einer

Die Ablehnung war früher ein generisches „usage limit reached“. Jetzt sagt sie, welche Allowance aufgebraucht ist, wann sie zurückkommt und was noch funktioniert: bis zu zwei Modelle aus der Empfehlungsliste des Plans, die noch laufen können. Plattformen, die schon Buttons haben, rendern sie als Buttons; alles andere bekommt einen Satz.

Eine Designentscheidung ist es wert, in jedes Agent-Produkt übernommen zu werden: Hermes wechselt nie von selbst das Modell. Ein usage-window-Limit geht nicht die fallback-Kette entlang – die fallback-Kette gibt es für „dieser provider ist down“, nicht für „du hast deinen Plan überschritten“. Du wählst entweder ein verfügbares Modell oder wartest auf den Reset.

Zwei kanalspezifische Details: Messaging-Plattformen zeigen auf das Portal statt auf /topup (ein Button im Chat könnte das Geld des Raum-Besitzers ausgeben), und mit einem credential-Pool wird nur das abgelehnte Modell bis zum Reset gesperrt – nicht die ganze Credential. Die anderen Modelle auf diesem Key laufen weiter.

Kompatibilität und Grenzen

Aus dem PR:

• Ohne Window-Plan ist jeder Codepfad derselbe wie vorher;
• usage-window-Response-Header und Ablehnungscodes werden nur auf Nous-Routen beachtet, ein anderer Upstream kann diese UI also nicht auslösen;
• nur additiv: kein bestehendes Verhalten von config, API oder CLI wird entfernt.

Release-Status

PR #142308 wurde am 22. Oktober 2026 nach main gemerged – über 200 Dateien, über CLI, TUI, gateway und Desktop hinweg. Das letzte Release ist weiterhin v0.22.4 vom 21. Oktober, das hier ist also nur auf main, bis das nächste Release den stabilen Kanal erreicht.

Damit die Nachbarn klar bleiben: /usage reset löst gebankte Codex-Resets ein (siehe diesen Beitrag), Resetwatch ist ein Desktop-Plugin von Drittanbietern, das das Restkontingent von 14 Plattformen auf einen Bildschirm bringt (siehe diesen Beitrag), und diese Änderung ist die offizielle Unterstützung für allowance-basierte Pläne selbst. Für den Rest des Verhaltens der Modell-Picker deckt die hermes model-Referenz die Flags ab.