Unit economics of AI features

Why this matters #

Traditional software has a comforting property: once it’s built, serving one more user costs almost nothing. AI features don’t. Every use has a real marginal cost, and the most enthusiastic users cost the most. A feature can grow quickly, delight people, and lose money faster with every new customer.

Unit economics is how you see that coming. It’s the per-unit view of a feature’s money: what one successful task costs, what it’s worth, and what that means per user and per plan. This article builds that view step by step, with a model you can adapt, and covers the levers that improve it.

Cost per successful task #

The unit that matters is the successful task, not the request. As covered in estimating cost per task:

cost per success = cost per call × calls per attempt ÷ success rate

In production you don’t need to estimate it; you can measure it. Total model spend for the feature over a period, from your traces or usage data, divided by the number of successful outcomes from your analytics. Include everything: retries, failed calls, background steps, evals that run on production traffic.

Track it per feature, per prompt version and per model. It’s the number that connects quality work to money: raise the success rate and cost per success falls, often more than a model switch would achieve.

Value per task #

Cost per success means little without what a success is worth. Depending on the feature:

• Time saved: minutes saved per success × the loaded hourly cost of the person saving them. Common for internal tools and B2B features.
• Revenue enabled: a feature that lifts conversion or upgrades is worth the share of that revenue it can credibly claim, ideally measured with an A/B test.
• Retention: a feature that keeps customers longer is worth part of the lifetime value it protects. Hard to measure directly; treat estimates cautiously.
• Cost avoided: a support feature that resolves tickets without an agent is worth the cost of handling those tickets.

Write down your estimate and how you got it. Rough is fine; unexamined isn’t. A feature whose cost per success is a small fraction of its value per success has room to prioritize quality. One where they’re close needs work before it scales.

Margins by plan and user #

When the feature is part of a paid product, the question becomes: after model cost, does each customer still make money? The trap is averages. Usage of AI features is often very uneven: many light users, some regular ones, and a small group of heavy users who use the feature far more than everyone else. An average customer can be comfortably profitable while the heavy segment loses money on every account.

A unit economics model #

This model computes margin per segment for a plan that includes an AI feature. Replace the assumptions with numbers from your own traces and analytics:

interface Segment {
  name: string;
  users: number;
  /** Successful AI tasks per user per month, from analytics. */
  successesPerMonth: number;
  /** Model calls per success, including retries and failed attempts, from traces. */
  attemptsPerSuccess: number;
}

const PRICE_PER_USER = 20; // USD per month, the plan price
const OTHER_COST_PER_USER = 4; // Infrastructure, support, payment fees
const COST_PER_ATTEMPT = 0.02; // Measured average model cost per call

const segments: Segment[] = [
  { name: 'light', users: 600, successesPerMonth: 20, attemptsPerSuccess: 1.2 },
  { name: 'regular', users: 300, successesPerMonth: 150, attemptsPerSuccess: 1.3 },
  { name: 'heavy', users: 100, successesPerMonth: 900, attemptsPerSuccess: 1.4 },
];

const usd = (n: number) => `${n < 0 ? '-' : ''}$${Math.abs(n).toFixed(2)}`;
let totalRevenue = 0;
let totalMargin = 0;

for (const s of segments) {
  const modelCost = s.successesPerMonth * s.attemptsPerSuccess * COST_PER_ATTEMPT;
  const margin = PRICE_PER_USER - OTHER_COST_PER_USER - modelCost;
  totalRevenue += PRICE_PER_USER * s.users;
  totalMargin += margin * s.users;
  console.log(
    `${s.name.padEnd(8)} model cost ${usd(modelCost).padStart(7)} per user, margin ${usd(margin).padStart(7)} (${((margin / PRICE_PER_USER) * 100).toFixed(0)}%)`,
  );
}

console.log(`Overall margin: ${usd(totalMargin)} on ${usd(totalRevenue)} revenue (${((totalMargin / totalRevenue) * 100).toFixed(0)}%)`);
// Overall the plan is profitable, but every heavy user loses money, and that segment is the one most likely to grow.

Running it shows the pattern clearly: light and regular users are healthy, heavy users each cost more in model spend than they pay, and the overall margin hides it. The fixes are product and pricing decisions, not only engineering ones: usage tiers, a fair-use limit, a higher plan for heavy use, or cheaper ways to serve the heaviest patterns.

Levers that improve unit economics #

Roughly in the order they’re usually worth trying:

Quality and cost are linked: the first lever, raising the success rate, improves both at once. Always check quality after a cost change, since a cheaper setting that fails more often can raise cost per success.

Common mistakes #

Try it #

Check your understanding #

Key takeaways #