Sipcode Sipcode 是一款开源工具，通过压缩冗余输出来清理 Claude Code 的上下文，帮助开发者获得更精准的 AI 编程回答。 热门评论 PH 用户嗨 PH，我是 Anuj，独立开发者。我做 Sipcode 是因为我老看着 Claude Code 每轮对话里反复读同一个文件 6-8 遍，还把 4000 行的 npm install 日志塞进上下文。窗口里每多一个不必要的 token，有效信号就被挤出去一点，下一个回答就更差。这就是我造它来解决的可靠性问题。它是一个 Claude Code 的 PreToolUse hook。它能截断冗长的输出（比如 git log、npm install、grep、tsc），去重同一轮对话中未变更文件的重复读取，还暴露了 15 个 MCP 工具让 Claude 可以读取自身的上下文卫生统计数据。Anthropic 自己的研究显示：更干净的上下文能让质量提升 29%，智能体错误减少 40%。Sipcode 针对的正是这个机制。省下的 token 就是上下文变干净的证明。在锁定 20 个任务的基准测试中：工具输出节省中位数 62.6%，每次语料运行花费 $67.43，任何机器都可复现。基准测试任务列表已提交到 repo 里。坦诚来说，这也成了发布故事：上周我的 drift 工具显示一次会话浪费了 624,940 个 token。而我代理的 --stats 只记了 7,553 个节省。少报了 83 倍，我自己的工具都在骗我。根因是会话中途的安装导致前半段会话未被缓存。24 小时后我发布了 v1.6.15 带 Verified Warm-Fill，现在 drift 显示“未检测到 drift”。今天又发布了 v1.6.16，修复了 cache-defer 和 grep-cap 问题。九天发了三个版本。MIT 协议，正常使用中零网络调用（如果有人在 src/ 里 import node:http，隐私测试会构建失败）。乐意回答任何技术问题，尤其是 Warm-Fill 正确性证明或基准测试方法。如果 Sipcode 帮你省了一次会话，在 github.com/Anuj7411/sipcode 上给个 star 对一个想找到真正受益者的个人项目来说意义重大。PH 用户我第一个会测的是同一轮对话的重复读取去重——反复读未变更文件 6-8 次正是悄悄搞坏长对话 Claude Code 的元凶。你怎么判断一个文件在两次读取之间“未变更”：mtime、内容哈希还是 git 状态？当一个子智能体在自己的上下文分支里读同一个文件时，这个判断还成立吗？对 npm/tsc 输出的截断也有道理，但模型能在真正需要时拉取完整未截断的日志吗？PH 用户重复读取去重看起来是个明显的胜利！问一下——当你给 Claude 运行的一个 grep（它本没加限制）注入 head_limit 时，模型会看到“已截断，还有 N 个匹配”的标记吗？它会把截断后的列表当作完整结果吗？总的来说，做得很好！PH 用户Claude Code 用户都知道上下文被日志、重复输出和工具噪音污染得有多快 😅 把上下文当作有限资源而不是无限资源这个思路真的很有共鸣。好奇……你在构建 Sipcode 时发现的最令人意外的上下文膨胀源是什么？PH 用户祝贺发布，Anuj！作为一个整天泡在 Claude Code 里的人（我在它上面搭了一整套自定义技能），工具冗长输出导致的上下文膨胀确实是个真实痛点，所以一个能截断它并在同一轮对话中去重重复读取的工具正是我切身体会到的需求。另外必须提一下你的发布视频。它真的是我在 PH 上见过最好的之一，那个音乐让我一股 RPG 怀旧感涌上心头。已经和你聊过了。给个 star，今天就在我的环境里试试。🌟PH 用户Claude Code 反复读取相同的文件，并把大量日志倾倒进 context 里，这种场景令人痛苦地熟悉。我喜欢 Sipcode 处理的是烦人的清理层，而不是假装更大的 context window 能解决一切。 热门产品Anuj ojha2026-06-23原文 打开互动版
它是一个 Claude Code 的 PreToolUse hook。它能截断冗长的输出（比如 git log、npm install、grep、tsc），去重同一轮对话中未变更文件的重复读取，还暴露了 15 个 MCP 工具让 Claude 可以读取自身的上下文卫生统计数据。Anthropic 自己的研究显示：更干净的上下文能让质量提升 29%，智能体错误减少 40%。Sipcode 针对的正是这个机制。
省下的 token 就是上下文变干净的证明。在锁定 20 个任务的基准测试中：工具输出节省中位数 62.6%，每次语料运行花费 $67.43，任何机器都可复现。基准测试任务列表已提交到 repo 里。
坦诚来说，这也成了发布故事：上周我的 drift 工具显示一次会话浪费了 624,940 个 token。而我代理的 --stats 只记了 7,553 个节省。少报了 83 倍，我自己的工具都在骗我。根因是会话中途的安装导致前半段会话未被缓存。24 小时后我发布了 v1.6.15 带 Verified Warm-Fill，现在 drift 显示“未检测到 drift”。今天又发布了 v1.6.16，修复了 cache-defer 和 grep-cap 问题。九天发了三个版本。
MIT 协议，正常使用中零网络调用（如果有人在 src/ 里 import node:http，隐私测试会构建失败）。乐意回答任何技术问题，尤其是 Warm-Fill 正确性证明或基准测试方法。
如果 Sipcode 帮你省了一次会话，在 github.com/Anuj7411/sipcode 上给个 star 对一个想找到真正受益者的个人项目来说意义重大。
另外必须提一下你的发布视频。它真的是我在 PH 上见过最好的之一，那个音乐让我一股 RPG 怀旧感涌上心头。已经和你聊过了。给个 star，今天就在我的环境里试试。🌟