超省钱组合！Claude Tokens 降 90% ？Headroom + CC Switch 教程

最近有一款非常火的 Agent 插件，叫做 Headroom 。它是一个给 AI Agent / 编程 Agent 用的“上下文压缩层” 应用，让大部分的工具输出、日志、文件读取、RAG 片段、对话历史等内容，在触及 LLM 之前就先进行压缩，目标是减少 token、降低费用、提高长上下文可用性。

官方 Readme 文档里介绍了项目的实际使用效果，即在不同的场景下 token 的节约占比，增加缓存命中。 最大的是代码搜索环节，可以节约 92% 的 token 消耗。而这一切都是保证 LLMs 输出的答案质量不变。

超省钱组合！Claude Tokens 降 90% ？Headroom + CC Switch 教程

它无需修改代码进行下面两项工作：

• Verbosity steering：在系统提示末尾附加一句简短的“请简洁，不要重复上下文”的说明（这样你的提示缓存仍然命中）。
• Effort routing：当一个回合只是模型在工具结果（文件读取、通过测试）之后继续时，它会降低模型的思考强度。新的问题和错误仍保持全力思考。

非常适合长时间进行工作的 Agent ，尤其是大量的开发编程、文本处理等。官方提供了四种接入方法，Wrap 和 MCP 适合的是 Agent 和 Headroom 装在一起的场景，而 Proxy 则是依靠网络的更通用的用法，支持部署后提供给外部 Agent 使用的。

于是我就部署测试了一番。没有使用其它的 token 降低办法，仅使用 Claude Code + Headroom + CC Switch 的组合，模型使用了 MiniMax-M3 。

实测下来，跑了 13.5M tokens（含缓存、输入、输出），输出到 LLMs 为 12.5M tokens，节约 tokens 910.8k ，占比约 6.8%。

这是因为官方提供的是专项场景的 tokens 占比，是我这边的真实开发场景。体验下来 token 节约率在 6% - 8% 之间（未区分是缓存还是非缓存），然后整体的缓存命中会有所增加。长期来看虽然不如官方说的那么夸张，但是降低 tokens 消耗的功能还是有的，另外可以配合一些其它的代码图谱等进一步降低 tokens 消耗。

更详细的数据在下面，实际消耗 tokens 13.5M，经过 headroom 压缩了 910.5K，压缩后为 12.5M tokens。

下面还有一个更明晰的数据，里面包括了 RTK 压缩量、内部流水线耗时等信息，相当的清晰。

然后这边是 CC-Switch 里的 tokens 统计。时间上可能有点误差，但是可以看到 CC Switch 接收到的 13.2M tokens 也是小于 Headroom 里 before 的 tokens 的，即通过 Headroom 压缩后实际发送到 LLMs 的 tokens 数量要小于对话中实际输入的。

有没有用？有，降低少量 tokens 消耗，增加一定的缓存命中。但是是否有很大的作用，我觉得并不一定

但是在 tokens 越来越贵、越来越少的现在，节约一切可以节约的 tokens，我觉得是非常有必要的。尤其是我日常使用 GLM5.2，基本上 2 天就可以用完一周的 Pro 用量，通过各种方法节约 tokens 后可以将这个用量提升到 3 天！

一. Headroom + CC Switch 配置指南

我这个场景的流程是这样的，CC -> Headroom -> CC Switch。 Headroom 起到的作用就是纯粹的文本内容压缩。

这套方案不局限于将 Headroom 配置到某个固定搭配的 Agent 上，而是所有部署在不同地方的 Agent ，都可以通过互联网访问 Headroom，然后再走到 CC Switch 上，打破物理和空间的隔阂。

部署的设备，我强烈推荐大家使用 NAS，比如极空间私有云。为什么这样说？因为现在越来越多的 AI 应用需要一个长期开机不间断的载体，很多时候你并只在一台设备上运行 AI Agent。

那么多的插件、工具，都需要一个中间态服务来运作。而 NAS 原本作为家庭存储中心，是 AI 知识库的天然存储位，而现在又可以利用家宽、异地组网来实现服务的分发，相当于变成了一个家庭服务中心。

1️⃣ 打开 CC Switch 网关功能

我们把网关的配置服务地址为 0.0.0.0，端口保持默认不变。

2️⃣ 配置虚拟组网

由于 token 使用是一个非常敏感的事情，所以我建议大家绝对不要使用互联网来转发和使用这些敏感端口。更好的方案，一定是进行异地组网。

极空间内置的节点小宝就是目前非常好的选择，免费账号可以提供 20 台设备的入网，P2P 连接后网速和公网家宽是一样的，丝毫不影响使用。

在应用商店的第三方应用里就可以直接安装使用，也可以通过 docker 部署（建议）。

services: owjdxb: image: ionewu/owjdxb container_name: owjdxb restart: unless-stopped network_mode: host volumes: - /etc/hostname:/host_hostname:ro devices: - /dev/net/tun:/dev/net/tun cap_add: - NET_ADMIN - SYS_ADMIN

接着打开节点小宝控制台，在里面找到 CC Switch 和 Headroom 所在的虚拟网 IP。我这里分别是 100.66.1.1 和 100.66.1.2。这个虚拟网 IP 不限地点、不限网络，所以哪怕具体再远也可以互联互通。

Headroom 还有一个功能叫做 Cross-agent memory。任何经过同一个 Headroom Proxy 的 Agent，都可以共享同一个 memory store。例如 Claude 保存一个事实，Codex 可以读回来。它还会记录是哪一个 agent 写入/更新的，并做自动去重。

这样就实现了跨 Agent 的事实和记忆共享。如果你刚好是做团队的，并且有项目团队成员需要一起压缩 token，一起共享事实进行开发，那么我们还可以通过节点小宝的网络团队来实现。

邀请团队其它成员后，我们部署的 Headroom 就可以被其它团队网路成员调用了，在工作室里特别方便。

3️⃣ 部署 Headroom

这里使用日常的 NAS 极空间Z4Pro 为例，打开极空间 Docker 应用，创建一个 Compose 项目，并将下方的代码填写到 compose 代码框内。

这里需要注意的是，ANTHROPIC_TARGET_API_URL 这个环境变量后面要改成你的 CC Switch 所在设备的 IP，端口保持 15721 不变。

services: headroom-proxy: image: ghcr.io/chopratejas/headroom:latest command: ["--host", "0.0.0.0"] environment: - HEADROOM_HOST=0.0.0.0 # 这里改成 CC switch 的节点小宝虚拟 IP - ANTHROPIC_TARGET_API_URL=http://100.66.1.1:15721 ports: - "8787:8787" volumes: - ./headroom:/home/nonroot/.headroom healthcheck: test: ["CMD", "curl", "--fail", "--silent", "http://127.0.0.1:8787/readyz"] interval: 30s timeout: 5s retries: 3 start_period: 20s depends_on: - qdrant - neo4j qdrant: image: qdrant/qdrant:v1.17.1 ports: - "6333:6333" # 可选，REST API - "6334:6334" # 可选，gRPC volumes: - ./qdrant_data:/qdrant/storage environment: - QDRANT__SERVICE__GRPC_PORT=6334 neo4j: image: neo4j:5.26 ports: - "7474:7474" # 可选，HTTP (Browser) - "7687:7687" # 可选，Bolt volumes: - ./neo4j_data:/data environment: - NEO4J_AUTH=${NEO4J_AUTH:-neo4j/devpassword} - NEO4J_PLUGINS=["apoc"] - NEO4J_apoc_export_file_enabled=true - NEO4J_apoc_import_file_enabled=true - NEO4J_apoc_import_file_use__neo4j__config=true

部署完成以后，可以打开 headroom 容器的管理页面查看具体的压缩量信息。如果你使用极空间的远程访问，那么默认的访问 URL 后面还要加一个 /dashboard 路径。