Pro 计划月初给你 500 fast request，看上去够用一个月；结果到月中 Composer 顶上出现 “You are on slow requests” 横幅，每次回复要等 20-60 秒。打开 Settings → Usage 一看：fast 早就归零，剩下的全在 slow 池排队。这不是 Cursor 偷扣，而是不同模型扣的不是 1:1，加上 Composer 一次 turn 可能调多次。
要把账单和体感对上，得先理清 Cursor 的三层计费模型。
常见原因
1. 不同模型扣的 fast request 数不一样
Cursor 在 models 文档 里列了每个模型的”premium request multiplier”。常见档位：
- claude-sonnet-4 / gpt-5：1× fast request
- claude-opus-4 / o3：通常 2-4× fast request
- gemini-2.5-pro：依据上下文长度按 1-2× 浮动
- 自家小模型（cursor-small）：不扣 fast
如果你默认用 opus，500 fast 实际只够大约 125 次 Composer turn。
如何判断：Settings → Usage → 把”Group by model”打开，看每个模型扣了多少，对照官方倍率。
2. Composer 一个 turn 内部调用多次
Agent 模式下，模型可能 read_file → grep → write_file → run_terminal 串起来，每一步都是一次 backend 调用。一次”帮我修复这个 bug”可能花掉 3-8 个 fast request，不止 1 个。
如何判断：看 Usage 仪表盘的”requests”列，对照你今天发的 prompt 数。差距 3 倍以上就是 agent 多步在烧。
3. Slow request 不是免费——是排队 + 限速
很多人以为 fast 耗完就降级到”免费但慢”。实际上 slow pool 是共享队列，高峰期可以等 30-90 秒。某些模型（opus/o3 等高成本）slow 池有月度硬上限，超过后直接拒绝。
如何判断：看 Output → Cursor 里 “slow pool full, please upgrade” 或类似日志。
4. Max mode / long-context mode 额外扣
启用 Composer 设置里的 “Max mode” 或 200k 上下文，模型每次调用按倍率额外计费。一次大重构可能 1 个 prompt 烧 5-10 个 fast。
如何判断：Composer 输入框旁边模型名后若有 “Max” 标签，就是 max mode 开着。
5. 用 BYOK 但忘了关 Cursor 的代理
如果你在 Settings → Models 配了 OpenAI / Anthropic API key 但没勾”Use my API key for …”，请求还是走 Cursor 代理、还是扣 fast request。
如何判断：Settings → Models，看每个模型旁边是 “Cursor” 还是 “Your API Key”。
6. 跨设备 / 跨账号统计延迟
切了设备或刚换网后 Usage 数字会落后实际几分钟，造成”我没用啊”的感觉。
如何判断：刷新 Settings 页或等 5 分钟再看。
动手前先确认
- 确认问题是在 chat / Composer / Cmd+K 哪个入口出现；三者计费规则一样但触发频率不同。
- 在 https://cursor.com/settings 网页端而不是 IDE 里看 Usage，数字更新更及时。
- 记下 Cursor 版本和当前默认模型（右下角下拉），不同模型 fast 倍率不一样。
需要收集的信息
- Cursor 版本、当前订阅档（Hobby / Pro / Business）、是否买过 fast-request add-on。
- Settings → Usage 的截图，分别按 model 和按 day 看。
- 一天里你大概发了多少 prompt、用了哪些模型、是否开 Max mode。
- 是否用 BYOK；如用，对应模型在 Settings → Models 是否标 “Your API Key”。
最短修复路径
按”省 fast”收益排序。
Step 1：搞清楚自己实际消耗结构
打开 https://cursor.com/settings → Usage，按 model 分组导出 CSV，把过去 30 天每个模型实际扣了多少 fast 列出来。通常会发现 60-80% 的额度被一两个高倍率模型吃掉。
Step 2：把日常任务降到 1× 模型
设置默认模型为 claude-sonnet-4 或 gpt-5（1× 倍率）。把 opus / o3 留给”小模型给不出对的答案”时手动切。
切换：Composer 输入框左下角模型下拉 → 选 1× 模型
固定默认：Settings → Models → 把高倍率模型从 "Enabled" 里关掉Step 3：关掉不需要的 Max mode
Composer 里不要默认开 Max mode。只在”必须把整个文件丢给模型”时开一次，结束后关掉。
Step 4：用 Cursor Tab + Cmd+K 替代 Composer
Cursor Tab 自动补全和 Cmd+K 行内编辑走的是 cursor-small / 内置小模型，基本不扣 fast。常规函数补全、改一行注释这类任务用 Tab/Cmd+K 即可。
Step 5：BYOK 接自家 API key
Settings → Models 输入 Anthropic / OpenAI key，勾上对应 model 的 “Use my API key”。这时 fast quota 不会被扣，只走你自己的账单。注意 BYOK 路径下 Composer agent 功能完整度略低（部分新特性需 Cursor 代理）。
Step 6：单买 fast-request pack 而不是升档
https://cursor.com/settings → Plan → “Usage-based pricing”，开启后超出 fast quota 部分按使用量后付（每次 $0.04 起，按倍率乘）。比从 Pro 升 Business 划算得多。
怎么确认已经修好
- 调整后用 7 天再看 Usage，确认 fast 消耗 / 天数下降到月底前能持平。
- 切换到另一台设备登录同账号看 Usage 数字一致，排除前端 cache 误差。
- 让同 plan 队友用同样模型设置跑同样任务，对比扣的 fast 数。
如果还是没修好
- 把复现路径缩到最小：单 prompt、单模型、看一次 Composer turn 扣多少。
- 回滚最近一次 Cursor 升级，确认不是新版本默认模型 / 倍率改了。
- 在 forum.cursor.com 搜同模型的 fast 倍率确认；带上你的 Usage 截图。
- 抓 View → Output → Cursor 日志贴 Bug Reports 频道，可直接 ping billing 团队。
预防建议
- 每周一固定看 Usage 仪表盘，月底前预估能否平稳落地。
- 给团队约定”opus 只用于难题”，sonnet/gpt-5 做主力。
- 把 Composer Max mode 当显式动作，不让它默认开。
- 用 .cursorrules 让模型回复更短，间接减少多 turn 调用。
- 大重构走 chat 先讨论方案，确认后再让 agent 执行，避免 agent 多步空转。