token-audit

Token 浪费审计

文档位置

事实来源：~/stuff/gitrepos/gh/vtmocanu/skills/skills/token-audit/SKILL.md（公开仓库：github.com/vtmocanu/skills）。通过 npx skills 安装的副本位于 ~/.claude/skills/token-audit/，该副本由源文件生成；编辑源文件后，再运行 npx skills update。切勿编辑安装后的副本。

此技能附带脚本。请从技能自身的基目录（技能加载时打印的 Base directory for this skill: 行）调用脚本，例如 <skill dir>/scripts/cache-report.sh。常规全局安装时，该路径为 ~/.claude/skills/token-audit/scripts/。

目的与硬性规则

诊断此环境中的 Token 消耗情况。仅报告，不得更改任何文件或设置——不得编辑、写入配置或修复问题，即使问题显而易见也不例外。

审计协议中的不可妥协规则：

• 测量，不要估算。 每个数字都必须通过运行命令或读取文件获得。会话日志和 /context 中的精确 Token 数为权威数据——它们由 API 记录。字节数是精确值；换算为 Token 时，请标注为近似值，并优先采用 /context。
• 写 UNKNOWN，绝不猜测。 如果某个值无法测量（没有权限、工具不可用、数据缺失），则该单元格填写 UNKNOWN 并说明原因——不得用形容词或看似合理的数字代替。
• 证据必须是数字或文件路径，不能是形容词。 例如“17253 字节”或 ~/.claude/settings.json，而不是“大”或“好几”。

你无法自行运行的斜杠命令

/context 和 /usage 是界面命令，工具调用无法运行它们。它们提供权威的实时数据（各类别的实际上下文 Token 数、计划/用量限制）。请用户运行 /context 和 /usage 并粘贴输出，然后继续。不要因此暂停整个审计——先完成所有 Shell 测量，收到用户粘贴的数据后再纳入结果；如果一直没有收到，则将依赖这些数据的项目标为 UNKNOWN (awaiting /context)。

七项测量

并行运行互不依赖的测量。每项都会为最终表格提供证据。

1. MEMORY — 启动时加载的 CLAUDE.md、导入内容和规则

从正在审计的目录运行附带的扫描器：

<skill dir>/scripts/memory-scan.py

扫描器会枚举 Claude Code 在启动时加载的所有内容，匹配 CC 的实际规则：存在时包括托管/企业版 CLAUDE.md、用户记忆（~/.claude/CLAUDE.md）、项目链（向上遍历祖先目录中的 CLAUDE.md 和 CLAUDE.local.md，以及当前工作目录中的 .claude/CLAUDE.md），还有 .claude/rules/ 和 ~/.claude/rules/ 下无条件加载的 *.md 文件。它会递归跟进 @import 行（裸 @README、@dir/file.md、~/…、绝对路径），最多遵循 CC 实际的 4 层限制，并跳过行内代码段/围栏代码块，避免将示例 @path 计入。带有 paths: 范围的规则会按需加载，因此虽会列出，但不计入启动总量。扫描器会打印每个文件的精确字节数/行数，以及近似 Token 数（字节数/4）。标记任何超过 5k Token 的单个文件，以及任何超过 10k Token 的启动总量。 粘贴 /context 输出后，将近似值与其中的“Memory files”数据核对；若不一致，以 /context 为准。

2. 工具 — MCP 服务、工具数量、延迟加载及代理

• 已配置的 MCP 服务：解析每个配置来源；服务可能定义在其中任意一个来源中：

  jq -r '.mcpServers | keys[]?' ~/.claude.json 2>/dev/null
  jq -r '.mcpServers | keys[]?' ./.mcp.json ~/.claude/settings.json .claude/settings.json .claude/settings.local.json 2>/dev/null
  

  会话连接的服务（claude.ai 连接器：Gmail、Slack、IBKR 等）不在这些文件中。请从你自己的工具列表中可见的 MCP 工具名称（mcp__<server>__<tool>）按 <server> 分组统计。报告每个服务的工具数量。
• 明确说明工具延迟加载为 ACTIVE 还是 NOT ACTIVE。 当 MCP/其他工具以延迟加载方式提供，并通过 ToolSearch 调用时，延迟加载处于启用状态（系统提醒会列出延迟加载的工具名称，且其架构不会预先加载）。当所有工具架构都预先加载时，则未启用。根据你本次会话中的工具界面判断，并说明 ACTIVE 或 NOT ACTIVE。
• 如果发现代理/网关，请明确指出。 通过代理路由会静默关闭延迟加载，且不会发出任何警告。检查环境变量和设置：

  env | grep -iE 'ANTHROPIC_BASE_URL|ANTHROPIC_AUTH_TOKEN|ANTHROPIC_API_KEY|ANTHROPIC_BEDROCK|ANTHROPIC_VERTEX|_PROXY|GATEWAY'
  jq -r '.env // {} | to_entries[] | "\(.key)=\(.value)"' ~/.claude/settings.json .claude/settings.json .claude/settings.local.json 2>/dev/null
  

  任何 ANTHROPIC_BASE_URL / ANTHROPIC_AUTH_TOKEN（或 Bedrock/Vertex/网关变量）= 正在使用代理 → RED，因为无论第 2 步的观察结果如何，延迟加载都很可能已关闭。

3. 模型 — 当前模型、推理强度及会话中途切换

• 报告模型和推理强度，并说明各自的设置来源。来源按覆盖优先级排列：ANTHROPIC_MODEL / ANTHROPIC_SMALL_FAST_MODEL 环境变量、~/.claude/settings.json 中的 model、项目 .claude/settings.json/.local.json 中的 model，以及任何 /model 运行时选择（当前模型位于你的环境信息块中）。推理强度同样从设置/环境变量获取。

  jq -r '{model, env}' ~/.claude/settings.json .claude/settings.json .claude/settings.local.json 2>/dev/null
  env | grep -iE 'ANTHROPIC_MODEL|ANTHROPIC_SMALL_FAST_MODEL|MAX_THINKING|REASONING'
  

• 标出任何会在会话中途自动更改模型的模式 — 例如 opusplan 之类的计划模型别名（规划时使用 Opus，执行时使用较小的模型），或任何会切换模型的 harness 设置。每次切换都会使整个提示词缓存失效并重建。如果模型是固定 ID，且未设置自动切换别名，请明确说明。

4. 钩子 — 减少输出的 PreToolUse 钩子

列出 PreToolUse 钩子，并判断它们是否会改写会产生大量输出的命令以减少输出（追加 --quiet/-q、--reporter=dot、2>/dev/null、| tail、pytest -q 等）：

jq -r '.hooks.PreToolUse[]? | .matcher as $m | .hooks[]? | "\($m)\t\(.command // .type)"' ~/.claude/settings.json .claude/settings.json .claude/settings.local.json 2>/dev/null

如果没有任何钩子，请明确说明 — 未过滤的测试/构建输出会原样进入上下文，并在本会话剩余时间里反复发送。缺少钩子本身就是一项发现。

5. 子 Agent — 显式指定模型还是继承模型

列出每个 Agent 定义，并逐一说明其 frontmatter 是否固定设置了 model:，还是继承主会话的模型：

for f in ~/.claude/agents/*.md .claude/agents/*.md; do
  [ -f "$f" ] || continue
  m=$(sed -n '/^---$/,/^---$/{s/^model:[[:space:]]*//p;}' "$f" | head -1)
  printf '%s\t%s\n' "$f" "${m:-INHERITS}"
done

未设置 model: 的 Agent 会继承会话模型（因此，使用 Opus 的会话会让该子 Agent 也使用 Opus）。报告两类 Agent 的数量及分布；在昂贵的会话模型下，一批继承模型的 Agent 会带来需要指出的成本。

6. 定时任务 — 间隔与实测缓存 TTL 的比较

列出所有周期性任务及其间隔，然后将每个间隔与实测的提示词缓存 TTL 进行比较（第 7 步会报告该值——5m 或 1h；不要自行假设）。标出所有长于 TTL 的间隔 — 这些任务每次触发时都会错过缓存。

• Claude Code 定时 Agent / 例程（由 cron 计划）：如果存在，请使用 CronList 工具（通过 ToolSearch("select:CronList") 加载）；否则，检查由 schedule/loop 技能管理的计划配置。
• 系统调度器：

  crontab -l 2>/dev/null
  ls ~/Library/LaunchAgents /Library/LaunchAgents /Library/LaunchDaemons 2>/dev/null   # macOS launchd
  

• 本次会话中任何正在运行的 /loop 任务及其间隔。

对于每项任务，列出间隔、TTL，以及当间隔 > TTL 时标记 MISS。

7. CACHE — 最新会话日志的令牌拆分

运行捆绑的报告工具（默认使用当前项目的最新日志）：

<skill dir>/scripts/cache-report.sh          # or: cache-report.sh /path/to/session.jsonl
<skill dir>/scripts/cache-report.sh --list    # list this project's logs, newest first

它会汇总每轮助手对话中的 cache_read_input_tokens、cache_creation_input_tokens、input_tokens、output_tokens，报告各项占总计的百分比，并给出第一轮和最后一轮的上下文大小（输入侧）以及实际使用的缓存 TTL。这些是 API 自己记录的计数，精确而非估算。将 TTL 带入步骤 6。令牌总和包含子 Agent（sidechain）轮次，作为会话总开销；第一轮和最后一轮的上下文大小不包含这些轮次（输出中的 subagent_turns 和 context_basis 会说明具体情况），因此上下文数据反映主线程，而非子 Agent。

解读拆分结果：健康的会话以 cache_read 为主（读取占比高，说明缓存正常工作）。相较于 cache_read，cache_creation 占比很大，意味着缓存在反复重建——这种反复变动值得解释（模型切换、TTL 过期、早期上下文被编辑）。报告数据；只有在其他测量结果能够支持时，才指出导致该情况的因素。

输出

只输出一个表格，按成本从高到低排序：

FINDING | SEVERITY | EVIDENCE | WHAT IT IS COSTING ME

• SEVERITY 为 RED、AMBER 或 GREEN。
• EVIDENCE 为数字或文件路径，绝不能是形容词。
• WHAT IT IS COSTING ME 为具体的令牌／延迟成本，并与证据对应。
• 任何无法测量的项目都要作为一行列出，EVIDENCE 填 UNKNOWN，并说明原因。

然后另起一行，只写最后一行内容，此后不得再写任何内容：最具杠杆效应的一项改动。一行。

不要附加总结、后续步骤或提供修复帮助。表格和这一行就是全部交付内容。

陷阱

• 把内存令牌估算当作精确值。 bytes/4 是近似值；应标明这一点，并以 /context 为准。绝不要把除以 4 得出的数字说成测量所得的令牌数。
• 只统计已配置的 MCP 服务。 ~/.claude.json 不包含仅在实时工具列表中显示的 claude.ai 连接器——两者都要统计，否则工具总数就不对。
• 假定缓存 TTL。 TTL 取决于账户／会话，为 5m 或 1h；会话日志会记录实际值（ephemeral_1h_input_tokens 或 ephemeral_5m_input_tokens）。在判断步骤 6 的间隔之前，先在步骤 7 中测量 TTL。
• 代理会掩盖延后加载状态。 如果设置了 ANTHROPIC_BASE_URL／ANTHROPIC_AUTH_TOKEN，无论实时工具界面显示什么，都应报告延后加载状态已受影响。
• 运行审计不等于修复。 不要做任何更改。如果用户之后想要修复，那是另一个明确的请求。