การประหยัด

PRECC ติดตามการประหยัดโทเค็นโดยประมาณจากทุกการสกัดกั้น ใช้ 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:

นี่เป็นการประมาณการแบบอนุรักษ์นิยม การประหยัดจริงมักสูงกว่าเพราะการให้เหตุผลของ 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 จะเพิ่มรายการ statusLine ลงใน ~/.claude/settings.json เพื่อให้แถบสถานะของ 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: ถูกวางไว้ท้ายสุด เพื่อให้เป็นส่วนแรกที่ถูกตัดเมื่อ UI ของ Claude Code ตัดแถบที่ขอบขวา

ทำไมค่าใช้จ่ายกับจำนวนโทเคนถึงหารกันไม่ได้

1.2M in/out ที่แสดง ไม่ใช่ ตัวส่วนที่ทำให้ได้ $0.42 spent cost.total_cost_usd ของ Claude Code คำนวณจากการแยกย่อยโทเคนเต็มรูปแบบของ API — อินพุตพื้นฐาน เอาต์พุต บวกการอ่านแคชและการสร้างแคช จำนวนโทเคนแคชสะสมตลอดเซสชันไม่ได้เปิดเผยในสคีมา statusline ดังนั้น PRECC จึงแสดงได้เฉพาะส่วนที่มองเห็นได้ (ไม่ใช่แคช)

ในเซสชันยาวที่มีการอ่านไฟล์ซ้ำมาก การอ่านแคชอาจสูงถึง 10 เท่าของจำนวนโทเคนที่มองเห็นได้ นั่นคือเหตุผลที่การจับคู่ทั้งสองเป็นอัตราส่วนจะทำให้เข้าใจผิด — PRECC จึงแสดงเป็นส่วนอิสระแทน

ทำไม PRECC ถึงไม่คำนวณค่าใช้จ่าย

ตัวเลขค่าใช้จ่ายเป็นค่าที่เชื่อถือได้ PRECC อ่าน cost.total_cost_usd ตามตัวอักษรจาก JSON ที่ Claude Code ส่งผ่าน stdin ไปยังคำสั่งสถานะ นั่นคือตัวเลขเดียวกันกับที่ Claude Code หักจากงบสมัครสมาชิก/การใช้งานของคุณ คุณสามารถตรวจสอบเมื่อใดก็ได้ด้วยคำสั่งสแลชในตัว /cost — ทั้งสองค่าควรตรงกัน

อะไรที่ขับเคลื่อนค่าใช้จ่าย

สำหรับ Claude Opus 4.6:

ปัจจัยที่ขับเคลื่อนค่าใช้จ่ายมากที่สุดในเซสชันยาวมักคือโทเคนเอาต์พุต (ประเภทที่แพงที่สุดต่อโทเคน โดยเฉพาะที่ระดับบริบท 1M) การอ่านแคชซ้ำๆ (แต่ละครั้งราคาถูกแต่สะสมเร็วในหลายเทิร์น) และการสร้างแคช (เขียนหนึ่งครั้งต่อการอ่านไฟล์ที่ ~1.25× อัตราอินพุตพื้นฐาน) PRECC ลดต้นทุนโทเคนที่มองเห็นได้โดยการบีบอัดเอาต์พุต Bash (ส่วน 📊 last cmd: แสดงการประหยัดต่อคำสั่ง) แต่ไม่สามารถลดการอ่านแคชของไฟล์ที่ Claude โหลดไว้แล้วได้

การนับเซสชันที่เสถียร

ส่วน “PRECC: N fixes” จะนับเหตุการณ์ตั้งแต่จุดเริ่มเซสชันที่ คงอยู่ ซึ่งเขียนลงใน ~/.local/share/precc/sessions/<session_id>.start ในการรีเฟรช statusline ครั้งแรกของแต่ละเซสชัน ทำให้การนับเป็นแบบโมโนโทน — ไม่สามารถลดลงกลางเซสชันได้แม้ว่า cost.total_duration_ms จะหายไปในการรีเฟรชหนึ่งๆ

สแน็ปช็อตตลอดอายุที่รีเฟรชอัตโนมัติ

ส่วน lifetime: อ่าน ~/.local/share/precc/.lifetime_summary.json ซึ่งจะถูกเขียนใหม่ทุกครั้งที่มีการวัด PostToolUse และทุกครั้งที่เรียก precc savings ส่วน this session: อ่านไฟล์ lifetime เดียวกันแต่ลบเส้นฐานต่อเซสชันที่เก็บไว้ในการรีเฟรชครั้งแรกของแต่ละเซสชัน ไม่ต้องรีเฟรชด้วยตนเอง — ไฟล์อัปเดตตัวเอง

การปิดแถบสถานะ

หากคุณต้องการเก็บแถบสถานะที่มีอยู่ ให้ตั้งคำสั่ง statusLine ของคุณเองใน ~/.claude/settings.json ตัวติดตั้ง PRECC จะตรวจพบค่าที่กำหนดเองและไม่แตะต้องมันในการอัปเดตครั้งต่อๆ ไป

หากต้องการระงับเฉพาะบรรทัด 📊 PRECC ต่อการโต้ตอบ (ใน additionalContext) ให้ตั้งค่า PRECC_QUIET=1 ในสภาพแวดล้อม 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.