2 min lesson
Where Cursor's cost actually lives
Give a practical answer to this: "A request in Cursor's agent mode triggers a retrieval call, a routing call and a generation. Why does conflating 'cost per request' with 'cost per inference' break your model?"
Step 1 of 2
Where Cursor's cost actually livesmap the product to the bill
Fires constantly as the user types.
Needs tens-of-ms latency, so it runs a small fast model.
Low cost per call, enormous call volume - the long tail of COGS.
Fewer calls, far larger context and output.
High cost per request, multi-step agent runs multiply it.
Where a single power user can dominate spend.
Small model for simple queries, large for complex.
The routing decision is a direct COGS lever.
Misroute a simple query to a big model and margin leaks.
The revenue-vs-cost-per-user view is what turns this into a business answer. A flat-priced seat that costs $4/month to serve a casual user and $40 to serve a power user has wildly different margins under the same price. That spread is the single most useful chart you can bring to a margin conversation.
Gross margin is the top-line number, but the one that drives action is cost per active user against revenue per active user, segmented by usage tier. It tells you whether each cohort is accretive and it's the bridge between an engineering knob (routing, batching) and a board narrative (margin trajectory).
When asked "how would you think about Cursor's costs," don't list cloud services. Build the stack out loud from token to margin, then immediately separate production COGS from R&D, then point at tab-prediction volume vs. agent-call size as the two cost shapes. That sequence proves you've modeled an AI product, not just managed a budget.
Learn more
Optional practice