Économies

PRECC suit les économies de tokens estimées à chaque interception. Utilisez precc savings pour voir combien de gaspillage PRECC a évité.

Résumé rapide

$ 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)

Ventilation détaillée (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>%

Comment les économies sont estimées

Chaque type de correction a un coût estimé en tokens basé sur ce qui se serait passé sans PRECC :

Ce sont des estimations conservatrices. Les économies réelles sont souvent plus élevées car le raisonnement de Claude sur les erreurs peut être verbose.

Économies cumulées

Les économies persistent entre les sessions dans la base de données PRECC. Au fil du temps, vous pouvez suivre l’impact total :

$ 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

Barre d’état

Après l’installation, PRECC ajoute une entrée statusLine dans ~/.claude/settings.json afin que la barre d’état de Claude Code affiche les métriques de session en direct :

$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)

Définissez PRECC_LANG pour afficher les étiquettes dans votre langue — voir le chapitre Localisation.

Chaque segment :

Le segment lifetime: est placé en dernier afin qu’il soit le premier tronqué si l’interface de Claude Code coupe la barre au bord droit.

Pourquoi le coût et le nombre de tokens ne se divisent pas

Le 1.2M in/out affiché n’est pas le dénominateur qui a produit $0.42 spent. Le cost.total_cost_usd de Claude Code est calculé à partir de la ventilation complète des tokens de l’API — entrée de base, sortie, plus les lectures de cache et les créations de cache. Les comptes cumulés de tokens de cache pour toute la session ne sont pas exposés dans le schéma de statusline, donc PRECC ne peut afficher que la partie visible (non-cache).

Lors de sessions longues avec de fréquentes relectures de fichiers, les lectures de cache peuvent atteindre 10× le nombre de tokens visibles. C’est pourquoi les associer en ratio induirait en erreur — PRECC les affiche plutôt comme des segments indépendants.

Pourquoi PRECC ne calcule pas le coût

Le nombre de coût fait autorité. PRECC lit cost.total_cost_usd mot pour mot depuis le JSON que Claude Code envoie à la commande de statut via stdin. C’est le même nombre que Claude Code facture sur votre budget d’abonnement/d’utilisation. Vous pouvez le vérifier à tout moment avec la commande slash intégrée /cost — les deux devraient correspondre.

Ce qui détermine le coût

Pour Claude Opus 4.6 :

Les principaux moteurs lors de longues sessions sont généralement les tokens de sortie (le type le plus cher par token, surtout au niveau de contexte 1M), les lectures de cache répétées (bon marché individuellement mais s’accumulant rapidement sur de nombreux tours), et les créations de cache (écrites une fois par lecture de fichier à ~1.25× le tarif d’entrée de base). PRECC réduit le coût des tokens visibles en compressant la sortie Bash (le segment 📊 last cmd: affiche l’économie par commande), mais il ne peut pas réduire les lectures de cache des fichiers que Claude a déjà chargés.

Comptages de session stables

Le segment « PRECC: N fixes » compte les événements depuis le début persisté de la session, écrit dans ~/.local/share/precc/sessions/<session_id>.start lors du premier rafraîchissement de la statusline de chaque session. Cela rend le compte monotone — il ne peut pas diminuer en cours de session même si cost.total_duration_ms est absent lors d’un rafraîchissement particulier.

Instantané à vie auto-rafraîchi

Le segment lifetime: lit ~/.local/share/precc/.lifetime_summary.json, qui est réécrit à chaque mesure PostToolUse et à chaque invocation de precc savings. Le segment this session: lit le même fichier lifetime mais soustrait une ligne de base par session persistée lors du premier rafraîchissement de chaque session. Aucun rafraîchissement manuel nécessaire — les fichiers se mettent à jour eux-mêmes.

Supprimer la barre d’état

Si vous préférez conserver votre barre d’état existante, définissez votre propre commande statusLine dans ~/.claude/settings.json. L’installateur de PRECC détectera la valeur personnalisée et la laissera intacte lors des mises à jour ultérieures.

Pour supprimer uniquement la ligne 📊 PRECC par interaction (dans additionalContext), définissez PRECC_QUIET=1 dans votre environnement shell.

Related research

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.