你大概想不到，一个"轻量使用"的AI编程助手，能在30天内悄悄吞掉2.4GB硬盘空间——而且永远不会自动清理。

这不是某个边缘案例。一位开发者在清理VPS时发现，OpenCode的会话数据库膨胀到了惊人的体积。更讽刺的是，真正有价值的对话文本只占不到1%，其余全是AI的"内心独白"：推理过程、工具调用结果、中间思考痕迹。

打开网易新闻 查看精彩图片

对比之下，Claude Code同期仅占用86MB，Codex约95MB。OpenCode的存储策略，似乎把"记住一切"当成了默认信条。

问题根源：SQLite里的数字囤积症

开发者用工具分析后发现，OpenCode把所有内容塞进单个SQLite数据库。每次对话回合，AI的完整思维链（思维链指模型逐步推理的中间步骤）和工具执行结果都被原封不动保留。

这种设计有个好处：你可以随时回溯AI"当时怎么想的"。但当809个会话累积到1.8GB垃圾数据时，便利性变成了负担。

更棘手的是，OpenCode没有内置清理机制。数据库会像滚雪球一样无限增长，直到某天你的服务器报警。

自救方案：一个第三方清理工具的诞生

开发者最终用Claude Code写了个小工具ocgc（OpenCode Garbage Collector），核心功能简单粗暴：

• ocgc status：查看空间都去哪了

• ocgc analyze：定位最臃肿的会话和增长趋势

• ocgc purge --subagents --older-than 7d：按条件批量删除

• ocgc vacuum：真正回收磁盘空间

执行效果立竿见影：809个会话、1.8GB数据被清除，数据库从2.3GB压缩到438MB。开发者还顺手清理了snapshot/和session_diff/目录的隐藏占用。

产品反思：便利性的隐性成本

这件事暴露了一个常见的产品盲区——开发者工具在追求"全能记录"时，往往把存储成本转嫁给用户。AI编程助手的核心价值是提升编码效率，但未经控制的日志膨胀反而成了运维负担。

Claude Code和Codex的克制设计（80-90MB级别）证明，精简存储并不牺牲核心体验。OpenCode的2.4GB则像一面镜子，照出"功能堆砌"与"用户真实需求"之间的落差。

值得玩味的是，这位开发者用Claude Code写出了清理OpenCode的工具。某种程度上，这是两种产品哲学的碰撞：一个帮你解决问题，一个帮你解决它制造的问题。

如果你也在用OpenCode，现在就去检查~/.local/share/opencode/opencode.db。硬盘空间不会自己长出来，但AI的日志会。