Cursor $1799超额账单被免除后又重新扣款事件始末

一笔被承诺免除的超额账单

近日，一位 Cursor Ultra 用户在 Reddit 上详细披露了自己遭遇的一起计费纠纷。事件的核心是一笔金额高达 $1799 的超额费用——Cursor 官方先是在发票上白纸黑字承诺免除，随后却在用户调整消费上限的瞬间，将完全相同的用量再次计入账单并试图扣款。

这位用户使用的是 Cursor Ultra 套餐，并开启了 on-demand（按需计费）功能，同时设置了 $1000 的硬性消费上限（hard limit）。然而在计费周期中段，他的用量突然显示为约 $2799，远超他设定的上限。

更值得玩味的是，Cursor 自家的发票明确承认了这一问题。发票上的退款说明原文写道：

"Refund because the last hard limit in the month was $1000.00, but the total cost was $2799.15 (likely because of processing delays — the hard limit enforcement is not instant!). We will eat this cost for you, to ensure that your hard limit is upheld."

翻译过来即：由于硬性上限设为 $1000，但实际总费用达到 $2799.15（很可能是处理延迟导致，硬性上限的执行并非实时的！），我们将为你承担这笔费用，以确保你的硬性上限得到维护。

"承担"承诺背后的隐形附加条款

事情本可到此为止。用户接受了这个解释，并支付了发票上剩余的 $445，使其 on-demand 累计支付额恰好达到 $1000 的上限。他保留了所有收据。

由于已经触达消费上限，用户无法继续使用模型，于是他将上限从 $1000 提高到 $3000 以继续工作。问题正是在此刻爆发：更改设置后仅仅几分钟内，Cursor 就生成了一张金额为 $1799.16 的新发票，并尝试从他的银行卡扣款。

用户随后逐行比对了两张发票，得出了一个关键结论：

• 相同的模型
• 相同的调用次数
• 精确到单个请求的相同 token 数
• 相同的 event ID（事件标识）

换言之，这并非新产生的用量，而是五天前被免除的那笔用量被重新计费，仅扣除了他已支付的 $1000。用户一针见血地指出：如果按照 Cursor 的说法，他必须在大约一分钟内产生 $1799.16 的全新用量，且每一行的 token 数都与被免除的金额分毫不差——这显然不可能。

承诺与现实的落差

这位用户用一个形象的比喻总结了自己的遭遇：所谓 "we will eat this cost for you"（我们为你承担这笔费用），似乎带着一个隐形的星号——除非你在本周期内再次触碰消费上限滑块，否则这笔承担就会被撤销。

而这个附加条件，无论是在发票上、还是在服务条款（ToS）中，都找不到任何说明。用户表示自己已仔细核查过。

客服沟通中的错位与僵局

在与 Cursor 客服的沟通中，用户的体验同样糟糕。据其描述，客服的回应存在明显的答非所问：

• 客服反复反驳一个用户从未提出的主张——即新发票"重复计算"了他已支付的 $445，而用户从未这样说过；
• 当用户明确表示自己并非在申请退款，而是拒绝为已被书面免除的用量支付一张未结账单时，客服却反复援引退款政策进行回应。

最终，客服给出的答复是：这笔费用成立，如有异议请联系法务部门。

目前该用户已提交正式争议申请，并在银行层面冻结了银行卡扣款，表示将持续更新事件进展。

对 on-demand 用户的实用警示

抛开纠纷本身的是非，这起事件暴露出 Cursor 计费机制中一个值得所有用户关注的技术细节。用户特别指出，他至少找到了另一篇描述相同情况的帖子（超额被免除后，在提高上限时被重新计费），因此这很可能并非孤例。

基于自身经历，这位用户给出了几条极具操作性的建议：

硬性上限并非实时执行

如果你在使用 on-demand 并设置了硬性上限，请务必明白：这个上限并不是实时生效的——Cursor 自家的发票已经明确承认了这一点（"the hard limit enforcement is not instant"）。这意味着实际扣费可能因处理延迟而超出你设定的上限。

保存发票与原始用量数据

用户强调，下载你的发票以及仪表盘中的原始用量事件（raw usage events） 至关重要。正是这份逐行比对的数据，才让他能够证明两张发票的用量完全一致。在任何计费争议中，这类原始数据是唯一可靠的证据。

收到超额减免后不要随意调整消费上限

这是本次事件最核心的教训：如果你曾获得过一笔超额减免（overage credit），在没有书面确认该减免依然有效之前，切勿在同一周期内触碰你的消费上限设置，因为根据这次的经历，减免可能会因此失效。

写在最后

这起纠纷目前仍在进行中，最终结果尚待观察。但它所折射出的问题，超出了单一账户的范畴：当计费系统的"承诺"缺乏明确的条款支撑，当自动化计费的执行存在延迟和不可预期的"回滚"行为时，用户的知情权与信任基础就会受到侵蚀。

对于依赖 AI 编程工具进行高强度、高消耗工作的开发者而言，这是一个及时的提醒：在享受按需付费带来的灵活性的同时，务必留存证据、理解计费规则的边界，并对任何"口头承诺"保持必要的审慎。