【免费下载链接】opencodexUniversal provider proxy for OpenAI Codex Claude Code — use any LLM (Claude, Gemini, Grok, DeepSeek, Ollama…) with Codex CLI, App, SDK, and Claude Code项目地址https://gitcode.com/gh_mirrors/ope/opencodex点击查看免费下载本文档基于 opencodex 项目中 devlog 调查单元 132_research_cursor_usage.md 整理该单元以 Einsteinsol high cxc-search 子代理线程对 Cursor 流式协议的 usage/缓存上报能力做了 Tier 2 原文级验证基于 jthweny/Cursor_Deobfuscation 提取 schema 与官方 Admin API 文档。结论是Cursor 流式通道在原理上不提供缓存数值opencodex 采用 estimated 标记 请求侧估算 显式『缓存未报告』标注 的组合方案保证日志与用量统计的诚实性并将usage_uuid事后查询列为可选的下一单元工作。一、调查背景Claude 入站路径上的 usage/缓存不透明问题在 130_desktop_effort_usage_cache.md 记录的用户实时日志2026-07-12 00:35~00:46中出现了两类问题usage/缓存不透明Claude 表面luna 等请求的日志中完全没有缓存 token累计合计输入缓存显示为空。且这一现象并非 Cursor 专属——native/openai 路径同样出现c 0缓存 0。推理强度effortClaude Desktop 3P 中路由模型的 effort 变更似乎未生效该问题由 131_research_desktop_effort_wire.md 单独调查。其中 cursorluna行的典型形态为cachedIn/read/write None全空无上下文检查点的轮次则显示in: 0, out: 7~211。对照同一时刻 codex 表面 sol 行9.5万 c 9.4万缓存正常差异点被锁定在Claude 入站inbound这一面。132_research_cursor_usage.md正是针对 Cursor 流中到底有没有可信的 usage/缓存帧 这一 H3 假设的专项调查。二、调查结论StreamUnifiedChatWithTools 流中不存在完整 usage 帧调查的核心判定原文级验证是StreamUnifiedChatWithTools流不携带完整的 usage 帧。整个流式响应中与用量相关的字段仅有以下三个字段位置/编号语义可用性评估usage_uuidStreamUnifiedChatResponsefield 27事后查询post-hoc lookup用的用量记录键可作为 GetTokenUsage 的入参但流本身不解析出任何数字context_window_statusStreamUnifiedChatResponsefield 30ContextWindowStatus.tokens_used 激活上下文active context的当前占用规模唯一可靠的数值来源但语义是checkpoint/占用量debugging_only_token_countfield 3调试用 token 计数语义无保证meaning not guaranteed不可作为用量依据需要特别强调的是context_window_status的语义陷阱适配器以 checkpoint 方式读取到的tokens_used并非 per-turn 的用量合计而是激活上下文的占用规模。因此现行 opencodex 在 bridge/internal.ts 中使用的in context - out估算公式其有效性是有边界的——它只在context 占用能近似反映该轮输入这一前提下成立这一点在调查文档中被明确标注为现行in context - out估计在该限制内是合理的현행in context - out추정은 그 한계 안에서 타당。三、缓存数字为什么拿不到两套查询接口的鸿沟调查进一步验证了缓存cache read/write数值的获取路径事后查询接口DashboardService/GetTokenUsage(usage_uuid)仅返回input/output两项不含任何缓存维度。缓存数值唯一存在的地方是 usage-event 查询GetFilteredUsageEvents/GetAggregatedUsageEvents属于官方 Team Admin API——但公开 schema 中没有可供 usage_uuid 与这些 usage-event 做 join 的手段usage_uuid로 join할 수단이 공개 스키마엔 없다。也就是说即使拿到usage_uuid也无法把它对应回缓存事件明细。这一结构性缺口直接宣告仅凭流式通道缓存数值在原理上不可得스트림만으로 캐시 수치는 원리적으로 불가。横向对照其他 Cursor 代理项目同样受限调查还做了同类项目横向验证结论是其他代理同样没有绕过这一限制wisdgod/cursor-api将 usage variant 部分注释掉无法支撑auth2api直接以0标注缓存。这从侧面印证了Cursor 协议本身未提供缓存帧是普遍性的协议级限制而非 opencodex 适配器实现缺失。四、opencodex 的落地处理诚实标注优先于虚构数字基于上述结论opencodex 采用的处理策略是缓存未报告provider 未提供显式标注在 Cursor 面含 Claude inbound 路由到 cursor 适配器的路径的日志中缓存字段不再是空白或 0而是明确显示未报告。GUI 侧对应的 i18n 文案gui/src/i18n/ko.ts / zh 等为Cursor 缓存详情未报告 / Cursor 协议不提供缓存 read/write token 数值这不代表缓存未命中。estimated 标记 请求侧估算校正由于 per-turn input 也没有可信来源opencodex 对 Cursor及同类的 Kiro适配器统一施加estimated标记并用请求侧estimateTokens估算值填充 input 列——这是正攻정공即在不虚构权威数值的前提下给出可参考的近似值。源码级实现佐证估算与标记逻辑的实现分布在以下位置src/usage/log.tsisEstimatedUsageProvider以适配器前缀匹配cursor/kiro含cursor-、kiro-命名变体usageForFinalLog在这些 provider 上强制追加estimated: trueusageStatusForFinalLog据此输出estimated而非reported状态。注释明确说明Kiro 与 Cursor 之所以被标记为 estimated是因为其适配器只能猜测真实推理的用量their adapters can only guess a real inferences usage同时locallyAnswered本地应答、未发出上游请求的轮次视为精确 0不适用 estimated 标记避免无推理轮被误判为用量帧丢失。src/usage/log.tsnormalizeUsageValue会保留contextTotalTokens字段其注释解释了语义——这是绝对激活上下文 checkpoint是有状态 providerKiro/Cursor唯一的累计上下文载体且刻意不并入 totalTokens因为 checkpoint 不是单请求合计跨请求求和会产生错误。src/adapters/cursor/protobuf-request.tsprepareCursorRunRequest在estimateInputTokens选项开启时用与最终序列化完全相同的实例rootPromptMessagesState.serialized、actionText、mcpToolDefs经modelVisibleToolText转换拼装modelVisibleParts后调用estimateTokens(...)。注释专门指出必须使用产出bytes的同一批实例否则估算会漏计被丢弃的历史/工具导致计数缺陷the defect that blocked PR #376。src/adapters/cursor/checkpoint-store.tscursorCheckpointShape对 checkpoint 只做计数turns / rootPromptMessages / todos / pendingToolCalls注释明确Counts only — never content绝不把readPaths、previousWorkspaceUris等用户路径/工作区标识读为值——这是隐私与诊断边界的设计约束。usage 状态机src/usage/log.ts 定义了四种 UsageStatusreported精确报告、unreported未报告、unsupported不支持、estimated估算。Cursor 路由的轮次最终落入estimated缓存字段落入显式未报告文案两条路径互不冲突。五、后续方向明确 OUT 的下一单元工作调查文档同时记下了可选的演进方向但明确排除在本轮范围之外解析usage_uuid并调用GetTokenUsage事后查询可以将 input/output 从估算升级为精确值但由于认证方式与调用时序均未确定인증/타이밍 미확정该工作被划入下一单元本轮不做任何代码承诺。这与 130_desktop_effort_usage_cache.md 中的范围声明一致OUT: ... cursor 协议新字段添加需 Einstein 调查结果支撑才能 IN——如今 Einstein 已给出否定结论因此协议层不做改动维持估算显式标注的组合。六、总结本次调查132 单元回答了一个关键问题Cursor 流的 usage 与缓存为何在日志中缺位。答案不是适配器实现缺陷而是协议结构性限制流中没有完整 usage 帧、缓存数值只存在于无法与usage_uuidjoin 的 Team Admin usage-event 接口中。opencodex 的应对是工程上最诚实的方案——用estimated状态 estimateTokens请求侧估算补齐 input 参考值用缓存未报告文案替代空白与伪 0并将usage_uuid精确化列为有明确前置条件的后续工作。这一处理贯穿 src/usage/log.ts、src/adapters/cursor/checkpoint-store.ts 与 GUI i18n 三层实现保证任何一位查看日志的用户都能区分精确值与估算值而不会被缺失的缓存数字误导。赞分享【免费下载链接】opencodexUniversal provider proxy for OpenAI Codex Claude Code — use any LLM (Claude, Gemini, Grok, DeepSeek, Ollama…) with Codex CLI, App, SDK, and Claude Code项目地址https://gitcode.com/gh_mirrors/ope/opencodex点击查看免费下载相关推荐Nativefier协议处理性能优化缓存与批处理Nativefier协议处理性能优化缓存与批处理 你是否遇到过这样的情况使用Nativefier将网页打包成桌面应用后频繁的网络请求导致应用响应缓慢甚至CLI桌面应用开发工具opencodex 流式适配器 Usage 保留实战Combined UsageChoice 块与 EOF 无 [DONE] 终端的修复方案opencodex 流式适配器 Usage 保留实战Combined UsageChoice 块与 EOF 无 DONE 终端的修复方案 导读 本篇文章聚焦opencodex 原生对齐之 Thinking 与 Usage双推理通道与用量细节透传实现指南opencodex 原生对齐之 Thinking 与 Usage双推理通道与用量细节透传实现指南 opencodex 作为 OpenAI Codex Cl创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 opencodex 对 Cursor 流式协议 usage/缓存报告的调查结论与透明化处理方案
【免费下载链接】opencodexUniversal provider proxy for OpenAI Codex Claude Code — use any LLM (Claude, Gemini, Grok, DeepSeek, Ollama…) with Codex CLI, App, SDK, and Claude Code项目地址https://gitcode.com/gh_mirrors/ope/opencodex点击查看免费下载本文档基于 opencodex 项目中 devlog 调查单元 132_research_cursor_usage.md 整理该单元以 Einsteinsol high cxc-search 子代理线程对 Cursor 流式协议的 usage/缓存上报能力做了 Tier 2 原文级验证基于 jthweny/Cursor_Deobfuscation 提取 schema 与官方 Admin API 文档。结论是Cursor 流式通道在原理上不提供缓存数值opencodex 采用 estimated 标记 请求侧估算 显式『缓存未报告』标注 的组合方案保证日志与用量统计的诚实性并将usage_uuid事后查询列为可选的下一单元工作。一、调查背景Claude 入站路径上的 usage/缓存不透明问题在 130_desktop_effort_usage_cache.md 记录的用户实时日志2026-07-12 00:35~00:46中出现了两类问题usage/缓存不透明Claude 表面luna 等请求的日志中完全没有缓存 token累计合计输入缓存显示为空。且这一现象并非 Cursor 专属——native/openai 路径同样出现c 0缓存 0。推理强度effortClaude Desktop 3P 中路由模型的 effort 变更似乎未生效该问题由 131_research_desktop_effort_wire.md 单独调查。其中 cursorluna行的典型形态为cachedIn/read/write None全空无上下文检查点的轮次则显示in: 0, out: 7~211。对照同一时刻 codex 表面 sol 行9.5万 c 9.4万缓存正常差异点被锁定在Claude 入站inbound这一面。132_research_cursor_usage.md正是针对 Cursor 流中到底有没有可信的 usage/缓存帧 这一 H3 假设的专项调查。二、调查结论StreamUnifiedChatWithTools 流中不存在完整 usage 帧调查的核心判定原文级验证是StreamUnifiedChatWithTools流不携带完整的 usage 帧。整个流式响应中与用量相关的字段仅有以下三个字段位置/编号语义可用性评估usage_uuidStreamUnifiedChatResponsefield 27事后查询post-hoc lookup用的用量记录键可作为 GetTokenUsage 的入参但流本身不解析出任何数字context_window_statusStreamUnifiedChatResponsefield 30ContextWindowStatus.tokens_used 激活上下文active context的当前占用规模唯一可靠的数值来源但语义是checkpoint/占用量debugging_only_token_countfield 3调试用 token 计数语义无保证meaning not guaranteed不可作为用量依据需要特别强调的是context_window_status的语义陷阱适配器以 checkpoint 方式读取到的tokens_used并非 per-turn 的用量合计而是激活上下文的占用规模。因此现行 opencodex 在 bridge/internal.ts 中使用的in context - out估算公式其有效性是有边界的——它只在context 占用能近似反映该轮输入这一前提下成立这一点在调查文档中被明确标注为现行in context - out估计在该限制内是合理的현행in context - out추정은 그 한계 안에서 타당。三、缓存数字为什么拿不到两套查询接口的鸿沟调查进一步验证了缓存cache read/write数值的获取路径事后查询接口DashboardService/GetTokenUsage(usage_uuid)仅返回input/output两项不含任何缓存维度。缓存数值唯一存在的地方是 usage-event 查询GetFilteredUsageEvents/GetAggregatedUsageEvents属于官方 Team Admin API——但公开 schema 中没有可供 usage_uuid 与这些 usage-event 做 join 的手段usage_uuid로 join할 수단이 공개 스키마엔 없다。也就是说即使拿到usage_uuid也无法把它对应回缓存事件明细。这一结构性缺口直接宣告仅凭流式通道缓存数值在原理上不可得스트림만으로 캐시 수치는 원리적으로 불가。横向对照其他 Cursor 代理项目同样受限调查还做了同类项目横向验证结论是其他代理同样没有绕过这一限制wisdgod/cursor-api将 usage variant 部分注释掉无法支撑auth2api直接以0标注缓存。这从侧面印证了Cursor 协议本身未提供缓存帧是普遍性的协议级限制而非 opencodex 适配器实现缺失。四、opencodex 的落地处理诚实标注优先于虚构数字基于上述结论opencodex 采用的处理策略是缓存未报告provider 未提供显式标注在 Cursor 面含 Claude inbound 路由到 cursor 适配器的路径的日志中缓存字段不再是空白或 0而是明确显示未报告。GUI 侧对应的 i18n 文案gui/src/i18n/ko.ts / zh 等为Cursor 缓存详情未报告 / Cursor 协议不提供缓存 read/write token 数值这不代表缓存未命中。estimated 标记 请求侧估算校正由于 per-turn input 也没有可信来源opencodex 对 Cursor及同类的 Kiro适配器统一施加estimated标记并用请求侧estimateTokens估算值填充 input 列——这是正攻정공即在不虚构权威数值的前提下给出可参考的近似值。源码级实现佐证估算与标记逻辑的实现分布在以下位置src/usage/log.tsisEstimatedUsageProvider以适配器前缀匹配cursor/kiro含cursor-、kiro-命名变体usageForFinalLog在这些 provider 上强制追加estimated: trueusageStatusForFinalLog据此输出estimated而非reported状态。注释明确说明Kiro 与 Cursor 之所以被标记为 estimated是因为其适配器只能猜测真实推理的用量their adapters can only guess a real inferences usage同时locallyAnswered本地应答、未发出上游请求的轮次视为精确 0不适用 estimated 标记避免无推理轮被误判为用量帧丢失。src/usage/log.tsnormalizeUsageValue会保留contextTotalTokens字段其注释解释了语义——这是绝对激活上下文 checkpoint是有状态 providerKiro/Cursor唯一的累计上下文载体且刻意不并入 totalTokens因为 checkpoint 不是单请求合计跨请求求和会产生错误。src/adapters/cursor/protobuf-request.tsprepareCursorRunRequest在estimateInputTokens选项开启时用与最终序列化完全相同的实例rootPromptMessagesState.serialized、actionText、mcpToolDefs经modelVisibleToolText转换拼装modelVisibleParts后调用estimateTokens(...)。注释专门指出必须使用产出bytes的同一批实例否则估算会漏计被丢弃的历史/工具导致计数缺陷the defect that blocked PR #376。src/adapters/cursor/checkpoint-store.tscursorCheckpointShape对 checkpoint 只做计数turns / rootPromptMessages / todos / pendingToolCalls注释明确Counts only — never content绝不把readPaths、previousWorkspaceUris等用户路径/工作区标识读为值——这是隐私与诊断边界的设计约束。usage 状态机src/usage/log.ts 定义了四种 UsageStatusreported精确报告、unreported未报告、unsupported不支持、estimated估算。Cursor 路由的轮次最终落入estimated缓存字段落入显式未报告文案两条路径互不冲突。五、后续方向明确 OUT 的下一单元工作调查文档同时记下了可选的演进方向但明确排除在本轮范围之外解析usage_uuid并调用GetTokenUsage事后查询可以将 input/output 从估算升级为精确值但由于认证方式与调用时序均未确定인증/타이밍 미확정该工作被划入下一单元本轮不做任何代码承诺。这与 130_desktop_effort_usage_cache.md 中的范围声明一致OUT: ... cursor 协议新字段添加需 Einstein 调查结果支撑才能 IN——如今 Einstein 已给出否定结论因此协议层不做改动维持估算显式标注的组合。六、总结本次调查132 单元回答了一个关键问题Cursor 流的 usage 与缓存为何在日志中缺位。答案不是适配器实现缺陷而是协议结构性限制流中没有完整 usage 帧、缓存数值只存在于无法与usage_uuidjoin 的 Team Admin usage-event 接口中。opencodex 的应对是工程上最诚实的方案——用estimated状态 estimateTokens请求侧估算补齐 input 参考值用缓存未报告文案替代空白与伪 0并将usage_uuid精确化列为有明确前置条件的后续工作。这一处理贯穿 src/usage/log.ts、src/adapters/cursor/checkpoint-store.ts 与 GUI i18n 三层实现保证任何一位查看日志的用户都能区分精确值与估算值而不会被缺失的缓存数字误导。赞分享【免费下载链接】opencodexUniversal provider proxy for OpenAI Codex Claude Code — use any LLM (Claude, Gemini, Grok, DeepSeek, Ollama…) with Codex CLI, App, SDK, and Claude Code项目地址https://gitcode.com/gh_mirrors/ope/opencodex点击查看免费下载相关推荐Nativefier协议处理性能优化缓存与批处理Nativefier协议处理性能优化缓存与批处理 你是否遇到过这样的情况使用Nativefier将网页打包成桌面应用后频繁的网络请求导致应用响应缓慢甚至CLI桌面应用开发工具opencodex 流式适配器 Usage 保留实战Combined UsageChoice 块与 EOF 无 [DONE] 终端的修复方案opencodex 流式适配器 Usage 保留实战Combined UsageChoice 块与 EOF 无 DONE 终端的修复方案 导读 本篇文章聚焦opencodex 原生对齐之 Thinking 与 Usage双推理通道与用量细节透传实现指南opencodex 原生对齐之 Thinking 与 Usage双推理通道与用量细节透传实现指南 opencodex 作为 OpenAI Codex Cl创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考