Claude Code 的 Cloud sessions 一放开，评论区吵得最凶的不是它好不好用，而是那笔钱到底怎么扣。Pro 用户看到 $100，Max 用户看到 $250，第一反应几乎都是"白送的额度"。Claude Devs 随后把话说清楚了：这是一次性的、可选的抵用金，Cloud sessions 会优先把它烧掉，烧完之后才回到你本来就有的 Pro 或 Max 订阅用量里去扣。听上去只是一句计费说明，实际上它决定了你该不该现在就去点那个开关。
抵用金的消耗顺序，比金额本身更要紧
先扣抵用金，再动订阅额度
顺序是这件事的全部重点。按 Claude Devs 的说法，Cloud sessions 产生的消耗会先从那笔一次性抵用金里出，抵用金见底之后，超出部分才计入你原本的订阅用量。翻译成人话：在抵用金还没烧完的那段时间里，你跑云端会话不会挤压平时用 Claude Code 的额度。这段窗口期的价值不在于"免费"，而在于它允许你在不改变日常使用习惯的前提下，去摸清云端执行的成本结构。
窗口一关，规则立刻变回原样。Cloud sessions 和补全、重构、Agent 任务一样，从同一个池子里扣。这是个容易被忽略的转折点——很多人会拿抵用金期间的使用手感去推断长期成本，结果发现续费后额度掉得比预期快。
它被标注为"可选"，不是随手写的
推广类额度最容易引发三种误解：以为自动生效、以为会自动续期、以为背后藏着一条新的付费通道。这次三条都不成立。抵用金需要你主动去用，一次性，上限明确，用完即止。对谨慎的用户而言，完全可以不碰它，订阅状态不会因此产生任何变化。
反过来看，对想搞清楚云端会话到底吃多少额度的人来说，这笔钱是一次低风险的实验预算。你不用自己掏钱试错，但试出来的数据是真实的。
Cloud sessions 没有一张单独的账单
这一点值得单独拎出来说。行业里谈"云端 Agent"，常见的做法是配一套独立的计费体系——按执行时长、按沙箱资源、按并发数分别收。Claude Code 走的是另一条路：执行放到了远端，计费仍然挂在订阅上，不额外加价，也没有平行账本。
好处是账目简单，你不需要在脑子里维护两套用量。代价是它和本地使用共享同一个额度上限，重度依赖云端会话的时候，本地那边的空间会被一并压缩。这不是 bug，是设计选择，但用户得知道自己站在哪一边。
合上笔记本之后，Agent 还在跑
研究预览这个标签，摘掉了
Cloud sessions 正式可用，脱离了研究预览状态。这个动作的含义常被低估。挂着"研究预览"的功能，官方随时可以改接口、调行为、甚至直接下线，用户也默认不指望它稳定。摘掉标签意味着团队认为它达到了常规功能的交付标准。
对一个每天都要跑代码任务的开发者来说，这个区别很实际：你可以把它写进工作流，而不只是拿来玩两天。
执行被从本地挪走了
核心能力一句话讲完：合上笔记本，任务继续。本地 Agent 的软肋一直很清楚——机器得开着，网络得连着，终端窗口不能关。云端会话把执行环节搬到了远端，关盖子、断网、换台设备登录，都不影响任务继续推进。
对短任务，这个变化无关痛痒。但对那种要跑一轮又一轮迭代、改完测试再改的长链条工作，体验差别是断崖式的。你不再是那个守在终端前面等结果的人，而是隔一段时间回来看一次进展的人。工作节奏从"盯着跑"变成"派出去"。
它适合谁，不适合谁
任务链长、迭代次数多、不想被机器绑住的人，会立刻感受到价值。反过来，如果你的代码依赖本机特定的环境变量、私有文件系统，或者团队对代码不能离开本机有硬性合规要求，云端执行就不是一个可以随手切换的选项。便利性和可控性在这里仍然是两条路，暂时没有中间态。
订阅用户该怎么算这笔账
$100 与 $250 之间的落差
Pro 拿 $100，Max 拿 $250。这个差距不是随手定的倍数，它透露了团队对用量分层的判断：Max 用户的会话强度更高、并行任务更多、单次执行时间更长，所以给的实验预算也更高。
对 Pro 用户来说，$100 放在真实任务里大概够跑一段像样的验证期，但撑不起长期依赖。心里有个数：这笔钱是用来回答"我要不要把它纳入日常工作流"这个问题的，不是用来省订阅费的。
抵用金是消耗品，不是长期额度
一次性，用完就没了，不会有第二次。这决定了唯一正确的使用姿态——把它当验证工具，而不是省钱手段。如果你的判断是"有这笔钱我才用，没有就不用"，那答案其实已经出来了：这个功能对你的价值还没到能自我支撑的程度。
先跑两周，再决定要不要上头
比较务实的做法是，在抵用金窗口内挑几类你平时真会做的任务，长短搭配着跑，记录消耗速度。等抵用金见底，你会得到一份属于自己的成本曲线，而不是别人嘴里的"够用"或"不够用"。这份数据比任何评测都准，因为它是从你自己的使用习惯里长出来的。
到那个时候再决定要不要继续依赖 Cloud sessions，才算是把这笔账算清楚了。
