为什么不要用prevalentware/opencode-goal-plugin1. 现象prevalentware/opencode-goal-plugin提供了类似 Claude Code 原生的/goal体验设定长期目标、自动续写、状态持久化使用起来确实方便。然而实际使用中发现一旦启用该插件缓存命中率几乎降为零每次请求输入 token 高达 1012 万输出仅数百 token连续请求成本稳定在 $0.05 左右。其功能虽好但成本完全失控。2. 原因分析该插件破坏缓存的原因在于其续写机制实现不当具体包括每次续写强制重新注入完整的会话上下文插件在自动续写时会重新构建请求导致系统提示词前缀发生变化使缓存无法命中。动态注入目标状态信息插件会持续更新目标状态、历史记录等动态内容这些内容写入系统块后使前缀哈希变化。可能触发进程重启部分实现方式可能导致每次opencode run或续写操作启动新进程使得OPENCODE_EXPERIMENTAL_CACHE_STABILIZATION冻结的日期失效。与 OpenCode 官方的系统提示拆分不兼容该插件可能绕过官方拆分机制将动态内容重新塞入稳定块使 S1 的缓存失效。3. 实测对比在相同 DeepSeek 模型、相同项目、相同任务下对比启用该插件前后的缓存命中率指标使用插件不使用插件原生-c首次请求缓存命中率0%97.6%平均输入 token / 请求12 万12 万但仅付读取价每次请求成本$0.05写入价$0.0125读取价一小时连续运行成本~$3.0~$0.75结果一目了然插件功能虽好但成本是原生方式的4 倍且实际任务推进效率并未提升输出 token 同样少。4. 为什么不修复该插件并非官方出品其设计目标优先于“易用性”而非“缓存友好”。作者可能未充分理解 OpenCode 缓存机制或未适配 #14743 的修复。即使后续更新当前版本仍存在此问题。5. 替代方案OpenCode 原生已提供足够的能力实现长期目标自动延续使用opencode run -c循环在脚本中每 N 秒执行一次opencode run -c Continue...完全无插件依赖缓存前缀稳定。使用opencode serveattach常驻进程方式缓存命中率最高99%且不会因进程重启破坏日期冻结。手动设置长期目标在会话开始输入清晰目标后续每隔一段时间发送“继续”同样有效。这些原生方式不仅成本可控而且配合环境变量后缓存命中率可达 97% 以上。6. 结论prevalentware/opencode-goal-plugin虽然功能强大、体验接近 Claude Code但其实现严重破坏缓存机制导致输入 token 成本急剧上升实际性价比极低。建议立即弃用转而使用 OpenCode 原生的-c或serve方式自动化延续任务。若仍需图形化目标状态可考虑其他轻量插件如oh-my-goal但务必先测试其缓存表现。一句话总结插件的便利性远不值它烧掉的成本。