- OpenProxy（171K 行 Rust）：在本地对请求做 RTK 实时压缩（重编码表格、注入极简输出指令），声称省 20%-40% Token——但它的代价是修改 Prompt 字节，会击穿模型厂商的 Prompt Cache，在长会话场景下存在"越压越贵"的风险（机制推导，非实测结论）。
- VMR（31K 行 Go）：一个字都不改，用 Session-Sticky 把整个会话钉死在同一个上游端点，让 80%-95% 的重复输入稳定命中缓存价（1-2 折），实测综合降本 50%-70%（自观测数据）。
- 选型速判：多轮长会话为主的 Agent 工作流（Claude Code / OpenClaw / Cursor 重度使用）→ 缓存亲和路线优先；大量一次性短请求 + 需要订阅账号逆向/可视化控制台 → OpenProxy 的功能面更全。
一、背景共识：都在解决同一个痛点
2026 年，模型厂商全面转向按量计费（Token Plan）之后，"多轮 Agent 会话的账单失控"成了所有重度用户的共同痛点。一个 30 轮的长会话，输入里可能 90% 以上都是前几轮已经算过的重复内容——怎么让这部分不花冤枉钱，是两条路线共同的目标。
但"省钱"这个词下面，藏着两种完全相反的工程假设。
二、核心分歧：本地压缩 vs 上游缓存
OpenProxy 的路线：RTK 实时压缩（假定上游"无状态"）
OpenProxy 的假设是：上游每次都是全价计费，所以我应该在本地把 token 变少。它的 src/core/rtk/ 实现了：
- TOON / GCF 算法：把请求里的 CSV、JSON 数组重编码成紧凑文本格式，减少 token 数；
- Caveman 提示词注入：强制模型以极简短促风格输出，少说废话；
- Tool Schema 裁剪：删掉本次没用的工具定义。
这一套在"单轮、短上下文、纯文本"场景下确实有效，这也是它声称省 20%-40% 的依据。
VMR 的路线：Cache 亲和保护（洞察上游"有状态"）
VMR 的假设相反：现代模型 90% 的成本由 Prompt Cache 决定，上游对重复前缀只收 1-2 折。所以正确的做法不是让内容变短，而是：
- 保持字节绝对不变（Byte-Faithful）——前缀哈希一丁点都不能动，动了缓存就归零；
- 会话级锁定端点（Session-Sticky）——同一个会话的所有轮次永远发给同一个上游端点，因为缓存按端点隔离，切一次账号缓存清零一次；
- 结果：命中率 80%-95% 时，账单大头自动变成缓存价。
为什么这两条路线会正面冲突
关键矛盾在这里：RTK 压缩的每一次"帮忙"，都在破坏缓存的前提。它动态重编码表格、注入 Caveman 指令、裁剪 Tool Schema——每一次改动都让输入前缀的哈希发生变化，供应商的缓存从第 0 个 token 起全部失配。
在"压缩省下的 token"和"缓存归零导致的全价重算"之间，长会话场景下后者通常是数量级的差距：压缩最多省 40%，而缓存失效意味着每一轮都要为前几十轮的内容再付一次全价。
一句话：OpenProxy 在"怎么让每轮更小"上下功夫，VMR 在"怎么让重复内容打折"上下功夫。 在缓存已成为行业标配的今天，后者的杠杆更大。
三、数据对比（带测量条件）
| 维度 | OpenProxy (RTK) | VMR (Session-Sticky) | 说明 |
|---|---|---|---|
| 降本机制 | 本地压缩，声称省 20%-40% | 缓存命中，实测降 50%-70% | OpenProxy 为官方声称值；VMR 为自观测（长会话压测，150 req/s），未第三方公证 |
| 缓存命中率 | 会被主动破坏（机制推导） | 80%-95%（以供应商 cache 计费字段为准） | OpenProxy 无公开命中率数据，此处为机制分析 |
| 长会话场景风险 | 存在"越压越贵"风险 | 稳定吃缓存价 | 风险结论为机制推导，非 OpenProxy 实测故障数据 |
| 代码规模 | 171,412 行 Rust，50+ crates | ~31,000 行 Go，4 个依赖 | 复杂度与维护成本差距显著 |
| 常驻内存 | 80-200MB（含 SQLite + Web UI） | 15-30MB | 个人本机场景差异可感知 |
四、双方优势与适用边界（互相承认）
公平地说，OpenProxy 是一把功能更全的瑞士军刀，很多能力 VMR 明确不做：
OpenProxy 明显更优的场景：
- 订阅账号逆向与轮询：内置 8+ 平台 OAuth 逆向（ChatGPT / Codex / Gemini 订阅等），能把多个订阅账号池化成 API——这是 VMR 完全没有的能力（VMR 只做标准 API Key / BaseURL）；
- 可视化控制台：内置 Astro Web UI，开箱即用的图表、会话监控——VMR 坚持零 UI，只有 CLI 与 Markdown 输出；
- 高级调度模式：Hedging（对冲请求，谁快用谁）、Fusion（多模型投票融合）——在"极端网络波动下的响应速度"和"多模型共识"场景有价值；
- 多模态与 MCP 扩展：内置 TTS/STT/Image 接口与 MCP Server Bridge。
VMR 明显更优的场景：
- 长会话成本控制：缓存亲和保护，稳定 50%-70% 降本；
- 字节保真与工具调用稳定性：不转译协议、不改 Payload——复杂 Tool Call Schema 在中间层转译下容易出边界 bug（OpenProxy 6.8 万行转译逻辑存在此风险，长期故障率需实测佐证）；
- 法医取证：
vmr replay一键重放、vmr story -compare跨运行分歧定位——OpenProxy 只有传统 Metrics 仪表盘，无法做上下文丢失推导； - 极简运维：单二进制、零数据库、零 Web UI，攻击面与出 bug 概率都小一个量级。
五、选型决策树
你的 Agent 工作流以什么为主？
│
├─ 多轮长会话为主（Claude Code / OpenClaw 重度、长上下文迭代）
│ ├─ 需要"省钱 + 稳定 + 出事了能查" → VMR（缓存亲和路线）
│ └─ 需要同时管一堆订阅账号（ChatGPT/Codex 逆向池化）→ OpenProxy（但注意
│ 关闭或谨慎使用 RTK 压缩，避免击穿缓存；或两者叠加：OpenProxy 管账号，
│ VMR 类路由管缓存亲和）
│
├─ 一次性短请求为主（批量调用、单轮问答）
│ ├─ 追求功能面与可视化 → OpenProxy
│ └─ 追求极简与低资源 → VMR
│
└─ 混合场景
└─ 推荐"功能层 + 网络层"分层：OpenProxy 负责账号/功能扩展，VMR 负责
字节保真转发与缓存锁定（两者定位不冲突，反而互补）
