ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

如何精准检测Codex订阅状态:codex-console多源解析与Rate Limit窗口识别原理

如何精准检测Codex订阅状态:codex-console多源解析与Rate Limit窗口识别原理 如何精准检测Codex订阅状态codex-console多源解析与Rate Limit窗口识别原理【免费下载链接】codex-consolecodex-console 是一个集成化控制台项目支持任务管理、批量处理、数据导出、自动上传、日志查看与打包支持。项目地址: https://gitcode.com/gh_mirrors/co/codex-consolecodex-console 是一个面向 Codex 账号的集成化控制台它通过多源解析 Rate Limit 窗口识别双引擎精准检测 Codex 订阅状态Plus / Team / Basic与 5 小时、周配额额度还能在代理异常、接口抖动时自动降级避免误判。本文将拆解它的订阅状态检测原理。一、为什么单接口检测不够可靠OpenAI 的订阅与配额信息分散在多个后端接口中且字段会随版本变化。只依赖某一个接口容易出现昨天能跑、今天翻车的问题某个接口返回 403 / 404 时直接判为无订阅会造成误判降级配额字段名不统一used_percent可能是 0~1 比例也可能是 0~100 百分比5 小时窗口和周窗口的字段可能互换位置。codex-console 的解法是并发抓多个来源、按优先级交叉验证、失败时静默降级核心逻辑在 src/core/openai/overview.py。二、多端点并发抓取3 个数据源各司其职检测入口是fetch_codex_overview()它同时请求 3 个后端接口数据源接口角色失败策略me/backend-api/me计划类型核心来源必选重试 2 次计入错误wham_usage/backend-api/wham/usage配额 计划核心来源必选重试 2 次计入错误codex_usage/backend-api/codex/usage兜底补充可选401/403/404 时静默降级端点定义见 overview.py#L26-L32。三个请求通过ThreadPoolExecutor并发执行主入口见 overview.py#L788-L843。两个关键的容错设计代理回退直连请求优先走当前代理代理异常时自动回退直连重试一次_request_json_with_proxy_fallback可重试错误识别只对 408、429、5xx 和超时类错误重试401/403/404 不重试避免无效等待。三、多源解析如何判断是 Plus / Team / Basic计划类型识别是订阅检测的重头戏。_detect_plan()采用六级优先链逐级降级确保任何一级拿到信号就能定论源码见 overview.py#L727-L785me 接口的 plan 字段扫描plan_type、subscription_plan、tier等 10 余个候选字段并归一化——enterprise/team → Team、plus → Plus、pro → Pro、free/basic → Basicorg / workspace 信息me.orgs里的workspace_plan_type为 team/enterprise 时直接判为 Team订阅布尔信号has_paid_subscription、is_subscribed等为true时按 Plus 处理wham/usage 与 codex/usage 的 plan_type这是与官方工具同款的核心信号JWT 声明兜底解码id_token/access_token的 payload读取chatgpt_plan_type声明不依赖任何网络刷新数据库已有订阅字段仍无信号则默认为 Basic。每一级检测都会记录plan_source如me.plan、id_token.chatgpt_plan_type让你可以追溯结论来自哪个来源排查误判时一目了然。四、Rate Limit 窗口识别区分 5 小时配额与周配额这是 codex-console 最有特色的部分。wham/usage返回的rate_limit包含primary_window和secondary_window两个窗口但窗口位置并不总是一成不变——接口改版后7 天窗口可能出现在 primary 位置。基于窗口时长的置信推断_infer_rate_limit_window_type()用两条阈值线判定窗口类型overview.py#L437-L448窗口时长limit_window_seconds≥5 天→ 判定为weekly周窗口高置信窗口时长 ≤12 小时→ 判定为hourly5 小时窗口高置信无时长信息时退化到 key 语义primary_window倾向 hourlysecondary_window倾向 weekly但置信度标记为低。三级选择策略_select_rate_limit_window()overview.py#L451-L478按置信度三级筛选优先高置信匹配基于窗口时长推断且类型命中避免把 7 天窗口误判成 5 小时窗口普通语义匹配无时长信息时按 key 语义兜底历史 key 兜底单窗口账号场景下按primary5h / secondary周的历史约定取值避免页面上出现--空值。配额数值归一化窗口内部的字段同样被做了防御式解析_extract_quota_from_rate_limit_windowused_percent在 0~1 与 0~100 之间自动换算total / used / remaining三者互相推算任一缺失可由另外两个补出resets_at与resets_in_seconds互推最终渲染成1小时23分这类人类可读的剩余时间时间戳兼容秒 / 毫秒两种 epoch 格式。最终每个账号输出hourly_quota5 小时窗口、weekly_quota周窗口、code_review_quotaCode Review 专属配额三组数据且每个窗口都标注了source溯源路径。五、缓存与信任源让检测又快又稳服务层 accounts.py#L585-L679 的_get_account_overview_data()在抓取之外还做了几件重要的事缓存优先结果缓存在账号extra_data.codex_overview中TTL 内直接读缓存首屏卡片列表默认不发网络请求避免被远端接口阻塞过期缓存标记 stale刷新失败时返回旧数据并打上stale标记而不是显示空白信任源同步只有来自me.、wham_usage.、codex_usage.、id_token.等高置信来源的计划类型才会回写数据库subscription_type字段防降级保护本地已确认的 Plus / Team 账号不会被远端偶发的 free/basic 响应覆盖降级只记录日志跳过停用识别请求过程中抛出AccountDeactivatedError时账号直接标记为 BANNED 并记录停用时间。六、批量刷新体验Web UI 的批量刷新走 accounts.py#L1235 的/api/accounts/overview/refresh接口默认只刷新卡片可见的付费账号plus / team无关账号不会拖慢整体进度支持按状态、邮箱服务、关键词筛选刷新范围每个账号优先使用其绑定的代理account.proxy_used无绑定代理时才用全局代理结果明细里带上plan_type与各窗口percentage日志中还记录每个配额的数据来源方便逐账号核对。七、核心文件速查文件职责src/core/openai/overview.py订阅状态与配额抓取解析核心多端点并发、计划六级解析链、窗口识别src/web/routes/accounts.py缓存策略、信任源回写、批量刷新 APIstatic/js/accounts_overview.js总览卡片前端交互tests/覆盖注册、上传、安全等链路的自动化测试小结codex-console 的订阅状态检测可以概括为一句话多点并发取数、按置信度定级、失败静默降级。多源交叉验证消除了单点接口波动带来的误判Rate Limit 窗口识别则让 5 小时 / 周配额在不同接口布局下都能被准确归类——这正是它在 v1.1 版本修复无法检查订阅状态问题后的核心能力。【免费下载链接】codex-consolecodex-console 是一个集成化控制台项目支持任务管理、批量处理、数据导出、自动上传、日志查看与打包支持。项目地址: https://gitcode.com/gh_mirrors/co/codex-console创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表