Claude Code的402错误：不只是余额不足

我在没有 Anthropic 订阅的情况下运行 Claude Code 大约三个月了。不是因为付不起——只是我的用量波动太大。忙的时候一周能顶得上三个安静月份的量。

这期间我遇到了一些错误，理解起来比想象中要久。写下来，方便有同样问题的人搜索到。

"402 Insufficient balance" 但你明明有余额

这个错误困扰了我整整一个下午。

系统在每次请求前会放置一笔预授权冻结款，金额按照该次调用的最大可能成本来计算——而非预期成本。必须这样做，否则你可能在余额只剩 0.02 美元时发起一个大文件生成，中途就开始欠费了。

这笔冻结款通常比你实际花费的要大得多。响应完成后，系统会按实际用量结算，并立即释放差额。

所以当余额较低时，一笔实际只需 3 美分的请求可能因为需要 40 美分的冻结款而被拒绝。错误信息显示余额不足——技术上说没错，但实际上容易误导。

解决方法：保持比你想象中更大的余额缓冲。我一直维持大约 8 美元，再没遇到过这个问题。

另外值得知道——以下情况根本不会扣费：

你在中途按了 Ctrl+C

我特意测试了最后这个场景。冻结款释放了，余额完好无损。

"503 No supply available"

意思是当前没有闲置配额供这个特定模型使用。

这是点对点供给模式的固有特性：供应来自真实用户未使用的订阅时段，而人有作息规律。我有一次在凌晨 3 点遇到了一堵 503 墙——大多数卖家的机器都关机了，或者他们的窗口还没轮换过来。

有两件事比较有帮助：

选择多个模型，而不是一个。购买页面允许勾选多个。当一个没有供应时，会自动切换到下一个。我一般勾选 3-4 个可比的模型。

不要在深夜安排关键任务。说起来容易做起来难。工作时间段的供应明显更好。

市场供应持续刷新，卖家窗口每 5 小时轮换一次，所以 503 错误通常不会持续太久。那堵凌晨 3 点的墙大约 20 分钟后就消散了。但如果你需要保证可用性，这个模式并不适合你——这是真实的权衡，不是挑剔。

开关开了但没有任何流量路由

三个原因，按频率排序：

1. 你没有重启工具。Claude Code 在启动时只读取一次 settings.json。这占了大多数反馈。关闭所有窗口，打开一个新的。

2. 工具覆盖了自己的配置。有些 CLI 在升级时会重写配置文件，抹掉你的修改。从购买页面重新应用配置，然后重启。

3. 环境变量优先级高于配置文件。这个是 Gemini CLI 特有的，而且确实坑。~/.gemini/.env 会败给同名真实环境变量。如果你曾在 .zshrc 里放过 GEMINI_API_KEY，那个就会生效——静默地。

echo $GEMINI_API_KEY
echo $GOOGLE_GEMINI_BASE_URL

任何输出都意味着你中招了。当场 unset 它们，或者从 shell rc 文件里删除那些行以获得永久修复。

真正改变了我成本的习惯

说实话不是定价的问题。是三个习惯，全都是免费的：

在不同任务之间清理上下文。用量是按上下文计费的，不是按请求次数。在一个 8 小时的会话里问一句一行的问题，比全新会话问同样的问题要贵一个数量级。

通过子 agent 路由探索性任务。当需要读取二十个文件来回答问题时，这些都会进入你的主上下文，并给后续每条消息都带来负担。子 agent 在自己的窗口里读取，然后返回摘要。

精简规则文件。我的有 200 行，每次会话完整加载。精简到 30 行后 agent 反而遵守得更好——长文件会埋没重要规则。

先做这些。比切换提供商能省下更多。

我在哪里用它、哪里不用

机制是这样的：你的请求会通过另一个用户的客户端中转，再由它向上游发起调用。这意味着载荷在这个中转节点是可见的——没有端到端加密。平台在他们自己的首页上明确说明了这一点，而不是藏在角落，这也是我信任他们其他声明的部分原因。

这给我划了一条清晰的界线。个人项目和开源：没问题。任何处于 NDA 下的东西：绝对不行，而且我不认为这是个模糊的权衡。

这个工具叫 Asale，客户端在 GitHub 上，如果你想了解它实际发送什么可以在运行前先看看。我认为这是必备条件，不是加分项——对于任何中转你请求的工具都该如此。

有人找到了比多选模型更好的 503 问题处理模式吗？很好奇大家是否在用更智能的降级策略。