# Pricing an AI Feature

Course: [LLM Cost, Latency & Model Selection](https://www.devtutorials.ai/learn/llm-cost-latency-model-selection) · Section: Foundations
Source: https://www.devtutorials.ai/learn/llm-cost-latency-model-selection/foundations/pricing-an-ai-feature

> Turn cost records into unit economics in TypeScript or C#: margin per seat, break-even usage, the price for a target margin, and an allowance plan that makes money on every seat.

## Price the Feature From Your Own Records

Brightgrid sells its AI assistant as an add-on: **$5 per agent seat per month**.

In **Where the Money and the Milliseconds Go**, your meter measured one ticket: about **$0.0034** in model calls. Search, logs and storage add about $0.0006. So one AI-handled ticket costs about **$0.0040**.

That looks tiny. But a seat that handles 5,200 tickets a month costs almost $21, and pays $5.

In this lesson, you will turn your cost records into unit economics in code. Then you will design a plan that makes money on every seat.

Press **Play**, or use **Next** to go one step at a time.

- **Each row:** one seat, its tickets this month, what it pays and what it costs.
- **Red rows:** seats that lose money.
- **The last frame:** the same seats on a plan with an allowance.

**Simple lesson:** a flat price on a usage-based cost loses money on your heaviest users.

### A Real-World Example

The billing export shows 12 seats last month. Five of them used more than 1,241 AI tickets.

The finance team saw "AI add-on: $60 revenue". They did not see the $74.59 in model and search costs, because those sit in a different bill.

**Simple lesson:** put revenue and model cost in the same report, per customer.

## What You Will Build

In this lesson, you will learn:

1. how to compute cost, revenue and margin per seat and for the whole plan
2. how to find the break-even usage of a seat
3. how to find the lowest price that reaches a target margin
4. how to design a plan with an allowance and overage, and check it in code

You will finish three files in the **pricing** folder of the project.

- **Seat economics** (`src/pricing/seatEconomics.ts`, or `Pricing/SeatEconomics.cs`): margin per seat and per plan.
- **Break-even** (`src/pricing/breakEven.ts`, or `Pricing/BreakEven.cs`): break-even tickets and the price for a margin.
- **Plan design** (`src/pricing/planDesign.ts`, or `Pricing/PlanDesign.cs`): bills with an allowance, and a plan check.

Open the **Code** tab.

- **The harness file:** the 12 seats from billing, the cost per ticket and today's price.
- **The cost per ticket:** your Lesson 2 number plus the non-model costs.

**For product managers:** this lesson is your main lesson. You can run every cell without changing code. Change the numbers in the cells to try your own prices.

**Simple lesson:** unit economics are code, so they can run on every month's real data.

## Margin per Seat

For one seat in one month:

- **Cost** = tickets × cost per ticket.
- **Revenue** = what the seat pays.
- **Margin** = revenue minus cost.

For the plan, add up revenue and cost across seats. **Margin %** = margin ÷ revenue.

Run the cell. Read the margin column from top to bottom.

- **Light seats:** almost all of the $5 is margin.
- **Heavy seats:** the margin goes negative and keeps falling.
- **The last line:** the whole plan loses money.

**Simple lesson:** look at the distribution of usage, not the average.

## Break-Even and Price for a Margin

Two numbers answer most pricing questions.

### Break-Even Usage

**Break-even tickets** = price ÷ cost per ticket, rounded down.

At $5 and about $0.0040 a ticket, a seat breaks even at **1,241 tickets**. Every ticket after that loses money.

### Price for a Target Margin

Software teams often aim for a gross margin such as 60% or more. Solve the margin formula for the price:

**price** = total cost ÷ (seats × (1 − target margin))

Round **up** to whole cents. Rounding to the nearest cent can land just below the target.

**The cost per ticket changes.** Every lever in this course lowers it, and a new model or a price change can raise it. Recompute these numbers from your cost records every month, not once at launch.

**Simple lesson:** know the usage where a customer stops paying for themselves.

## Design a Plan That Covers Heavy Users

A flat price that covers the heaviest seat is too expensive for everyone else. At about $16 a seat the plan reaches 60%, and the 5,200-ticket seat still loses money.

A common fix is an **allowance**:

- the price includes a number of AI tickets
- each started block of 1,000 extra tickets costs a fixed amount

Run the cell. Then add your own plan to the list.

- **Flat $5:** five seats lose money.
- **Flat $16:** good margin, but one seat still loses money, and light users pay three times more.
- **$5 + 1,000 included + $6 per started 1,000:** no seat loses money.

**Test the plan on real usage, not on a typical customer.** A plan that works for the average seat can still lose money on the top 10%. Run the plan check on last month's billing data before you change prices.

Run `npm run economics` (or `dotnet run -- economics`) in the Code tab. It prints today's margin, the break-even, the price for 60% and the allowance plan.

**Simple lesson:** charge for usage above a fair allowance, and prove it on real data.

**Try it on a real model.** Guessed costs make weak plans. Run three real tickets, and get a cost per seat from measured tokens. Switch **Model** to **Real** in the lab's top bar. It runs an open model in your browser with WebLLM, and needs WebGPU. It is not graded.

## Put It in Your App

- **Join the data.** Group your cost records by customer or seat id, and join them with billing. Pass that id in every `CallMeta`.
- **Run the check monthly.** A scheduled job can run `checkPlan` on last month's data and post the result.
- **Show usage to customers.** If a plan has an allowance, show how much is left. Surprise overage bills create support tickets.

**Keep pricing logic out of the request path.** The meter logs costs. A separate job turns them into bills and reports. Then a pricing change never slows down a user's request.

**Simple lesson:** cost records plus billing data give you margin per customer.

## Common mistakes

| Mistake | Wrong idea | Correct idea | What goes wrong |
|---|---|---|---|
| Pricing from the average user | "Most users are light." | Check the whole distribution. | The heaviest users wipe out the margin. |
| Counting only model calls | "The LLM bill is the cost." | Add search, storage and logging per action. | Margin looks higher than it is. |
| Rounding the price to the nearest cent | "A cent does not matter." | Round up for a target margin. | The margin lands just below the target. |
| Floor instead of ceiling for overage blocks | "1,200 extra is one block, 200 is zero." | Charge each started block. | Usage just over the allowance is free. |
| Setting the price once | "Costs are stable." | Recompute monthly from records. | A model change silently erodes margin. |

## Check Your Understanding

## Exercises

## Build It in the Project

The other files of this lesson's project are optional practice. Finish them to run the lesson's script on your own code.

## What to Remember

- Cost per action comes from your cost records, plus non-model costs.
- A flat price on usage-based cost loses money on heavy users.
- Break-even usage = price ÷ cost per action, rounded down.
- Price for a margin = cost ÷ (seats × (1 − margin)), rounded up.
- An allowance plus overage keeps light users cheap and heavy users profitable.
- Recompute these numbers every month.

Next: **How LLM Latency Works**. You will split a slow answer into network, queue, prefill and decode, and give each step a budget.