fix(usage): bill Codex Fast from requested tier

[seakee]

Summary

Fix Codex Fast usage pricing when CPA records a requested priority tier but reports default in the upstream response. Requested and reported tiers remain separately available for diagnosis.

Scope

• Frontend panel
• Manager Server
• CPA panel mode
• Full Docker mode
• Native packages / release
• Docs / Wiki
• CI / build / tooling

Changes

• Use the requested service tier for Codex billing and aggregation while retaining response-tier precedence for other providers.
• Preserve and display both requested and reported tiers, including legacy Codex identity metadata.
• Add backend persistence/import tests and frontend pricing/presentation tests.

User Impact

Codex OAuth requests made with priority or Fast mode are priced with the expected multiplier even when the response reports default. Realtime monitoring shows both requested and reported tiers.

Compatibility / Runtime Notes

• CPA panel mode: Frontend fallback pricing recognizes Codex executor, provider, and legacy auth type metadata.
• Manager Server mode: New Codex usage events aggregate by the requested tier while retaining the reported tier.
• Full Docker / native packages: Same Manager Server and embedded panel behavior; no configuration changes.

Data / Security Notes

No schema or sensitive-data changes. Existing requested and reported tier fields remain separate. Historical pre-aggregated rows are not automatically repriced.

Risk / Rollback

Risk level: Low

Rollback notes: Revert the two commits to restore response-tier precedence and the previous single-tier presentation.

Verification

• Type check
• Lint
• Tests
• Build
• Manual UI check
• Docs/link check
• Not applicable, docs-only

Commands / evidence:

npm run type-check
npm run lint
npm run test                 # 108 files, 997 tests
npm run manager-server:test # go test ./...
git diff --check

Build was not rerun because this change does not alter bundling or asset behavior.

Screenshots / Recordings

Not captured. The visible change is limited to requested/reported tier labels and is covered by the realtime panel render test.

Docs

• README / README_CN updated for user-visible capabilities
• Matching docs manual and navigation updated
• Demo fixtures, screenshots, and deep links reviewed
• Release notes needed
• Not needed — explanation included below

Docs decision: This corrects existing monitoring and billing semantics without adding configuration or a new workflow.

Related

Refs #372
Refs router-for-me/CLIProxyAPI#4486.

[HMBSbige]

@seakee
似乎没有覆盖 payload.override 的场景：客户端原始请求未传 service_tier，由 CLIProxyAPI 覆盖为 priority 后，CPAMP 仍显示 auto 并按 1× 计费
看起来当前逻辑使用的仍是 override 前的请求 tier，而不是最终生效的 tier

[seakee]

@seakee 似乎没有覆盖 payload.override 的场景：客户端原始请求未传 service_tier，由 CLIProxyAPI 覆盖为 priority 后，CPAMP 仍显示 auto 并按 1× 计费 看起来当前逻辑使用的仍是 override 前的请求 tier，而不是最终生效的 tier

这个问题之前考虑过，但当前 CPAMP 无法仅从使用数据中获取 payload.override 后的最终 tier。

以下两种请求会产生完全相同的使用数据：

• 客户端未传 tier，且没有 override：service_tier=auto、response_service_tier=default
• 客户端未传 tier，override 为 priority：仍是 service_tier=auto、response_service_tier=default

Codex 即使实际发送 priority，响应也可能报告 default，因此响应字段也不能作为可靠依据。

要彻底解决，必须由 CLIProxyAPI 在应用 override 后，从最终出站请求中提取 tier，并在使用数据中增加例如：

{
"service_tier": "auto",
"effective_service_tier": "priority",
"response_service_tier": "default"
}

CPAMP读取 CPA 配置并自行复算理论上可尝试，但规则可能依赖请求头、协议、原始 payload 和匹配顺序，无法保证准确，不建议作为计费依据。所以根源生还是需要 CPA 去做的，根据以往我给 CPA 提 PR 好久都不会看的经验，建议你直接去 CPA 那边提 issue，这样就有可能会得到解决。