正在加载，请稍候
云端会话没让账单多一行，却把 AIcoding 的瓶颈从本机算力挪到了平台配额。本文只算云端带来的三个增量成本项：环境生命周期、仓库克隆带宽、并发重试，并给出隔离边界与 20 人团队的可复算示例。
有个二十来人的后端团队，这个月账单没多一行，工程师却开始排队「抢配额」——因为编码任务从各自的笔记本搬到了云端，瓶颈从本机 CPU 变成了平台的速率限制。
先对齐事实。Anthropic 的 官方公告页 已经把 cloud sessions（原名即 Claude Code on the web）标为正式可用（GA），覆盖 Pro、Max、Team，以及持有 premium seat 或 Chat + Claude Code seat 的 Enterprise 账号；官方文档确认同一适用范围。所谓「云端会话」，就是跑在 Anthropic 托管云基础设施上的一个编码会话：合上笔记本它还在跑，入口可以是浏览器 claude.ai/code、手机 App 的 Code 标签、桌面端选 Cloud、终端 claude --cloud，以及定时任务（Routines）。
它对账单的影响，可以拆成三个被改写的变量：
claude --cloud 命令创建独立会话、独立运行，可以同时开好几个。本地并行三四个，风扇就开始叫；云端的硬约束不再是你的 CPU，而是套餐给的速率预算。第三个变量不是「多收钱」，而是「钱花在哪变了」。这正是席位制账本要重算的原因。
站内那篇 《桌面端 AIcoding 成本测算：席位费只是账单的第一行》 讲的是桌面端的三层成本：席位费、token 用量、隐性协作开销。本篇不重复它，只算云端带来的增量项——三个在桌面端几乎不存在的科目（组织侧怎么从一人尝鲜推到全组，见站内 桌面端落地指南）。
云端的机器不是一直活着。按 cloud environments 文档：闲置几分钟后它会被暂停（文件保留），你下一条消息会唤醒同一台并重启编码代理；但如果暂停期间它已被回收，重新打开会话就会重建一台全新的。重建意味着环境缓存失效——依赖要重装、setup 脚本要重跑、测试基线要重建。对按工时计费的团队，这部分是「看不见的重复劳动」。
在终端敲下那条云端命令时，远端克隆的是「你当前目录的 GitHub remote 在当前分支」，不是你的本地 checkout——有未推送的本地提交，得先 push，否则云端看到的是旧代码（同上文档）。没有 remote 的仓库会走 bundle 上传，且 bundle 必须小于 100MB，超限会降级到「只打包当前分支」，再超就退化成单次 squash 快照。大 monorepo 团队在这一点上会持续付出带宽与等待成本。
并行是这套云端方案最大的卖点，也最容易吃掉额度。多个任务同时跑，会一起撞上那份额度；一次被限流的任务不是「免费失败」——它已经消耗了此前发生的上下文处理，然后你得重跑。桌面端时代，失败最多浪费本机时间；到了云端，浪费的是全团队共享的池子。多席位团队真正该盯的指标因此变了：不是「多少人买了席位」，而是「每单位额度换来多少个可合并的 PR」。
安全模型值得单独说，因为很多团队误以为「跑在别人的机器上」就自动更安全。Anthropic 的 工程博客 讲得比营销话术清楚：沙箱建立在操作系统原语上（Linux bubblewrap、macOS seatbelt），提供两层边界——文件系统隔离（只能读写特定目录）与网络隔离（只能连到批准的服务器）。两层缺一不可：只有文件系统隔离，被提示注入的 agent 能外传 SSH 密钥；只有网络隔离，它能逃出沙箱再拿网络。工程博客给出的内部数据是：沙箱把权限弹窗减少了 84%。站内 Claude Code 沙箱架构深度解读 对本地侧的沙箱实现有更细的拆解。
凭据边界是另一半。托管环境里 GitHub 凭据加密存在服务端，从不进入会话的虚拟机；机器里的 git 操作走 GitHub 代理，由服务端附加凭据（文档）。收益是实打实的，但代价是你得主动补两件事：
还有两个容易被忽略的坑：原生 Windows 上用 bundle 上传时，已跟踪文件里未提交的敏感内容会原样上传（macOS / Linux / WSL 会剔除 .env、*.tfvars、id_rsa、*.pem 等）；启用了 Zero Data Retention 或应用了 HIPAA 配置的组织，根本用不了 /web-setup 及其他云端功能。选型时这两条要先过合规。
| 工作场景 | 云端是否合适 | 原因 |
|---|---|---|
| CI 集成、按 PR 触发修复 | 适合 | 会话可自动化触发，产出可转 PR 的分支；Auto-fix 可用（需装 Claude GitHub App） |
| 批量文档校对、结构化日志重构 | 适合 | 任务定义清晰、可并行、验收标准明确 |
| 依赖本机私有依赖 / 内网数据库 | 不适合 | 机器跑在 Anthropic 网络，默认只放行 allowlist 域名，连不上内网 |
| 需要真实设备、驱动或专有 SDK | 不适合 | 环境是标准化的，装不出你的硬件 |
| 需要反复人机结对调试 | 看情况 | 云端适合「派活」，本地交互式调试仍更顺手 |
一条实用的分工原则来自官方文档：「本地做规划，云端做执行」——复杂任务先用 plan 模式在本地把方案谈妥，把计划提交进仓库，再让云端自主执行。另外，交接只能单向：--teleport 能把云会话拉回本地终端，但推不上去，你没办法把一个已经在本地跑的会话「送到云端」。
用官方定价（Anthropic 定价页）搭个模型。假设 20 人团队，其中 8 名平台 / 后端工程师配 Premium 席位（更高用量），12 名配标准席位：
只跑桌面端，账到这里基本就完了。但一开放云端，约束就换成额度怎么分：这 1,040 美元买到的是若干份共享预算，而云端得和终端、IDE、桌面端抢同一个池子。这套「席位 + 额度」的拆分口径，是 蓝曜炬辉（www.lanyaoai.com）在企业 AIcoding 落地项目里常用的记账方式。于是要回答的问题，从「买几个席位」变成：
算清楚这三条，才知道要不要把几个人升到更高档套餐，或者干脆对「批量文档校对」这类任务设并发上限。Enterprise 的口径不一样——席位价加上按 API 费率的用量，也就是「用得越多、账单越随用量走」，在这条路径上，额度规划更接近容量规划，而非采购人头。
问：云端会话要额外付费吗？
答：不需要。它被算进套餐能力，Pro、Max、Team 与部分 Enterprise 席位均可使用；限制在于额度需与终端、IDE 等入口共用。
问：独立虚拟机就等于权限自动安全了吗？
答：不是。它提供文件系统与网络隔离，凭据默认不进机器，但你仍要配置访问级别、收紧 allowlist，并留意 Team / Enterprise 暂不支持 API credentials。
问：本地已经改了一半的代码，能直接派给云端吗？
答：不能直接推。远端克隆的是仓库当前分支，本地未推送的改动要先 commit + push；没有 remote 的仓库走 100MB 上限的 bundle 上传。交接只能单向，--teleport 从云到本地。
问：哪些仓库不适合放到云端？
答：依赖内网数据库、私有依赖源或专有硬件的仓库。默认只连 allowlist 域名，连不回你的内网。
问：在云端跑得越多越省钱吗？
答：不一定。它不单独计费，却会消耗共享额度；并发越高，撞限额与重跑的概率越大，隐性的环境重建开销也跟着涨。更值得看的，是这份额度最终转化成多少个可合并的 PR。