买 AI 订阅最容易犯的错，是拿「我一天用几小时」去估。真实决定因素有两个：你同时开几个任务，以及每个任务吃多少上下文。一个终端慢慢干，入门档通常够用；四个任务并行跑，每个都在自己读文件、跑命令、思考，消耗大约是四倍。
这篇把两家的档位结构、额度的限制方式、订阅与按量付费怎么选、以及上手必须配的三件事讲清楚。所有价格都以官方页面为准——这类数字几个月就动一次，我核到的是写这篇文章时的状态，你付钱前请自己再看一眼官网。
一、先搞懂一件事：额度不是按「次」算的
很多人以为订阅是「每月多少次」，所以撞上限时很困惑：明明才问了十几个问题。
实际上消耗和这些有关：上下文有多长（它读了多少文件、历史有多长）、用的哪个模型（贵的模型吃得快）、任务轮次（来回改了几次）、并行了几个。一个 agent 在大仓库里反复读文件，一小时能烧掉一个聊天用户一周的用量——这不是夸张，是很多人第一次用 agent 时的真实体验。
所以估算需求的时候，别数次数，数并行度和上下文。
二、Claude 的档位结构
先说一个关键事实：Claude Code 不单独卖，它是订阅的一部分。免费档没有，从付费档开始才有。
| 档位 | 价格（官方页面，不含税） | Claude Code |
|---|---|---|
| Free | $0 | 不含 |
| Pro | 年付折合 $17/月（一次性付 $200），月付 $20 | 含 |
| Max | From $100/月，可选 Pro 的 5 倍或 20 倍用量 | 含 |
| Team 标准席位 | 年付 $20/席/月，月付 $25 | 含 |
| Team 高级席位 | 年付 $100/席/月，月付 $125 | 含 |
| Enterprise | $20/席/月（年付）+ 用量按 API 费率另计 | 含 |
| API（控制台） | 按 token 计费，无会话上限 | 自带 key 即可用 |
几个容易看漏的点：
- 年付折扣只有部分档位有。Pro 年付能省一截，而重度用户最可能用到的高档位通常只支持月付。
- 倍数是「每次会话」的倍数，不是「每月」的。这是定价页最常被误读的一处。
- 编码和聊天共用一份额度。白天在网页版聊了很久，晚上跑 agent 的钱就少了。这个坑非常常见。
- 按量付费（usage credits）可以在超出包含额度后继续干活，按 API 费率另算。
- 官方不公布任何档位的 token 数，只公布相对倍数——因为实际消耗取决于你的上下文长度和模型选择。
三、额度的三层限制
付费档通常是两个时钟叠加，理解这个能省掉很多困惑：
第一层：滚动的 5 小时会话窗口
从你第一条消息开始计时，向前滑动。
一个高强度的下午就能把它用完，而周额度几乎没动。
第二层：周上限（按固定时间重置，不滚动、不累计）
├─ 全模型共用的周额度
└─ 高端模型单独的一条周额度
→ 所以「我这周明明没怎么用」和「你已超出限制」
可以同时成立：你撞的是高端模型那一条。撞上限的时候先别怀疑东西坏了，用 /usage 看一眼是哪一层到了顶：5 小时窗口、全模型周额度、还是高端模型周额度。三种情况对策完全不同——第一种等窗口滑动就行，第二种得省着用，第三种换个模型继续干。
四、Codex 的订阅与用法
Codex 的订阅结构和 Claude 不一样：它是和 ChatGPT 的订阅捆绑的，没有独立的「Codex 套餐」。具体档位名和价格请查 OpenAI 官方页面——这部分更新频繁，我不写死数字，免得误人。
用法上的差异比订阅更值得说。Codex 的设计取向是并行和后台：
- 它会起一个隔离的云端环境，克隆你的仓库，干活，然后回一个 PR，全程不用你盯着；
- 多个任务可以并行，各自在独立的工作副本里，互不冲突；
- 适合那些「能说清楚、跑起来要很久」的活：迁移、批量改、补测试。
代价是：任务之间不共享上下文，你上次说过的约束下一次它不一定记得；云端环境的网络和权限通常是受限的；任务描述含糊时它容易跑偏。所以给 Codex 的任务书要比给终端 agent 的写得更完整、更自包含。
五、订阅还是按量付费，怎么算
判断标准其实就一条：你的用量是稳定的，还是突发的？
| 场景 | 建议 | 理由 |
|---|---|---|
| 每天都在用，量比较稳 | 订阅 | 订阅相当于把「每 token 单价」打了个大折扣，重度用明显划算 |
| 偶尔用，集中在某些天 | 按量付费 | 订阅的额度不累计，闲着的月份等于白交 |
| 重度用且经常撞上限 | 高档位订阅 + 按量兜底 | 包含额度用完后按量续，比直接买最高档灵活 |
| 跑 CI、批量重构、夜间任务 | 按量付费（走批处理） | 批处理通常有折扣，且异步任务不和你的交互抢额度 |
| 接单做交付，成本要可控 | 订阅 + 按量，并设支出上限 | 项目制必须能预测成本，否则利润全变成 token |
做交付的尤其要注意最后一条：接活之前先把这笔钱算进报价。AI 辅助交付的成本结构变了——人天少了，token 多了，别到最后发现省下的时间全花在账单上。
六、上手必须配的三件事
第一件：给每个仓库写一份项目说明文件
这是投入产出比最高的一件事。agent 每次启动都要重新摸索：怎么构建、怎么跑测试、代码风格是什么、哪些目录不能碰。你不写，它就猜，猜错了就是你来擦屁股。
# 项目说明文件（放在仓库根目录）
## 构建与测试
- 构建：mvn -q clean package -DskipTests
- 跑单个测试：mvn -q test -Dtest=OrderServiceTest
- 跑全量：mvn test
- 提交前必须跑：mvn test
## 约定
- Java 17，不要引入 Lombok（项目没用）
- 所有对外接口必须校验入参，不要相信上游
- 异常统一走 BizException，不要直接抛 RuntimeException
- 数据库改动必须有对应的迁移脚本，禁止直接改表
## 不要碰
- config/ 下的生产配置
- 任何带 @Deprecated 的遗留模块（正在下线，改动会被回滚）
## 提交
- 提交信息用中文，格式：模块：做了什么
- 一次提交一件事，不要把重构和功能混在一起写得越具体，它犯蠢的概率越低。尤其是「不要碰」那一节，能省掉很多次返工。
第二件：大改动先让它出方案
跨文件重构这类活，先让它只读不写，输出方案和风险评估，你确认之后再执行。一次性的大任务最容易埋雷——它会为了跑通测试删掉挡路的东西，而你在几千行 diff 里根本看不见。
先只读这个项目，给我一份迁移方案：
1. 涉及哪些模块、哪些文件
2. 每一步怎么改，风险在哪
3. 哪些地方需要我人工确认
不要修改任何文件，也不要改数据库结构，等我确认。第三件：养成看用量的习惯
跑之前和跑之后各看一眼 /usage，两周下来你就知道哪类任务最烧钱。多数人第一次看到结果都会意外：最费的往往不是那个大重构，而是某个在仓库里反复搜索的小任务。
七、可以照抄的日常工作流
早上到工位
├─ 开一个终端 agent，处理昨天的重构（长任务，让它慢慢跑）
├─ 同时在 IDE 里写今天的新功能（小步迭代，要盯着看）
└─ 有明确描述、能放手的活 → 丢给云端 agent，回 PR 再看
评审阶段
├─ 先看改动文件清单：范围不对直接打回
├─ 再过滤 diff 里的删除行：被删的校验是重灾区
├─ 检查新增依赖是否真实存在
└─ 边界条件有没有覆盖（空值/超时/并发/重复请求）
收工前
├─ /usage 看一眼今天烧了多少
└─ 把今天踩到的坑补进项目说明文件最后补一句：这些工具迭代极快，档位和价格几个月就会变。但「按并行度和上下文估算需求」「三层额度限制」「给仓库写说明文件」这三件事，是不会过时的。
备忘
- 估算需求别数次数，数并行度和上下文长度：四个并行任务约四倍消耗。
- Claude Code 不单独卖，从付费档开始包含；免费档没有。（价格以官网为准）
- 倍数指「每次会话」，不是「每月」；编码与聊天共用一份额度。
- 三层额度：5 小时滚动窗口 / 全模型周上限 / 高端模型单独的周上限。撞限先
/usage看是哪层。 - Codex 订阅与 ChatGPT 捆绑（价格查官网）；取向是云端并行、回 PR；代价是任务间不共享上下文。
- 订阅 vs 按量：量稳用订阅，量突发用按量，重度用订阅+按量兜底，CI/批量走批处理。
- 接单做交付必须把 token 成本算进报价，并设置支出上限。
- 上手三件事：仓库说明文件（含「不要碰」清单）、大改先出方案、养看
/usage的习惯。 - 项目说明文件里最有价值的是「不要碰」那一节。
- 工作流：长活开终端、小步写 IDE、能说清的丢云端；评审先看范围、再看删除行、再查依赖与边界。
一起聊聊