RunInfra 不是又一个编程 Agent，而是把你在用的 Agent 接到另一组模型上的那根管子。发布页列了六个客户端——Claude Code、Codex、OpenCode、Cline、Droid、Grok Build——和三个开源模型——GLM 5.3、DeepSeek V4.1 Flash、Qwen3.8 27B，每月 10 美元起，宣称缓存命中最高 99.5%、零数据保留。
关键事实
| 项目 | 内容 |
|---|---|
| 回答的问题 | RunInfra 是什么：让编程 Agent 换成开源模型 |
| 简答 | RunInfra 把 Claude Code、Codex、OpenCode、Cline、Droid、Grok Build 接到 GLM 5.3、DeepSeek V4.1 Flash、Qwen3.8 27B 等开源模型，每月 10 美元起，宣称缓存命中最高 99.5%、零数据保留。 |
| 阅读时长 | ~3 分钟 |
| 最后更新 | 2026-10-21 |
这个定位比再套一层聊天界面有意思，因为它动的是 Agent 栈里真正花钱的地方：循环里的那一次模型调用。
它到底做了什么
编程 Agent 本质是客户端：读仓库拼提示词、发给模型端点、按返回结果行动。多数客户端默认绑定一家厂商，部分允许你改成兼容 API。
RunInfra 就坐在这个接缝上：接住客户端的请求，用开源权重模型来应答，兼容层和计费由它处理。卖点很直接——客户端不变、模型更便宜、工作流不用重搭。
承诺清单足够具体，可以验证：三个模型、六个客户端、一个起步价、一个缓存指标。没公布的是各模型的上下文窗口、速率限制，以及哪些客户端是完整兼容、哪些只是部分兼容。
缓存命中为什么比单价重要
Agent 循环天生重复：每一轮都重发系统提示、工具定义，常常还有同一批文件内容。提示缓存就是为这段重复前缀准备的——服务方认得出来，计费方式和返回速度都不一样。
如果 99.5% 的命中率在你的负载上成立，它比每 token 降价更能改变成本结构，也更影响延迟，而延迟决定一个 Agent 用起来顺不顺。
问题是缓存行为由负载形状决定：长而稳定的前缀容易命中，反复重写的上下文一定 miss。第一周先量自己的命中率，别信发布页的数字。
切换前要确认什么
兼容深度。 「支持 Codex」可能只是说接口格式一致，也可能意味着工具调用、流式输出、图片输入、缓存全部一致。要测你真正用到的功能，尤其是工具调用——一个工具调用不稳的编程 Agent，比一个慢一点但可靠的更糟。
各模型的上下文窗口。 列出的三个模型不一定同样大。长仓库任务在窗口缩小时失败方式很隐蔽：Agent 悄悄丢文件，或者开始改错地方。
保留范围。 零数据保留说的是服务方怎么处理请求，不覆盖客户端本地日志、shell 历史，也不覆盖 Agent 发往别处的遥测。仓库敏感就逐层确认。
失败行为。 路由到的模型出问题时，客户端是优雅降级还是死循环？把真实仓库接上去之前，先设消费上限和重试上限。
对桌面 Agent 用户意味着什么
同样的路由问题正在桌面端出现。操作应用的 Agent 需要能规划、能读屏、能输出结构化动作的模型；最便宜的聊天模型通常不胜任，最贵的又常常没必要。
能按任务切换后端——规划用强模型、重复点击用快模型——才是「模型路由」的实用版本。不管这能力来自 RunInfra 这类路由层，还是 Agent 自己的设置，能换后端而不换工作流，才是关键。
MOOGH 是跑在 Windows 本机上的桌面 Agent；想补上桌面这一半，可以下载 MOOGH，编程客户端保持你习惯的那个，模型单独路由。
结论
RunInfra 瞄准的是真实的成本问题，发布页的承诺也具体到可以测，而不是只能信。风险是路由层的常见风险：兼容性边角、只在压力下才暴露的限制，以及需要你亲自读范围的保留承诺。
拿一个副项目、用你现有的客户端试。量三个数：缓存命中率、工具调用可靠性、每个完成任务的成本。三个都优于现在的方案，10 美元起步价很好接受；不然，单价从来不是重点。
相关阅读：