很多人搜 Opus 多少钱，其实卡在同一个地方：看到的数字不知道是哪条渠道的——官方按量、订阅折算、还是中转站倍率，三种口径混着比，越比越乱。这篇不给你写死的数字，而是把 Opus 全部收费入口拆成三条线，每条线告诉你算的是什么、适合谁、去哪里看当期价格，再给一份下单前的核对顺序。
搜 Opus 多少钱的人，最后卡在同一件事上：看到的数字不知道是哪条渠道的。官方按量报价是按百万 token 记的，订阅是按月固定支出，中转站是在官方价上叠了倍率和汇率。三种口径混在一起比，越比越乱，也容易拿着一个过期报价去做预算。
这篇不给写死的数字，而是把 Opus 的全部收费入口拆成三条线，每条线告诉你它算的是什么、适合哪类团队、该去站内哪一页看当期数字。最后给一份下单前的核对顺序，照着走一遍，至少不会因为口径错了把成本估偏。
先分清三条线：官方按量、官方订阅、中转与云平台
| 渠道 | 计价方式 | 适合谁 | 去哪儿核对 |
|---|---|---|---|
| 官方 API 按量 | 输入、输出分别按 token 计价 | 要接进系统、跑批量任务的团队 | /official-api/providers/anthropic |
| 官方订阅 | 按月固定费用换额度 | 天天用、用量平稳的个人或小团队 | /plans/claude-pro 与 /plans/claude-max-20x |
| 中转与云托管 | 在官方口径上叠倍率、汇率或自己的计价单位 | 想省事或已有云账号的团队 | /sites 与 /official-api/providers/amazon-bedrock |
这三条线的数字不能直接相减，因为单位根本不一样：一边是每百万 token，一边是每月固定支出，还有一边是经过换算的名义单价。比价之前先确认自己看的是哪条线，否则很容易得出「订阅比 API 便宜一半」这种口径错位的结论。
- 按量那条线看的是单价乘以用量，用量估错单价再准也没用
- 订阅那条线看的是额度够不够覆盖你的实际消耗，超出的部分怎么算要单独确认
- 中转那条线看的是倍率和计价单位，名义单价低不代表结算低
- 同一个模型在三条线上都可能出现，但价格不可横向对比
按量那条线，价格由什么决定
按量计费的底层逻辑是输入和输出分开定价，而且输出通常比输入贵一截。这意味着同样跑一万次调用，做摘要和做长文生成的花费可能差出好几倍。所以问「Opus 多少钱」之前，先问自己这批任务的输入输出比例大概是多少。
另一个容易被低估的变量是上下文长度。请求一次性塞进去的长文档、长代码库、长对话历史，会把你推到不同的计费档，单价跟着变。很多人预算超了不是用得多，而是每次请求都塞得太满。
- 输入 token
- 你发给模型的内容，包括系统提示和历史对话，按量计费的一个方向
- 输出 token
- 模型生成的内容，单价通常高于输入，长文任务要重点盯这个
- 上下文档位
- 请求总长度跨过某个阈值后单价会变，具体档位到 /official-api/providers/anthropic 看当期表
- 缓存
- 缓存写入和缓存读取各有单价，和普通输入不是一回事，口径细节见站内 token-cost 那篇
订阅还是走 API：拿你的用量来判
- 第一步：分出使用形态高频交互式使用、用量平稳、不需要嵌进自己系统，这类场景订阅通常更省心。要接进产品、跑批量任务、用量波动大，按量更可控。
- 第二步：把用量换成钱从日志里取近一个月的输入 token、输出 token、平均上下文长度，拿去 /tools/model-cost-calculator 算按量成本，再去订阅页比月度支出。
- 第三步：确认额度口径订阅档位覆盖多少、超出怎么算，看 /coding-plans/anthropic-claude-product-subscription-pro 的当期说明，别按印象估。
- 第四步：两边都用的团队查重复付费同一批活路由错了渠道，账单会翻倍。排查思路参考站内 token-cost 那篇里账单对不上的部分。
判断依据是月均 token 量，不是哪边单价看起来低。用量还在几十万 token 级别的试水阶段，先别纠结选哪条线，把请求结构和缓存命中率调好，省下来的往往比换渠道多。什么情况下不适用：如果你的调用有强合规要求，必须走指定云平台，那就没有可比性，直接按那条线的口径做预算。
走中转或云平台时，多核对哪几项
- 倍率怎么定的：名义单价低不代表结算低，倍率和汇率叠完才是真实成本
- 计价单位：是官方口径还是被换算过，输入输出是否同价，这两点写错一处结果就偏
- 渠道可信度：先看 /rankings 里的可信度信息，价格再低也要先过这一关
- 云平台托管：Bedrock、Vertex 这类按自己的单位计费，和官方页面的数字不能混着看
- 非价格限制：并发上限、限速、旺季排队都会影响实际成本，价格不是唯一变量
中转站的价格是会动的，旧报价失效很常见。比价的时候顺手去 /price-watch 看一眼变动记录，如果某家的价格最近调过，就别拿记忆里的数字做判断。另外，中转站的服务条款和数据处理方式要和你的合规要求对一遍，这条不属于价格问题，但会决定你能不能长期用。
下单前的核对清单与量级预估顺序
| 顺序 | 动作 | 去哪儿 |
|---|---|---|
| 1 | 取近一个月的输入 token、输出 token、平均上下文长度 | 自己的日志，没有就先跑一周埋点 |
| 2 | 算按量成本，再看订阅档位 | /tools/model-cost-calculator 与 /plans/claude-pro |
| 3 | 月度结果并排比，差距小选省心，差距大选便宜 | 自己拉个表就行 |
| 4 | 走中转的，把最近的价格变动对一遍 | /price-watch |
| 5 | 把渠道可信度和条款过一遍 | /rankings 与 /sites |
这份顺序的核心是先用真实用量换出钱，再比渠道。反过来先看价格再倒推用量，几乎一定会估偏。什么情况下可以跳过：公司已经统一采购了某个云平台，个人无法选择渠道，那就直接按那条线的当期表做预算，把精力放在控制请求长度上。
价格不是拿来比的，是拿来对着自己用量算的；口径没对齐之前，任何数字都没有意义。下一步把当月用量算出来之后，去价格追踪页对一遍最近有没有调价，再看渠道可信度评分，避免拿着过期报价做决定。→
常见问题
claude opus 的官方价格在哪里看当期数字？
去 /official-api/providers/anthropic，那里按模型列了输入输出单价和规格。别背数字，价格会调整，背下来的数字过期后比价全错。如果你关心的是订阅而非 API，同一页的价格不适用，要转到 /plans 下的 Claude 订阅页面看。
订阅 Claude Pro 和直接调 Opus 的 API，哪个更省钱？
取决于你的月均 token 量和输出占比。交互式聊天、每天用几个小时，订阅一般更稳；要把模型接进产品或者跑批量任务，按量更可控。正确做法是先从用量日志里取出真实 token 数，再去 /tools/model-cost-calculator 换算成钱，两边放一起比。
中转站报的 Opus 价格比官方低，能信吗？
先看它按什么口径报：是按官方倍率折算，还是自己定义了计价单位。低很多通常意味着有限速、并发限制或者额度不稳。把 /rankings 的可信度信息和 /price-watch 的变动记录一起看，再决定要不要把生产流量切过去；试水阶段先用小额度验证。
