排障

Codex CLI 接入 CCSub 报错 upstream_insufficient_balance 完整排查指南

排障2026-10-03·10 分钟阅读

如果你用 Codex CLI 接到 CCSub 之后,请求突然失败并返回 upstream_insufficient_balance,第一反应往往是「我明明刚充过钱」。这条报错和 Claude Code 常见的余额不足看起来相似,实际涉及的结构不一样。下面按三层结构拆开讲清楚,并给出可以直接照做的排查步骤。

先分清三层「余额」,报错含义不一样

在 CCSub 上跑任何客户端,额度问题都只可能出现在三层中的某一层。把它们分开看,排查速度会快很多:

  • 本地 CCSub 账户余额:你在 CCSub 账户里剩余的可用金额。不足时,请求在进入上游之前就会被拦下。
  • CCSub 侧对上游的额度:CCSub 向模型提供方发起调用时需要消耗的资源。这一层出现问题时,客户端看到的就是 upstream_insufficient_balance 这类上游侧报错,而不是本地余额不足。
  • Codex CLI 自身的用量展示:Codex CLI 在终端里统计的 token 数量,只反映「这个会话消耗了多少」,不代表账户里还有多少钱。它很容易让人误判。

关键结论:Codex CLI 显示的 token 数字和账户余额是两套东西,看到 token 没跑多少,不代表余额是满的;反过来也一样。

为什么 Codex CLI 更容易撞上这个报错

Codex CLI 走的是原生 Responses 接口(wire_api = responses),默认会对 https://ccsub.xyz/openai/responses 发起请求。相比一次性的短问答,Codex CLI 的会话往往更长、上下文更大、连续调用更密集,单位时间内消耗的额度明显更高。如果你同时开着多个终端窗口,或让 Codex CLI 长时间自动执行任务,额度下降会比你预期更快。

在平台的错误统计里,upstream_insufficient_balance 属于出现频率较低但会真实影响使用的一类错误,它和 connect_error、upstream_unavailable 的处理方式完全不同——前者要看额度,后两者要看网络和线路。

第一步:确认是不是本地余额问题

  1. 登录 ccsub.xyz 账户,查看当前剩余额度。
  2. 如果显示的余额已经很低,直接去 /docs/pricing 按文档说明充值。文档里写明了注册、选金额、充值、创建 API 密钥的完整流程。
  3. 充值到账后,重新发起一次 Codex CLI 请求。如果报错消失,问题就到此为止。

注意:充值后不需要重新生成 API 密钥,但如果你在多个客户端共用同一个 Key,建议确认没有其他客户端同时在大量消耗额度。

第二步:余额充足却仍然报错怎么查

如果余额明显还有余量,但 Codex CLI 持续返回 upstream_insufficient_balance,按下面顺序排查:

检查 Codex CLI 配置是否指向了错误地址

Codex CLI 的正常配置应该是:

base_url = "https://ccsub.xyz/openai"
wire_api = "responses"

Codex CLI 会自动向 https://ccsub.xyz/openai/responses 发送请求。如果你把它填成了 https://ccsub.xyz/v1,请求会被路由到 OpenAI 兼容通道,行为不一致,容易产生难判断的报错。

检查模型 ID 是否真实存在

Codex CLI 使用的模型必须在平台模型列表里。可以先查一遍:

curl https://ccsub.xyz/v1/models \
  -H "Authorization: Bearer sk-你的CCSub密钥"

确认返回的列表里包含你配置的模型 ID,再继续往下查。填错模型 ID 可能触发上游侧的错误响应,其中就包括额度类报错。

核对 Codex CLI 的 token 统计

Codex CLI 会在会话中输出 token 消耗。它的作用是帮你判断单次会话的开销量级,而不是账户余额。如果你发现某个会话短时间内消耗了异常大的 token 数量(比如长时间自动循环、反复读取大文件),那额度下降速度就会远超预期。关于 token 统计的口径和常见异常,可以参考站内 Codex CLI token 消耗诊断相关文章,对照着看懂每一栏数字代表什么。

第三步:区分它和 Claude Code 余额报错的差异

同样叫「余额不足」,Claude Code 走的是 ANTHROPIC_BASE_URL=https://ccsub.xyz/api,客户端自动请求 /v1/messages;Codex CLI 走的是 https://ccsub.xyz/openai,自动请求 /responses。两条链路的上游不同,报错的触发条件也不同。

因此,Claude Code 的余额排查文章(claude-code-balance-insufficient-troubleshooting)里的步骤不能直接套用到 Codex CLI 上。你可以沿用「本地余额—上游额度—客户端用量」这个三层框架,但每一层的检查点和数据来源都要按 Codex CLI 的链路替换。

通用接入配置:方便对照检查

如果你需要重新校验配置,下面三种接入方式的正确写法如下。

OpenAI 兼容调用

export OPENAI_BASE_URL=https://ccsub.xyz/v1
export OPENAI_API_KEY=sk-你的CCSub密钥

请求地址为 https://ccsub.xyz/v1/chat/completions。适合 Cursor、VS Code、Windsurf、CherryStudio、OpenCode、OpenClaw 等客户端。

Codex CLI 原生调用

base_url = "https://ccsub.xyz/openai"
wire_api = "responses"

Codex CLI 自动请求 https://ccsub.xyz/openai/responses。

Claude Code 原生调用

export ANTHROPIC_BASE_URL=https://ccsub.xyz/api
export ANTHROPIC_API_KEY=sk-你的CCSub密钥

Claude Code 自动请求 https://ccsub.xyz/api/v1/messages。

日常使用中的额度管理建议

  • 给不同客户端分开建 API 密钥。Codex CLI 消耗快,单独一个 Key 更容易追踪用量,也能避免一个 Key 出问题影响全部工具。
  • 别把 Codex CLI 的 token 数字当成余额。想确认余额只看账户页面,不要在终端里推算。
  • 合理选择模型。不同模型的输入输出单价差异较大,长会话任务用高单价模型时额度消耗会明显加快。定价分组在 /docs/pricing 有说明。
  • 控制自动执行范围。让 Codex CLI 长时间无人值守地跑任务,容易在你不注意时消耗大量额度。
  • 遇到不认识的报错先看文档。/docs/troubleshooting 里有按症状整理的排查表和速查入口。

常见问题

充值之后还要重新配置 Codex CLI 吗?

不需要。充值只影响账户余额,配置地址和密钥都不用改。重新发起请求即可。

为什么有时候第一次请求正常,后面才开始报错?

说明额度是在使用过程中被消耗掉的,而不是一开始就不足。重点检查是不是有超长会话或并发任务在持续消耗。

能不能同时用 Codex CLI 和 Claude Code?

可以,两者接入地址不同、互不冲突。但建议使用不同的 API 密钥,方便分别观察用量。

下一步

如果你还没充值,先到 /docs/pricing 按文档完成流程,这是解决 upstream_insufficient_balance 最直接的一步。如果余额正常但报错仍在,就按本文第二步依次核对 Codex CLI 的 base_url、模型 ID 和 token 消耗情况。接入过程中遇到其他报错,可以在 /docs/troubleshooting 按症状查找对应条目。

读完想动手试试?3 分钟接入 CCSub。