Devin 超额按 API pricing 计费是什么意思？超支了怎么控成本
Devin 的定价页上有一句容易被划过去的话：Pro 档超出套餐之后，你可以额外购买用量，而这部分用量 “is consumed at API pricing”——按 API 价格计费。
很多人看到这句会默认它跟别家的超额是一回事：反正就是超了要另外掏钱嘛。但它和「固定超额单价」是两种机制，差别不在贵不贵，而在你能不能提前算出要花多少钱。前者你能，后者你算不了，只能边用边看。
这篇就干两件事：把「按 API pricing 计费」这件事讲到你能对着账单点头，然后给出超额期间真正能压住成本的做法。先说清楚一个前提——Devin 各档到底含多少额度、这里说的 API pricing 具体指哪一张价目表、按哪个模型的单价算，定价页都没有写。我不会替它编。下面凡是涉及具体数字的地方，我只用能查到出处的，其余一律指向官方定价页。
两种超额，先分清楚
拿一个有公开数字的例子当参照物：Kiro 的 PRO 档是 $20/月含 1,000 credits，超额单价 $0.04/credit。这两个数一摆，你能自己算——$20 ÷ 1000 = $0.02/credit，是套餐内的等效单价；超额 $0.04 ÷ $0.02 = 2 倍。也就是说超出去的每一个 credit，价格是套餐内的两倍。
这个算式的价值不在于「两倍贵不贵」，而在于它是可以事先算出来的。你月中一看还剩 200 credits，估计这个月要用到 1,800，那超出的 800 × $0.04 = $32。这个 $32 在你花之前就已经确定了，你可以拿它去跟升档的差价做比较，然后做决定。
Devin 的机制不是这样。它不告诉你「超出后每单位多少钱」，它说的是超出后的用量按 API 价格结算。API 价格是按 token 计费的——你实际喂进去多少输入 token、模型吐出来多少输出 token，就结多少钱。同一个任务，不同的问法、不同的上下文长度、不同的模型档位，结出来的数可以差出好几倍。
| 对比项 | 固定超额单价 | 按 API pricing 计费 |
|---|---|---|
| 计价对象 | 平台自定义的抽象单位（credit 之类） | 实际消耗的 token |
| 单价是否公开固定 | 是，定价页直接给一个数 | 取决于你用哪个模型、哪张价目表 |
| 花之前能不能算准 | 能，缺口 × 单价即可 | 不能，只能事后看账单 |
| 同一个任务的成本波动 | 小，平台已经帮你把波动吸收进 credit 换算里 | 大，问法和上下文长度直接改变金额 |
| 你能做的成本管理 | 主要是「要不要超」这一个决定 | 变成日常操作：选模型、圈范围、控上下文 |
| 适合的心态 | 预算制，月初定个上限 | 计量制，把每次调用都当成花钱 |
用一句话概括这张表：固定单价把不确定性留在了平台那边，你只需要决定超不超；按 API pricing 则把不确定性原样传给了你，你得自己管住它。
为什么按 token 结算的成本就是算不准
有三个东西在同时推高实际 token 消耗，而它们都不在定价页上，只在你的使用习惯里。
第一是模型档位。 同一句话交给不同价位的模型，token 数几乎一样，钱差很多——因为 API 价目表本来就是按模型分行的。这一条是所有按 token 计费的产品共有的，Devin 也不例外。至于 Devin 具体能用哪些模型、各自按什么价结算，页面没写，我不猜。
第二是上下文长度。 这一条最容易被低估。Agent 干活不是只发你打的那几十个字，它会把相关文件、目录结构、之前几轮的对话历史一起塞进去。你在一个会话里聊到第十轮的时候，前九轮的内容很可能还在被重复发送。也就是说，同样一句”再改一下”，在第一轮和第十轮的成本完全不同。
第三是 Agent 自己展开的步数。 这是 Agent 类产品跟聊天类产品最大的差别。你说一句话，它可能自己拆成搜索、读文件、生成方案、逐个文件改、跑一遍自检——每一步都是一次真金白银的模型调用。你只发了一句话，账单上却是十几次调用。
三者叠在一起就是：一个含糊的需求，配上一个长会话，配上一个贵模型，实际花掉的钱可以是同一件事最省做法的好几倍。而这个倍数没人能在你按下回车之前告诉你。
超额期间，实际能做的四件事
既然算不准，那就只能压低。下面四条按见效速度排序。
一、粗活换便宜模型
把任务分成两类：需要判断力的（架构怎么设计、这个 bug 的根因在哪）和不需要的（改个变量名、把这段注释补上、按现成模式再写一个类似的 handler）。后者占日常工作量的大头，而它们对模型强弱的敏感度很低。超额期间把这一类切到便宜档位跑，是唯一一个「改一个设置就生效」的动作。
具体哪些档位可选、各自按什么价结算，看你账号里的模型列表和官方定价页，这个我给不了。
二、把需求圈死，别让 Agent 自己展开
这一条省下来的钱通常比换模型还多，因为它直接砍掉的是调用次数。对比一下：
含糊版：“帮我优化下这个项目。”
Agent 拿到这句话会怎么办？它得先搞清楚”这个项目”是什么，于是扫目录、读 README、抽样读几个核心文件；然后它得猜”优化”指什么——性能？可读性？依赖版本？于是它可能三个方向都给你碰一遍；然后逐个文件改，改完还要自检。一句话，十几次调用，其中大半你根本不需要。
圈死版：“只改
order/service.ts里的createOrder，把里面的库存校验提成独立函数，别动支付逻辑。”它只需要读一个文件、改一个函数、自检一次。范围明确，它没有自由发挥的空间，也就没有多余的调用。
区别不在于第二句话更长，而在于它把边界写死了。“别动支付逻辑”这半句尤其值钱——Agent 最烧钱的行为之一就是好心地顺手改了你没让它改的地方，然后你还得再花一轮让它改回来。
三、控制上下文，别把整个项目塞进去
两个具体动作。一是换话题就开新会话，别在一个几十轮的长对话里接着聊不相关的事——那些历史每一轮都在被重发。二是明确指出该看哪几个文件，而不是让它自己去项目里翻。你心里清楚答案在哪三个文件里的时候，直接点名，比让它自己搜一圈便宜得多。
反过来说，如果你自己都不知道该看哪里，那这次探索本身就是要花钱的，这没什么好省的，认了就行。要省的是那些你明明知道位置、却图省事让 Agent 自己找的场合。
四、超额之前先估一次：是不是该升档
这一条要在你开始超之前做，晚了就没意义了。
思路是这样：先看你这个月大概超出去多少比例——是超了一点点（比如月底最后三天不够用），还是从月中就开始超。前者按超额买划算，后者基本上都是该升档的信号。因为超额部分按 API 价格走，而套餐价通常是打包价，长期稳定地超额，几乎必然比换一个更大的档位贵。
Devin 的档位是 Free、Pro $20/月、Max $200/月、Teams $80/月 + $40/月/座位，Enterprise 需要洽谈。各档具体含多少额度，页面没写，所以我没法替你算出「超到什么程度该升 Max」这个临界点——这个数只能你自己用一两个月的实际账单反推。有一点是页面写明的：Devin 的用量额度是按日 / 按周自动刷新的（原文用词是 automatically refresh）。这意味着如果你的超额是集中爆发式的——某两天猛干、其余时间闲着——那把活摊平到刷新周期里，可能比升档更省。
这种计费方式适合谁、不适合谁
不做优劣判断，只说匹配关系。
按 API pricing 结算这种模式，对用量本来就不规律的人是友好的。 你这个月只干了三天活，就只花三天的钱，不会像固定档位那样为闲置容量买单。它本质上是把「按容量付费」换成了「按实际消耗付费」。
对需要提前报预算的人则是麻烦的。 如果你要在月初跟老板说”这个月 AI 工具花多少”，一个说不出确切数字的计费方式会让你很被动。这种场景下，能给出固定超额单价的产品——或者干脆用量到顶就停、不让你超的产品——反而更好交代。
顺带说一句机制上的对照：市面上这几家处理「超出去之后怎么办」的思路其实是分岔的。有的是加钱续（花钱买额外用量，Devin、Kiro 都属于这一类，只是定价方式不同）；有的是降速用，Cursor 的快速请求用完后会掉到慢速池，代价从钱变成了排队时间，具体机制我们在Cursor 快速请求用完了怎么办里拆过；还有的是只能等，到点了就是不让用，比如 Claude Code 的额度限制那一套。
选哪种，本质上是在回答一个问题：你更愿意让代价落在钱上，还是落在时间上？ 赶 deadline 的时候加钱续是划算的，因为你的时间比那几十美元贵；而做长期项目、进度不那么紧的时候，降速排队反而是更理性的选择。同样是按用量计费的产品，Codex 的用量与计费也可以拿来对着看，思路上是相通的。
最后
回到最开始那句话。“consumed at API pricing” 传递的信息不只是”要另外花钱”，而是”这笔钱的多少由你的使用方式决定，不由平台的价目表单方面决定”。
这句话有两面。坏的一面是你没法提前报预算，好的一面是你手里确实有方向盘——换个便宜模型、把需求圈死、开个新会话，这三件事加起来能实实在在地改变账单数字，而在固定超额单价的产品上，你做这些的收益要小得多。
至于具体多少钱、哪个模型多少单价、各档含多少额度——以官方定价页为准。我没写数字不是偷懒，是因为定价页上确实没有，而在计费这种事情上，猜错一个数比不给数要糟糕得多。你自己去核一遍，顺手把当天的截图存下来，下次账单对不上的时候能用得上。