跳到正文
cccskills
免费在 GitHub 公开

cache-efficiency

Analyze prompt-cache effectiveness for Claude Code usage from the Agent Monitor dashboard — cache hit rate (total_cache_read / (total_cache_read + total_input)), cache_write vs cache_read reuse, cache-read vs cache-write spend, and the sessions with the poorest reuse. Pulls token totals from /api/analytics, per-session detail from /api/sessions, and dollar splits from /api/pricing/cost. Use when diagnosing cache spend or deciding whether prompt caching is paying off.

中文简介正在准备中。当前显示原文说明。

查看安装方法

包含的文件(2)

  • SKILL.md3.8 KB
  • agents/openai.yaml269 B

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

Cache Efficiency

Diagnose whether prompt caching is actually saving money, and where it is not.

Input

The user provides: $ARGUMENTS

This may be: empty (analyze the whole fleet), "today" / "this week" / a date range, a session ID to scope the analysis, or a target like "hit rate > 80%". When empty, analyze all data from /api/analytics.

Data Sources

EndpointReturns
GET /api/analyticstokens.total_input, tokens.total_output, tokens.total_cache_read, tokens.total_cache_write (baselines pre-summed), plus daily_sessions
GET /api/sessions?limit=200Session list — each has model, cwd, started_at, ended_at, inline cost, metadata (JSON: usage_extras with cache token detail)
GET /api/sessions/{id}Full session detail with nested agents and events, for drill-down on a flagged session
GET /api/pricing/cost{ total_cost, breakdown: [{ model, input_tokens, output_tokens, cache_read_tokens, cache_write_tokens, cost, matched_rule }] } — used to price cache read vs write spend

How cache economics work

cache_hit_rate   = total_cache_read / (total_cache_read + total_input)
cache_reuse      = total_cache_read / total_cache_write
cache_read_cost  = (cache_read_tokens  / 1M) × cache_read_per_mtok
cache_write_cost = (cache_write_tokens / 1M) × cache_write_per_mtok

Cache writes cost more per token than cache reads (e.g. Sonnet $3.75 write vs $0.30 read per Mtok), and writes are billed even if the cached block is never reused. The payoff only arrives on subsequent reads — so a healthy fleet shows cache_read_tokens far exceeding cache_write_tokens. When cache_reuse < 1, you are paying to cache context you barely re-read.

Token counts are effective totals = current + baseline (baselines preserve pre-compaction tokens).

Report Sections

1. Fleet Cache Hit Rate

From /api/analytics: compute cache_hit_rate × 100. State raw total_cache_read and total_input. Benchmark: >70% strong, 40–70% moderate, <40% weak prompt-cache utilization.

2. Write vs Read Reuse

Compute cache_reuse = total_cache_read / total_cache_write. Show both token counts. Flag if reuse < 1 (writing more cache than is ever read back).

3. Cache Spend Split

From /api/pricing/cost breakdown, sum cache_read_cost and cache_write_cost across all models. Show the dollar split and what fraction of total cost is cache-write overhead vs cache-read savings.

4. Sessions With Poor Reuse

From /api/sessions?limit=200, parse metadata.usage_extras for per-session cache read/write where available; rank sessions by lowest read/write reuse (and by cache_write-heavy cost). List the worst 10 with model, cost, and reuse ratio. Use /api/sessions/{id} to drill into any single flagged session.

5. Recommendations

  • Sessions where cache_write >> cache_read: short or one-shot sessions rarely recoup cache writes — note them.
  • Stable, repeated context (system prompts, large files) should be cached once and reused; high churn defeats caching.
  • Estimate the dollar impact of raising the hit rate to the next benchmark tier.

Output

Structured Markdown with tables. Currency as USD to 4 decimal places; rates as $/Mtok; percentages with ▲/▼ for any trend. Token counts with thousands separators.

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

Inspect fired CCAM alerts and manage alert rules for token thresholds, event patterns, inactivity, and status duration. Use when acknowledging alerts, creating or editing a rule, checking cooldowns, or connecting alert rules to webhook targets.

中文简介正在准备中。当前显示原文说明。

hoangsonww/Claude-Code-Agent-Monitor11062026年10月22日 更新

Identify anomalous sessions using Agent Monitor data — cost outliers from the pricing engine, token anomalies (cache miss spikes, compaction baseline surges), unusual event type ratios (PreToolUse/PostToolUse gaps, APIError clusters), behavioral deviations from workflow intelligence (complexity score outliers, error propagation anomalies), and sessions with abnormal metadata (extreme turn_count, high thinking_blocks, zero turn_duration).

中文简介正在准备中。当前显示原文说明。

hoangsonww/Claude-Code-Agent-Monitor11062026年10月22日 更新

Produce a detailed report on APIError events from Agent Monitor data — counts over time, which sessions and models are affected, and the likely root cause (rate limits, overload/529, or context-window pressure) inferred from each event's summary and data payload. Use when API errors spike or when you need to explain why requests are failing.

中文简介正在准备中。当前显示原文说明。

hoangsonww/Claude-Code-Agent-Monitor11062026年10月22日 更新

benchmark

免费

Benchmark one session (or a small recent set) against the rolling average using Agent Monitor data — cost, total tokens, tool count, and workflow complexity score — and report where each metric lands as a percentile of the population. Tells you whether a session was normal, cheap, or an outlier. Use when judging whether a session was typical or out of band.

中文简介正在准备中。当前显示原文说明。

hoangsonww/Claude-Code-Agent-Monitor11062026年10月22日 更新

Define a spend budget for Claude Code and, optionally, create a cost alert rule that fires when usage crosses the limit, via POST /api/alerts/rules on the Agent Monitor dashboard. Reads current spend from /api/pricing/cost to size the budget sensibly and explains every rule field before writing. Use when setting a spend limit or wiring up a budget guardrail.

中文简介正在准备中。当前显示原文说明。

hoangsonww/Claude-Code-Agent-Monitor11062026年10月22日 更新

Report concurrency and parallelism for a session — how many agents ran in parallel, concurrency-lane utilization, peak parallel width, and serialization bottlenecks (sequential chains that could have run as parallel lanes) — using the Agent Monitor workflow intelligence API. Use when checking whether a multi-agent session used parallelism efficiently.

中文简介正在准备中。当前显示原文说明。

hoangsonww/Claude-Code-Agent-Monitor11062026年10月22日 更新

查看 hoangsonww 的全部技能

报告此技能的问题