Du starrst auf die Status-Bar am unteren Rand deines Terminals: Modellname, Kontext-Prozentsatz, ein Komprimierungs-Icon. Jede Menge Information — aber was du eigentlich wissen willst, ist: „Ist das Modell gerade schnell? Trifft der Cache? Wie viele Tokens pro Sekunde erzeugt es?“ — denn die Cache-Hit-Rate entscheidet darüber, ob deine API-Rechnung nur ein Zehntel kostet oder den vollen Preis. Ein am 30. August gemergtes Update (PR #98250) packt alle drei Antworten direkt in die Status-Bar: Cache-Hit-Rate (◎), gleitende Durchschnittslatenz (◷) und Ausgabe-Tokens pro Sekunde (↑) — und jedes Feld lässt sich per Konfiguration ein- und ausschalten.

Was es Neues in der Bar gibt

Auf einem breiten Terminal sieht die aktualisierte Bar so aus:

⚕ model │ 3% │ ◎ 87.4% │ ◷ 3.2s │ ↑ 50 t/s │ 2m

Von links nach rechts: Modellname, Kontext bei 3%, Cache-Hit-Rate 87.4%, durchschnittliche Latenz 3.2s, 50 Ausgabe-Tokens pro Sekunde, Session-Dauer 2 Minuten. Die drei neuen Metriken sind gleitende Statistiken — Latenz und Durchsatz bilden den gleitenden Mittelwert der letzten ~10 API-Calls statt eines Durchschnitts seit dem Start, sodass sie den aktuellen Zustand des Modells widerspiegeln.

Ein paar durchdachte Details:

• Die Cache-Hit-Rate setzt ihre Baseline bei Modellwechseln und Kontext-Komprimierung zurück — sie spiegelt das aktuelle Cache-Regime wider, keine durch die Vergangenheit verwässerte Zahl;
• Wenn es überhaupt keine Cache-Reads gibt, versteckt sich das Feld, statt ein alarmierendes 0% zu zeigen — keine irreführenden Signale;
• Negative oder NaN-Latenz wird abgefangen — ein einziger zittriger Call kann die Statistiken nicht verunreinigen.

Feld-Toggles: display.status_bar.fields

Die neuen Metriken werden dir nicht aufgezwungen — jedes Feld lässt sich unabhängig aktivieren oder deaktivieren. Der Konfigurationsschlüssel ist display.status_bar.fields; eine leere Liste bedeutet „alle Standardfelder“:

display:
  status_bar:
    fields: []   # leer = eingebaute Standardwerte (alle Felder)

Sagen wir, du interessierst dich nur für Cache und Geschwindigkeit — behalte einfach diese:

display:
  status_bar:
    fields: [model, ctx, cache_hit, latency, tps]

Deine Bar wird zu ⚕ model │ 3% │ ◎ 87.4% │ ◷ 3.2s │ ↑ 50 t/s. Laut Quellcode (hermes_cli/config_defaults.py) lautet die vollständige Feldliste: cache_hit, latency, tps, compressions, bg_tasks, bg_processes, bg_subagents, goal, duration, prompt_elapsed, idle_since, focus, yolo, stash, battery, title, total_tokens. Zwei Einschränkungen:

• total_tokens (Session-Summen-Tokens) ist nur opt-in — es erscheint nie, außer du nimmst es ausdrücklich in die Liste auf;
• Schmale Terminals lassen Nur-Breitbild-Felder weg (context_detail, prompt_elapsed, idle_since) — unabhängig von der Konfiguration.

Warum die Cache-Hit-Rate einen Blick wert ist

Das ist die „wertvollste“ der drei neuen Metriken. Große API-Anbieter (Anthropic, OpenAI, DeepSeek und andere) berechnen Prompt-Cache-Reads typischerweise mit 1/10 des normalen Eingabepreises oder weniger. Die Hit-Rate in der Status-Bar ist ein Live-Dashboard für deine Kostenstrategie: Bleibt sie lange niedrig, zerkaut deine Session-Struktur ständig (sich oft ändernder System-Prompt, instabile Tool-Beschreibungen), sodass der Cache immer daneben liegt; liegt sie konstant über 80%, wird dein Geld dort ausgegeben, wo es zählt.

So bekommst du es

PR #98250 wurde am 30. August 2026 gemerged und ist nur auf main — v0.20.6 hat es nicht. Aktualisiere auf das aktuelle main, und die neuen Felder erscheinen im ganz normalen hermes; zum Feinjustieren editierst du display.status_bar.fields über hermes config edit.

Die Status-Bar ist das Dashboard der CLI, und diese neuen Metriken machen aus Deko echte Betriebsdaten. Für das komplette Token- und Cache-Spar-Playbook kombinierst du das mit dem Guide zu 5 kostenlosen Suchkanälen und dem Kontext-Token-Optimierungs-Guide; weitere versteckte CLI-Effizienzgewinne findest du im Command-Palette-Guide.