Hermes mit PayPerQ (ppq.ai) einrichten

Lange Sessions kosten mehr, als der Listenpreis des Modells vermuten lässt: jeder Turn rechnet den gesamten aufgelaufenen Kontext neu ab — die Kosten wachsen also mit Kadenz und mitgeschlepptem Kontext, nicht damit, wie viel du „erledigt“ hast. Dieses Blatt liefert das mentale Modell, die Kernzahlen und eine Handvoll Hebel — Kadenz, Delegation und Forking —, die die Rechnung planbar halten. Wer nur eine Minute hat, liest die Abschnitte 1–3; der Rest ist Nachschlagewerk.

Zum manuellen Nutzen oder um es jemandem zu erklären. Vor großen Entscheidungen den Preisanker neu verifizieren. Geschrieben aus dem eigenen Hermes-Workflow des Autors — Hebel, Schwellwerte und Zahlen sind vom Autor gemessen, nicht aus der Vendor-Doku.

1 · Das mentale Modell (3 Sätze)

1. Jeder Turn schickt die gesamte Konversation erneut ans Modell — aufgelaufener Kontext ist eine wiederkehrende Kostenposition, keine einmalige.
2. Die erneute Übertragung wird nur zum Cache-Preis (1/5 von fresh) abgerechnet, wenn der vorherige Turn aktuell ist; nach einer Minutenlücke stirbt der Cache und alles rechnet zum vollen fresh-Preis neu.
3. Output ist die Premium-Dimension: ~3,3× der fresh-Input-Preis; Output+Reasoning dominieren typischerweise die reale Rechnung.

2 · Erklärversion (ein Absatz)

„Jeder Konversation-Turn rechnet den gesamten aufgelaufenen Kontext neu ab. Cache macht das 5× günstiger, aber nur, wenn du nicht für Minuten pausierst. Also: halte die Haupt-Session schlank (knappe Turns, gebündelte Calls, kurze Outputs), schiebe jeden großen Lesevorgang in einen Wegwerf-Subagenten, der eine Zusammenfassung zurückgibt, und wenn die Session über ihren Brief hinaus ~10–15k Tokens gewachsen ist, teile sie an einer natürlichen Bruchstelle mit einem schriftlichen Handover-Brief — der Split kostet Cents, der mitgeschleppte Kontext kostet Dollars. Miss echte Sessions in der state.db statt zu raten, und verifiziere Preise neu, bevor du den Schwellwerten vertraust.“

3 · Die drei Entscheidungen

(a) Inline — jetzt in der Haupt-Session erledigen: ≤ ~10 Tool-Calls, kein einzelner Lesevorgang > ~35k Zeichen (~8k Tokens; ~44k Zeichen, wenn die Child-Baseload ~20k ist), geringes Risiko, keine Nutzer-Eingabe mitten im Lauf nötig.

(b) Delegieren — an einen Subagenten schieben: jeder Bulk-Lesevorgang > ~8k Tokens (~35k Zeichen), wenn ≥10 Turns übrig sind.

• Inline zahlt R fresh einmal + R × T × Trage-Rate wiederkehrend.
• Das Child zahlt R fresh einmal in seinem eigenen kurzlebigen Kontext; das Parent trägt nur die ~2–3k-Token-Zusammenfassung.
• Rechenbeispiel: 50k-Zeichen-Lesevorgang über 20 Turns → inline $0.0396 vs. delegiert $0.0109 — 3,6× günstiger.
• Delegier-Regeln: in sich geschlossenes Ziel+Kontext (Children sehen nichts von deiner Konversation), überprüfbarer Anker für jeden externen Effekt, EIN Call mit Tasks-Array für parallele Posten, Children liefern KURZE Ergebnisse zurück (≤ ~2k Tokens).

(c) Fork — /new mit einem Handover-Brief: wenn der Kontext jenseits des Briefs ~10–15k Tokens übersteigt und noch mehrere Turns übrig sind. Der Fork selbst ist fast gratis; die echten Kosten sind der menschliche /new-Aufwand und der Verlust von Arbeitszustand — beide durch die Brief-Konvention minimiert.

• Nur an natürlichen Bruchstellen forken: fertiges Deliverable, Themenwechsel, oder alle restlichen Posten nutzer-gated.
• Fork-Prozedur: YYYY-MM-DD-handover-<slug>.md schreiben mit Status+Grund, fetter Kickoff-Formel („lies <Datei> und führe aus"), nummerierten offenen Posten mit exakten Befehlen/Pfaden, Beleg-Pfaden. Dann den Nutzer um /new bitten und den Kickoff machen.
• Ausnahme: fork KEINEN absichtlich großen, read-only-Referenzkontext, der in enger Schleife abgefragt wird — warme Großkontext-Schleifen sind günstig.

Risiko schlägt Größe: ein winziger Posten, der Geheimnisse, destruktive Ops oder nach außen gerichtete Sends berührt, ist Nutzer-GO-Territorium — niemals ein günstiger Inline-Posten.

4 · Die Zahlen (ppq-Listenpreise)

f = cache_read / (fresh + cache_read) pro Session — berechenbar aus ~/.hermes/state.db, Tabelle session_model_usage.

5 · Cache-TTL-Regel

• Keine publizierte TTL (Z.ai: nur „reasonable time limits, will recalculate after expiration“). Empirisch im Minutenbereich.
• Jede Nutzerlücke > ein paar Minuten als vollen Cache-Miss behandeln: der gesamte aufgelaufene Kontext rechnet im nächsten Turn fresh neu ab.
• Folge: dichte Bursts schlagen verteiltes Tempo — antworte hintereinander weg und forke dann an der Pause, statt in einer schweren Session zu idlen.
• Willst du eine gemessene Grenze für dein Konto? Das braucht pro-Call-Timestamps aus der ppq-Usage-CSV (die Hermes-DB zeichnet keine auf).

6 · Output-Disziplin

• Knappe Haupt-Session-Turns; von Children kurze Ergebnisse verlangen.
• Tool-Calls zu einzelnen Turns bündeln — hält den Cache warm UND umgeht den Min-Abrechnungs-Floor, der Mini-Calls ~1,8× Input-Satz zahlen lässt.
• Output+Reasoning ist typischerweise der größte Anteil der realen Rechnung → der Hebel Nr. 1 nach der Kadenz.

7 · Anti-Patterns

• Eine große Datei inline vorzusammenfassen, „um Tokens zu sparen“ — verbrennt genau den Kontext, den du schützen willst. Den Lesevorgang delegieren.
• Manuelles /new zwischen jeder Runde — Forks sind günstig, aber jeder braucht einen Brief; Arbeit stattdessen routen, nur an natürlichen Bruchstellen forken.
• Idlen/Polling in einer schweren Session, während man auf einen Timer oder einen Nutzer-Test wartet — zeitgesteuerte Arbeit gehört in den Kickoff der NÄCHSTEN Session.
• Der DB-Kostenschätzung für die Abrechnung vertrauen — bei reasoning-lastigen Sessions ~10–15% dazurechnen; für €-Beträge die CSV verwenden.
• Eine warme Großkontext-Read-only-Schleife forken.
• Einem Child einen riesigen context-Block schicken, der die gesamte Session dupliziert — in sich geschlossen ≠ alles; gib das Ziel, die exakten Pfade und die Abnahmekriterien.

8 · Messen statt vorhersagen

sqlite3 ~/.hermes/state.db \
  "SELECT session_id, input_tokens, cache_read_tokens, output_tokens,
          reasoning_tokens, api_call_count
   FROM session_model_usage ORDER BY rowid DESC LIMIT 10;"
# f = cache_read / (input + cache_read)

Die Kontextgröße einer Aufgabe lässt sich nicht vorab annehmen — frag ab, was IST, bevor du Schwellwerte justierst. Prüfe auch sessions.parent_session_id für echte Child-Baseloads.

9 · Offene Caveats (ehrliche Unbekannte)

• Die Schwellwerte sind ein Schnappschuss — Preise neu verifizieren; es gibt keinen Repricing-Alarm.
• Child-Baseload ~15k ist unverifiziert — nachmessen.
• Cache-TTL ist nicht publiziert; Minutenbereich aus gemessenem f abgeleitet, nicht aus einer Vendor-Angabe.
• Dieses Blatt deckt nur Größe/Kosten/Risiko-Routing ab — privacy-sensible Arbeit braucht eine zusätzliche Schicht obendrauf.