節省

PRECC追蹤每次攔截的估計token節省。使用 precc savings 查看PRECC阻止了多少浪費。

快速摘要

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

詳細分類（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>%

如何估算節省

每種修正類型都有基於沒有PRECC時會發生什麼的估計token成本：

這些是保守估計。實際節省通常更高，因爲Claude對錯誤的推理可能很冗長。

累計節省

節省數據在PRECC數據庫中跨會話持久化。隨着時間推移，您可以跟蹤總體影響：

$ 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

狀態列

安裝後，PRECC 會在 ~/.claude/settings.json 中寫入一個 statusLine 條目，使 Claude Code 狀態列顯示即時工作階段指標：

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

設定 PRECC_LANG 以你的語言顯示標籤 — 請參閱本地化章節。

每個分段：

lifetime: 分段放在最後，這樣如果 Claude Code 的介面在右側裁剪狀態列，它會最先被截斷。

為何費用和 token 數不能相除

顯示的 1.2M in/out 不是產生 $0.42 spent 的分母。Claude Code 的 cost.total_cost_usd 是根據 API 的完整 token 分項計算的——基礎輸入、輸出，外加快取讀取和快取建立。整個工作階段累計的快取 token 數未在 statusline 架構中暴露，因此 PRECC 只能顯示可見的（非快取）部分。

在頻繁重讀檔案的長工作階段中，快取讀取可能是可見 token 數的 10 倍。這就是為何將兩者作為比率配對會產生誤導——PRECC 改為將其顯示為獨立分段。

為何 PRECC 不計算費用

費用數字是權威的。PRECC 從 Claude Code 透過 stdin 傳給狀態命令的 JSON 中逐字讀取 cost.total_cost_usd。這就是 Claude Code 對你訂閱/用量預算扣費的同一個數字。你可以隨時使用內建的 /cost 斜線命令驗證 — 兩者應一致。

什麼驅動費用

對於 Claude Opus 4.6：

長工作階段中最大的驅動通常是輸出 tokens（每 token 最貴的類型，尤其在 1M 上下文層級）、重複的快取讀取（單次便宜但跨多輪快速累積），以及快取建立（每次檔案讀取寫入一次，約為基礎輸入費率的 1.25 倍）。PRECC 透過壓縮 Bash 輸出來降低可見 token 成本（📊 last cmd: 分段顯示每條命令的節省），但無法減少 Claude 已載入檔案的快取讀取。

穩定的工作階段計數

“PRECC: N fixes” 分段統計自持久化的工作階段開始以來的事件，工作階段開始在每個工作階段首次 statusline 重新整理時寫入 ~/.local/share/precc/sessions/<session_id>.start。這使計數單調 — 即使某次重新整理中缺少 cost.total_duration_ms，工作階段中途也不會減少。

自動重新整理的累計快照

lifetime: 分段讀取 ~/.local/share/precc/.lifetime_summary.json，該檔案在每次 PostToolUse 測量和每次 precc savings 呼叫時被重寫。this session: 分段讀取相同的 lifetime 檔案，但減去在每個工作階段首次重新整理時持久化的工作階段基線。無需手動重新整理 — 檔案會自動更新。

禁用狀態列

如果你更想保留現有的狀態列，請在 ~/.claude/settings.json 中設定你自己的 statusLine 命令。PRECC 的安裝程式會偵測到自訂值，並在後續更新中保持不變。

若只想抑制每次互動的 📊 PRECC 行（在 additionalContext 中），請在 shell 環境中設定 PRECC_QUIET=1。

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.