CodexBar 接入 StepFun阶跃星辰用量统计Oasis-Token 登录流、双计费模型解析与配置实战【免费下载链接】CodexBarShow usage stats for OpenAI Codex and Claude Code, without having to login.项目地址: https://gitcode.com/GitHub_Trending/co/CodexBar导读本文以 docs/stepfun.md 为主线系统讲解 CodexBar 如何为 OpenAI Codex / Claude Code 生态之外的 Web 型服务商 StepFun阶跃星辰提供用量统计从三种认证方式自动登录、手动 Token、环境变量到 Oasis-Token 的三步获取流程再到 Step Plan 限流 API 与套餐状态 API 的字段解析最后深入两套并行计费模型滚动 5 小时/周窗口与月度 Credit 池在菜单栏卡片上的呈现逻辑。读完本文你将掌握 StepFun 在 CodexBar 中的完整配置方法、API 响应结构与核心解析算法并能读懂对应源码与测试。一、StepFun Provider 概览StepFun 是一个 Web 型用量服务商与 OpenAI、Claude 等直接使用账号体系读取仪表盘的方式不同CodexBar 通过以下两条数据源获取其用量认证层以用户名 密码或直接粘贴 Oasis-Token换取并缓存会话令牌令牌存放在 Keychain 背书的CookieHeaderCache中数据层调用 Step Plan 限流 API 读取剩余额度百分比调用套餐状态 API 读取套餐名称。该 Provider 的标识为.stepfunCLI 名称为stepfun别名step-fun、sf仪表盘地址为https://platform.stepfun.com/plan-usage这些元数据定义在 Sources/CodexBarCore/Providers/StepFun/StepFunProviderDescriptor.swift 的ProviderMetadata中。二、三种认证方式与优先级CodexBar 按固定优先级解析 StepFun 的认证凭据该逻辑实现在 StepFunProviderDescriptor.swift 的resolveToken(context:allowCached:)中优先级方式来源说明1Manual 模式设置 → Providers → StepFun 中粘贴 Oasis-Token直接从设置读取并归一化不发起网络登录2缓存 TokenKeychain 中的CookieHeaderCache复用上次登录/刷新得到的令牌3设置内账号密码设置界面填写的用户名 密码触发完整三步登录流并回写缓存4环境变量 TokenSTEPFUN_TOKEN直接使用环境变量中的令牌5环境变量账号密码STEPFUN_USERNAMESTEPFUN_PASSWORD触发完整登录流并回写缓存其中第 2、3、5 种方式成功后都会把令牌写入CookieHeaderCachesourceLabel 分别为login从而让后续刷新直接命中第 2 级缓存。环境变量的读取与清洗去空白、剥掉首尾成对引号实现在 Sources/CodexBarCore/Providers/StepFun/StepFunSettingsReader.swift对应测试见 StepFunUsageFetcherTests.swift 中的StepFunSettingsReaderTests。三、Oasis-Token 三步登录流当使用用户名 密码登录时CodexBar 会依次调用三个接口换取令牌整体流程封装在 StepFunUsageFetcher.swift 的fullLogin(username:password:)中获取 INGRESSCOOKIEGET https://platform.stepfun.com从响应的Set-Cookie头中提取INGRESSCOOKIE值源码中同时从HTTPCookieStorage兜底读取。注册匿名设备POST …/passport/proto.api.passport.v1.PassportService/RegisterDevice请求体为空 JSON{}携带Cookie: INGRESSCOOKIE…返回匿名 access/refresh token 对。密码登录POST …/passport/proto.api.passport.v1.PassportService/SignInByPassword请求体为{username: …, password: …}携带Cookie: Oasis-Token匿名token; Oasis-Webid…; INGRESSCOOKIE…返回已认证的 Oasis-Token 对。源码将 access token 与 refresh token 拼接为access...refresh的复合格式combinedToken并在后续所有请求中作为Oasis-Token头与Cookie值使用。除登录外StepFunUsageFetcher.swift 还实现了refreshOasisToken(token:)通过POST …/PassportService/RefreshToken刷新过期令牌成功后返回新的 access/refresh 复合令牌。所有网络请求都经由共享的ProviderHTTPClient超时时间为 15 秒基础请求头包括content-type: application/json、oasis-appid: 10300、oasis-platform: web以及浏览器 UA。四、Oasis-Webid 与 device_id 绑定约束StepFun 服务端要求Oasis-Webid头/Cookie 必须与令牌 JWT 载荷中的device_id声明一致否则会返回auth failed: oasis-token is embezzled类错误。为此StepFunUsageFetcher.swift 实现了webID(forToken:)复合令牌按...拆成两半优先取 refresh 半段device_id声明通常位于 refresh token失败则回退 access 半段对 JWT 的第二段payload做 base64url 解码从中提取device_id字段在登录/注册阶段尚无可推导 token使用内置兜底defaultWebID拿到令牌后再用真实device_id覆盖请求中的oasis-webid头。这也解释了文档中「Manual 模式浏览器导入的 Token其 device_id 从 refresh-token JWT 载荷推导」的由来自动登录的 device_id 属于 CodexBar 应用自身手动粘贴的令牌则属于导入的浏览器会话。五、限流 API 与响应字段用量数据来自限流接口POST https://platform.stepfun.com/api/step.openapi.devcenter.Dashboard/QueryStepPlanRateLimit请求头为Cookie: Oasis-Tokentoken、Content-Type: application/json请求体为空 JSON。响应结构在 StepFunUsageFetcher.swift 中定义核心字段如下字段类型含义statusint请求状态1表示成功isSuccessfive_hour_usage_left_ratenumber5 小时窗口剩余比例如0.99781543weekly_usage_left_ratenumber周窗口剩余比例five_hour_usage_reset_timestring/int5 小时窗口重置时间戳weekly_usage_reset_timestring/int周窗口重置时间戳plan_familynumber套餐族标识2表示 Credit 计费套餐如 Mini、Proplan_credit_rate_limitobjectCredit 用量对象plan_family: 2时出现plan_credit_rate_limit内部包含subscription_credit_left_rate订阅额度剩余比例如0.9641subscription_credit_reset_time额度重置/回填时间戳topup_credit_left_rate充值额度剩余比例credit_buckets数组元素为{ credit_total, credit_residual, expire_at, next_reset_at }的额度桶。为兼容该 API 的松散类型源码定义了StepFunFlexibleNumber可同时解码 int/float/数字字符串与StepFunFlexibleTimestamp可同时解码字符串与整数时间戳两个弹性类型实测响应中既有five_hour_usage_left_rate: 1这样的整数也有1777528800这样的字符串时间戳对应解析测试见 StepFunUsageFetcherTests.swift 中的StepFunUsageFetcherParsingTests。六、套餐状态 API 与套餐名套餐名称来自POST https://platform.stepfun.com/api/step.openapi.devcenter.Dashboard/GetStepPlanStatus同样携带 Oasis-Token 认证头响应中的subscription.name即套餐名如 Plus、Mini。在 StepFunUsageFetcher.swift 中该请求被设计为可选增强请求失败或解析失败仅记录 debug 日志并返回nil用量数据仍照常展示只是缺少套餐名标签。套餐名经过去空白处理后最终以loginMethod标签的形式显示在菜单栏卡片上。七、两套计费模型与解析判定StepFun 在 2026-06-18 升级后并行运行两套 Step Plan 计费模型源码注释明确引用了 docs/zh/step-plan/upgrade-notice滚动窗口模型Coding Plan 老套餐计量滚动的 5 小时 / 周窗口月度 Credit 池模型Token Plan 新套餐通过plan_credit_rate_limit计量月度额度池其窗口字段返回0、reset_time返回0——这是「未配置窗口」而非「额度用尽」。因此isCreditPlan的判定不单纯信任plan_family而是按载荷形状分级判断StepFunUsageFetcher.swift若存在活跃窗口任一*_usage_reset_time 0→ 判定为窗口计费非 Credit否则若存在 Credit 池subscription_credit_left_rate、topup_credit_left_rate、非空credit_buckets任一存在→ 判定为 Credit 计费以上都不满足如全新套餐既无窗口也无额度时才以plan_family 2作为最终兜底。这样设计是为了避免未来 family-id 变化时把窗口套餐错误地渲染成 Credit 卡片或反之。7.1 窗口套餐的展示逻辑toUsageSnapshot()将解析结果映射为 CodexBar 的UsageSnapshot主窗口顶部条5 小时限流windowMinutes: 300次窗口底部条周限流windowMinutes: 10080usedPercent (1.0 - left_rate) × 100并夹取到[0, 100]区间。7.2 Credit 套餐的展示逻辑Credit 套餐没有 5 小时/周窗口其展示规则如下主窗口展示合并后的 Credit 余额usedPercent (1.0 - credit_left_rate) × 100次窗口不显示secondary: nil合并比例的算法在totalCreditLeftRate中实现当credit_buckets存在且所有桶都能提供合法的credit_total/credit_residual均为有限数、total 0、0 ≤ residual ≤ total时按sum(residual) / sum(total)加权合并缺少桶数据时不能简单相加两个独立比例而是取subscription_credit_left_rate仅在订阅额度不存在时才回退topup_credit_left_rate当 Credit 池存在真实月度重置时间时主窗口的windowMinutes被设置为月度窗口哨兵值从而让月度额度池也能接入套餐利用历史与节奏预测pace forecast若没有重置时间则置nil避免产生无意义的预测。对应测试覆盖了 bucket 加权、无 bucket 回退、空 bucket 数组等多种形态见 StepFunUsageFetcherTests.swift 中 Credit 相关用例。八、设置项与配置实操StepFun 的设置字段在 Sources/CodexBar/Providers/StepFun/StepFunProviderImplementation.swift 中声明底层存储映射在 Sources/CodexBar/Providers/StepFun/StepFunSettingsStore.swift设置项显示存储位置Auth sourceAuto / Manual / OffcookieSource配置字段Username平台账号手机号或邮箱Auto 模式显示复用apiKey字段Password安全输入Auto 模式显示复用cookieHeader字段安全存储Oasis-TokenManual 模式粘贴含「Open StepFun Platform」跳转按钮复用region字段原字段重用途UI 的可见性规则cookieSource ! .manual时显示账号密码字段cookieSource .manual时显示 Token 字段。Auth source 设为Off时StepFunWebFetchStrategy.isAvailable返回falseProvider 完全不发起后台刷新StepFunProviderDescriptor.swift。当选择 Manual 模式时设置界面还会引导用户打开platform.stepfun.com/plan-usage页面复制浏览器会话中的 Oasis-Token。8.1 手动 Token 的归一化粘贴的令牌可能是裸 JWT也可能是一段Oasis-Token…; …形式的 Cookie 头。StepFunTokenNormalizer.normalizeStepFunProviderDescriptor.swift会识别并剥离Oasis-Token前缀仅保留;之前的令牌本体。手动持久化的 Token 写入配置文件的region字段persistManualToken。8.2 环境变量配置CLI / 无 UI 场景# 方式一用户名 密码自动完成三步登录流 export STEPFUN_USERNAMEuserexample.com export STEPFUN_PASSWORDyour-password # 方式二直接使用已有 Oasis-Token跳过登录 export STEPFUN_TOKENoasis-token 或 Oasis-Token… cookie 头环境变量支持首尾空格去除、成对双引号/单引号剥离空值视为未配置详见StepFunSettingsReader与对应单元测试。九、Token 过期、失败恢复与错误处理当限流 API 返回认证类错误401/403、unauthorized、unauthenticated、invalid credentials、invalid token、token expired 等判定函数见 StepFunProviderDescriptor.swift时抓取策略会进入recoverFromAuthenticationFailure恢复流程优先尝试用缓存令牌调用RefreshToken接口刷新若刷新失败且令牌来自缓存则清除陈旧缓存CookieHeaderCache.clear后按优先级重新解析回到环境变量或设置内账号密码若仍不可行则尝试用设置内或环境变量中的账号密码重新执行完整登录流全部失败时抛出带可操作提示的错误Manual 模式提示刷新 Oasis-Token 或改用账号密码自动登录环境变量 Token 模式提示刷新STEPFUN_TOKEN或配置账号密码。恢复成功后新令牌会按来源写回缓存类来源存入CookieHeaderCacheManual / 环境变量 Token 来源则通过 token account 更新器回写。错误类型统一收敛到StepFunUsageError枚举missingCredentials、missingToken、networkError、apiError、parseFailed、loginFailed、tokenRefreshFailed、deviceRegistrationFailed便于上层展示与诊断。十、关键文件与测试索引Sources/CodexBarCore/Providers/StepFun/StepFunProviderDescriptor.swiftProvider 描述符、凭据适配、Web 抓取策略与令牌解析/恢复逻辑Sources/CodexBarCore/Providers/StepFun/StepFunUsageFetcher.swift登录流、HTTP 客户端、JSON 解析与快照映射Sources/CodexBarCore/Providers/StepFun/StepFunSettingsReader.swift环境变量解析Sources/CodexBarCore/Providers/StepFun/StepFunProviderSettings.swift设置快照结构Sources/CodexBar/Providers/StepFun/StepFunProviderImplementation.swift设置字段与激活逻辑Sources/CodexBar/Providers/StepFun/StepFunSettingsStore.swiftSettingsStore 扩展与存储映射Tests/CodexBarTests/StepFunUsageFetcherTests.swift覆盖环境变量读取、Token 解析、API 响应解析、Credit/窗口套餐判定、错误路径等 26 个测试用例。从测试集可以看出该项目对 StepFun 的处理不仅验证「理想响应」还专门覆盖了字符串时间戳、整数比例、0重置时间、空 bucket、缺字段回退等边界形态确保两套计费模型都能稳定、准确地呈现在菜单栏卡片中。【免费下载链接】CodexBarShow usage stats for OpenAI Codex and Claude Code, without having to login.项目地址: https://gitcode.com/GitHub_Trending/co/CodexBar创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 CodexBar 接入 StepFun（阶跃星辰）用量统计：Oasis-Token 登录流、双计费模型解析与配置实战
CodexBar 接入 StepFun阶跃星辰用量统计Oasis-Token 登录流、双计费模型解析与配置实战【免费下载链接】CodexBarShow usage stats for OpenAI Codex and Claude Code, without having to login.项目地址: https://gitcode.com/GitHub_Trending/co/CodexBar导读本文以 docs/stepfun.md 为主线系统讲解 CodexBar 如何为 OpenAI Codex / Claude Code 生态之外的 Web 型服务商 StepFun阶跃星辰提供用量统计从三种认证方式自动登录、手动 Token、环境变量到 Oasis-Token 的三步获取流程再到 Step Plan 限流 API 与套餐状态 API 的字段解析最后深入两套并行计费模型滚动 5 小时/周窗口与月度 Credit 池在菜单栏卡片上的呈现逻辑。读完本文你将掌握 StepFun 在 CodexBar 中的完整配置方法、API 响应结构与核心解析算法并能读懂对应源码与测试。一、StepFun Provider 概览StepFun 是一个 Web 型用量服务商与 OpenAI、Claude 等直接使用账号体系读取仪表盘的方式不同CodexBar 通过以下两条数据源获取其用量认证层以用户名 密码或直接粘贴 Oasis-Token换取并缓存会话令牌令牌存放在 Keychain 背书的CookieHeaderCache中数据层调用 Step Plan 限流 API 读取剩余额度百分比调用套餐状态 API 读取套餐名称。该 Provider 的标识为.stepfunCLI 名称为stepfun别名step-fun、sf仪表盘地址为https://platform.stepfun.com/plan-usage这些元数据定义在 Sources/CodexBarCore/Providers/StepFun/StepFunProviderDescriptor.swift 的ProviderMetadata中。二、三种认证方式与优先级CodexBar 按固定优先级解析 StepFun 的认证凭据该逻辑实现在 StepFunProviderDescriptor.swift 的resolveToken(context:allowCached:)中优先级方式来源说明1Manual 模式设置 → Providers → StepFun 中粘贴 Oasis-Token直接从设置读取并归一化不发起网络登录2缓存 TokenKeychain 中的CookieHeaderCache复用上次登录/刷新得到的令牌3设置内账号密码设置界面填写的用户名 密码触发完整三步登录流并回写缓存4环境变量 TokenSTEPFUN_TOKEN直接使用环境变量中的令牌5环境变量账号密码STEPFUN_USERNAMESTEPFUN_PASSWORD触发完整登录流并回写缓存其中第 2、3、5 种方式成功后都会把令牌写入CookieHeaderCachesourceLabel 分别为login从而让后续刷新直接命中第 2 级缓存。环境变量的读取与清洗去空白、剥掉首尾成对引号实现在 Sources/CodexBarCore/Providers/StepFun/StepFunSettingsReader.swift对应测试见 StepFunUsageFetcherTests.swift 中的StepFunSettingsReaderTests。三、Oasis-Token 三步登录流当使用用户名 密码登录时CodexBar 会依次调用三个接口换取令牌整体流程封装在 StepFunUsageFetcher.swift 的fullLogin(username:password:)中获取 INGRESSCOOKIEGET https://platform.stepfun.com从响应的Set-Cookie头中提取INGRESSCOOKIE值源码中同时从HTTPCookieStorage兜底读取。注册匿名设备POST …/passport/proto.api.passport.v1.PassportService/RegisterDevice请求体为空 JSON{}携带Cookie: INGRESSCOOKIE…返回匿名 access/refresh token 对。密码登录POST …/passport/proto.api.passport.v1.PassportService/SignInByPassword请求体为{username: …, password: …}携带Cookie: Oasis-Token匿名token; Oasis-Webid…; INGRESSCOOKIE…返回已认证的 Oasis-Token 对。源码将 access token 与 refresh token 拼接为access...refresh的复合格式combinedToken并在后续所有请求中作为Oasis-Token头与Cookie值使用。除登录外StepFunUsageFetcher.swift 还实现了refreshOasisToken(token:)通过POST …/PassportService/RefreshToken刷新过期令牌成功后返回新的 access/refresh 复合令牌。所有网络请求都经由共享的ProviderHTTPClient超时时间为 15 秒基础请求头包括content-type: application/json、oasis-appid: 10300、oasis-platform: web以及浏览器 UA。四、Oasis-Webid 与 device_id 绑定约束StepFun 服务端要求Oasis-Webid头/Cookie 必须与令牌 JWT 载荷中的device_id声明一致否则会返回auth failed: oasis-token is embezzled类错误。为此StepFunUsageFetcher.swift 实现了webID(forToken:)复合令牌按...拆成两半优先取 refresh 半段device_id声明通常位于 refresh token失败则回退 access 半段对 JWT 的第二段payload做 base64url 解码从中提取device_id字段在登录/注册阶段尚无可推导 token使用内置兜底defaultWebID拿到令牌后再用真实device_id覆盖请求中的oasis-webid头。这也解释了文档中「Manual 模式浏览器导入的 Token其 device_id 从 refresh-token JWT 载荷推导」的由来自动登录的 device_id 属于 CodexBar 应用自身手动粘贴的令牌则属于导入的浏览器会话。五、限流 API 与响应字段用量数据来自限流接口POST https://platform.stepfun.com/api/step.openapi.devcenter.Dashboard/QueryStepPlanRateLimit请求头为Cookie: Oasis-Tokentoken、Content-Type: application/json请求体为空 JSON。响应结构在 StepFunUsageFetcher.swift 中定义核心字段如下字段类型含义statusint请求状态1表示成功isSuccessfive_hour_usage_left_ratenumber5 小时窗口剩余比例如0.99781543weekly_usage_left_ratenumber周窗口剩余比例five_hour_usage_reset_timestring/int5 小时窗口重置时间戳weekly_usage_reset_timestring/int周窗口重置时间戳plan_familynumber套餐族标识2表示 Credit 计费套餐如 Mini、Proplan_credit_rate_limitobjectCredit 用量对象plan_family: 2时出现plan_credit_rate_limit内部包含subscription_credit_left_rate订阅额度剩余比例如0.9641subscription_credit_reset_time额度重置/回填时间戳topup_credit_left_rate充值额度剩余比例credit_buckets数组元素为{ credit_total, credit_residual, expire_at, next_reset_at }的额度桶。为兼容该 API 的松散类型源码定义了StepFunFlexibleNumber可同时解码 int/float/数字字符串与StepFunFlexibleTimestamp可同时解码字符串与整数时间戳两个弹性类型实测响应中既有five_hour_usage_left_rate: 1这样的整数也有1777528800这样的字符串时间戳对应解析测试见 StepFunUsageFetcherTests.swift 中的StepFunUsageFetcherParsingTests。六、套餐状态 API 与套餐名套餐名称来自POST https://platform.stepfun.com/api/step.openapi.devcenter.Dashboard/GetStepPlanStatus同样携带 Oasis-Token 认证头响应中的subscription.name即套餐名如 Plus、Mini。在 StepFunUsageFetcher.swift 中该请求被设计为可选增强请求失败或解析失败仅记录 debug 日志并返回nil用量数据仍照常展示只是缺少套餐名标签。套餐名经过去空白处理后最终以loginMethod标签的形式显示在菜单栏卡片上。七、两套计费模型与解析判定StepFun 在 2026-06-18 升级后并行运行两套 Step Plan 计费模型源码注释明确引用了 docs/zh/step-plan/upgrade-notice滚动窗口模型Coding Plan 老套餐计量滚动的 5 小时 / 周窗口月度 Credit 池模型Token Plan 新套餐通过plan_credit_rate_limit计量月度额度池其窗口字段返回0、reset_time返回0——这是「未配置窗口」而非「额度用尽」。因此isCreditPlan的判定不单纯信任plan_family而是按载荷形状分级判断StepFunUsageFetcher.swift若存在活跃窗口任一*_usage_reset_time 0→ 判定为窗口计费非 Credit否则若存在 Credit 池subscription_credit_left_rate、topup_credit_left_rate、非空credit_buckets任一存在→ 判定为 Credit 计费以上都不满足如全新套餐既无窗口也无额度时才以plan_family 2作为最终兜底。这样设计是为了避免未来 family-id 变化时把窗口套餐错误地渲染成 Credit 卡片或反之。7.1 窗口套餐的展示逻辑toUsageSnapshot()将解析结果映射为 CodexBar 的UsageSnapshot主窗口顶部条5 小时限流windowMinutes: 300次窗口底部条周限流windowMinutes: 10080usedPercent (1.0 - left_rate) × 100并夹取到[0, 100]区间。7.2 Credit 套餐的展示逻辑Credit 套餐没有 5 小时/周窗口其展示规则如下主窗口展示合并后的 Credit 余额usedPercent (1.0 - credit_left_rate) × 100次窗口不显示secondary: nil合并比例的算法在totalCreditLeftRate中实现当credit_buckets存在且所有桶都能提供合法的credit_total/credit_residual均为有限数、total 0、0 ≤ residual ≤ total时按sum(residual) / sum(total)加权合并缺少桶数据时不能简单相加两个独立比例而是取subscription_credit_left_rate仅在订阅额度不存在时才回退topup_credit_left_rate当 Credit 池存在真实月度重置时间时主窗口的windowMinutes被设置为月度窗口哨兵值从而让月度额度池也能接入套餐利用历史与节奏预测pace forecast若没有重置时间则置nil避免产生无意义的预测。对应测试覆盖了 bucket 加权、无 bucket 回退、空 bucket 数组等多种形态见 StepFunUsageFetcherTests.swift 中 Credit 相关用例。八、设置项与配置实操StepFun 的设置字段在 Sources/CodexBar/Providers/StepFun/StepFunProviderImplementation.swift 中声明底层存储映射在 Sources/CodexBar/Providers/StepFun/StepFunSettingsStore.swift设置项显示存储位置Auth sourceAuto / Manual / OffcookieSource配置字段Username平台账号手机号或邮箱Auto 模式显示复用apiKey字段Password安全输入Auto 模式显示复用cookieHeader字段安全存储Oasis-TokenManual 模式粘贴含「Open StepFun Platform」跳转按钮复用region字段原字段重用途UI 的可见性规则cookieSource ! .manual时显示账号密码字段cookieSource .manual时显示 Token 字段。Auth source 设为Off时StepFunWebFetchStrategy.isAvailable返回falseProvider 完全不发起后台刷新StepFunProviderDescriptor.swift。当选择 Manual 模式时设置界面还会引导用户打开platform.stepfun.com/plan-usage页面复制浏览器会话中的 Oasis-Token。8.1 手动 Token 的归一化粘贴的令牌可能是裸 JWT也可能是一段Oasis-Token…; …形式的 Cookie 头。StepFunTokenNormalizer.normalizeStepFunProviderDescriptor.swift会识别并剥离Oasis-Token前缀仅保留;之前的令牌本体。手动持久化的 Token 写入配置文件的region字段persistManualToken。8.2 环境变量配置CLI / 无 UI 场景# 方式一用户名 密码自动完成三步登录流 export STEPFUN_USERNAMEuserexample.com export STEPFUN_PASSWORDyour-password # 方式二直接使用已有 Oasis-Token跳过登录 export STEPFUN_TOKENoasis-token 或 Oasis-Token… cookie 头环境变量支持首尾空格去除、成对双引号/单引号剥离空值视为未配置详见StepFunSettingsReader与对应单元测试。九、Token 过期、失败恢复与错误处理当限流 API 返回认证类错误401/403、unauthorized、unauthenticated、invalid credentials、invalid token、token expired 等判定函数见 StepFunProviderDescriptor.swift时抓取策略会进入recoverFromAuthenticationFailure恢复流程优先尝试用缓存令牌调用RefreshToken接口刷新若刷新失败且令牌来自缓存则清除陈旧缓存CookieHeaderCache.clear后按优先级重新解析回到环境变量或设置内账号密码若仍不可行则尝试用设置内或环境变量中的账号密码重新执行完整登录流全部失败时抛出带可操作提示的错误Manual 模式提示刷新 Oasis-Token 或改用账号密码自动登录环境变量 Token 模式提示刷新STEPFUN_TOKEN或配置账号密码。恢复成功后新令牌会按来源写回缓存类来源存入CookieHeaderCacheManual / 环境变量 Token 来源则通过 token account 更新器回写。错误类型统一收敛到StepFunUsageError枚举missingCredentials、missingToken、networkError、apiError、parseFailed、loginFailed、tokenRefreshFailed、deviceRegistrationFailed便于上层展示与诊断。十、关键文件与测试索引Sources/CodexBarCore/Providers/StepFun/StepFunProviderDescriptor.swiftProvider 描述符、凭据适配、Web 抓取策略与令牌解析/恢复逻辑Sources/CodexBarCore/Providers/StepFun/StepFunUsageFetcher.swift登录流、HTTP 客户端、JSON 解析与快照映射Sources/CodexBarCore/Providers/StepFun/StepFunSettingsReader.swift环境变量解析Sources/CodexBarCore/Providers/StepFun/StepFunProviderSettings.swift设置快照结构Sources/CodexBar/Providers/StepFun/StepFunProviderImplementation.swift设置字段与激活逻辑Sources/CodexBar/Providers/StepFun/StepFunSettingsStore.swiftSettingsStore 扩展与存储映射Tests/CodexBarTests/StepFunUsageFetcherTests.swift覆盖环境变量读取、Token 解析、API 响应解析、Credit/窗口套餐判定、错误路径等 26 个测试用例。从测试集可以看出该项目对 StepFun 的处理不仅验证「理想响应」还专门覆盖了字符串时间戳、整数比例、0重置时间、空 bucket、缺字段回退等边界形态确保两套计费模型都能稳定、准确地呈现在菜单栏卡片中。【免费下载链接】CodexBarShow usage stats for OpenAI Codex and Claude Code, without having to login.项目地址: https://gitcode.com/GitHub_Trending/co/CodexBar创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考