Home
May 5, 2026
View All

Why SaaS Freemium Doesn't Work for AI — and What Cursor's Enterprise Controls Tell Us

·1 underrepresented voice

The Short Version#

Two threads today: Lenny's new piece on AI monetization breaks down why the SaaS freemium playbook fails for AI products and what to build instead — and Cursor's enterprise update shows exactly what "governance for AI tools at scale" looks like in practice. Both are decision inputs for PMs managing AI products right now.

Lenny Rachitsky — Why SaaS Freemium Playbooks Don't Work in AI#

Source: https://www.lennysnewsletter.com/p/why-saas-freemium-playbooks-dont Credibility: High (first-party newsletter from one of the most-cited PM voices; synthesizes patterns from AI product builders across the industry)

What happened: Lenny published a breakdown of why traditional SaaS freemium monetization fails when applied to AI products — and what AI-native monetization strategies actually work. The core argument: SaaS freemium works because the marginal cost of serving a free user is near-zero. In AI products, that's not true. Inference costs are real, and free users who actually use the product cost you money rather than spreading it across a larger base. The playbook needs to change.

Key patterns:

  • Freemium is a distribution strategy, not a monetization strategy — in SaaS, it works because retention, expansion, and virality eventually cover the cost of free. In AI, the cost structure doesn't allow that equation to close the same way.
  • Usage-based pricing aligns incentives — when you charge per inference or per output rather than per seat, you capture value proportional to what you deliver. Flat-rate subscriptions for AI features often leave money on the table or create unsustainable cost exposure.
  • Free tiers need to be capability-limited, not just usage-limited — the effective AI freemium models cap what the AI can do (complexity, accuracy, model tier) rather than just how many times you can do it. This lets power users self-identify and convert without burning inference budget on casual users.
  • Conversion signals look different — in SaaS, activation events (first value moment) often predict conversion. In AI, the signal is repeated high-quality output usage — users who are "aha, this is genuinely better than what I had before" rather than users who just tried the feature once.

Why it matters for PMs: AI products built on top of foundation models have a fundamentally different cost structure than SaaS, and copying freemium playbooks without adjusting for that will either destroy margins or create a free tier nobody uses. If you're setting pricing strategy for an AI feature — or evaluating whether to add one — this piece is a direct input. The "capability-limited free tier" pattern is the most actionable: it lets you run a real freemium funnel while protecting inference spend. This connects directly to the open question of whether users will pay for AI features — the answer here is yes, but only if pricing is structured to match how value is actually delivered.

Critical questions:

  • How do you define "capability-limited" without making the free tier so weak that it doesn't demonstrate real value?
  • For B2B AI features bundled into existing SaaS products, does usage-based pricing create friction that hurts adoption even if it improves margins?
  • What's the right conversion window for AI products — does the "repeated high-quality output" signal come faster or slower than traditional SaaS activation?
  • If inference costs keep dropping (as they have been), does the cost structure argument eventually weaken and bring freemium back into play?

Action you could take today: Audit your current AI feature pricing against the cost structure: calculate your actual per-active-user inference cost at different usage levels and check whether your free tier is subsidizing meaningful usage or just trials. That number will tell you whether your freemium funnel is a growth engine or a cost center.

Cursor — Model Controls, Spend Management, and Usage Analytics#

Source: https://cursor.com/changelog/05-04-26 Credibility: High (first-party changelog, shipped product change)

What happened: Cursor shipped a significant enterprise admin update: granular model controls (allowlists and blocklists at the org level), updated spend management, and more detailed usage analytics. This is the governance layer enterprises need before they can deploy Cursor broadly — admins can now control which models individual users or teams can access, set spending limits, and get visibility into how AI usage breaks down across the organization.

Key technical details:

  • Model access controls: Admins can now set allow or blocklists for specific models — meaning an org can enforce that users only access, say, Claude Sonnet and not GPT-4o, or can block experimental models entirely
  • Spend management: Updated controls for setting and tracking AI spend per user, team, or project — this is the cost governance layer that large deployments require before they'll approve purchasing
  • Usage analytics: More granular breakdown of how usage is distributed across the org — which teams are heaviest users, which models are being invoked, where spend is concentrating
  • Coding agents: The changelog notes that coding agents can also leverage the new metrics capabilities, suggesting this isn't just human-facing — it's infrastructure for agent governance too

Why it matters for PMs: This is what enterprise AI tool adoption actually looks like at the governance layer. The question for enterprise buyers isn't "does Cursor work?" — it's "can I control it, audit it, and manage its cost?" Cursor just answered all three. For PMs building AI developer tools, this is the checklist: model controls, spend caps, and usage visibility. Without these, enterprise procurement will stall. With them, you're unblocking a completely different buyer conversation. Also worth noting: adding agent-level governance signals Cursor is thinking ahead to a world where agents, not just humans, are consuming these APIs — and someone needs to be accountable for that spend.

Critical questions:

  • Do model blocklists create real security value, or are they primarily a compliance theater feature that procurement requires but doesn't actually reduce risk?
  • How does Cursor handle the case where a blocked model is the best one for a specific task — does it silently fall back or surface the constraint to the user?
  • What's the right granularity for spend management — per-seat caps can disincentivize the most productive users, which may undercut the ROI case
  • Will usage analytics be good enough to help team leads make resourcing decisions, or will it require a separate BI layer to be useful?

Action you could take today: If you're in a conversation about enterprise AI tool adoption for your dev team, use this changelog as a template for what governance capabilities to require from any AI coding tool. Model controls, spend management, and usage analytics are now the baseline — if a vendor can't show you these, ask why.

Notion — What We Learned During the Custom Agents Beta#

Source: https://www.notion.com/blog/what-we-learned-during-the-custom-agents-beta Credibility: High (first-party post-mortem from Notion's co-founder Akshay Kothari on a real shipped beta)

What happened: Notion published a retrospective on their Custom Agents beta — autonomous AI teammates that handle entire workflows without user intervention. The post is co-founder Akshay Kothari reflecting on what they learned building agents that run inside an existing productivity product rather than as a standalone AI tool. The core insight: agents that work within a user's existing context (their Notion workspace, their pages, their workflows) are fundamentally different from agents that operate in a blank-slate environment.

Key patterns from the beta:

  • Context is the moat — agents with access to a user's existing Notion data (documents, databases, linked content) performed dramatically better than agents working from scratch. The workspace-as-context advantage is Notion's actual differentiator, not the model underneath
  • Autonomy level is a dial, not a switch — users wanted different autonomy levels for different task types. Agents handling data formatting could run fully autonomous; agents touching external communication or decisions needed approval gates
  • Repetitive workflow automation drove retention — the use cases that stuck were the boring, high-frequency ones: weekly summaries, data entry, report generation. Creative or strategic tasks had lower retention (users felt less confident in outputs)
  • Transparency in agent actions was table stakes — users needed to see what the agent did, not just the output. Black-box agents generated support tickets even when they produced correct results

Why it matters for PMs: This is a rare first-party post-mortem on an agent beta from a company with real scale. The "autonomy as a dial" insight maps directly to the open question of how much autonomy users are comfortable giving AI agents — and the answer here is: it depends entirely on the stakes and reversibility of the task. The transparency finding is especially actionable: users don't trust agents they can't audit, even correct ones. If you're building agentic features, your audit log is a product feature, not a backend concern.

Critical questions:

  • How did Notion measure "retention" for agents — is it the agent being re-run, or the user staying on the platform longer?
  • What's the failure mode when an agent gets context wrong — does it silently produce bad output, or does it surface uncertainty?
  • For a productivity tool like Notion, does agent automation cannibalize premium seat usage (if agents do the work, do users still need to be in the product)?
  • How does the "context as moat" insight hold up as competitors integrate with the same underlying data sources?

Action you could take today: If you have an agentic feature in your product or roadmap, audit it against the transparency question: can a user trace exactly what the agent did and why? If the answer is no — or if it requires digging through logs — you have a trust gap that will show up in support volume and churn before it shows up in your metrics.

Quick Hits#

  • Lenny Rachitsky / Teresa Torres: Teresa Torres joined the All Things Product podcast episode on "Taste" — what it means to develop good product taste, and whether AI changes what taste looks like in product decisions. PM craft content worth a listen. (2026-05-05): https://www.producttalk.org/taste-all-things-product-podcast-with-teresa-torres-petra-wille/

  • OpenAI: Published a technical deep-dive on how they rebuilt their WebRTC stack to deliver low-latency voice AI at scale — global infrastructure, turn-taking, and real-time conversation handling. If you're building voice-first features, this is the engineering bar you're competing against. (2026-05-04): https://openai.com/index/delivering-low-latency-voice-ai-at-scale

  • Vercel: Added observability metrics to the Vercel CLI — you can now query performance data for any team or project via vercel metrics. Coding agents can also access this programmatically. Small feature, but it signals that observability tooling is becoming agent-native, not just human-facing. (2026-05-05): https://vercel.com/changelog/vercel-metrics-in-cli

  • Microsoft: Published their 2026 Work Trend Index on "frontier firms" — how leading organizations are rebuilding their operating model for AI. Worth scanning for data points on AI adoption patterns and organizational change signals. (2026-05-05): https://news.microsoft.com/annual-work-trend-index-2026

  • Notion: Shipped a new mobile home screen redesign (separate from the Custom Agents update) — a new home on mobile. Incremental UX but signals continued investment in mobile as a primary surface for AI productivity workflows. (2026-05-04): https://www.notion.so/releases/2026-05-04

The Thread#

Governance is becoming the enterprise AI product. Cursor added model controls and spend management. Notion's agent beta found that transparency was table stakes for user trust. Lenny's freemium piece is fundamentally about cost governance. The pattern this week: the teams winning enterprise AI adoption aren't just shipping smarter features — they're shipping the controls that let organizations say yes to those features. Audit logs, spend caps, model allowlists, and agent transparency aren't compliance overhead. They're the product.

Sit With This#

Notion's Custom Agents beta found that users needed to see what the agent did, not just the output — and that black-box agents generated support tickets even when they produced correct results. Trust required transparency, not just accuracy.

For your AI product: Is there an agent or AI feature in your product where users can't trace the reasoning or actions behind the output? If a user got a wrong answer and came to you with "why did it do that?" — could you show them? If not, what would it take to make that auditability a first-class product feature rather than a backend concern?