Einsparungen

PRECC verfolgt die geschätzten Token-Einsparungen bei jeder Interception. Verwenden Sie precc savings, um zu sehen, wie viel Verschwendung PRECC verhindert hat.

Kurzübersicht

$ precc savings
Session Token Savings
=====================
Total estimated savings: <span data-stat="session_tokens_saved">8,741</span> tokens

Breakdown:
  Pillar 1 (cd prepends):         <span data-stat="session_p1_tokens">3,204</span> tokens  (<span data-stat="session_p1_count">6</span> corrections)
  Pillar 4 (skill activations):   <span data-stat="session_p4_tokens">1,560</span> tokens  (<span data-stat="session_p4_count">4</span> activations)
  RTK rewrites:                   <span data-stat="session_rtk_tokens">2,749</span> tokens  (<span data-stat="session_rtk_count">11</span> rewrites)
  Lean-ctx wraps:                 <span data-stat="session_lean_tokens">1,228</span> tokens  (<span data-stat="session_lean_count">2</span> wraps)

Detaillierte Aufschlüsselung (Pro)

$ precc savings --all
Session Token Savings (Detailed)
================================
Total estimated savings: <span data-stat="session_tokens_saved">8,741</span> tokens

Command-by-command:
  #  Time   Command                          Saving   Source
  1  09:12  cargo build                      534 tk   cd prepend (cargo-wrong-dir)
  2  09:14  cargo test                       534 tk   cd prepend (cargo-wrong-dir)
  3  09:15  git status                       412 tk   cd prepend (git-wrong-dir)
  4  09:18  npm install                      824 tk   cd prepend (npm-wrong-dir)
  5  09:22  find . -name "*.rs"              387 tk   RTK rewrite (output truncation)
  6  09:25  cat src/main.rs                  249 tk   RTK rewrite (lean-ctx wrap)
  7  09:31  cargo clippy                     534 tk   cd prepend (cargo-wrong-dir)
  ...

Pillar Breakdown:
  Pillar 1 (context resolution):   <span data-stat="session_p1_tokens">3,204</span> tokens  <span data-stat="session_p1_pct">36.6</span>%
  Pillar 2 (GDB debugging):            0 tokens   0.0%
  Pillar 3 (mined preventions):        0 tokens   0.0%
  Pillar 4 (automation skills):    <span data-stat="session_p4_tokens">1,560</span> tokens  <span data-stat="session_p4_pct">17.8</span>%
  RTK rewrites:                    <span data-stat="session_rtk_tokens">2,749</span> tokens  <span data-stat="session_rtk_pct">31.5</span>%
  Lean-ctx wraps:                  <span data-stat="session_lean_tokens">1,228</span> tokens  <span data-stat="session_lean_pct">14.1</span>%

Wie Einsparungen geschätzt werden

Jeder Korrekturtyp hat geschätzte Token-Kosten basierend darauf, was ohne PRECC passiert wäre:

Korrekturtyp	Geschätzte Einsparung	Begründung
cd prepend	~500 tokens	Fehlerausgabe + Claude-Reasoning + Wiederholung
Skill-Aktivierung	~400 tokens	Fehlerausgabe + Claude-Reasoning + Wiederholung
RTK rewrite	~250 tokens	Ausführliche Ausgabe, die Claude lesen müsste
Lean-ctx wrap	~600 tokens	Große Dateiinhalte komprimiert
Gelernte Prävention	~500 tokens	Bekanntes Fehlermuster vermieden

Dies sind konservative Schätzungen. Die tatsächlichen Einsparungen sind oft höher, da Claudes Reasoning über Fehler ausführlich sein kann.

Kumulative Einsparungen

Einsparungen bleiben sitzungsübergreifend in der PRECC-Datenbank erhalten. Im Laufe der Zeit können Sie die Gesamtwirkung verfolgen:

$ precc savings
Session Token Savings
=====================
Total estimated savings: <span data-stat="session_tokens_saved">8,741</span> tokens

Lifetime savings: <span data-stat="total_tokens_saved">142,389</span> tokens across <span data-stat="total_sessions">47</span> sessions

Statusleiste

Nach der Installation trägt PRECC einen statusLine-Eintrag in ~/.claude/settings.json ein, damit die Statusleiste von Claude Code Live-Sitzungsmetriken anzeigt:

$0.42 spent | 1.2M in/out | 📊 last cmd: −1.2K | PRECC: 7 fixes | 5.8ms avg | this session: 320 saved over 7 cmds (~$0.05) | lifetime: 8.9K saved over 217 cmds (~$2.85)

Setze PRECC_LANG, um die Beschriftungen in deiner Sprache anzuzeigen — siehe Kapitel Lokalisierung.

Jedes Segment:

Segment	Quelle	Bedeutung	Wird beim Sitzungs-Neustart zurückgesetzt?
`$0.42 spent`	`cost.total_cost_usd`	Von Claude Code gemeldete kumulierte Sitzungskosten	Ja
`1.2M in/out`	`total_input_tokens + total_output_tokens`	Nicht gecachte Eingabe- + Ausgabetokens über die Sitzung	Ja
`📊 last cmd: −1.2K`	PRECC-Messung des letzten Bash-Befehls	Reale, gemessene Einsparung durch erneutes Ausführen des Originals	Nein (bleibt über Sitzungen hinweg erhalten)
`PRECC: 7 fixes`	`metrics.log`	Anzahl der Korrekturen in dieser Sitzung — nur Korrekturzahl, keine Fake-Token-Schätzung	Ja
`5.8ms avg`	PRECC-Hook-Latenz p50	Zeit, die PRECC mit der Verarbeitung jedes Tool-Aufrufs verbracht hat	Ja
`bash 18% of total`	`post_observations.log`	Anteil der Sitzungstokens, die aus Bash-Ausgaben stammen — erklärt, warum die Einsparungen von PRECC naturgemäß nur einen Bruchteil der Gesamtkosten ausmachen (PRECC optimiert nur Bash-Ausgaben)	Ja
`this session: 320 saved over 7 cmds (~$0.05)`	`.lifetime_summary.json` − baseline	Tatsächliche Sitzungs-Delta. Ausgeblendet, wenn das Delta null ist (Sitzungsbeginn)	Ja (Baseline wird neu erfasst)
`lifetime: 8.9K saved over 217 cmds (~$2.85)`	`.lifetime_summary.json`	Kumulativ gesparte Tokens und neu gemessene Befehle seit der ersten PRECC-Installation, zuzüglich eines geschätzten USD-Werts zum aktuellen Token-Preis	Nein

Das lifetime:-Segment steht am Ende, damit es als erstes abgeschnitten wird, falls die Claude-Code-Benutzeroberfläche die Leiste am rechten Rand abschneidet.

Warum sich Kosten und Token-Anzahl nicht teilen lassen

Das angezeigte 1.2M in/out ist nicht der Nenner, der $0.42 spent ergeben hat. Der cost.total_cost_usd von Claude Code wird aus der vollständigen Token-Aufschlüsselung der API berechnet — Basis-Eingabe, Ausgabe, plus Cache-Lesevorgänge und Cache-Erstellungen. Die sitzungsweiten kumulativen Cache-Token-Zahlen werden im Statusline-Schema nicht offengelegt, daher kann PRECC nur den sichtbaren (Nicht-Cache-)Anteil anzeigen.

Bei langen Sitzungen mit häufigen Datei-Erneut-Lesungen können Cache-Lesevorgänge das 10-fache der sichtbaren Token-Zahl betragen. Deshalb wäre eine Paarung als Verhältnis irreführend — PRECC zeigt sie stattdessen als unabhängige Segmente.

Warum PRECC die Kosten nicht berechnet

Die Kostenzahl ist maßgeblich. PRECC liest cost.total_cost_usd wörtlich aus dem JSON, das Claude Code über stdin an den Statusbefehl pipet. Das ist dieselbe Zahl, die Claude Code gegen dein Abonnement-/Nutzungsbudget abrechnet. Du kannst sie jederzeit mit dem eingebauten /cost-Slash-Befehl überprüfen — beide sollten übereinstimmen.

Was die Kosten antreibt

Für Claude Opus 4.6:

Token type	Standard (≤200k context)	1M context tier
Input	$15 / MTok	$30 / MTok
Output	$75 / MTok	$150 / MTok
Cache write	$18.75 / MTok	$37.50 / MTok
Cache read	$1.50 / MTok	$3 / MTok

Die größten Treiber bei langen Sitzungen sind in der Regel Ausgabetokens (der teuerste Pro-Token-Typ, besonders auf der 1M-Kontextstufe), wiederholte Cache-Lesevorgänge (einzeln günstig, aber über viele Runden schnell akkumulierend) und Cache-Erstellungen (einmal pro Datei-Lesevorgang zum ~1,25-fachen der Basis-Eingaberate). PRECC reduziert die Kosten der sichtbaren Tokens durch Komprimierung der Bash-Ausgabe (das Segment 📊 last cmd: zeigt die Pro-Befehl-Einsparung), kann aber Cache-Lesevorgänge von Dateien, die Claude bereits geladen hat, nicht reduzieren.

Stabile Sitzungszählungen

Das Segment “PRECC: N fixes” zählt Ereignisse seit dem persistierten Sitzungsbeginn, geschrieben in ~/.local/share/precc/sessions/<session_id>.start bei der ersten Statusline-Aktualisierung jeder Sitzung. Das macht die Zählung monoton — sie kann mitten in der Sitzung nicht sinken, selbst wenn cost.total_duration_ms bei einer bestimmten Aktualisierung fehlt.

Automatisch aktualisierter Lifetime-Snapshot

Das lifetime:-Segment liest ~/.local/share/precc/.lifetime_summary.json, das bei jeder PostToolUse-Messung und bei jedem precc savings-Aufruf neu geschrieben wird. Das this session:-Segment liest dieselbe Lifetime-Datei, subtrahiert aber eine pro Sitzung persistierte Baseline, die bei der ersten Aktualisierung jeder Sitzung gespeichert wird. Keine manuelle Aktualisierung erforderlich — die Dateien aktualisieren sich selbst.

Statusleiste unterdrücken

Wenn du deine bestehende Statusleiste behalten möchtest, setze deinen eigenen statusLine-Befehl in ~/.claude/settings.json. Der Installer von PRECC erkennt den benutzerdefinierten Wert und lässt ihn bei nachfolgenden Updates unangetastet.

Um nur die Pro-Interaktion-📊 PRECC-Zeile (im additionalContext) zu unterdrücken, setze PRECC_QUIET=1 in deiner Shell-Umgebung.

PRECC’s three savings mechanisms each have a counterpart in the recent literature. These are related work — the ideas PRECC’s design draws on. Their reported figures are their measurements, not PRECC’s: PRECC only ever quotes numbers measured on your own machine (see “measured, not estimated”, above).

Output/trajectory trimming (PRECC’s diet + bash-output compression) — Reducing Cost of LLM Agents with Trajectory Reduction (AgentDiet), FSE 2026, arXiv:2509.23586. Removes redundant/expired trajectory content post-hoc; reports −39.9–59.7% input tokens. PRECC applies the same idea pre-execution and deterministically (no extra LLM call).
Skills as programs (PRECC’s mined + builtin rewrite skills) — Harnessing LLM Agents with Skill Programs, arXiv:2605.17734. Frames reusable agent skills as executable program functions — the same analogy behind PRECC’s command-rewrite skills (a pattern → a deterministic rewrite).
Context compression (PRECC’s compress + lean-ctx wrapping) — Compress the Context, Keep the Commitments: A Formal Framework for Verifiable LLM Context Compression, arXiv:2605.17304. Recent work on compressing context without losing required information — the property PRECC’s deterministic, cache-stable rewrites aim to preserve.

Keyboard shortcuts

PRECC User Guide