Skip to main content

Hur Cursor fakturerar

Cursor kombinerar en månadsprenumeration med en förbrukande pool av inkluderad användning. Användarna betalar ett förutsägbart pris, och Cursor täcker den varierande kostnaden för olika AI-modeller från den poolen. Prisnivåer: Cursor erbjuder nivåer från Hobby till Ultra. Cursors planer inkluderar användningspooler som debiteras enligt varje modells API-pris, inte fasta antal förfrågningar (Cursor pricing docs). Antalet tillåtna förfrågningar i tabellen är illustrativa värden som används i denna rekonstruktion. Modellviktad förbrukning: Varje förfrågan förbrukar krediter baserat på kostnaden för den underliggande modellen. En prenumeration omfattar flera modell-leverantörer, och dyra operationer förbrukar mer från poolen. Cursor publicerar inte kreditkostnader per förfrågan, så vikterna nedan är illustrativa. Slut på krediter och överdebitering: När krediterna tar slut flyttas användarna till en “Slow”-kö med billigare modeller i stället för att stängas ute. Användarna kan också aktivera användning on demand för att behålla premiumåtkomst, vilket debiteras i slutet av perioden. Enterprise: I Enterprise-planen delar hela organisationen på en användningspool. Intensiva användare förbrukar från samma pool som alla andra, så en persons gräns blockerar inte dem när teammedlemmar har outnyttjad kapacitet. Cursor anger poolad användning som en Enterprise-funktion på dess prissida.

Vad gör den unik

Cursors modell balanserar användarupplevelse mot infrastrukturkostnad på fyra sätt:
  • Leverantörsabstraktion: En prenumeration omfattar flera LLM-leverantörer, till exempel OpenAI och Anthropic. Cursor hanterar leverantörernas prissättning och API-nycklar.
  • Viktad förbrukning: Kraftfulla modeller kostar fler krediter, så priset för en förfrågan följer dess kostnad.
  • Mjuk degradering: Kön “Slow” ersätter en hård avstängning. Användarna stannar kvar i produkten, och den långsammare upplevelsen uppmuntrar till en uppgradering.
  • Poolade krediter: En pool på organisationsnivå låter ett team dela kapacitet i stället för att hantera individuella gränser.

Bygg detta med Dodo Payments

Du kan bygga denna modell med kreditentitlements och användningsbaserad fakturering i Dodo Payments. Stegen nedan skapar krediten, planerna, mätaren, logiken för den långsamma kön och checkout-flödet.
1

Create a Custom Unit Credit Entitlement

Gå till Products → Credits och klicka på Create Credit. Denna kredit representerar de “Premium Requests” som ingår i varje prenumeration. Använd följande inställningar:
  • Credit Type: Custom Unit
  • Unit Name: “Premium Requests”
  • Precision: 0 (en förfrågan kan inte delas upp)
  • Credit Expiry: 30 dagar (krediterna återställs varje faktureringsperiod)
  • Rollover: Disabled (oanvända förfrågningar förs inte över)
  • Allow Overage: Enabled
  • Price Per Unit: $0.04 (kostnaden för varje förfrågan efter att den inkluderade poolen har använts)
  • Overage Behavior: Bill overage at billing (kostnaden för överdebitering läggs till på nästa faktura)
Varje användare får en fast pool med förfrågningar per period och betalar för extra förfrågningar enligt styckpriset.
2

Create Subscription Products

Skapa en prenumerationsprodukt per nivå. Koppla samma kreditentitlement till varje produkt med ett annat värde för Credits issued per billing cycle. Ett gemensamt kreditsystem för alla nivåer gör upp- och nedgraderingar enkla.
  • Hobby: $0/månad, 50 krediter/period
  • Pro: $20/månad, 500 krediter/period
  • Pro+: $60/månad, 5000 krediter/period (i praktiken obegränsat för de flesta användare)
  • Ultra: $200/månad, 50000 krediter/period (i praktiken obegränsat)
När en kund prenumererar tilldelar Dodo Payments produktens krediter för faktureringsperioden och tilldelar dem igen vid varje förnyelse.
3

Create a Usage Meter Linked to Credits

Skapa en mätare med händelsenamnet ai.request, aggregeringen Sum och credit_cost som Over Property. I din användningsbaserade produkt aktiverar du Bill usage in Credits, väljer kreditentitlement och ställer in Meter units per credit på 1.Din applikation avgör kreditkostnaden för varje förfrågan utifrån modellen och åtgärdstypen och skickar den i händelsen:
En Sum-mätare över credit_cost låter en enskild händelse bära valfri vikt. Du skickar en händelse per förfrågan i stället för en händelse per kredit, vilket håller ingestion-volymen liten även vid höga volymer.
4

Handle Credit Exhaustion (Slow Queue)

Prenumerera på webhooken credit.balance_low. När en kunds saldo understiger Low Balance Threshold som angetts för produkten flyttar du kunden till en långsam kö i din applikation. Detta är logiken för mjuk degradering.
5

Create Checkout

Skapa en checkout-session när en användare prenumererar på en plan. Dodo Payments behandlar betalningen, beräknar skatt och tilldelar planens krediter.

Påskynda med LLM Ingestion Blueprint

Händelserna ovan, som viktas efter krediter, driver faktureringen. Om du även vill registrera rå tokenförbrukning per leverantör kör du LLM Ingestion Blueprint parallellt med ditt kreditsystem.
Varje spårat anrop skickar inputTokens, outputTokens, totalTokens och model i händelsens metadata. Du får två datalager: kreditviktade händelser för fakturering och råa tokenantal för kostnads- och marginalanalys.
LLM Blueprint stöder OpenAI, Anthropic, Groq, Google Gemini, OpenRouter och Vercel AI SDK. Se den fullständiga dokumentationen för blueprinten för alla stödda leverantörer.

Poolade teamkrediter (Enterprise)

Cursors Enterprise-plan poolar användningen över ett team. Om du vill bygga detta med Dodo Payments skapar du en prenumeration för organisationen i stället för en per användare. Teamets användning samlas då hos en enda faktureringsenhet, vilket större kunder förväntar sig.

Implementeringsstrategi

  1. Kund på organisationsnivå: Skapa en Dodo Payments-kund för hela organisationen. Denna kund innehåller den delade kreditpoolen, och alla fakturor och kredittilldelningar tillhör dess customer_id.
  2. Sätesbaserad fakturering: Ta ut en plattformsavgift per användare med ett seat-tillägg, enligt beskrivningen i Seat-Based Billing. När teamet lägger till en medlem ändrar du tilläggskvantiteten. Intäkterna växer med antalet användare, medan kreditpoolen hålls separat.
  3. Delad användningsspårning: Skicka varje teammedlems förfrågningar med organisationens customer_id, så att varje förfrågan förbrukar från samma pool. Om du vill rapportera per enskild användare lägger du till en user_id i händelsens metadata.
Varje medlem betalar en förutsägbar plattformsavgift och teamet delar på en kreditpool för de dyra AI-resurserna. Medlemmarna behöver inte hantera sina egna gränser.

Jämförelse med traditionell SaaS-fakturering

Traditionell SaaS-fakturering använder fasta prisnivåer, till exempel $10/månad för 100 enheter. En användare som behöver 101 enheter måste ofta hoppa upp till en nivå på $50/månad. Detta “stup” frustrerar användare och driver churn. Fasta nivåer bortser också från att olika typer av användning har olika kostnader, vilket är viktigt för AI-produkter. En Cursor-liknande modell byggd på Dodo Payments undviker dessa problem:
  • Inga “stup”-effekter: Användarna behöver inte uppgradera när de når en gräns. De kan betala för överdebitering eller acceptera långsammare prestanda och fortsätta arbeta i produkten.
  • Kostnadsanpassning: Intäkterna följer infrastrukturkostnaden. Användare av dyra modeller betalar mer, genom krediter eller överdebitering, vilket skyddar marginalerna för kostsamma funktioner.
  • Bättre retention: Användare som når sin gräns kan fortsätta arbeta i stället för att stängas ute. Fortsatt användning bygger lojalitet och ökar kundens livstidsvärde.

Hantera modelluppdateringar och utveckling

AI-leverantörer uppdaterar och ersätter modeller ofta, och en ny modell kan ha en annan kostnad. Eftersom kreditkostnaderna finns i din applikation kan du prissätta en ny modell utan att migrera faktureringsdata. Om du vill lägga till en dyrare modell ger du den en högre kostnad i getCreditCost. Du ändrar inte kreditentitlement, mätaren eller befintliga prenumerationer. Faktureringen hålls separat från applikationslogiken, så du kan lansera modelländringar utan att röra faktureringen.

Användaraviseringar och transparens

Visa användarna hur många krediter de har använt så att de kan hantera kostnaderna och känna förtroende för fakturan. Webhooken credit.balance_low aktiveras när ett saldo sjunker under produktens Low Balance Threshold. För fler kontrollpunkter, till exempel vid 50 och 80 procents användning, jämför du saldot i händelserna credit.deducted med planens tilldelning. Skicka dessa aviseringar via e-post, meddelanden i appen eller Slack. En varning i rätt tid låter användarna minska användningen eller uppgradera innan de når den långsamma kön, vilket minskar antalet supportärenden.

Säkerhet och bedrägeriförebyggande

Krediter har ett direkt monetärt värde, så skydda systemet som förbrukar dem.
  • Idempotens: Ge varje användningshändelse ett unikt event_id. Dodo Payments använder event_id för att upptäcka dubbletter, så att ett nätverksförsök med samma ID inte debiterar användaren två gånger.
  • Hastighetsbegränsning: Begränsa förfrågningshastigheten i din applikation så att en användare inte kan tömma sina krediter eller din leverantörsbudget för snabbt.
  • Övervakning: Övervaka användningen efter avvikelser, till exempel kontodelning eller automatiserat missbruk. Mätarens dashboard-vy Customers visar användningens totaler per kund.

Bästa praxis för kreditsystem

Ha följande praxis i åtanke när du utformar ett kreditsystem:
  1. Håll det enkelt: Användarna ska förstå vad en förfrågan kostar och hur många krediter de har kvar.
  2. Skapa värde: Prissätt förfrågningar så att användarna upplever att krediterna är värda kostnaden. En kostnad som känns för hög för en liten åtgärd uppfattas som småsnål detaljdebitering.
  3. Var transparent: Visa aktuellt kreditsaldo och användningshistorik. Kunderna kan också se båda i Customer Portal.
  4. Automatisera allt: Använd Dodo Payments webhooks och API:er för att automatisera faktureringsuppgifter och minska manuellt arbete.

Viktiga Dodo-funktioner som används

Credit-Based Billing

Hantera pooler med förbrukande krediter och överdebitering med anpassade enheter.

Subscriptions

Konfigurera återkommande fakturering för olika nivåer med integrerade krediter.

Usage-Based Billing

Spåra händelser och fakturera baserat på förbrukning.

Event Ingestion

Skicka användningsdata i hög volym till Dodo Payments.

Webhooks

Reagera på förändringar i kreditsaldot och automatisera användarnas nivåindelning.

LLM Ingestion Blueprint

Automatisk tokenspårning över flera LLM-leverantörer.
Senast ändrad 26 september 2026