Claude Code 终于不重读代码了:这个 7 star 小工具把 token 砍掉 60%

Claude Code 终于不用「每次开新会话就重读一遍代码库」了 —— 这是 live-memory 给我最大的一个体感冲击。

一个真实痛点：context 烧在哪儿了

如果你用 Claude Code 写过稍微大一点的项目，一定经历过这个场景：开一个新 session，问一句「这个仓库里 auth 模块在哪儿」，agent 立刻开始 Read、Grep、Glob 一通操作,把整个目录树扫一遍。然后你 follow-up：「jwt 校验在哪一层做的」，它又读一遍相关文件。等到你真正想动手改东西时,主模型的 context 已经塞满了临时扫过的源码——而这些信息其实跟 session 没啥关系。

live-memory 直球拆穿这件事：理解型任务的 cost,61% 花在 agent 反复读同一个仓库的「项目理解」上。真正用于编辑和生成的 token,反而是少数。

它到底是怎么做的

live-memory 不是又一个 RAG。设计很克制:

• 一个独立 MCP server(单例,常驻 HTTP),跑一个便宜的 large-context 模型(默认 Haiku,可换 DeepSeek 或本地模型)
• 被动学习:通过 PostToolUse 和 FileChanged hook,把 agent 实际读/写的文件内容 tee 到 server——不增加额外 token 开销,纯粹是工作副产物
• 一个 read-only 工具:ask_live_memory(question, cwd),agent 问「X 在哪儿/怎么工作」时直接调它,不再去碰 Read 工具
• 跨 session 持久:state 按 cwd 分工作区,JSON snapshot 落盘,下次开会话还在
• append-only + 中性压缩:不是简单的「截断前面」,而是按高低水位做 batched 知识聚合,把已经看过的东西蒸馏成结构化 ledger

整个机制看起来就一句话:让一个便宜的伴生模型替你记仓库,主模型只负责「问 → 拿答案 → 干活」。

实测数据

作者在一个真实仓库做了 A/B:

注意三个细节:
1. 理解型任务上,主模型把 93% 的 codebase-reading token 转移给了伴生模型
2. DeepSeek-v4-flash 在 15 问 × 3 轮的准确率 set 上打平 Haiku(98% vs 91%),价格是 Haiku 的 1/8
3. 收益不是均匀分布的——纯打字场景基本没差别,「理解」密集型才是它的主场

几个让人放心的工程细节

• 零配置就能跑:有 Claude 订阅就用订阅的 OAuth token 跑 Haiku,不用单独买 API key
• 只读 + 路径 jail:伴生模型无论如何都改不了你代码,只能读
• 背压保护:两层 timeout,模型预算耗尽就 best-effort 兜底返回,不会卡死主流程
• 过程可观测:/live-memory-stats 看累积了多少知识、烧了多少 token,人能看到,不需要 agent 介入
• Slash command 隔离:/live-memory-stats、/live-memory-config、/live-memory-empty 都是用户面命令,不进 agent 的工具集

我会怎么用它

如果你日常 80% 的 Claude Code 时间花在「进一个新仓库 / 新会话,把项目摸熟」上,live-memory 基本就是为你设计的。装上之后,新会话的第一句「帮我看看 auth flow」从「花几毛钱读 30 个文件」变成「花几分钱问一个问题」——成本差一个数量级。

至于硬性 work(edit/exec type),它不抢功也不拖后腿,体感差不多。

局限

• 目前只支持 Claude Code,Cursor / Codex / Continue 暂时用不上
• 需要本地常驻一个 HTTP server(有 systemd unit 模板,也可以裸跑)
• 想要更激进的成本节省,得自己换更便宜的伴生模型

这个 7 star 的小项目刚在 Show HN 上挂出来没几天,但它的设计哲学非常对——把「理解」当成可外置的状态,而不是每个 session 都要重新交一次的学费。

GitHub: https://github.com/shofer-dev/claude-code-live-memory

(Apache-2.0,Python,需要 Claude Code 或装了它的 IDE)

GitHub: https://github.com/shofer-dev/claude-code-live-memory