[Feature]: Codex 套餐剩余时间是否改用 /backend-api/subscriptions 的 active_until？

[HuiCheng]

Affected Page / Module

Accounts page / Codex subscription remaining days (remainingDays / 套餐剩余时间)

Use Case

账号列表里 Codex 付费套餐的「剩余 N 天」依赖订阅到期时间。希望确认维护者是否考虑把 live 订阅有效期 的数据源，从当前的 wham/usage 改为（或兼用）ChatGPT 的 /backend-api/subscriptions（字段 active_until）。

Current Pain Point

当前解析路径（accountSubscriptionPresentation / fetchCodexQuotaSummary）大致是：

1. 优先 live：api-call → GET https://chatgpt.com/backend-api/wham/usage → subscription_active_until / subscriptionActiveUntil
2. 否则 fallback：解析凭证 id_token 里的 chatgpt_subscription_active_until（管理端常把 JWT 嵌套 claim https://api.openai.com/auth 拍平后返回）
3. 仅当 isPaidCodex && subscriptionUntilMs > now 时渲染「N 天」；过期或不存在则空白

实际观察：

• 多张 Codex 凭证上 wham/usage 可稳定返回 401 Unauthorized，live 路径形同失效
• 列表「N 天」实际几乎全靠 JWT claim fallback
• JWT 里的 chatgpt_subscription_active_until 可能与真实订阅不同步：token 换发（iat 更新）后 claim 仍可能停留在旧周期；而同一账号对 /backend-api/subscriptions 可返回更新的 active_until
• 结果：claim 已过期、subscriptions 仍有效时，列表空白，但运维侧用 subscriptions 能看到正确到期日

Expected Solution

请维护者评估是否采用（或混合）以下方案，并给出倾向。

方案 A（现状）：wham/usage + id_token claim

做法	live 用 wham/usage 的 subscription_active_until；失败则用 JWT chatgpt_subscription_active_until
优点	已实现；与配额刷新同链路；无额外 endpoint；改动面小
缺点	wham/usage 在部分部署上对 Codex OAuth 常 401，live 不可用；JWT claim 可能陈旧（换 token ≠ 更新 until）；过期 claim + 失败 live → 列表空白，易误判为「无套餐/已失效」；与运维侧常用的 subscriptions 真相源不一致

方案 B：/backend-api/subscriptions 的 active_until

做法	通过现有 api-call（或等价代理）请求 ChatGPT /backend-api/subscriptions，用响应 active_until 作为 live subscriptionUntilMs（可保留 JWT 作二次 fallback）
优点	与真实订阅状态对齐（含 scheduled_cancellation 等）；在 wham/usage 401 时仍可能拿到有效 until；减少「claim 过期但订阅仍在」导致的空白；和常见 Codex 账号池对账脚本同一数据源
缺点	需新增/确认 endpoint、鉴权头与错误处理；多一次上游请求（成本、限流、延迟）；响应字段/语义需与现有 subscriptionActiveUntil 映射并写测试；若 OpenAI 变更路径，维护成本高于沿用现有 usage 链路；是否与配额窗口逻辑耦合需设计清楚

可选折中

• B 优先，A 垫底：subscriptions → wham/usage → JWT claim
• 或仅在 wham 非 2xx / 无 subscription_active_until 时再打 subscriptions
• UX：until <= now 时显示「已过期」或绝对日期，避免空白（与数据源选择正交）

Relevant Data Dimensions

• Auth file
• Account
• Quota
• API Key / client
• AI provider
• Model
• Project
• Time range
• Cost
• Token / usage
• Failure reason / error type
• None of these

Expected Acceptance Result

维护者明确倾向其一（或折中），以便后续按社区规范向 dev 提实现 PR。若认可方案 B / 折中，希望约定：

1. live until 的权威字段与优先级
2. 失败时的 fallback 顺序
3. 过期时列表/详情的展示语义（空白 vs「已过期」）

Priority

Medium: clearly improves usability

Additional Context

相关前端逻辑大致在：

• apps/web/src/features/accounts/model/accountSubscriptionPresentation.ts（resolveCodexSubscriptionUntilMs / remainingDays）
• apps/web/src/utils/quota/providerRequests.ts（fetchCodexQuotaSummary → CODEX_USAGE_URL = .../wham/usage）
• apps/web/src/utils/quota/constants.ts

这是咨询向 issue，尚未实现 subscriptions 接入；先征求方案态度，避免直接改 live 源与上游意图不符。

Checklist

• I have searched existing Issues and did not find a duplicate request.

[seakee]

这个 Issue 是有价值的，方向也认可。

我们之前实际验证过 /backend-api/subscriptions 的返回。相比 JWT 里的 chatgpt_subscription_active_until，它更适合作为当前订阅状态的数据源；JWT 更接近 token 签发时的快照，续费后确实可能出现 active_until 不同步的问题。

我们的倾向是：

• wham/usage 继续负责 Codex 的 quota / reset / credits，不替换现有额度链路；
• /backend-api/subscriptions 独立负责套餐和订阅元数据；
• JWT 保留为最终 fallback；
• 对订阅有效期，可以按 subscriptions > wham > JWT 的优先级处理。

另外，如果继续推进这个功能，我们更希望不仅修复列表里的「剩余 N 天」，而是把它作为一个轻量的 Codex Subscription 能力来处理。

可以参考下面这个方向：

• 订阅数据和 quota 使用独立刷新周期，不跟随高频 quota refresh；
• 同一个 chatgpt_account_id 的订阅数据在列表和详情之间共享，避免重复请求和显示不一致；
• 仅对 非 Free 的 Codex 显示「套餐 / Subscription」详情 Tab，Free 和其他 Provider 不显示；
• 点击列表中的套餐列时，可以直接打开详情并定位到这个 Tab；
• 详情页以 plan_type、active_start、active_until、billing_period、will_renew 为核心；
• seats、is_delinquent、grace_period_end_timestamp、discount、credit grant 等字段根据实际返回和值的意义条件展示，不需要全部平铺；
• subscriptions 请求失败时不影响 quota，并继续 fallback 到 wham / JWT；
• 详情手动刷新后，列表中的套餐剩余时间应同步更新。

实现上暂时不需要扩展成完整 billing 系统，也不需要提前抽象成所有 Provider 通用的 Subscription Framework，先把 Paid Codex 这一条链路做好即可。

还有一个实现前置点需要确认：请先验证 /backend-api/subscriptions 通过当前 CPA /v0/management/api-call 转发时是否能稳定获取。如果这里涉及额外的 transport / TLS 兼容能力，更适合优先放到 CPA 上游处理。

如果你愿意继续推进，可以按这个方向向 dev 提 PR。具体实现不必完全照上面的结构，只要保持数据源、刷新生命周期、共享状态和 UI 边界一致即可。