Unit economics

Lesson 10
55 min
Module 3: Estimate resources and cost

Lesson 10 of 19 · AI System Design and Cost EngineeringUnit economics

Course overview

1. Start with requirements

2. Design the end-to-end architecture

3. Estimate resources and cost

4. Optimize with measured trade-offs

5. Design for failure and growth

6. Communicate the proposal

7. Case studies

What you will be able to do

Turn the monthly cost into the numbers that Omar can use for a price: the cost per question, per document change and per shop. Then test them against the low, base and high cases and a sensitivity table, so nobody quotes a unit cost without its volume.

Before you startWhat to know and to have readyAbout 55 minutes

What you need to know

The cost-driver table and the monthly cost of US$52.67 (base case), from Cost model.
The demand ranges and the third and fourth shops, from Demand assumptions.

What you need on your computer

Your folder design-pack from the last lesson, with python -m pytest -q printing 28 passed.
A spreadsheet program is optional. The calculator writes a CSV file that any spreadsheet can open.

Tested with Python 3.12 on macOS (Apple silicon). The Windows (PowerShell) and Linux commands are written, not tested.

A shared flat

Two friends share a flat. The rent is 1,000 dollars a month, and it does not change if they cook at home or eat out. The food changes: each one pays for what he eats.

How do they split the bill? The rent, equally: 500 each, because each one has a room. The food, by use. And what does one dinner at home cost? It depends on how many dinners they cook. With 10 dinners a month, each dinner carries 100 dollars of rent. With 60, it carries less than 17. The food in each dinner costs the same either way.

Three ideas hide in this flat. Some costs are fixed and some vary with use. The cost of one unit depends on how many units share the fixed part. And splitting a shared bill needs a rule that both people accept. This lesson applies all three to the assistant.

The problem: “about a cent per question”

Tomás has a number for Omar: “It costs about a cent per question.” Omar can use a number like that. He can multiply it by a shop’s questions and put it in a price.

But which cent? With this module’s model, the cost per question is US$0.0034 in the low case, US$0.0012 in the base case and US$0.0005 in the high case. The design is the same in all three; only the volume changes. A cent is about eight times the base case. And a price of US$0.0012 per question fails for a small shop. Bramble Books asks 65 questions a day, 1,950 a month. At US$0.0012, it would pay US$2.34 a month, but its share of the fixed cost is about US$22.

Omar’s own question has the same trap: “If usage doubles, does the cost per shop double?” A model with only one number per question would say yes. The real answer depends on how much of the cost is fixed.

The idea: unit economics

Unit economics is the cost of one unit of what the customer gets: one question, one document change, one shop for a month. It answers “what does one more cost?” and “what should we charge?”. It needs one split first:

A fixed cost is paid even with no questions: the API replica that waits, the database server, the minimum storage.
A variable cost grows with the questions and the documents: tokens, retries, requests, logs, network.

From the split come two costs per question, and both are useful:

The variable cost per question is what one more question adds. It stays the same at any volume.
The all-in cost per question is the whole bill divided by the questions. It falls when the volume grows, because more questions share the fixed cost.

A unit cost is useless without its volume and its scenario. A sensitivity table shows how the total moves when one assumption changes, with everything else the same. It answers Omar’s “what if?” questions with numbers instead of opinions.

A tiny example: the base case, split

Here is the base case, with every value visible. The monthly cost of US$52.67 has two parts:

Fixed: API replica 27.43 + database server 13.50 + database storage 4.05 = US$44.99 (85%). The lines are rounded; the calculator adds the exact values.
Variable: answers’ tokens 7.52 + retries 0.15 + question embeddings 0.01 = US$7.68 (15%).

Per question, with 43,950 questions a month:

Variable: 7.68 ÷ 43,950 = US$0.000175: what one more question adds.
All-in: 52.67 ÷ 43,950 = US$0.0012: about an eighth of a cent.

Per shop, the pack uses the flat’s rule. The fixed cost is shared equally, because each shop needs the whole system to be there. The variable cost follows each shop’s questions:

The monthly cost of US$52.67 splits into a fixed part of US$44.99, for the API replica and the database, and a variable part of US$7.68, for tokens and retries. The fixed part is divided equally: US$22.49 for each shop. The variable part is divided by questions: 1,400 of 1,465 gives US$7.34 to Larkfield, 65 of 1,465 gives US$0.34 to Bramble Books. Larkfield pays US$29.83, Bramble Books US$22.83. — The cost per shop in the base case: fixed cost shared equally, variable cost by each shop's share of the questions.

Bramble Books asks 4% of the questions and pays 43% of the cost. Is that fair? It is a choice, and the proposal must say so. The other simple rule, everything by questions, would give Bramble Books US$2.34 and Larkfield US$50.33. Then Larkfield pays for a system that Bramble Books also needs. Omar picks the rule; the model shows both. The equal split of the fixed cost also has a good side: each new shop takes a share of it from the others.

Guided practice: unit costs, scenarios and sensitivity

In your folder design-pack, with the environment active, copy the last two code files of the module and their tests.
- macOS / Linux
- Windows (PowerShell)
Terminal window
S=../nextia-learning-labs/C26/snapshots/end-of-m03 cp "$S/costmodel/units.py" "$S/costmodel/export.py" costmodel/ cp "$S/tests/test_units.py" "$S/tests/test_export.py" tests/
Terminal window
$S = "..\nextia-learning-labs\C26\snapshots\end-of-m03" Copy-Item "$S\costmodel\units.py", "$S\costmodel\export.py" costmodel\ Copy-Item "$S\tests\test_units.py", "$S\tests\test_export.py" tests\

Print the unit costs of the base case:

python -m costmodel units

Unit economics, scenario base, month 0
  total                        US$      52.67 per month (fixed 85%, variable 15%)
  per question (variable only) US$   0.000175
  per question (everything)    US$   0.001198
  per document change          US$   0.000169 (embed + summary + worker)
  Larkfield                    US$      29.83 per month
  Bramble Books                US$      22.83 per month

These are the numbers of the tiny example. A document change costs US$0.000169: embedding it, summarising it and the worker’s seconds. Eleven changes a month cost less than a cent.

Print the three scenarios, now and in month 12:

python -m costmodel scenarios

Scenarios (US$ per month)
                     low        base        high
  month 0          40.54       52.67       84.83   (2 tenants)
  per tenant       20.27       26.33       42.41
  month 12         40.79       57.07      129.60   (4 tenants)
  per tenant       10.20       14.27       32.40

Print the sensitivity table:

python -m costmodel sensitivity

Sensitivity (base scenario, month 0)
  what if                         US$/month   change  per question  per tenant
  base                                52.67      +0%      0.001198       26.33
  usage x 2                           60.35     +15%      0.000687       30.17
  answers 2x longer                   56.09      +7%      0.001276       28.05
  chat-strong for every answer       188.32    +258%      0.004285       94.16
  all prices +20%                     63.20     +20%      0.001438       31.60

Write the export files for a spreadsheet:
Terminal window
```
python -m costmodel export
```
```
Wrote costs.csv: 84 rows (3 scenarios x 2 months x 14 drivers)
Wrote explorer.json: usage x1 US$52.67 per month, x2 US$60.35 (1.15 times, not 2)
```
Open costs.csv in a spreadsheet if you like. Each row is one driver in one scenario and month, with the word fixed or variable. The sum of the 14 rows of base, month 0, is 52.67.
Run the tests:
Terminal window
```
python -m pytest -q
```
```
...................................                                      [100%]
35 passed in 0.06s
```
Your pack is now the snapshot end-of-m03. costs.csv and explorer.json are not part of it: the pack’s .gitignore lists them, because the calculator can write them again at any time.

Read the scenarios

The scenario table is easier to judge as a picture:

Low
Base
High

The monthly cost in the low, base and high cases, now and in month 12 (M12). All six stay under Omar's budget of US$150 a month (Q8).

Text description of the chart

A column chart with six columns in three colours. Now: low US$40.54, base US$52.67, high US$84.83. In month 12, with four shops: low US$40.79, base US$57.07, high US$129.60. The low columns hardly change. The base column grows by 8%, the high column by 53%.

Three things stand out. First, the demand ranges were wide, but the cost range is narrow. Today, the high demand is 14 times the low demand, yet the high cost is only about twice the low cost. Fixed costs make a design’s cost much less uncertain than its demand.

Second, every case stays under the budget target Q8, at most US$150 a month in the first year. The tightest is the high case in month 12: US$129.60, 86% of the budget. Kwame writes that into the proposal as the number to watch.

Third, the cost per shop falls in month 12, from US$26.33 to US$14.27 in the base case. Four shops share the same fixed cost. That is Omar’s answer for the third and fourth shops: each new shop makes the assistant cheaper for the others.

Read the sensitivity table

Each row of the sensitivity table changes one thing and keeps the rest:

Usage × 2: +15%. Only the variable 15% doubles. This answers Omar: when usage doubles, the cost per shop grows from US$26.33 to US$30.17, not to US$52.67.
Answers 2× longer: +7%. Only the output tokens double, and they are about half of the token cost.
chat-strong for every answer: +258%. The strong model’s prices are 20 times chat-small’s. The token line grows from US$7.52 to about US$140, and it becomes the dominant driver. This is the biggest risk in the table, and Module 4 measures whether chat-strong is worth it.
All prices +20%: +20%. Every line moves by the same factor. The free amounts do not change, but at this volume they hold only lines that are zero anyway.

The table also tells Kwame which assumptions to check first. A wrong usage forecast moves the cost by 15%. A wrong choice of model moves it by 258%.

Now try the question yourself. The explorer uses the same calculator at seven usage levels, from a quarter of the base case to 16 times:

Explore

If usage doubles, does the cost per shop double?

Questions a month: 43,950
Total a month: US$52.67
Change from ×1: +0%
Per shop (2 shops): US$26.33
Per question, all-in: US$0.00120
Fixed share: 85%
Chat calls in the busiest minute / quota: 16.1 / 100

At ×1, the shops ask 43,950 questions a month and the design costs US$52.67 a month. This is the base case. 85% of the cost is fixed: it does not depend on the number of questions. Each question carries US$0.00120 of the whole cost. The busiest minute needs 16.1 chat calls; the provider quota is 100.

API replica (always on)
Database server and storage
Model tokens and retries
Files, requests, logs, network, worker

Cost by driver group at ×1
Driver group	Kind	US$ per month
API replica (always on)	fixed	27.43
Database server and storage	fixed	17.55
Model tokens and retries	variable	7.68
Files, requests, logs, network, worker	mostly variable	0.00
Total		52.67

The design pack's calculator at the end of Module 3, base case, month 0, two shops: the monthly cost by driver group at seven usage levels. The dashed line is twice the cost at ×1.

Text description of the explorer

The explorer has one control, a slider for the usage, from ×0.25 to ×16; each step doubles the questions. Seven stacked columns show the monthly cost at each usage level. Each column has four groups: the API replica, the database, the model tokens with retries, and the rest. A dashed line marks US$105.34, twice the cost at ×1. At ×1: 43,950 questions and US$52.67 a month. That is US$26.33 per shop and US$0.00120 per question; 85% is fixed. The busiest minute has 16.1 chat calls. At ×2: 87,900 questions, US$60.35 (+15%), US$30.17 per shop, US$0.00069 per question. At ×4: US$75.71 (+44%). At ×8: US$106.43, about twice the ×1 cost. The busiest minute needs 128.5 chat calls, more than the provider’s quota of 100. At ×16: US$167.88, 3.19 times the ×1 cost, with 257.1 chat calls in the busiest minute. At ×0.25: US$46.91, only 11% less than at ×1, and US$0.00427 per question.

The cost doubles only at about ×8, when the variable part has grown by as much as the whole cost at ×1. Look at the readout there: the busiest minute needs 128.5 chat calls, more than the quota. So the provider quota stops the growth before the money does. This is the same lesson as the workload arithmetic, now seen from the cost side.

The chart below shows the cost per question at the same seven levels:

All-in
Variable only

The cost per question at seven usage levels, base case. The all-in cost falls as more questions share the fixed cost; the variable cost stays the same.

Text description of the chart

A line chart. The x axis shows the usage from ×0.25 to ×16, each step twice the one before. The all-in cost per question falls as the usage grows. It is US$0.00427 at ×0.25, US$0.00222 at ×0.5 and US$0.00120 at ×1. It is US$0.00069 at ×2, US$0.00043 at ×4, US$0.00030 at ×8 and US$0.00024 at ×16. A dashed, flat line shows the variable cost per question, US$0.000175 at every level. The all-in line comes closer to the flat line as the usage grows.

That is why “a cent per question” cannot be right or wrong on its own. At low volume, the all-in cost is many times the variable cost; at high volume, it comes close to it. Quote a unit cost only with its volume, its scenario and the rule that produced it.

When to use unit economics

Use it whenever someone needs a price, a budget per customer or a “what if”. Use the variable cost per question to decide about one more question or one more feature. Use the all-in cost per question and per shop for prices and budgets, always with the volume.

Do not compare unit costs from different volumes, or from different allocation rules. The all-in cost per question of a busy month always looks better than a quiet one, and the design did not change. And do not hide the allocation rule: Bramble Books’ US$22.83 is a choice, not a measurement.

The cost is one more table in the proposal and some care with words. The benefit is that Omar can answer a shop’s question about price without a new calculation each time.

Common mistakes

Common mistake

A spreadsheet total that is eight times too big

Symptom: you open costs.csv in a spreadsheet, sum the column usd_per_month, and get US$405.49. The calculator says US$52.67.

Cause: the file holds six cases: three scenarios, now and in month 12. The sum adds all six totals: 40.54 + 52.67 + 84.83 + 40.79 + 57.07 + 129.60 = 405.50, one cent away because each total is rounded.

Fix: filter the rows first: scenario = base and month = 0. Then the sum of the 14 rows is 52.67, as the calculator says. The calculator and a sheet must give the same numbers; if they do not, the sheet is summing the wrong rows.

Common mistake

A unit cost quoted without its volume

Symptom: a new shop expects a monthly bill of 2,000 questions × US$0.0012 = US$2.40, and the real share is about US$20.

Cause: US$0.0012 is the all-in cost per question at the base volume, with the fixed cost shared by the two shops. A new shop brings few questions but takes a share of the fixed cost.

Fix: quote two numbers: a share of the fixed cost per shop per month, and the variable cost per question (US$0.000175). Write the volume and the scenario next to any all-in cost.

Reset. If your pack breaks, copy the snapshot end-of-m03 as the snapshots README shows.

Your turn: the home page and the cost per shop

Change one assumption once more. Omar puts the assistant on Larkfield’s home page: 1,600 asking customers a day in the base case, not 800. From the first lesson of this module, you know the new volume: 79,950 questions a month.

Before you run anything, predict three numbers: Larkfield’s cost per month, Bramble Books’ cost per month, and the all-in cost per question. Then change the base value of Larkfield’s customers_per_day in demand.toml to 1600, run python -m costmodel units, and change the value back.

Show the answer

The fixed cost does not change: US$44.99, or US$22.49 per shop. The extra 36,000 questions a month each add the variable US$0.000175: 36,000 × 0.000175 = US$6.30. So Larkfield pays 29.83 + 6.30 = US$36.13. Bramble Books asks the same questions as before, so it still pays US$22.83. The total is 52.67 + 6.30 = US$58.97, and the all-in cost per question is 58.97 ÷ 79,950 = US$0.00074.

Unit economics, scenario base, month 0
  total                        US$      58.96 per month (fixed 76%, variable 24%)
  per question (variable only) US$   0.000175
  per question (everything)    US$   0.000737
  per document change          US$   0.000169 (embed + summary + worker)
  Larkfield                    US$      36.13 per month
  Bramble Books                US$      22.83 per month

The calculator’s total is US$58.96, a cent below the hand result, because it rounds only at the end. One shop’s growth does not change the other shop’s bill. That is a property of the allocation rule, and Omar can explain it to Ines in one sentence. Change the value back to 800.

Module practice: a transparent calculation sheet

You now have a full cost model in code. The module’s practice asks you to build a small one yourself, in Markdown or a simple script, so that every step stays visible. Use fictional rates: the point is the structure, not the prices.

A worked example, small. A café wants a question bot for its menu. Fictional rates: a server at US$10 a month; US$0.002 per question for tokens; 3,000 questions a month.

Driver	Quantity	Rate (fictional)	US$ a month
Server (fee)	1 month	10.00 a month	10.00
Tokens (usage × price)	3,000 questions	0.002 per question	6.00
Total			16.00

With usage × 2: 10.00 + 12.00 = 22.00, which is +38%, not +100%. The server is the dominant driver at both volumes. Each row has a quantity, a rate and a result, and the kind of each line is in its name.

Your task. Build the sheet for the Fern Street Library’s help-desk assistant, with these fictional rates and assumptions:

600 questions a day (assumed), 30 days a month, 730 hours a month;
an always-on server at US$0.02 an hour;
storage: 20 GB, the smallest size, at US$0.10 per GB a month;
1,200 tokens per question at US$0.50 per million tokens;
5 KB of logs per question; the first 1 GB a month free, then US$2.00 per GB.

Compute the total, the share of each line, the dominant driver and the all-in cost per question. Then do it all again with usage × 2.

Show a worked solution

As a Markdown sheet, base case: 600 × 30 = 18,000 questions a month.

Driver	Quantity	Rate (fictional)	US$ a month	Share
Server (fee)	730 hours	0.02 an hour	14.60	53%
Storage (fee)	20 GB	0.10 per GB	2.00	7%
Tokens (usage × price)	18,000 × 1,200 = 21.6M	0.50 per 1M	10.80	39%
Logs (above the allowance)	18,000 × 5 KB = 0.09 GB	free up to 1 GB	0.00	0%
Total			27.40

The same sheet as a short Python script, practice_sheet.py. Each driver is one line: (quantity − free amount) × rate.

QUESTIONS_PER_DAY = 600            # assumption: Fern Street Library, base case
DAYS_PER_MONTH = 30
HOURS_PER_MONTH = 730

# Fictional rates: not real prices.
SERVER_PER_HOUR = 0.02             # an always-on server
STORAGE_GB = 20                    # the smallest size you can buy
STORAGE_PER_GB_MONTH = 0.10
TOKENS_PER_QUESTION = 1_200
PRICE_PER_MILLION_TOKENS = 0.50
LOG_KB_PER_QUESTION = 5
LOG_FREE_GB = 1.0
LOG_PER_GB = 2.00


def sheet(questions: float) -> dict:
    """One line per driver: (quantity - free amount) x price."""
    log_gb = questions * LOG_KB_PER_QUESTION / 1e6
    return {
        "server (fee)": SERVER_PER_HOUR * HOURS_PER_MONTH,
        "storage (fee)": STORAGE_GB * STORAGE_PER_GB_MONTH,
        "tokens (usage x price)": questions * TOKENS_PER_QUESTION / 1e6 * PRICE_PER_MILLION_TOKENS,
        "logs (above the allowance)": max(0.0, log_gb - LOG_FREE_GB) * LOG_PER_GB,
    }


def show(title: str, questions: float) -> float:
    lines = sheet(questions)
    total = sum(lines.values())
    print(f"{title}: {questions:,.0f} questions a month")
    for name, usd in lines.items():
        print(f"  {name:<28} {usd:>7.2f}  {usd / total:>4.0%}")
    top = max(lines, key=lines.get)
    print(f"  {'total':<28} {total:>7.2f}   per question {total / questions:.6f}; biggest: {top}")
    return total


base = show("Base", QUESTIONS_PER_DAY * DAYS_PER_MONTH)
double = show("Usage x 2", 2 * QUESTIONS_PER_DAY * DAYS_PER_MONTH)
print(f"Usage x 2 changes the total by {double / base - 1:+.0%}")

Run it with python practice_sheet.py:

Base: 18,000 questions a month
  server (fee)                   14.60   53%
  storage (fee)                   2.00    7%
  tokens (usage x price)         10.80   39%
  logs (above the allowance)      0.00    0%
  total                          27.40   per question 0.001522; biggest: server (fee)
Usage x 2: 36,000 questions a month
  server (fee)                   14.60   38%
  storage (fee)                   2.00    5%
  tokens (usage x price)         21.60   57%
  logs (above the allowance)      0.00    0%
  total                          38.20   per question 0.001061; biggest: tokens (usage x price)
Usage x 2 changes the total by +39%

With usage × 2, the total grows by 39%, not 100%, and the all-in cost per question falls from US$0.0015 to US$0.0011. The dominant driver changes: at the base volume it is the server; at twice the volume it is the tokens. The logs stay free in both cases, because 0.18 GB is below the free 1 GB.

Check your own sheet in three ways. Every line has a quantity, a rate and its kind. The fictional rates are marked as fictional. And the usage × 2 case changes only the lines that depend on questions.

Knowledge check

Check your understanding

Module completion check: the base case costs US$52.67 a month: API replica 27.43, database server 13.50, answers' tokens 7.52, database storage 4.05, retries 0.15, question embeddings 0.01, all other lines 0. Recompute the total when usage doubles, without the calculator, and name the dominant cost driver after the change. Say which lines you doubled and why.

Show the answer

Double only the lines that grow with the questions: answers’ tokens 7.52 → 15.04, retries 0.15 → 0.30, question embeddings 0.01 → 0.02. The fixed lines stay: 27.43 + 13.50 + 4.05 = 44.98. New total: 44.98 + 15.04 + 0.30 + 0.02 = US$60.34, which is +15% (the calculator says 60.35; it rounds only at the end). The logs, requests and network stay at 0: twice their quantity is still inside the free amounts. The dominant driver is still the API replica: 27.43 of 60.34, about 45%. The tokens grow to 25%. They would need about 3.6 times today’s usage to become as big as the API line.

Check your understanding

Tomás tells a new shop: 'It costs about a cent per question.' Explain to him, with this module's numbers, why the sentence cannot be right or wrong as it stands, and rewrite it so that it is true.

Show the answer

A cost per question depends on the volume, because 85% of the base cost is fixed. With the same design, the all-in cost per question is US$0.0034 in the low case, US$0.0012 in the base case and US$0.0005 in the high case. The variable cost per question, US$0.000175, is the same at every volume. A true sentence: “With two shops and about 44,000 questions a month, the assistant costs about US$53 a month, or US$0.0012 per question all-in. Each extra question adds about US$0.0002, and each shop shares the fixed cost of about US$45 a month.”

Check your understanding

In month 12, the base case has four shops and costs US$57.07 a month. Predict whether the cost per shop is higher or lower than today's US$26.33, explain why, then check with the scenario table.

Show the answer

Lower. The fixed cost stays about US$45, but four shops share it instead of two. The variable cost grows with the new questions, but it is a small part. The scenario table says US$14.27 per shop in month 12, against US$26.33 today. Each new shop lowers the cost of the others. That is a good argument for Omar’s growth plan, as long as the quota and the budget hold.

Recap

Unit economics is the cost of one unit: per question, per document change, per shop. It needs the split between fixed costs (85% in the base case) and variable costs.
Base case: variable US$0.000175 per question; all-in US$0.0012 per question. The all-in cost falls as volume grows; quote it only with its volume.
Per shop: the fixed cost shared equally, the variable cost by questions. Larkfield US$29.83, Bramble Books US$22.83: a choice, written in the proposal.
Scenarios: US$40.54 / 52.67 / 84.83 now, 40.79 / 57.07 / 129.60 in month 12; all under the US$150 budget. Per shop in month 12, base: US$14.27.
Sensitivity: usage × 2 +15%, answers 2× longer +7%, chat-strong for everything +258%, prices +20% +20%.
python -m pytest -q prints 35 passed. Your pack is now the snapshot end-of-m03.

Module 3 in one paragraph. You turned the demand into work: 43,950 questions and 41.6 million input tokens a month, and 16.4 MB of new data. At the busiest minute, 0.58 answers are in flight. The provider quota is the first limit, and the high case passes it today. You priced the work with one line per driver: quantity × list price, minus the free amount. The design costs US$52.67 a month in the base case, and the always-on API replica is the dominant driver. And you split that cost into fixed and variable parts. A question costs US$0.0012 all-in, and doubling usage adds 15%, not 100%. The biggest risk in the table is the model choice.

Next, Module 4 tests three ways to change the biggest lines: a different model, a cache and batching, and building instead of buying. Each one comes with measured quality, latency and cost.

Next: Model routing