最大化 Claude Code 会话价值与令牌效率

通过提示缓存降低令牌成本

Claude Code 使用提示缓存来降低重复输入令牌的成本。当请求以与之前请求相同的令牌开头时，服务器会从缓存中加载状态，而不是重新计算，从而将这些令牌的成本降低至标准输入价格的 0.1 倍。然而，将新令牌写入缓存的成本最高可达正常输入价格的 2 倍。

避免缓存未命中

由于缓存键从请求开头开始，请求前缀的任何更改都会使整个后续缓存失效。用户应在会话过程中避免以下操作，以防止昂贵的完整上下文重新填充：

• 切换模型（/model）： 每个模型维护其独立的缓存。
• 更改努力级别（/effort）： 努力级别是缓存键的一部分；更改它们会破坏缓存。
• 切换快速模式： 启用快速模式会更改缓存键。应在会话开始时启用。
• 使用 /compact： 此命令会用较短的摘要替换对话，导致之前的对话历史不再匹配缓存。
• 基于时间的过期： 订阅用户缓存一小时后过期，API 密钥用户五分钟过期（除非设置 ENABLE_PROMPT_CACHING_1H=1）。

为最小化成本，用户应在会话开始时或在执行 /clear 命令后立即进行模型和努力级别的更改。使用 /rewind 比 /compact 更具成本效益，因为它仅截断对话末尾，保留前面的缓存历史不变。

战略性上下文管理

会话中添加的每个文件读取或命令输出都会保留在后续所有回合的上下文中，增加每次请求的令牌负载。管理进入上下文的内容对于保持性能和降低成本至关重要。

优化输入与工具结果

• 使用 @-提及： 提及文件（例如 @utils.test.ts）会将文件附加到第一个请求中，跳过对单独 Read 工具调用的需求以及随之而来的回合。
• 静默命令标志： 命令输出会附加到对话中。为防止上下文膨胀，用户应在 CLAUDE.md 中为常见命令添加静默标志（例如，Vitest 使用 --reporter=dot）以限制返回文本量。
• 限制启动上下文： 在新会话中使用 /context 识别不必要的加载项。特定工作流的指令应从 CLAUDE.md 移至仅在需要时加载的技能中，并通过 /mcp 禁用未使用的 MCP 服务器。

管理会话长度

长会话比多个短会话的成本呈指数级增长，因为每个回合都会重新处理整个先前历史。用户应在切换任务时使用 /clear，在任务早期部分完成后使用 /compact。对于使用 1M 上下文模型的用户，可使用 /autocompact 200k 重新启用自动压缩安全机制（Claude Code v2.1.221+ 可用）。

利用子代理处理嘈杂任务

子代理提供了一种在独立上下文窗口中执行任务的方法。子代理拥有自己的系统提示和工具，但不会继承主会话的对话历史。只有最终答案返回主会话，所有中间回合和工具输出均被丢弃。

子代理非常适合处理“嘈杂”任务，例如解析大型日志文件，否则中间输出会膨胀主会话的上下文。用户可以显式请求子代理（例如“在这个日志中使用子代理处理”），或定义特定子代理定义，使用更便宜的模型（如 Haiku 或 Sonnet）以进一步优化成本。

社区见解与替代工作流

Hacker News 上的用户提出了补充官方建议的额外策略：

• /handoff 工作流： 一些用户更倾向于使用 /handoff 技能创建可移植的上下文文档。这允许他们使用 /continue [file] 启动新会话，有效重置缓存和上下文，同时保留关键项目记忆。
• 验证循环： 高效用户报告通过让代理编写测试、删除覆盖代码以验证测试失败（变为“红色”），然后恢复代码以验证其通过，确保测试在人工审查前具有实际意义。
• 对手动优化的担忧： 一些社区成员认为，要求用户通过 /clear 和 /compact 等命令手动管理缓存和上下文是一种倒退，向形式语言靠拢，AI 应自主处理这些优化。

"我发现 [/handoff] 比 /compact 或 /clear 更有用，因为上下文保存在可移植的文件中，而不是绑定到单一会话……我每 20 条消息左右这样做，效果比长时间会话更好。"

"更改努力级别会破坏缓存……努力级别难道不能仅作为解码操作，仅改变 令牌的概率吗？"

高成本区域总结

优先级	区域	优化操作
最高	会话长度	频繁使用 /clear 和 /compact
高	上下文膨胀	使用 @-提及和静默命令标志
中	缓存未命中	在会话开始时设置 /model 和 /effort
低	启动加载	检查 /context 并禁用未使用的 MCP 服务器