What an AI chat request really costs: $0.017 or $0.0035

One request to an AI support chat costs $0.0168 on Claude Sonnet 5.5 when every call resends the full prompt. Two changes cut that to $0.0035: prompt caching and sending easy questions to a cheaper model. At a $29 seat price, that moves the break-even from 1,726 requests per seat per month to 8,278 (our model, 2026).

This post opens the series on designing AI and SaaS products. It builds a cost model you can copy, shows where the money goes, and ends with a margin table for a $29 seat. Every price comes from Anthropic's pricing page, read on October 23, 2026.

What is cost per request, and why model it before you build?

Cost per request is the sum of input, cached input and output token charges for one call to a language model, divided by the number of calls. It is the number every other AI pricing decision depends on.

Most teams find it after launch, on the invoice. A model written first takes an hour and tells you whether the product can work at your price.

Unit economics is the profit or loss on one customer or one unit of usage. For an AI feature, the unit is a request, and the customer is a paid seat. If one heavy seat costs more than it pays, growth makes the loss bigger.

I model one workload throughout: a support copilot inside a SaaS app. A user asks a question, the system retrieves help-center passages, and the model answers using a long system prompt with tool definitions. Conversations run five turns on average.

What workload does the model assume?

The model uses five token counts per turn. They are round numbers I chose to resemble a real support copilot, not measurements of live traffic.

Part of each request	Tokens	Notes
System prompt and tool definitions	4,000	Identical on every request
Retrieved help-center context	1,500	Different on every request
User message	150
History added per turn	500	User message plus the answer, kept for later turns
Model answer	350

Turn one sends 5,650 input tokens. Turn five sends 7,650, because four earlier turns of history ride along. Output stays at 350 tokens.

Your numbers will differ, so the script at the end takes them as constants. The ratios between strategies move less than the absolute dollars do.

What do the four current models cost per request?

On a five-turn conversation with no caching, a request costs $0.0840 on Claude Fable 5.1, $0.0336 on Claude Opus 5.5, $0.0168 on Claude Sonnet 5.5 and $0.00084 on Claude Haiku 5.5. These figures use list prices per million tokens from Anthropic's pricing page.

Claude Sonnet 5.5 is Anthropic's mid-tier model, priced at $2 per million input tokens and $10 per million output tokens. Claude Haiku 5.5 is the small, fast tier at $0.10 input and $0.50 output for prompts up to 100,000 tokens.

Model	Input per MTok	Cache read per MTok	Output per MTok	Per request, no cache	Per request, cached
Fable 5.1	$10	$0.25	$50	$0.0840	$0.0501
Opus 5.5	$4	$0.20	$20	$0.0336	$0.0204
Sonnet 5.5	$2	$0.10	$10	$0.0168	$0.0102
Haiku 5.5	$0.10	$0.01	$0.50	$0.00084	$0.00053

Model choice is a 100x lever. The gap between Fable 5.1 and Haiku 5.5 on this workload is $0.0832 per request. No amount of prompt tuning on the expensive model closes it.

Where does the money go in a chat bill?

Input tokens account for 79 percent of the bill. For one five-turn conversation on Sonnet 5.5 with no caching, input costs $0.0665 and output costs $0.0175 (our model, 2026).

That surprises people, because output tokens cost five times more per token on Sonnet 5.5. The volume is the reason. Each turn resends the system prompt, the context and all earlier history. Input volume grows with every turn, while output stays at 350 tokens.

Consider what that means for a cost-cutting plan. Asking the model to "be concise" trims output and saves little. Shortening the system prompt, trimming history and caching the repeated prefix attack the 79 percent.

Conversation length matters even more. Without caching, cost grows faster than linearly, because turn N pays for N-1 turns of history.

Turns in conversation	No cache	Prompt cache	Saving
1	$0.0148	$0.0168	-$0.0020
3	$0.0474	$0.0339	$0.0136
5	$0.0840	$0.0511	$0.0329
8	$0.1464	$0.0774	$0.0690
12	$0.2436	$0.1131	$0.1306

A twelve-turn conversation costs 16.5 times a one-turn conversation without caching, and about 6.7 times with it (our model, 2026).

How much does prompt caching save, and when does it lose?

Prompt caching is an API feature that stores a repeated prompt prefix so later requests read it at a fraction of the input price. On Claude Sonnet 5.5, a cache read costs $0.10 per million tokens against $2 for fresh input, a 20x discount, according to the pricing page.

Writing to the cache costs more. A 5-minute cache write is billed at 1.25 times the base input price, per Anthropic's prompt caching documentation. The documentation says a 5-minute write pays for itself after one read.

That rule has a flip side I measured in the model. A one-turn request costs $0.0168 cached and $0.0148 uncached, a 13.5 percent penalty. If your feature makes one call and never reuses the prefix, caching costs you money.

Two more cases decide whether caching pays:

1. The gap between requests. The cache lives 5 minutes by default. If users pause longer between turns, each turn rewrites the whole prefix. In my model that makes a five-turn conversation cost $0.1006 against $0.0840 uncached, 19.8 percent worse.
2. The prefix must be identical. One changing token early in the prompt, such as a timestamp or a user name in the system prompt, breaks the cache for everything after it. Put the volatile parts last.

The 1-hour write costs 2 times base input, so it needs two reads to pay back. Use it when conversations have long pauses, such as a support agent who answers a customer after lunch.

Caching takes a five-turn request from $0.0168 to $0.0102, and routing takes it to $0.0035 (our model, 2026).

Strategy	Cost per request	Versus naive
Naive Sonnet 5.5, no cache	$0.0168	baseline
Sonnet 5.5 with prompt cache	$0.0102	39 percent lower
Cache plus 50 percent routed to Haiku	$0.0054	68 percent lower
Cache plus 70 percent routed to Haiku	$0.0035	79 percent lower
Cache plus 90 percent routed to Haiku	$0.0016	91 percent lower

What is model routing, and what does it cost to run?

Model routing is sending each request to the cheapest model that can answer it well. A small classifier call decides whether a question is easy, such as "where do I reset my password?", or hard, such as a multi-step billing dispute.

In the model, the classifier is a Haiku 5.5 call with 600 input tokens and 10 output tokens. It costs $0.000065 per request. That is under 1 percent of a Sonnet request, so the router pays for itself if it moves even a few requests to Haiku.

The savings scale with the share you can safely route down. At 70 percent, the blended cost is $0.0035 per request. At 90 percent it is $0.0016.

The model does not measure quality, and that is the real risk. A cheaper model that answers 5 percent of easy questions wrongly may cost more in support tickets than it saves in tokens. Before you route, sample 200 real conversations and have a person grade the Haiku answers. Route only the categories that pass.

What does this do to margin on a $29 seat?

A $29 seat earns a positive margin at up to 1,726 requests per month on naive Sonnet 5.5, and at up to 8,278 with caching and 70 percent routing. Past those points the seat loses money, and a rate limit on the vendor side will not protect your margin. Gross margin is revenue minus the direct cost of serving the customer, here the API bill.

Requests per seat per month	Naive Sonnet 5.5	Cached Sonnet 5.5	Cached + 70% routed	Naive Fable 5.1
200	$25.64	$26.96	$28.30	$12.20
500	$20.60	$23.89	$27.25	-$13.00
1,000	$12.20	$18.78	$25.50	-$55.00
2,000	-$4.60	$8.56	$21.99	-$139.00
5,000	-$55.00	-$22.10	$11.48	-$391.00

Naive Fable 5.1 breaks even at 345 requests per seat per month, so a single power user at 1,000 requests loses $55 on a $29 plan.

Averages hide the problem. Revenue is flat per seat, and cost follows the heaviest users. A Forbes Technology Council column by Glean product manager Rahul Dey gives an example: a company with 1,000 seats might have 50 power users generating 80 percent of the inference cost. The same column says a complex query sent to a frontier model can cost 50 to 100 times more than a simple one. That is why usage caps or metered credits matter. Stripe's documentation on usage-based billing describes the metering model, and a later post in this series builds it.

What should you do first?

Start with the cheapest fixes and measure after each. This is the order I would apply them in a real product:

1. Log tokens per request. Record input, cached input and output tokens for every call, tagged by feature and customer. The API response reports them in its usage field, and Anthropic's token counting guide covers estimating a prompt before you send it. You cannot model what you do not measure.
2. Move static text to the front of the prompt. System instructions, tool definitions and policies go first. Timestamps, user names and retrieved context go last.
3. Turn on caching for multi-turn features only. Leave single-shot calls uncached unless the same prefix repeats across users within five minutes.
4. Cap history. Summarise turns older than six or eight, because history grows cost with every turn.
5. Add routing last. It carries the quality risk, so it needs graded samples first.
6. Use the Batch API for work nobody waits on. Batch processing gives a 50 percent discount on input and output, per the pricing page. Nightly summaries and bulk classification qualify.

If you are shopping for infrastructure around these choices, the hosting side of the same math is in the earlier series on shipping indie products.

The cost model in 30 lines

Paste this into a Python file, change the constants and run it. It reproduces every number above.

P = {  # input, 5m cache write, cache read, output; USD per MTok
 "sonnet": (2, 2.5, 0.10, 10),
 "haiku":  (0.10, 0.125, 0.01, 0.50),
}
SYS, CTX, USER, OUT, HIST = 4000, 1500, 150, 350, 500

def conv_cost(model, turns, cache):
    i, w, r, o = P[model]
    total = 0.0
    for t in range(turns):
        hist = t * HIST
        if not cache:
            total += (SYS + hist + CTX + USER) * i + OUT * o
        else:
            read = SYS + hist if t > 0 else 0
            write = SYS if t == 0 else HIST
            fresh = CTX + USER
            total += read * r + write * w + fresh * i + OUT * o
    return total / 1e6

per_request = conv_cost("sonnet", 5, True) / 5
print(round(per_request, 4))  # 0.0102

The script assumes every turn lands inside the 5-minute window. It also ignores retries, tool-call round trips and failed requests, which all add cost. Add a 10 to 20 percent buffer when you set a price.