即刻App年轻人的同好社区
下载
cursor 次数从原来的 500 → 变成 2000 次
反正 一次 Agent 对话因为调用了多次工具，会算很多次的
池子扩大了4倍，但每次请求消耗的成本也同比增加了4倍，实际可用量并没有变化。
这种重新计算方式可能为未来"悄悄涨价"留了口子——比如某些模型的请求现在可以算作 1.25 个单位，变相涨价却不显山露水
反正 一次 Agent 对话因为调用了多次工具，会算很多次的
池子扩大了4倍，但每次请求消耗的成本也同比增加了4倍，实际可用量并没有变化。
这种重新计算方式可能为未来"悄悄涨价"留了口子——比如某些模型的请求现在可以算作 1.25 个单位，变相涨价却不显山露水
1 30
继续更新一下 Cursor 这个 quota 事件。
这次他们终于给了更明确的书面回复，核心有 3 点：
billable request = 单次 model API call
也就是说，计费单位不是“我发出 1 条消息”，而是 Cursor 后台每一次实际调用模型。
thinking model 确实有 multiplier
也就是同样一次调用，thinking model 可能按多于 1 个 request 计算。
这些 multiplier 细节，在提交前不会实时显示
这点是他们邮件里明确承认的。
所以现在问题已经很清楚了：
Cursor 所谓的 request-based pricing，并不是用户直觉里的“我发 1 次请求 = 1 次 request”，而是系统层面的内部 model invocation 计数。
更关键的是，他们也承认了：
用户在按下发送前，看不到这些 multiplier 的实时细节。
这也是我一直在追问的核心：
不是后台能不能多次调用，而是如果要这么计费，为什么提交前没有足够透明的成本信息？
这次他们终于给了更明确的书面回复，核心有 3 点：
billable request = 单次 model API call
也就是说，计费单位不是“我发出 1 条消息”，而是 Cursor 后台每一次实际调用模型。
thinking model 确实有 multiplier
也就是同样一次调用，thinking model 可能按多于 1 个 request 计算。
这些 multiplier 细节，在提交前不会实时显示
这点是他们邮件里明确承认的。
所以现在问题已经很清楚了：
Cursor 所谓的 request-based pricing，并不是用户直觉里的“我发 1 次请求 = 1 次 request”，而是系统层面的内部 model invocation 计数。
更关键的是，他们也承认了：
用户在按下发送前，看不到这些 multiplier 的实时细节。
这也是我一直在追问的核心：
不是后台能不能多次调用，而是如果要这么计费，为什么提交前没有足够透明的成本信息？
airobus火锅: 事件更新一下。 Cursor 上一封邮件，已经明确承认： Pro 里的 billable request，不是 1 条用户消息，而是每一次内部 model API call。 也就是说，你按下一次发送，后台可能因为： planning tools file reads context handling follow-up 拆成多次调用，然后都记进 quota。 他们还补了一句： thinking models may further increase usage。 死追到底！已经不是“帮我补 quota”了。而是要求他们把这件事说清楚： request 的正式定义是什么 thinking model 到底几倍 用户提交前能不能看到 agent mode 的消耗能不能预估 为什么叫 request-based pricing，却不是按用户理解里的 request 算
1 20
事件更新一下。
Cursor 上一封邮件，已经明确承认：
Pro 里的 billable request，不是 1 条用户消息，而是每一次内部 model API call。
也就是说，你按下一次发送，后台可能因为：
planning
tools
file reads
context handling
follow-up
拆成多次调用，然后都记进 quota。
他们还补了一句：
thinking models may further increase usage。
死追到底！已经不是“帮我补 quota”了。而是要求他们把这件事说清楚：
request 的正式定义是什么
thinking model 到底几倍
用户提交前能不能看到
agent mode 的消耗能不能预估
为什么叫 request-based pricing，却不是按用户理解里的 request 算
Cursor 上一封邮件，已经明确承认：
Pro 里的 billable request，不是 1 条用户消息，而是每一次内部 model API call。
也就是说，你按下一次发送，后台可能因为：
planning
tools
file reads
context handling
follow-up
拆成多次调用，然后都记进 quota。
他们还补了一句：
thinking models may further increase usage。
死追到底！已经不是“帮我补 quota”了。而是要求他们把这件事说清楚：
request 的正式定义是什么
thinking model 到底几倍
用户提交前能不能看到
agent mode 的消耗能不能预估
为什么叫 request-based pricing，却不是按用户理解里的 request 算
airobus火锅: 我在 Cursor 遇到一个很离谱的计费问题。 晚上只用了 2 次，结果 500 次调用配额直接见底。 更抽象的是，我去问客服后，对方前后给了几套完全不一样的说法： 第一次说： 这不是 bug，因为 Cursor 是按 token 计费，不是按简单请求次数计费，thinking model 还会吃掉更多 token。 后面又改口说： 我的账户其实是 API / dollar-based pricing，只是 dashboard 错误显示成了 “500 / 500 Included-Request Usage”。 再后来support 又改口： 我其实仍然是 per-request model，只不过在 agent / multi-step workflow 里，一条用户消息可能触发多个 model API calls，这些都可能分别算作 billable request。 也就是说—— 用户看到的是：按次计费 但实际可能是： 你发 1 次，我后台拆成 N 次，然后按 N 次扣你 这就有意思了。 如果“request-based pricing”的实际扣费单位，不是用户发出的 request，而是平台内部自己拆出来的调用次数，那用户怎么预估消耗？ 如果 planning、tool usage、file reads、context management 都能继续拆着扣，那这到底还算不算普通人理解里的“按次计费”？ 我肯定会继续追问下去的，太离谱了！ 这事不只是我一个人的问题，所有按“request”理解套餐的人，没有转token计费的，理论上都该关心。
1 01