Skip to main content

Comment Cursor facture

Cursor combine un abonnement mensuel avec un pool dégressif d’utilisation incluse. Les utilisateurs paient un prix prévisible, et Cursor couvre le coût variable des différents modèles d’IA à partir de ce pool. Paliers tarifaires : Cursor propose des paliers allant de Hobby à Ultra. Les forfaits de Cursor incluent des pools d’utilisation facturés au tarif API de chaque modèle, et non selon un nombre fixe de requêtes (documentation tarifaire de Cursor). Les allocations de requêtes du tableau sont des valeurs illustratives utilisées par cette déconstruction. Épuisement pondéré par modèle : chaque requête consomme des crédits en fonction du coût du modèle sous-jacent. Un abonnement couvre plusieurs fournisseurs de modèles, et les opérations coûteuses consomment davantage le pool. Cursor ne publie pas le coût en crédits par requête ; les pondérations ci-dessous sont donc illustratives. Épuisement des crédits et dépassements : lorsque les crédits sont épuisés, les utilisateurs passent dans une file d’attente “Slow” utilisant des modèles moins coûteux au lieu d’être bloqués. Ils peuvent également activer l’utilisation à la demande pour conserver l’accès premium, avec une facturation en fin de cycle. Enterprise : avec le forfait Enterprise, toute l’organisation partage un même pool d’utilisation. Les utilisateurs intensifs puisent dans le même pool que les autres ; la limite d’une personne ne les bloque donc pas lorsque leurs coéquipiers disposent encore de capacité inutilisée. Cursor présente l’utilisation mutualisée comme une fonctionnalité Enterprise sur sa page tarifaire.

Ce qui le rend unique

Le modèle de Cursor équilibre l’expérience utilisateur et le coût de l’infrastructure de quatre façons :
  • Abstraction des fournisseurs : un seul abonnement regroupe plusieurs fournisseurs de LLM, tels que OpenAI et Anthropic. Cursor gère la tarification des fournisseurs et les clés API.
  • Épuisement pondéré : les modèles puissants coûtent davantage de crédits, de sorte que le prix d’une requête reflète son coût.
  • Dégradation progressive : la file d’attente “Slow” remplace un blocage complet. Les utilisateurs restent dans le produit, et l’expérience plus lente encourage la mise à niveau.
  • Crédits mutualisés : un pool au niveau de l’organisation permet à une équipe de partager la capacité au lieu de gérer des limites individuelles.

Construire cela avec Dodo Payments

Vous pouvez créer ce modèle avec les droits aux crédits et la facturation à l’usage de Dodo Payments. Les étapes ci-dessous créent le crédit, les forfaits, le meter, la logique de file d’attente lente et le checkout.
1

Create a Custom Unit Credit Entitlement

Accédez à Products → Credits et cliquez sur Create Credit. Ce crédit représente les “Premium Requests” incluses dans chaque abonnement. Utilisez les paramètres suivants :
  • Credit Type: Custom Unit
  • Unit Name: “Premium Requests”
  • Precision: 0 (une requête ne peut pas être fractionnée)
  • Credit Expiry: 30 jours (les crédits sont réinitialisés à chaque cycle de facturation)
  • Rollover: Disabled (les requêtes inutilisées ne sont pas reportées)
  • Allow Overage: Enabled
  • Price Per Unit: $0.04 (le coût de chaque requête après utilisation du pool inclus)
  • Overage Behavior: Bill overage at billing (le coût du dépassement est ajouté à la facture suivante)
Chaque utilisateur reçoit un pool fixe de requêtes par cycle et paie les requêtes supplémentaires au prix unitaire.
2

Create Subscription Products

Créez un produit d’abonnement par palier. Associez le même droit aux crédits à chaque produit avec une valeur différente pour Credits issued per billing cycle. Un seul système de crédits pour tous les paliers simplifie les mises à niveau et les rétrogradations.
  • Hobby: $0/mois, 50 crédits/cycle
  • Pro: $20/mois, 500 crédits/cycle
  • Pro+: $60/mois, 5000 crédits/cycle (effectivement illimité pour la plupart des utilisateurs)
  • Ultra: $200/mois, 50000 crédits/cycle (effectivement illimité)
Lorsqu’un client s’abonne, Dodo Payments lui accorde les crédits du produit pour le cycle de facturation, puis les lui accorde à nouveau à chaque renouvellement.
3

Create a Usage Meter Linked to Credits

Créez un meter avec le nom d’événement ai.request, l’agrégation Sum, et credit_cost comme Over Property. Dans votre produit basé sur l’utilisation, activez Bill usage in Credits, sélectionnez le droit aux crédits et définissez Meter units per credit sur 1.Votre application détermine le coût en crédits de chaque requête à partir du modèle et du type d’action, puis l’envoie dans l’événement :
Un meter Sum sur credit_cost permet à un seul événement de porter n’importe quelle pondération. Vous envoyez un événement par requête plutôt qu’un événement par crédit, ce qui limite la taille de l’ingestion à haut volume.
4

Handle Credit Exhaustion (Slow Queue)

Abonnez-vous au webhook credit.balance_low. Lorsque le solde d’un client passe sous le Low Balance Threshold défini sur le produit, faites-le passer dans une file d’attente lente dans votre application. Il s’agit de la logique de dégradation progressive.
5

Create Checkout

Créez une session de checkout lorsqu’un utilisateur s’abonne à un forfait. Dodo Payments traite le paiement, calcule la taxe et accorde les crédits du forfait.

Accélérer avec le LLM Ingestion Blueprint

Les événements pondérés par crédits ci-dessus alimentent la facturation. Pour enregistrer également la consommation brute de tokens par fournisseur, exécutez le LLM Ingestion Blueprint parallèlement à votre système de crédits.
Chaque appel suivi envoie inputTokens, outputTokens, totalTokens et model dans les métadonnées de l’événement. Vous disposez de deux niveaux de données : des événements pondérés par crédits pour la facturation et des décomptes bruts de tokens pour l’analyse des coûts et des marges.
Le LLM Blueprint prend en charge OpenAI, Anthropic, Groq, Google Gemini, OpenRouter et le Vercel AI SDK. Consultez la documentation complète du blueprint pour connaître tous les fournisseurs pris en charge.

Crédits d’équipe mutualisés (Enterprise)

Le forfait Enterprise de Cursor mutualise l’utilisation au sein d’une équipe. Pour créer cela avec Dodo Payments, créez un seul abonnement pour l’organisation plutôt qu’un abonnement par utilisateur. L’utilisation de l’équipe est alors rattachée à une seule entité de facturation, ce qu’attendent les clients de grande taille.

Stratégie d’implémentation

  1. Customer au niveau de l’organisation : créez un customer Dodo Payments pour l’ensemble de l’organisation. Ce customer détient le pool de crédits partagé, et toutes les factures et attributions de crédits appartiennent à son customer_id.
  2. Facturation par siège : facturez des frais de plateforme par utilisateur avec un add-on de sièges, comme décrit dans Seat-Based Billing. Lorsque l’équipe ajoute un membre, modifiez la quantité de l’add-on. Les revenus augmentent avec le nombre d’utilisateurs et le pool de crédits reste séparé.
  3. Suivi de l’utilisation partagée : envoyez les requêtes de chaque membre avec l’customer_id de l’organisation, afin que chaque requête réduise le même pool. Pour établir des rapports sur les utilisateurs individuels, ajoutez un user_id aux métadonnées de l’événement.
Chaque membre paie des frais de plateforme prévisibles et l’équipe partage un seul pool de crédits pour les ressources d’IA coûteuses. Les membres ne gèrent pas leurs propres limites.

Comparaison avec la facturation SaaS traditionnelle

La facturation SaaS traditionnelle utilise des paliers forfaitaires, par exemple $10/mois pour 100 unités. Un utilisateur qui a besoin de 101 unités doit souvent passer à un palier à $50/mois. Cet “effet de seuil” frustre les utilisateurs et favorise le churn. Les paliers forfaitaires ignorent également les coûts différents des différents types d’utilisation, pourtant importants pour les produits d’IA. Un modèle inspiré de Cursor et construit avec Dodo Payments évite ces problèmes :
  • Pas d’effet de seuil : les utilisateurs n’ont pas besoin de changer de forfait lorsqu’ils atteignent une limite. Ils peuvent payer le dépassement ou accepter des performances plus lentes, et continuer à travailler dans le produit.
  • Alignement sur les coûts : les revenus suivent les coûts d’infrastructure. Les utilisateurs de modèles coûteux paient davantage, via les crédits ou les dépassements, ce qui protège vos marges sur les fonctionnalités coûteuses.
  • Meilleure rétention : les utilisateurs qui atteignent leur limite peuvent continuer à travailler au lieu d’être bloqués. La poursuite de l’utilisation renforce la fidélité et augmente la valeur vie client.

Gestion des mises à jour et de l’évolution des modèles

Les fournisseurs d’IA mettent fréquemment à jour et remplacent leurs modèles, et un nouveau modèle peut avoir un coût différent. Comme les coûts en crédits sont gérés dans votre application, vous pouvez définir le prix d’un nouveau modèle sans migrer les données de facturation. Pour ajouter un modèle plus coûteux, attribuez-lui un coût supérieur dans getCreditCost. Vous ne modifiez ni le droit aux crédits, ni le meter, ni les abonnements existants. La facturation reste séparée de la logique applicative ; vous pouvez donc déployer des changements de modèle sans toucher à la facturation.

Notifications et transparence pour les utilisateurs

Montrez aux utilisateurs combien de crédits ils ont utilisés afin qu’ils puissent maîtriser leurs coûts et faire confiance à la facture. Le webhook credit.balance_low est déclenché lorsqu’un solde passe sous le Low Balance Threshold du produit. Pour obtenir davantage de points de contrôle, par exemple à 50 % et 80 % d’utilisation, comparez le solde dans les événements credit.deducted avec l’allocation du forfait. Envoyez ces alertes par e-mail, via un message intégré à l’application ou sur Slack. Un avertissement opportun permet aux utilisateurs de réduire leur utilisation ou de passer à un forfait supérieur avant d’atteindre la file d’attente lente, ce qui réduit le nombre de tickets d’assistance.

Sécurité et prévention de la fraude

Les crédits ont une valeur monétaire directe ; protégez donc le système qui les dépense.
  • Idempotence : attribuez à chaque événement d’utilisation un event_id unique. Dodo Payments utilise event_id pour détecter les doublons ; une nouvelle tentative réseau avec le même ID ne facture donc pas deux fois l’utilisateur.
  • Rate Limiting : limitez les taux de requêtes dans votre application afin qu’un utilisateur ne puisse pas épuiser trop rapidement ses crédits ou votre budget fournisseur.
  • Monitoring : surveillez les anomalies d’utilisation, comme le partage de compte ou les abus automatisés. La vue Customers du tableau de bord du meter affiche les totaux d’utilisation par client.

Bonnes pratiques pour les systèmes de crédits

Gardez ces pratiques à l’esprit lors de la conception d’un système de crédits :
  1. Simplicité : les utilisateurs doivent comprendre le coût d’une requête et le nombre de crédits restants.
  2. Apporter de la valeur : fixez le prix des requêtes de manière à ce que les utilisateurs estiment que les crédits en valent la peine. Un coût perçu comme trop élevé pour une petite action donne l’impression de facturer chaque détail.
  3. Transparence : affichez le solde actuel de crédits et l’historique d’utilisation. Les clients peuvent également voir les deux dans le Customer Portal.
  4. Tout automatiser : utilisez les webhooks et les APIs de Dodo Payments pour automatiser les tâches de facturation et supprimer le travail manuel.

Principales fonctionnalités de Dodo utilisées

Credit-Based Billing

Gérez les pools de crédits qui s’épuisent et les dépassements avec des unités personnalisées.

Subscriptions

Configurez une facturation récurrente pour différents paliers avec des crédits intégrés.

Usage-Based Billing

Suivez les événements et facturez en fonction de la consommation.

Event Ingestion

Envoyez des données d’utilisation à haut volume à Dodo Payments.

Webhooks

Réagissez aux changements de solde des crédits et automatisez l’attribution des paliers aux utilisateurs.

LLM Ingestion Blueprint

Suivi automatique des tokens auprès de plusieurs fournisseurs de LLM.
Dernière modification le 26 septembre 2026