How Cursor Bills
Cursorは、月額サブスクリプションと、使用すると減少する含まれる使用量プールを組み合わせています。ユーザーは予測可能な料金を支払い、Cursorはそのプールから異なるAIモデルの変動コストを負担します。 料金ティア: Cursor は Hobby から Ultra までのティアを提供しています。Cursor のプランには、固定されたリクエスト数ではなく、各モデルの API 価格に基づいて課金される使用量プールが含まれます(Cursor の料金ドキュメント)。表のリクエスト許容量は、このデコンストラクションでモデル化した例示的な値です。
モデルによる消費量の重み付け: 各リクエストは、基盤となるモデルのコストに基づいてクレジットを消費します。1つのサブスクリプションで複数のモデルプロバイダーを利用でき、高コストの処理ほどプールから多く消費します。Cursor はリクエストごとのクレジットコストを公開していないため、以下の重み付けは例示的なものです。
クレジットの使い切りと超過分: クレジットがなくなると、ユーザーは利用を停止されるのではなく、より低コストのモデルを使う「Slow」キューに移動します。ユーザーはオンデマンド利用を有効にしてプレミアムアクセスを継続することもでき、その料金はサイクル終了時に請求されます。
Enterprise: Enterprise プランでは、組織全体で1つの使用量プールを共有します。ヘビーユーザーも他の全員と同じプールから利用するため、チームメイトに未使用の容量がある場合でも、1人の上限によって利用がブロックされることはありません。Cursor は、料金ページでプール型の使用量を Enterprise の機能として掲載しています。
これを独自のものにしている要素
Cursor のモデルは、次の4つの方法でユーザー体験とインフラコストのバランスを取っています。- プロバイダーの抽象化: 1つのサブスクリプションで、OpenAI や Anthropic など複数の LLM プロバイダーを利用できます。Cursor がプロバイダーの料金と API キーを管理します。
- 重み付けされた消費: 高性能なモデルほど多くのクレジットを消費するため、リクエストの価格がそのコストに連動します。
- 段階的な機能低下: ハードな利用停止の代わりに「Slow」キューを使用します。ユーザーはプロダクト内で利用を継続でき、遅い体験がアップグレードを促します。
- クレジットの共有プール: 組織レベルのプールにより、個別の上限を管理するのではなく、チームで容量を共有できます。
Dodo Payments で構築する
Dodo Payments のクレジットエンタイトルメントと使用量ベースの課金を使って、このモデルを構築できます。以下の手順では、クレジット、プラン、メーター、Slow キューのロジック、チェックアウトを作成します。1
Create a Custom Unit Credit Entitlement
Products → Credits に移動し、Create Credit をクリックします。このクレジットは、各サブスクリプションに付属する「Premium Requests」を表します。次の設定を使用します。
- Credit Type: Custom Unit
- Unit Name: “Premium Requests”
- Precision: 0 (リクエストを分割できないようにする)
- Credit Expiry: 30 days (各請求サイクルでクレジットをリセット)
- Rollover: Disabled (未使用のリクエストを繰り越さない)
- Allow Overage: Enabled
- Price Per Unit: $0.04 (含まれるプールを使い切った後の各リクエストのコスト)
- Overage Behavior: Bill overage at billing (超過分のコストを次回の請求書に追加)
2
Create Subscription Products
ティアごとに1つのサブスクリプションプロダクトを作成します。同じクレジットエンタイトルメントを各プロダクトに関連付け、Credits issued per billing cycle の値だけを変えます。すべてのティアで1つのクレジットシステムを使うことで、アップグレードとダウングレードを簡単に管理できます。
- Hobby: $0/月、1サイクルあたり50クレジット
- Pro: $20/月、1サイクルあたり500クレジット
- Pro+: $60/月、1サイクルあたり5000クレジット(ほとんどのユーザーにとって実質無制限)
- Ultra: $200/月、1サイクルあたり50000クレジット(実質無制限)
3
Create a Usage Meter Linked to Credits
イベント名
ai.request、Sum 集計、および Over Property として credit_cost を指定してメーターを作成します。使用量ベースのプロダクトで Bill usage in Credits を有効にし、クレジットエンタイトルメントを選択して、Meter units per credit を1に設定します。アプリケーションは、モデルとアクションタイプから各リクエストのクレジットコストを決定し、その値をイベントで送信します。4
Handle Credit Exhaustion (Slow Queue)
credit.balance_low webhook をサブスクライブします。顧客の残高がプロダクトに設定した Low Balance Threshold を下回ったら、アプリケーション内でその顧客を Slow キューに移動します。これが段階的な機能低下のロジックです。5
Create Checkout
ユーザーがプランを契約するときにチェックアウトセッションを作成します。Dodo Payments が支払いを処理し、税金を計算して、プランのクレジットを付与します。
LLM Ingestion Blueprint で加速する
プロバイダーごとの生のトークン消費量も記録するには、クレジットシステムと並行して LLM Ingestion Blueprint を実行します。inputTokens、outputTokens、totalTokens、model が送信されます。これにより、課金用のクレジット重み付けイベントと、コストおよびマージン分析用の生のトークン数という2層のデータを取得できます。
チームで共有するクレジット(Enterprise)
Cursor の Enterprise プランでは、チーム全体で使用量を共有します。Dodo Payments でこれを構築するには、ユーザーごとではなく組織ごとに1つのサブスクリプションを作成します。これにより、チームの使用量が1つの請求エンティティに集約され、大規模な顧客が期待する形になります。実装戦略
- 組織レベルの Customer: 組織全体に対して1つの Dodo Payments customer を作成します。この customer が共有クレジットプールを保持し、すべての請求書とクレジット付与はその
customer_idに属します。 - シートベースの課金: Seat-Based Billing の説明に従い、シートアドオンでユーザーごとのプラットフォーム料金を請求します。チームがメンバーを追加したら、アドオンの数量を変更します。ユーザー数に応じて収益は増加しますが、クレジットプールは分離されたままです。
- 共有使用量の追跡: チームメンバー全員のリクエストを組織の
customer_idとともに送信し、各リクエストが同じプールを消費するようにします。個々のユーザーについてレポートするには、イベントメタデータにuser_idを追加します。
従来の SaaS 課金との比較
従来の SaaS 課金では、たとえば100ユニットで月額 $10 のような定額ティアを使用します。101ユニット必要なユーザーは、月額 $50 のティアへ一気に移行しなければならないことがよくあります。この「段差」はユーザーを不満にさせ、解約を促します。また、定額ティアでは、AI プロダクトにとって重要な、使用量の種類ごとの異なるコストも考慮されません。 Dodo Payments 上に構築した Cursor 型のモデルは、これらの問題を回避します。- 「段差」の回避: ユーザーは上限に達したときにアップグレードする必要がありません。超過分を支払うか、遅いパフォーマンスを受け入れることで、プロダクト内で作業を継続できます。
- コストの整合: 収益がインフラコストに連動します。高コストなモデルのユーザーには、クレジットまたは超過分を通じてより多く支払ってもらえるため、高コスト機能のマージンを守れます。
- 高いリテンション: 上限に達したユーザーも、利用を停止されることなく作業を継続できます。継続的な利用がロイヤルティを高め、顧客生涯価値を向上させます。
モデルの更新と進化への対応
AI プロバイダーはモデルを頻繁に更新・置換しており、新しいモデルではコストが異なる場合があります。クレジットコストはアプリケーション内にあるため、課金データを移行せずに新しいモデルの価格を設定できます。 より高コストなモデルを追加するには、getCreditCost で高いコストを設定します。クレジットエンタイトルメント、メーター、既存のサブスクリプションを変更する必要はありません。課金はアプリケーションロジックから分離されているため、課金に触れることなくモデルの変更をリリースできます。
ユーザーへの通知と透明性
ユーザーがコストを管理し、請求内容を信頼できるように、使用したクレジット数を表示します。credit.balance_low webhook は、残高がプロダクトの Low Balance Threshold を下回ったときに発火します。50% や80%の使用量など、より多くのチェックポイントを設けるには、credit.deducted イベントの残高をプランの割り当てと比較します。
これらのアラートをメール、アプリ内メッセージ、または Slack で送信します。タイムリーな警告により、ユーザーは Slow キューに入る前に使用量を減らすかアップグレードでき、サポートチケットを削減できます。
セキュリティと不正利用の防止
クレジットには直接的な金銭的価値があるため、クレジットを消費するシステムを保護してください。- 冪等性: すべての使用量イベントに一意の
event_idを付与します。Dodo Payments はevent_idを使用して重複を検出するため、同じ ID でネットワーク再試行が発生しても、ユーザーに二重請求されません。 - レート制限: アプリケーションでリクエストレートを制限し、1人のユーザーがクレジットやプロバイダーの予算を短時間で使い切れないようにします。
- モニタリング: アカウント共有や自動化された不正利用などの異常がないか、使用量を監視します。メーターダッシュボードの Customers ビューには、顧客ごとの使用量合計が表示されます。
クレジットシステムのベストプラクティス
クレジットシステムを設計するときは、次のプラクティスを念頭に置いてください。- シンプルにする: ユーザーがリクエストのコストと残りのクレジット数を理解できるようにします。
- 価値を提供する: ユーザーがクレジットに価値を感じられるようにリクエストの価格を設定します。小さなアクションに対して高すぎると感じるコストは、細かな追加課金だと受け取られます。
- 透明性を確保する: 現在のクレジット残高と使用履歴を表示します。顧客は Customer Portal でも両方を確認できます。
- すべてを自動化する: Dodo Payments の webhook と API を使用して課金タスクを自動化し、手作業をなくします。
使用する Dodo の主な機能
Credit-Based Billing
カスタムユニットを使って、消費されるクレジットプールと超過分を管理します。
Subscriptions
クレジットと統合された、異なるティア向けの定期課金を設定します。
Usage-Based Billing
イベントを追跡し、消費量に基づいて課金します。
Event Ingestion
大量の使用量データを Dodo Payments に送信します。
Webhooks
クレジット残高の変更に反応し、ユーザーのティア変更を自動化します。
LLM Ingestion Blueprint
複数の LLM プロバイダーにまたがるトークン追跡を自動化します。