尧图网站建设 
LiteLLM 用量接入实战CodexBar 虚拟密钥方案的数据源、配置与安全边界【免费下载链接】CodexBarShow usage stats for OpenAI Codex and Claude Code, without having to login.项目地址: https://gitcode.com/GitHub_Trending/co/CodexBar导读本文以 CodexBar 仓库中的 LiteLLM 接入文档为主线系统讲解如何为 LiteLLM 代理网关配置用量统计从虚拟密钥virtual key加代理 Base URL 的认证模型到/key/info、/user/info、/team/info三类管理端点的数据读取链路再到 HTTPS 校验、密钥存储等安全设计。读完本文你将掌握在 CodexBar 中为 LiteLLM 配置 API Key 与 Base URL 的完整步骤、理解个人预算与团队预算如何映射为菜单栏指标并能依据源码与测试定位常见配置与权限问题。LiteLLM 在 CodexBar 中的定位LiteLLM 是一款流行的 LLM 代理网关通过虚拟密钥virtual key对外统一暴露多个上游模型同时集中管理每个密钥对应的预算与消费。CodexBar 将 LiteLLM 作为一个可选的用量统计 Provider其核心思路是不依赖主密钥master key而是让虚拟密钥通过 LiteLLM 自带的管理端点读取自身的身份、花费与预算数据。这一点在文档中被明确表述为LiteLLM uses a virtual key plus the proxy base URL. The key reads its own identity and budget data through LiteLLMs authenticated information endpoints.从源码角度看该 Provider 由三部分组成Sources/CodexBarCore/Providers/LiteLLM/LiteLLMProviderDescriptor.swiftProvider 的注册描述、凭据适配、取数策略与菜单栏展示规则LiteLLMSettingsReader.swift读取并清洗LITELLM_API_KEY与LITELLM_BASE_URL两个配置源LiteLLMUsageFetcher.swift实现三类管理端点的请求、解析与快照转换是数据链路的执行核心。此外Sources/CodexBar/Providers/LiteLLM/LiteLLMProviderImplementation.swift 负责在应用侧呈现设置表单字段并监听配置变化。配置方式图形界面与配置文件双通道CodexBar 支持两种等价配置途径。方式一图形界面在Settings - Providers - LiteLLM中填写两个字段对应源码中的settingsFields实现字段说明占位示例API keyLiteLLM 虚拟密钥用于读取该密钥自身的花费与预算sk-…Base URLLiteLLM 代理 Base URL允许带/v1后缀管理端点会自动剥离https://litellm.example.com方式二~/.codexbar/config.json{ id: litellm, enabled: true, apiKey: LITELLM_API_KEY, enterpriseHost: https://litellm.example.com }方式三环境变量export LITELLM_API_KEYsk-... export LITELLM_BASE_URLhttps://litellm.example.com两个环境变量的键名在源码中硬编码于 LiteLLMSettingsReader.swiftpublic static let apiKeyEnvironmentKey LITELLM_API_KEY public static let baseURLEnvironmentKey LITELLM_BASE_URL值得注意的细节环境变量的读取会先做空白与引号清理——源码中的cleaned(_:)会trimmingCharacters去掉首尾空白并且如果值被成对的双引号或单引号包裹也会一并剥离对应测试settings reader trims quoted environment values见 Tests/CodexBarTests/LiteLLMUsageFetcherTests.swift。因此LITELLM_API_KEYsk-test这类带引号的写法也能被正确解析。另外CodexBar 还支持在 token-account 存储中保存多把 LiteLLM API Key描述器中的TokenAccountSupport注明 Store multiple LiteLLM API keys.通过环境注入方式把选定密钥传给取数流程。Base URL 的/v1处理与校验规则/v1后缀自动剥离LiteLLM 的代理地址通常形如https://host/v1而管理端点/key/info等并不在/v1前缀之下。CodexBar 在构造管理端点 URL 时会对 Base URL 做归一化managementBaseURL(_:)会检查路径的最后一段是否为v1若是则移除该段后再拼接管理路径LiteLLMUsageFetcher.swift。该行为有测试直接验证management urls accept root or v1 base urlshttps://litellm.example.com→https://litellm.example.com/key/infohttps://litellm.example.com/v1→https://litellm.example.com/key/infohttps://gateway.example.com/litellm/v1/→https://gateway.example.com/litellm/user/info?user_iduser-123嵌套路径同样支持只剥离最后一段v1协议与凭证校验文档明确Base URL 必须满足以下条件否则被视为非法并被拒绝取数必须使用 HTTPS除非该地址指向回环地址loopback、私网地址RFC 1918、链路本地地址link-local或 IPv6 唯一本地地址unique-local或者是一个.localmDNS 主机名不得内嵌凭证如https://user:passhost因为 API Key 会以 Bearer token 形式发送到该地址纯 HTTP 仅对自建代理可用且限回环、RFC 1918、链路本地、IPv6 唯一本地网络。这些规则由ProviderEndpointOverrideValidator().validatedURLAllowingPrivateNetworkHTTP(raw)统一实施LiteLLMSettingsReader.swift与其他 Provider 的端点覆盖校验共用同一套逻辑。值得一提的设计是当 Base URL 配置了但未通过校验时CodexBar 会明确抛出LiteLLMUsageError.invalidEndpointOverride(LITELLM_BASE_URL)并提示使用 HTTPS 或仅对回环/私网地址使用 HTTP、且不得内嵌凭证见 LiteLLMUsageError。为了做到这一点hasBaseURLOverride(environment:)专门区分从未配置与已配置但被拒绝两种状态取数策略据此决定抛invalidEndpointOverride还是missingBaseURLLiteLLMProviderDescriptor.swift避免 Provider 静默不可用让用户无从排查。此外文档还提到一条约束原生取数器native fetcher仍是权威路径配置的插件源plugin origins覆盖 HTTPS 与回环 HTTP但在没有更宽泛的主机网络策略时并不覆盖既有的私网与.localHTTP 契约。即插件化替代方案目前不能完全替代原生取数器对私网 HTTP 场景的支持。数据源与取数流程三阶段请求链路文档给出的调用序列与LiteLLMUsageFetcher.fetchUsage的实现完全一致LiteLLMUsageFetcher.swiftGET /key/info读取当前虚拟密钥自身的user_id与team_id。注意源码注释明确指出Virtual keys may read their own metadata; omit?keyto avoid requiring or exposing a master key.——即请求不带?key参数从而避免暴露主密钥。GET /user/info?user_iduser_id当密钥绑定了用户时读取个人花费、预算与团队列表。GET /team/info?team_idteam_id当密钥是仅团队密钥无user_id只有team_id时读取团队花费与预算。所有请求均为GET请求头固定为Authorization: Bearer apiKey Accept: application/json源码中request(url:apiKey:)的实现LiteLLMUsageFetcher.swift还确认CodexBar 从不请求也不存储 LiteLLM master key仅使用虚拟密钥本身的 Bearer 认证。发送前还会对 API Key 做空白清理fetchUsage中先trimmingCharacters再校验非空。响应字段映射/key/info的响应解析为LiteLLMKeyInfoSnapshot关注字段JSON 字段快照属性说明info.key_namekeyName密钥名称脱敏展示用info.spendspendUSD该密钥累计花费USDinfo.expiresexpiresAt密钥过期时间info.user_iduserID绑定的用户 IDinfo.team_idteamID绑定的团队 ID/user/info的响应解析关注user_info下的user_email、user_alias、max_budget、spend、budget_reset_at以及metadata.preferred_username账户邮箱会按邮箱 别名 preferred_username的优先级取第一个非空值firstNonEmpty。团队信息则从teams数组中按team_id精确匹配/key/info中声明的团队preferredTeam。/team/info的响应解析关注team_info下的team_alias、team_id、max_budget、spend、budget_reset_at、budget_duration。身份一致性校验CodexBar 会把/key/info返回的user_id/team_id与后续/user/info、/team/info响应中的 ID 做交叉比对不一致时直接抛parseFailed(user_id did not match /key/info)或parseFailed(team_id did not match /key/info)LiteLLMUsageFetcher.swift。这一设计保证展示的预算确实属于当前密钥防止越权或串号数据被误展示。用量窗口的映射逻辑个人密钥个人窗口为主、团队窗口为辅对于绑定了用户的密钥主窗口primary个人花费与个人预算user_info.max_budget次窗口secondary与/key/info团队 ID精确匹配的团队预算菜单栏自动指标由于团队预算是该密钥实际被执行的约束自动模式.automatic下菜单栏优先展示团队预算窗口。这一逻辑在描述器的menuBarWindowResolver中实现自动模式下依次选择exhausted(primary, secondary) ?? secondary ?? primaryLiteLLMProviderDescriptor.swift即优先展示已耗尽的窗口否则优先团队窗口。仅团队密钥团队预算为唯一窗口当/key/info没有user_id只有team_id时CodexBar 直接走/team/info分支个人窗口为空团队预算成为唯一用量窗口providerCostSnapshot中period显示为 Team budget。无预算配置保留花费可见性当 LiteLLM 没有为该用户或团队配置预算max_budget为空或为 0时CodexBar 仍以API 花费行API-spend row展示实际花费而不是隐藏整个 Provider。这在providerCostSnapshot()中体现为limit: 0、period显示为 Personal spend 或 Team spendLiteLLMUsageFetcher.swift。对应测试preserves personal spend when no budget is configured验证了used 12.5, limit 0的行为。快照中的其他信息LiteLLMUsageSnapshot.toUsageSnapshot()还会填充subscriptionExpiresAt← 密钥过期时间info.expiresidentity.accountEmail← 解析出的邮箱/别名identity.accountOrganization← 团队别名team_aliasidentity.loginMethod←api。菜单卡片中ProviderCostPresentation依据limit 0选择apiSpend样式否则为hidden即预算场景下花费并入主/次窗口展示不重复显示花费行。权限要求与错误排查虚拟密钥所需的最小权限要让 CodexBar 正确读取用量虚拟密钥必须被允许访问自身的/key/info数据对应user_id的/user/info数据用户绑定的密钥或对应team_id的/team/info数据仅团队密钥。任何一端返回 401/403 都会导致取数失败。测试fetch surfaces rejected virtual key验证了 401 响应会抛出LiteLLMUsageError.apiError(HTTP 401: ...)且只发起一次请求Tests/CodexBarTests/LiteLLMUsageFetcherTests.swift。常见错误与对应提示场景错误类型提示文案未配置 API KeymissingCredentialsMissing LiteLLM API key. Set apiKey in~/.codexbar/config.jsonorLITELLM_API_KEY.未配置 Base URLmissingBaseURLMissing LiteLLM base URL. Set enterpriseHost in~/.codexbar/config.jsonorLITELLM_BASE_URL.Base URL 非法HTTP 公网 / 内嵌凭证invalidEndpointOverride提示改用 HTTPS或仅对回环/私网地址与.local主机使用 HTTP且不得内嵌凭证/key/info无user_id与team_idmissingUserIDLiteLLM key info did not include a user_id or team_id.HTTP 非 2xxapiErrorLiteLLM API error: HTTP status: 响应摘要前 500 字节安全边界文档的 Security 一节虽然简短但结合源码可以确认以下事实密钥按秘密对待LiteLLM 密钥只存于 Provider 配置或 token-account 存储后者支持多密钥管理不落盘到其他位置密钥只发送给配置的 Base URL所有请求统一走Authorization: Bearer头且 URL 校验禁止内嵌凭证避免密钥被当作 URL 的一部分泄露到日志或 Referer不使用主密钥/key/info请求有意省略?key参数既满足虚拟密钥读取自身信息的需要又从设计上杜绝了主密钥的获取与存储私网 HTTP 白名单自建代理在回环、RFC 1918、链路本地与 IPv6 唯一本地网络可继续使用明文 HTTP兼顾本地部署的便利性与公网传输的保密性。小结CodexBar 的 LiteLLM 接入以虚拟密钥自读信息为设计主线一份 Base URL 加一把虚拟密钥即可通过三个管理端点获得个人/团队的花费与预算并自动映射为菜单栏主次窗口与预算/花费两种展示形态。配置上支持图形界面、~/.codexbar/config.json与环境变量三种途径安全上通过 URL 校验、禁止内嵌凭证、不使用主密钥以及 ID 交叉比对把密钥暴露面控制在最小。若需继续深入建议阅读 LiteLLMUsageFetcher.swift 的完整解析逻辑与 Tests/CodexBarTests/LiteLLMUsageFetcherTests.swift 的六组测试用例它们覆盖了个人/团队密钥、无预算场景、/v1归一化、引号清理、401 拒绝等全部关键路径。【免费下载链接】CodexBarShow usage stats for OpenAI Codex and Claude Code, without having to login.项目地址: https://gitcode.com/GitHub_Trending/co/CodexBar创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 LiteLLM 用量接入实战：CodexBar 虚拟密钥方案的数据源、配置与安全边界
LiteLLM 用量接入实战CodexBar 虚拟密钥方案的数据源、配置与安全边界【免费下载链接】CodexBarShow usage stats for OpenAI Codex and Claude Code, without having to login.项目地址: https://gitcode.com/GitHub_Trending/co/CodexBar导读本文以 CodexBar 仓库中的 LiteLLM 接入文档为主线系统讲解如何为 LiteLLM 代理网关配置用量统计从虚拟密钥virtual key加代理 Base URL 的认证模型到/key/info、/user/info、/team/info三类管理端点的数据读取链路再到 HTTPS 校验、密钥存储等安全设计。读完本文你将掌握在 CodexBar 中为 LiteLLM 配置 API Key 与 Base URL 的完整步骤、理解个人预算与团队预算如何映射为菜单栏指标并能依据源码与测试定位常见配置与权限问题。LiteLLM 在 CodexBar 中的定位LiteLLM 是一款流行的 LLM 代理网关通过虚拟密钥virtual key对外统一暴露多个上游模型同时集中管理每个密钥对应的预算与消费。CodexBar 将 LiteLLM 作为一个可选的用量统计 Provider其核心思路是不依赖主密钥master key而是让虚拟密钥通过 LiteLLM 自带的管理端点读取自身的身份、花费与预算数据。这一点在文档中被明确表述为LiteLLM uses a virtual key plus the proxy base URL. The key reads its own identity and budget data through LiteLLMs authenticated information endpoints.从源码角度看该 Provider 由三部分组成Sources/CodexBarCore/Providers/LiteLLM/LiteLLMProviderDescriptor.swiftProvider 的注册描述、凭据适配、取数策略与菜单栏展示规则LiteLLMSettingsReader.swift读取并清洗LITELLM_API_KEY与LITELLM_BASE_URL两个配置源LiteLLMUsageFetcher.swift实现三类管理端点的请求、解析与快照转换是数据链路的执行核心。此外Sources/CodexBar/Providers/LiteLLM/LiteLLMProviderImplementation.swift 负责在应用侧呈现设置表单字段并监听配置变化。配置方式图形界面与配置文件双通道CodexBar 支持两种等价配置途径。方式一图形界面在Settings - Providers - LiteLLM中填写两个字段对应源码中的settingsFields实现字段说明占位示例API keyLiteLLM 虚拟密钥用于读取该密钥自身的花费与预算sk-…Base URLLiteLLM 代理 Base URL允许带/v1后缀管理端点会自动剥离https://litellm.example.com方式二~/.codexbar/config.json{ id: litellm, enabled: true, apiKey: LITELLM_API_KEY, enterpriseHost: https://litellm.example.com }方式三环境变量export LITELLM_API_KEYsk-... export LITELLM_BASE_URLhttps://litellm.example.com两个环境变量的键名在源码中硬编码于 LiteLLMSettingsReader.swiftpublic static let apiKeyEnvironmentKey LITELLM_API_KEY public static let baseURLEnvironmentKey LITELLM_BASE_URL值得注意的细节环境变量的读取会先做空白与引号清理——源码中的cleaned(_:)会trimmingCharacters去掉首尾空白并且如果值被成对的双引号或单引号包裹也会一并剥离对应测试settings reader trims quoted environment values见 Tests/CodexBarTests/LiteLLMUsageFetcherTests.swift。因此LITELLM_API_KEYsk-test这类带引号的写法也能被正确解析。另外CodexBar 还支持在 token-account 存储中保存多把 LiteLLM API Key描述器中的TokenAccountSupport注明 Store multiple LiteLLM API keys.通过环境注入方式把选定密钥传给取数流程。Base URL 的/v1处理与校验规则/v1后缀自动剥离LiteLLM 的代理地址通常形如https://host/v1而管理端点/key/info等并不在/v1前缀之下。CodexBar 在构造管理端点 URL 时会对 Base URL 做归一化managementBaseURL(_:)会检查路径的最后一段是否为v1若是则移除该段后再拼接管理路径LiteLLMUsageFetcher.swift。该行为有测试直接验证management urls accept root or v1 base urlshttps://litellm.example.com→https://litellm.example.com/key/infohttps://litellm.example.com/v1→https://litellm.example.com/key/infohttps://gateway.example.com/litellm/v1/→https://gateway.example.com/litellm/user/info?user_iduser-123嵌套路径同样支持只剥离最后一段v1协议与凭证校验文档明确Base URL 必须满足以下条件否则被视为非法并被拒绝取数必须使用 HTTPS除非该地址指向回环地址loopback、私网地址RFC 1918、链路本地地址link-local或 IPv6 唯一本地地址unique-local或者是一个.localmDNS 主机名不得内嵌凭证如https://user:passhost因为 API Key 会以 Bearer token 形式发送到该地址纯 HTTP 仅对自建代理可用且限回环、RFC 1918、链路本地、IPv6 唯一本地网络。这些规则由ProviderEndpointOverrideValidator().validatedURLAllowingPrivateNetworkHTTP(raw)统一实施LiteLLMSettingsReader.swift与其他 Provider 的端点覆盖校验共用同一套逻辑。值得一提的设计是当 Base URL 配置了但未通过校验时CodexBar 会明确抛出LiteLLMUsageError.invalidEndpointOverride(LITELLM_BASE_URL)并提示使用 HTTPS 或仅对回环/私网地址使用 HTTP、且不得内嵌凭证见 LiteLLMUsageError。为了做到这一点hasBaseURLOverride(environment:)专门区分从未配置与已配置但被拒绝两种状态取数策略据此决定抛invalidEndpointOverride还是missingBaseURLLiteLLMProviderDescriptor.swift避免 Provider 静默不可用让用户无从排查。此外文档还提到一条约束原生取数器native fetcher仍是权威路径配置的插件源plugin origins覆盖 HTTPS 与回环 HTTP但在没有更宽泛的主机网络策略时并不覆盖既有的私网与.localHTTP 契约。即插件化替代方案目前不能完全替代原生取数器对私网 HTTP 场景的支持。数据源与取数流程三阶段请求链路文档给出的调用序列与LiteLLMUsageFetcher.fetchUsage的实现完全一致LiteLLMUsageFetcher.swiftGET /key/info读取当前虚拟密钥自身的user_id与team_id。注意源码注释明确指出Virtual keys may read their own metadata; omit?keyto avoid requiring or exposing a master key.——即请求不带?key参数从而避免暴露主密钥。GET /user/info?user_iduser_id当密钥绑定了用户时读取个人花费、预算与团队列表。GET /team/info?team_idteam_id当密钥是仅团队密钥无user_id只有team_id时读取团队花费与预算。所有请求均为GET请求头固定为Authorization: Bearer apiKey Accept: application/json源码中request(url:apiKey:)的实现LiteLLMUsageFetcher.swift还确认CodexBar 从不请求也不存储 LiteLLM master key仅使用虚拟密钥本身的 Bearer 认证。发送前还会对 API Key 做空白清理fetchUsage中先trimmingCharacters再校验非空。响应字段映射/key/info的响应解析为LiteLLMKeyInfoSnapshot关注字段JSON 字段快照属性说明info.key_namekeyName密钥名称脱敏展示用info.spendspendUSD该密钥累计花费USDinfo.expiresexpiresAt密钥过期时间info.user_iduserID绑定的用户 IDinfo.team_idteamID绑定的团队 ID/user/info的响应解析关注user_info下的user_email、user_alias、max_budget、spend、budget_reset_at以及metadata.preferred_username账户邮箱会按邮箱 别名 preferred_username的优先级取第一个非空值firstNonEmpty。团队信息则从teams数组中按team_id精确匹配/key/info中声明的团队preferredTeam。/team/info的响应解析关注team_info下的team_alias、team_id、max_budget、spend、budget_reset_at、budget_duration。身份一致性校验CodexBar 会把/key/info返回的user_id/team_id与后续/user/info、/team/info响应中的 ID 做交叉比对不一致时直接抛parseFailed(user_id did not match /key/info)或parseFailed(team_id did not match /key/info)LiteLLMUsageFetcher.swift。这一设计保证展示的预算确实属于当前密钥防止越权或串号数据被误展示。用量窗口的映射逻辑个人密钥个人窗口为主、团队窗口为辅对于绑定了用户的密钥主窗口primary个人花费与个人预算user_info.max_budget次窗口secondary与/key/info团队 ID精确匹配的团队预算菜单栏自动指标由于团队预算是该密钥实际被执行的约束自动模式.automatic下菜单栏优先展示团队预算窗口。这一逻辑在描述器的menuBarWindowResolver中实现自动模式下依次选择exhausted(primary, secondary) ?? secondary ?? primaryLiteLLMProviderDescriptor.swift即优先展示已耗尽的窗口否则优先团队窗口。仅团队密钥团队预算为唯一窗口当/key/info没有user_id只有team_id时CodexBar 直接走/team/info分支个人窗口为空团队预算成为唯一用量窗口providerCostSnapshot中period显示为 Team budget。无预算配置保留花费可见性当 LiteLLM 没有为该用户或团队配置预算max_budget为空或为 0时CodexBar 仍以API 花费行API-spend row展示实际花费而不是隐藏整个 Provider。这在providerCostSnapshot()中体现为limit: 0、period显示为 Personal spend 或 Team spendLiteLLMUsageFetcher.swift。对应测试preserves personal spend when no budget is configured验证了used 12.5, limit 0的行为。快照中的其他信息LiteLLMUsageSnapshot.toUsageSnapshot()还会填充subscriptionExpiresAt← 密钥过期时间info.expiresidentity.accountEmail← 解析出的邮箱/别名identity.accountOrganization← 团队别名team_aliasidentity.loginMethod←api。菜单卡片中ProviderCostPresentation依据limit 0选择apiSpend样式否则为hidden即预算场景下花费并入主/次窗口展示不重复显示花费行。权限要求与错误排查虚拟密钥所需的最小权限要让 CodexBar 正确读取用量虚拟密钥必须被允许访问自身的/key/info数据对应user_id的/user/info数据用户绑定的密钥或对应team_id的/team/info数据仅团队密钥。任何一端返回 401/403 都会导致取数失败。测试fetch surfaces rejected virtual key验证了 401 响应会抛出LiteLLMUsageError.apiError(HTTP 401: ...)且只发起一次请求Tests/CodexBarTests/LiteLLMUsageFetcherTests.swift。常见错误与对应提示场景错误类型提示文案未配置 API KeymissingCredentialsMissing LiteLLM API key. Set apiKey in~/.codexbar/config.jsonorLITELLM_API_KEY.未配置 Base URLmissingBaseURLMissing LiteLLM base URL. Set enterpriseHost in~/.codexbar/config.jsonorLITELLM_BASE_URL.Base URL 非法HTTP 公网 / 内嵌凭证invalidEndpointOverride提示改用 HTTPS或仅对回环/私网地址与.local主机使用 HTTP且不得内嵌凭证/key/info无user_id与team_idmissingUserIDLiteLLM key info did not include a user_id or team_id.HTTP 非 2xxapiErrorLiteLLM API error: HTTP status: 响应摘要前 500 字节安全边界文档的 Security 一节虽然简短但结合源码可以确认以下事实密钥按秘密对待LiteLLM 密钥只存于 Provider 配置或 token-account 存储后者支持多密钥管理不落盘到其他位置密钥只发送给配置的 Base URL所有请求统一走Authorization: Bearer头且 URL 校验禁止内嵌凭证避免密钥被当作 URL 的一部分泄露到日志或 Referer不使用主密钥/key/info请求有意省略?key参数既满足虚拟密钥读取自身信息的需要又从设计上杜绝了主密钥的获取与存储私网 HTTP 白名单自建代理在回环、RFC 1918、链路本地与 IPv6 唯一本地网络可继续使用明文 HTTP兼顾本地部署的便利性与公网传输的保密性。小结CodexBar 的 LiteLLM 接入以虚拟密钥自读信息为设计主线一份 Base URL 加一把虚拟密钥即可通过三个管理端点获得个人/团队的花费与预算并自动映射为菜单栏主次窗口与预算/花费两种展示形态。配置上支持图形界面、~/.codexbar/config.json与环境变量三种途径安全上通过 URL 校验、禁止内嵌凭证、不使用主密钥以及 ID 交叉比对把密钥暴露面控制在最小。若需继续深入建议阅读 LiteLLMUsageFetcher.swift 的完整解析逻辑与 Tests/CodexBarTests/LiteLLMUsageFetcherTests.swift 的六组测试用例它们覆盖了个人/团队密钥、无预算场景、/v1归一化、引号清理、401 拒绝等全部关键路径。【免费下载链接】CodexBarShow usage stats for OpenAI Codex and Claude Code, without having to login.项目地址: https://gitcode.com/GitHub_Trending/co/CodexBar创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考