Megtakarítások

A PRECC nyomon követi a becsült token-megtakarításokat minden elfogásnál. Használja a precc savings parancsot a megelőzött pazarlás megtekintéséhez.

Gyors összefoglaló

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

Részletes bontás (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>%

Hogyan becsüljük a megtakarításokat

Minden javítási típusnak van egy becsült token-költsége azon alapulva, mi történt volna PRECC nélkül:

Ezek konzervatív becslések. A tényleges megtakarítások gyakran magasabbak, mert Claude hibákról való gondolkodása terjedelmes lehet.

Kumulatív megtakarítások

A megtakarítások munkamenetek között megmaradnak a PRECC adatbázisban. Idővel nyomon követheti az összesített hatást:

$ 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

Állapotsor

A telepítés után a PRECC bejegyez egy statusLine elemet a ~/.claude/settings.json fájlba, hogy a Claude Code állapotsora élő munkamenet-metrikákat jelenítsen meg:

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

Állítsd be a PRECC_LANG változót, hogy a címkék a saját nyelveden jelenjenek meg — lásd a Lokalizáció fejezetet.

Minden szegmens:

A lifetime: szegmens utolsóként szerepel, így ezt csonkolja először a Claude Code felülete, ha a sávot a jobb szélen levágja.

Miért nem osztható el a költség és a tokenszám

A megjelenített 1.2M in/out nem a $0.42 spent értéket előállító nevező. A Claude Code cost.total_cost_usd értéke az API teljes token-bontásából számolódik — alap bemenet, kimenet, plusz a gyorsítótár-olvasások és gyorsítótár-létrehozások. A munkamenet egészére vonatkozó összesített gyorsítótár-token számok nem érhetők el a statusline sémában, ezért a PRECC csak a látható (nem gyorsítótár) részt tudja megjeleníteni.

Hosszú munkamenetekben, ahol sok fájl-újraolvasás történik, a gyorsítótár-olvasások a látható tokenszám 10-szerese is lehetnek. Ezért lenne félrevezető arányként összepárosítani őket — a PRECC ezért független szegmensként jeleníti meg azokat.

Miért nem számítja ki a PRECC a költséget

A költségszám hiteles. A PRECC szó szerint olvassa be a cost.total_cost_usd értéket abból a JSON-ból, amelyet a Claude Code stdin-en keresztül a status parancsba küld. Ez ugyanaz a szám, amelyet a Claude Code a feliratkozási/használati keretedből levon. Bármikor ellenőrizheted a beépített /cost perjel-paranccsal — a kettőnek egyeznie kell.

Mi határozza meg a költséget

A Claude Opus 4.6 esetén:

A leghosszabb munkamenetek legnagyobb költségmeghajtói általában a kimeneti tokenek (a tokenenkénti legdrágább típus, különösen az 1M kontextusszinten), az ismételt gyorsítótár-olvasások (egyenként olcsók, de sok forduló alatt gyorsan halmozódnak) és a gyorsítótár-létrehozások (fájlolvasásonként egyszer írva, az alap bemeneti díj ~1,25-szeresén). A PRECC a Bash kimenet tömörítésével csökkenti a látható token-költséget (a 📊 last cmd: szegmens parancsonkénti megtakarítást mutat), de nem tudja csökkenteni a Claude által már betöltött fájlok gyorsítótár-olvasásait.

Stabil munkamenet-számlálók

A “PRECC: N fixes” szegmens a megőrzött munkamenet-kezdet óta számolja az eseményeket, amelyet az egyes munkamenetek első statusline-frissítésekor a ~/.local/share/precc/sessions/<session_id>.start fájlba írunk. Ez teszi monotonná a számlálást — még akkor sem csökkenhet a munkamenet közepén, ha a cost.total_duration_ms egy adott frissítésnél hiányzik.

Automatikusan frissített élettartam-pillanatkép

A lifetime: szegmens a ~/.local/share/precc/.lifetime_summary.json fájlt olvassa, amelyet minden PostToolUse mérésnél és minden precc savings hívásnál újraírunk. A this session: szegmens ugyanezt a lifetime fájlt olvassa, de levon egy munkamenetenként megőrzött alapértéket, amelyet az egyes munkamenetek első frissítésekor mentünk el. Nincs szükség kézi frissítésre — a fájlok maguktól frissülnek.

Az állapotsor elrejtése

Ha inkább megtartanád a meglévő állapotsorodat, állíts be saját statusLine parancsot a ~/.claude/settings.json fájlban. A PRECC telepítője észleli az egyéni értéket, és későbbi frissítéseknél nem nyúl hozzá.

Ha csak az interakciónkénti 📊 PRECC sort szeretnéd elrejteni (az additionalContext-ben), állítsd be a PRECC_QUIET=1 változót a shell környezetedben.

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.