[Bug]: 最新版本fast（priority）模式无法正常统计

[msm8976]

问题类型

用量 / 成本统计不准确

部署方式

Windows / 非 Docker

CPA 版本

v7.2.73

CPA Manager Plus 版本

v1.11.1

问题描述

请求监控页面 强度下方的等级 无论是否开fast模式都显示default

复现步骤

v7.2.73+v1.11.1版本 开fast请求 界面显示 default
不清楚真实的请求是否成功应用fast了，但是测了多个客户端以及不同的模型调用都只显示default
之前版本是可以正常显示的，不清楚是CPA问题还是CPAMP问题

关键配置

v7.2.73+v1.11.1版本 Windows本地部署

/status 返回内容

日志

截图

检查清单

• 我已经搜索过现有 Issues，没有找到重复问题
• 我已经确认敏感信息已经脱敏，例如 token、key、账号信息

[seakee]

感谢反馈，已经核对 CPA 和 CPAMP 的相关逻辑。

CPA 会分别上报：

• service_tier / request_service_tier：请求使用的等级，例如 priority
• response_service_tier：上游实际返回的处理等级

CPAMP v1.11.1 会优先展示 response_service_tier。因此可能出现请求为 priority，但页面显示 default 的情况。这不代表 CPA 一定没有发送 fast 请求，而是 Codex 上游最终返回的实际等级为
default。

CPA 上游也验证过该情况：请求传入 priority 可以正常返回 200，但响应中的 service_tier 仍可能是 default：
router-for-me/CLIProxyAPI#4275

所以当前统计逻辑符合“以实际上游响应等级为准”的设计，避免将未实际按 priority 处理的请求错误计费。不过目前页面只显示最终等级，确实容易被理解为请求没有启用 fast。

[HMBSbige]

这问题关键不是 CPA 是否发送了 priority，而是：ChatGPT-auth Codex 返回的 service_tier=default，是否能作为实际处理和计费层级。

OpenAI Codex 贡献者也说明，ChatGPT 登录态的 Fast 由服务端路由，最终响应为 default 不代表 Fast 未生效
openai/codex#14204 (comment)

建议区分公共 OpenAI API 与 Codex OAuth：保留并同时展示 requested/reported tier；对于 Codex OAuth，不要仅凭响应 default 按 Standard 估价

[HMBSbige]

@seakee 建议重开此 issue。

CLIProxyAPI 维护者已在 #4355 明确说明：对于 Codex OAuth，响应中的 service_tier=default/auto 不能用于判断 Fast 是否生效；Fast 由请求中的 priority/fast 决定，请求 tier 与响应 tier 分开保存是有意设计。

当前 CPAMP 对：

request_service_tier: priority
response_service_tier: default

仍优先采用响应 tier，导致页面显示为 default，并将 GPT‑5.6 Fast 从应有的 2× 错算为 1×。这已经不是上游 Fast 状态不明确的问题，而是 CPAMP 的计费 tier 来源选择问题。

建议：

• 同时保留并展示 requested / reported tier
• Codex OAuth 默认按 requested priority/fast 计费

PS: CLIProxyAPIHome 的 PR #40 已采用请求 tier 默认计费

[seakee]

已进一步核实，反馈成立，感谢补充上游维护者说明和参考实现。

对于 Codex OAuth，响应中的 service_tier=default/auto 不能用于判断 Fast 是否生效；计费应以请求侧的 priority/fast 为准，同时保留响应 tier 作为观测信息。此前 CPAMP 优先采用响应 tier，确实会导致 request_service_tier=priority、response_service_tier=default 的请求显示为 default，并按标准费率计算。

修复已提交至 PR #415：

• Codex 使用 requested tier 进行计费和聚合
• 其他提供商继续保持 response tier 优先，避免改变既有语义
• 监控同时展示 requested / reported tier
• 补充后端持久化、导入及前端计费回归测试

此处保持 issue 当前状态，不重新打开；后续进展请关注 PR #415。