Skip to main content

Cursor 如何计费

Cursor 将月度订阅与一个会逐渐消耗的包含用量池结合起来。用户支付可预测的价格,Cursor 则从该用量池中承担不同 AI 模型产生的可变成本。 定价层级:Cursor 提供从 Hobby 到 Ultra 的层级。Cursor 的套餐包含按各模型 API 价格计费的用量池,而不是固定的请求次数(Cursor 定价文档)。表中的请求额度是本次解构所建模的示例值。 按模型加权扣减:每个请求都会根据底层模型的成本消耗 credits。一个订阅涵盖多个模型提供商,成本较高的操作会从池中扣除更多 credits。Cursor 不会公布每个请求的 credit 成本,因此下面的权重仅为示例。 Credit 耗尽与超额用量:当 credits 用完后,用户会进入使用更便宜模型的“Slow”队列,而不会被直接切断。用户还可以启用按需用量以继续使用高级访问权限,费用会在周期结束时收取。 Enterprise:在 Enterprise 套餐中,整个组织共享一个用量池。高用量用户会与其他所有用户从同一个池中扣减,因此即使团队成员还有未使用的容量,也不会因为某个人达到上限而阻止其继续使用。Cursor 在其定价页面上将共享用量列为 Enterprise 功能。

它的独特之处

Cursor 的模型通过四种方式平衡用户体验与基础设施成本:
  • 提供商抽象:一个订阅封装多个 LLM 提供商,例如 OpenAI 和 Anthropic。Cursor 负责处理提供商定价和 API keys。
  • 加权扣减:功能强大的模型消耗更多 credits,因此请求价格会反映其成本。
  • 平滑降级:“Slow”队列取代了硬性切断。用户仍可留在产品中使用,而较慢的体验会促使其升级。
  • 共享 Credits:组织级用量池允许团队共享容量,而不是分别管理个人上限。

使用 Dodo Payments 构建此模型

你可以使用 Dodo Payments 的 credit entitlements 和基于用量的计费来构建此模型。以下步骤会创建 credit、套餐、meter、慢速队列逻辑和 checkout。
1

Create a Custom Unit Credit Entitlement

前往 Products → Credits,然后点击 Create Credit。此 credit 代表每个订阅包含的“Premium Requests”。使用以下设置:
  • Credit Type: Custom Unit
  • Unit Name: “Premium Requests”
  • Precision: 0(请求不能拆分)
  • Credit Expiry: 30 天(credits 在每个计费周期重置)
  • Rollover: Disabled(未使用的请求不会结转)
  • Allow Overage: Enabled
  • Price Per Unit: $0.04(包含的用量池用完后每个请求的成本)
  • Overage Behavior: Bill overage at billing(超额费用会添加到下一张发票中)
每个用户在每个周期获得固定的请求池,并按每单位价格支付额外请求的费用。
2

Create Subscription Products

为每个层级创建一个订阅产品。将同一个 credit entitlement 关联到每个产品,并为 Credits issued per billing cycle 设置不同的值。所有层级使用同一个 credit 系统,可以简化升级和降级。
  • Hobby: $0/月,50 credits/周期
  • Pro: $20/月,500 credits/周期
  • Pro+: $60/月,5000 credits/周期(对大多数用户来说实际上是无限的)
  • Ultra: $200/月,50000 credits/周期(实际上是无限的)
当客户订阅时,Dodo Payments 会在该计费周期授予产品对应的 credits,并在每次续订时再次授予。
3

Create a Usage Meter Linked to Credits

创建一个 event name 为 ai.request、使用 Sum aggregation,并将 credit_cost 设为 Over Property 的 meter。在基于用量的产品上,启用 Bill usage in Credits,选择 credit entitlement,并将 Meter units per credit 设置为 1。你的应用会根据模型和操作类型决定每个请求的 credit 成本,然后将其发送到 event 中:
基于 credit_cost 的 Sum meter 允许单个 event 携带任意权重。你可以每个请求发送一个 event,而不是每个 credit 发送一个 event,从而减少高吞吐量数据接收的规模。
4

Handle Credit Exhaustion (Slow Queue)

订阅 credit.balance_low webhook。当客户余额低于产品上设置的 Low Balance Threshold 时,在你的应用中将其移入慢速队列。这就是平滑降级逻辑。
5

Create Checkout

用户订阅套餐时创建 checkout session。Dodo Payments 会处理付款、计算税费,并授予套餐对应的 credits。

使用 LLM Ingestion Blueprint 加速

上面的 credit 加权 event 会驱动计费。若还要记录每个提供商的原始 token 消耗,请在 credit 系统旁运行 LLM Ingestion Blueprint。
每次被跟踪的调用都会在 event metadata 中发送 inputTokens、outputTokens、totalTokens 和 model。你可以获得两层数据:用于计费的 credit 加权 event,以及用于成本和利润率分析的原始 token 数量。
LLM Blueprint 支持 OpenAI、Anthropic、Groq、Google Gemini、OpenRouter 和 Vercel AI SDK。有关所有受支持提供商的信息,请参阅完整的 blueprint 文档。

共享团队 Credits(Enterprise)

Cursor 的 Enterprise 套餐会在团队范围内共享用量。要使用 Dodo Payments 构建此功能,请为组织创建一个订阅,而不是为每个用户分别创建订阅。这样,团队的用量会累计到单个计费实体中,这正是大型客户所期望的模式。

实施策略

  1. 组织级 Customer: 为整个组织创建一个 Dodo Payments customer。此 customer 持有共享 credit 池,所有发票和 credit 授予都归属于其 customer_id。
  2. 按席位计费: 使用 seat add-on 收取按用户计费的平台费用,具体方式请参阅 Seat-Based Billing。团队添加成员时,修改 add-on 数量。收入会随用户数量增长,而 credit 池保持独立。
  3. 共享用量跟踪: 使用组织的 customer_id 发送每位团队成员的请求,使每个请求都从同一个池中扣减。若要报告单个用户的用量,请将 user_id 添加到 event metadata 中。
每位成员支付可预测的平台费用,团队则共享一个用于高成本 AI 资源的 credit 池。成员无需管理自己的上限。

与传统 SaaS 计费的比较

传统 SaaS 计费使用固定费率层级,例如每月 $10 获得 100 个单位。需要 101 个单位的用户通常必须升级到每月 $50 的层级。这种“断崖式”体验会令用户感到沮丧并导致流失。固定层级还忽略了不同类型用量之间的成本差异,而这对 AI 产品十分重要。 基于 Dodo Payments 构建的 Cursor 风格模型可以避免这些问题:
  • 没有“断崖式”影响: 用户达到上限时无需升级。他们可以支付超额费用或接受较慢的性能,因此仍可继续在产品中工作。
  • 成本匹配: 收入会跟随基础设施成本变化。使用高成本模型的用户会通过 credits 或超额费用支付更多费用,从而保护高成本功能的利润率。
  • 更高的留存率: 达到上限的用户仍可继续工作,而不会被直接切断。持续使用有助于建立忠诚度并提高客户生命周期价值。

处理模型更新与演进

AI 提供商经常更新和替换模型,新模型的成本可能不同。由于 credit 成本存储在你的应用中,因此无需迁移计费数据即可为新模型定价。 若要添加成本更高的模型,请在 getCreditCost 中为其设置更高的成本。无需更改 credit entitlement、meter 或现有订阅。计费与应用逻辑保持分离,因此你可以发布模型变更,而无需改动计费系统。

用户通知与透明度

向用户展示他们已使用的 credits 数量,让他们能够管理成本并信任账单。当余额低于产品的 Low Balance Threshold 时,credit.balance_low webhook 会触发。若要设置 50% 和 80% 用量等更多检查点,请将 credit.deducted event 中的余额与套餐分配额进行比较。 通过 email、应用内消息或 Slack 发送这些提醒。及时的警告可以让用户在进入慢速队列前减少用量或升级,从而减少支持工单。

安全与欺诈防范

Credits 具有直接的货币价值,因此请保护消耗 credits 的系统。
  • 幂等性: 为每个 usage event 提供唯一的 event_id。Dodo Payments 使用 event_id 检测重复事件,因此使用相同 ID 的网络重试不会向用户重复收费。
  • 速率限制: 在应用中限制请求速率,避免单个用户过快耗尽其 credits 或你的提供商预算。
  • 监控: 监控用量异常,例如账号共享或自动化滥用。meter dashboard 的 Customers 视图会显示每个 customer 的用量总额。

Credit 系统最佳实践

设计 credit 系统时,请牢记以下实践:
  1. 保持简单: 用户应该能够理解一个请求的成本,以及自己还剩多少 credits。
  2. 提供价值: 为请求合理定价,让用户觉得 credits 物有所值。对于一个小操作而言,过高的成本会让人觉得是在斤斤计较地收费。
  3. 保持透明: 展示当前 credit 余额和用量历史。客户也可以在 Customer Portal 中查看这两项信息。
  4. 全面自动化: 使用 Dodo Payments webhooks 和 APIs 自动执行计费任务,减少手动工作。

使用的关键 Dodo 功能

Credit-Based Billing

使用自定义单位管理会耗尽的 credit 池和超额用量。

Subscriptions

使用集成 credits 为不同层级设置 recurring billing。

Usage-Based Billing

跟踪 event,并根据消耗进行计费。

Event Ingestion

将高吞吐量用量数据发送到 Dodo Payments。

Webhooks

响应 credit 余额变化并自动管理用户层级。

LLM Ingestion Blueprint

跨多个 LLM 提供商自动跟踪 token。
最后修改于 2026年9月26日