我的 Claude Code 配额耗尽了。我用 Qwen Cloud 撑完了那一周——花费分毫可查

我的 Claude Code 配额在一个星期二耗尽了。周二下午,一周的中段,一件工作的中段。

我正在做一个提取任务:焦氏易林——一部汉代占卜文献,4,096 个古汉语条目,我的 coding agent 正把它们整理成结构化数据。它还有好几天的工作要做,配额却一点不剩了。

如果你在香港做 AI 开发,你早已习惯这堵墙。美国的大型服务封锁我们,所以我们学会绕行,随时准备替代方案。这个星期二的不同之处不在墙本身,而在它倒下的位置:我自己的主力工具,在一件只有它知道状态的工作中间。

于是我做了那件一直想试的事:把 Claude Code 指向 Qwen Cloud,让它撑完这一周。以下是这一周的花费,精确到 token。控制台给了我完整的账单,所以这不是凭感觉的评测,而是一张账单。

换后端只需要一个配置文件

Qwen Cloud(阿里云 Model Studio,新加坡区)的 Token Plan 正是为此而生。你会拿到一把专属 API key 和一个兼容 Anthropic 协议的 base URL。任何支持 Anthropic 协议的工具都能接上——Claude Code、Cursor、Qwen Code、Codex、Qoder、OpenClaw。

我为每个后端保留一个配置文件,需要时把对应的符号链接到 ~/.claude/settings.json:

• -settings.json.claude — 平常的一周
• -settings.json.deepseek — 我另外购买的 DeepSeek 方案
• -settings.json.qwen — 这篇文章的那一周

切换就是换一个符号链接,重启一次。撑过重活那天的配置长这样(密钥已省略):

记住倒数第二行。它决定了这个故事的一半。

积分不是 token

Token Plan 不按 token 计费,而是按积分(credits)计费,每次调用扣除:

积分 = (输入 × 输入系数 + 缓存输入 × 缓存系数 + 输出 × 输出系数) / 10,000

网页搜索等工具调用另行计费。系数按模型而定,而且只在控制台公布,文档里没有。公开的唯一计算示例是 qwen3.6-plus:大约每积分 5,000 个新输入 token、25,000 个缓存 token、830 个输出 token。缓存输入比较便宜,但不是免费。这句话后面会起大作用。

个人方案如下(括号为限时价):

三条规则让这个制度变得锋利:

• -7 天窗口从你第一次调用开始,不是从购买那天。
• -碰到上限,服务就暂停。没有降级运行,必须等满 7 天。
• -未用完的积分不会结转。

有一个"重置用量上限"的控制项,也有夜间费率:qwen3.8-max 在 HKT 22:00 到 08:00 之间半价。夜猫子工作流有补贴。而我的,事后证明,没有。

403 的那一晚

在 Token Plan 接上之前,我在按量付费上度过了一个晚上。当晚的请求日志读起来像心率图。一个跑在 qwen3.8-max 上的 agent 会话,五分钟,输入 token 每一轮都在攀升:

42k → 44k → 68k → 70k → 72k → 75k → 87k → 91k → 97k → 101k → 103k → 106k

大约五分钟内 128 万个输入 token。每一轮,agent 都把到目前为止的整个对话重新读一遍。按定价,这一波大约花掉 $2.65——而它的结局只有一种:

HTTP 403 — AllocationQuota.FreeTierOnly

墙,现场现行。这个错误就是我买 Token Plan 的那一刻。

一天,两匹马

第二天,Token Plan 承载了真正的工作量。我事后从控制台拉出了每日数字。以下是我 Token Plan 近 30 天的用量,以 token 计:

一天吃掉了整个窗口。Token Plan 按滚动的 7 天窗口限流,不按日历月计——月视图只是把窗口排在一起。那个尖峰是一个工作日烧掉了整个窗口的额度:3.56 亿个 token。然后我把 8 月 20 日按模型拆分,事情变得更有趣了:

两匹旗舰级模型并行了一整天,几乎平分秋色。形状说明了各自的工作。qwen3.8-max 是读者——94% 缓存命中、输出简短,还有全部 621,000 个图像 token,也就是喂给提取任务的扫描页面。qwen3.7-max 是写手——输出是前者的 2.4 倍,每次生成都是全新上下文,缓存命中只有 68.7%。

为什么它们会并行?再看一次配置:

CLAUDE_CODE_SUBAGENT_MODEL — qwen3.7-max

主循环跑 3.8-max。Claude Code 生成的每个子代理都跑 3.7-max。 这个环境变量我很早以前设过一次,之后再没想过它。它悄悄决定了那天将近一半的账单。按定价,3.7-max 每个 token 甚至比 3.8-max 更贵——你放在子代理位置的模型不是脚注,而是一个成本决策。

账单

现在把那一天换算成积分。阿里没有公布 qwen3.8 的系数,所以用公开的 qwen3.6-plus 费率做代理估算,把它当作数量级就好:

• -3.8-max:约 10,100 积分(大头是 1.72 亿缓存 token——光是缓存就 6,900 积分)
• -3.7-max:约 17,600 积分
• -flash:零头

一个工作日 ≈ 27,700 积分。而 Standard 方案一整个星期只有 10,000。那一天相当于 2.8 个 Standard 周。Pro 的 40,000 大约撑一天半。

这是我亲身经历的过程:正如算式所示,Standard 的 10,000 在周中耗尽。我升级到 Pro。我还是买了 $15 的积分包——20,000 积分,不受窗口限制——等我坐下来写这篇文章时,它只剩 8,841.89。计量表不讲价。

带回 Claude 的修正

这是我没预料到的部分。教训没有只流向 Qwen,而是流回了我的 Claude 配置。

固定配额和积分暴露的是同一件事:重复读取上下文才是真正的成本。我的高负载会话一路跑到约 100 万的上限,然后每一轮把一切重新发送——和 403 那晚一模一样。于是我设置了自动压缩窗口:

CLAUDE_CODE_AUTO_COMPACT_WINDOW = 400000

到 400k 时,会话会在重复读取变贵之前压缩自己的历史。效果在一周后测出来了:整整一周高强度 Claude Code 工作——以前会在星期二就杀死配额的那种工作——撑到星期日早上,用了 97%。剩下 3%,离重置还有几个小时。紧,但活着。修正之前,周中耗尽是常态。

再坦白一件事。这周我新建 settings.json.qwen 的时候,漏掉了自动压缩窗口。教训只住在我的 Claude 配置里,哪里都没去。我在它闯祸之前抓到了。如果你为每个后端保留配置文件,每一个都要检查。纪律不会自己迁移。

账单之后的配置

开头那张表,是我进场时的配置——账单后来点名的两处天真:没有压缩防护,子代理位置停着一个旗舰级模型。之后变了两件事:一周的计量表读数,和一个新的便宜模型 qwen3.8-flash。这是 settings.json.qwen 今天的内容(密钥已省略):

三行变了。每一行都是账单里的一条,落回了配置:

• -子代理位置从 qwen3.7-max 降到 qwen3.8-flash。计量表说明这个位置的代价:尖峰日 48% 的 token,按旗舰级费率。新发布的 flash 提供了更便宜的模型。现在子代理跑 flash,主循环负责写。
• -CLAUDE_CODE_AUTO_COMPACT_WINDOW 写进了配置文件。400000——上面坦白漏掉的那一行,补上了。
• -haiku 位置换成 qwen3.8-flash。背景调用跟上了当前的便宜模型。

如果你要进场

七个动作,每一个背后都有数字:

• -第一个会话之前,先设好自动压缩窗口。 CLAUDE_CODE_AUTO_COMPACT_WINDOW 设在 300–400k。这是最大的杠杆:我没设防的那一天是 3.56 亿个 token,而压缩之后的同样一周工作,装进了一个固定配额。这个方案惩罚重复读取,压缩就是你停止重复读取的方法。
• -不要让上下文上限不设防。 CLAUDE_CODE_MAX_CONTEXT_TOKENS 逼近 100 万又没有压缩,等于上限就是你的成本上限。两者要搭配,否则就把上限调低。
• -把子代理模型当成成本决策来选。我的子代理通道吃掉了那天将近一半的 token,缓存命中率更低,输出却是 2.4 倍。只做侦察的子代理:用便宜的模型。要出货的生成:用好的模型。不要放任它停在几个月前设的值。
• -按你最重的一周来买,不是按平均的一天。Standard 的 10,000 积分,对一两个代理的聊天和轻度编码是真够用的。持续的 agent 工作——我的一天估算约 27,700 积分——意思是 Pro,不然就是 Standard 加上随时待命的积分包。
• -把积分包当桥,不当底。它不受 7 天窗口限制,这正好是尖峰日的形状。
• -能挪到夜间的都挪。qwen3.8-max 在 HKT 22:00 到 08:00 半价。
• -先看一周自己的计量表,再相信任何费率表——包括本文的。系数没有公布,你自己的工作负载才是唯一诚实的基准。

再补一句:旧的按请求计数的 Coding Plan 把成本和上下文长度完全脱钩。对长上下文的 agent 工作,这就是它全部的论点——也是为什么在压缩驯服重复读取之前,积分制感觉那么残忍。

计量表教会我们的事

Qwen Cloud 不是慈善机构,Token Plan 也不是凭空变钱。它是一个计量表。这结果证明是它最好的功能。

固定周配额只告诉你什么时候用完。积分计量表告诉你什么在吃:缓存重复读取、不设防的上下文上限、指向错误模型的子代理位置。这些全都可修正,而固定配额恰恰把这些藏起来了。

这适合谁?如果你是香港开发者,光是访问这一点就够了——它让 Claude Code 跑在你真正有权使用的模型上,还能给财务团队交出清楚的账单。如果你在别处,睁大眼睛进去:不要猜系数,看一周的计量表,按自己的工作负载校准。早压缩。守住上下文上限。选子代理模型的时候,像按 token 付费那样认真。

因为你就是在按 token 付费。

Augustin Chan 是 Hong Kong AI Podcast 的共同主持人。本文数字取自他本人的控制台:2026 年 8 月 30 日获取的 Token Plan 用量 API 响应与请求日志。积分估算以阿里公布的 qwen3.6-plus 示例费率为代理,请以数量级视之。

在我们发布新文章和节目时收到通知。没有垃圾邮件，只有信号。