Submissions are open — put your project in front of the r/startupaccelerator community →
Monetization3 min read

Meter your AI feature: the cost ledger that decides your price

Most founders shipping an AI feature have never measured what a single user costs them in a month. Ninety minutes of instrumentation produces that number, and three levers already in the API move it.

The StartupAccelerator team

The short version

  • Every AI feature has a per-customer cost line, and most founders are pricing on top of one they have never measured.
  • Meter at the call site: one row per request carrying user, feature, model, effort, the token counts and the computed cost.
  • Output bills at five times input on every current model, so asking for less prose back is the cheapest lever you own.
  • Finish with one query: thirty-day cost per user beside what that user pays, worst first. The same table carries the ceiling.

You set the price before you knew the cost. Nearly everyone shipping an AI feature did. The call is a few lines of code and the bill is one number at month end, and the line between them is never urgent until the invoice makes it urgent.

Ninety minutes to a real number

The instrumentation is smaller than it sounds. One wrapper, one table, one rate constant.

  1. One row per model call: user id, feature, model, effort, cost, and four token counts — input, cache write, cache read, output. Never a total; they bill differently.
  2. Route every call through one meter() wrapper. A call site that still reaches the SDK makes the ledger lie within a week.
  3. Compute cost from one rate constant: Opus 5 at $5 and $25 per million tokens, Sonnet 5 at $3 and $15 (introductory $2 and $10 until 31 August 2026), Haiku 4.5 at $1 and $5.
  4. Write the row outside the request path and swallow its errors. A ledger that can break the feature it measures gets deleted.

A day of rows produces the first finding for you: output bills at five times input, on all three models. Most AI features spend those tokens on prose a user skims once. Ask for less back.

One heavy user's month, billed three ways. The line is what they pay you, and only the first configuration fails to clear it.

Three levers, in the order they pay

  1. Cache the stable half: hoist the fixed system and reference block above everything per-request. The match is on the prefix, so one timestamp near the top voids the rest. It engages only above roughly a thousand tokens of stable prefix.
  2. Route by difficulty: Haiku 4.5 classifies, Sonnet 5 carries the work, Opus 5 handles escalation. On those last two, depth is the effort dial rather than a fixed thinking budget.
  3. Batch anything not answering a human this second: digests and backfills run asynchronously at half cost on the Batches API. Key results by their own id, never by position.

The query that decides the price

  1. Sum thirty days of cost by user, join it to what that user pays, sort worst first. Read that list before your next pricing conversation.
  2. Then cap it. A per-user ceiling checked before the call, degrading or refusing honestly, turns a report into a control that stops the runaway on the Saturday it starts.

None of this tells you what to charge. The alternative your customer would otherwise use still decides that. It tells you which of your plans are paying for themselves, and which are being subsidised by the others.

Accelerator AI

Put this article to work

Ask it a question, or turn it into a to-do list for your own project. Both answer strictly from this article — nothing invented.

Answers are generated from this article only and are a working draft, not advice.

Questions this answers

How do you calculate the cost of an AI feature per user?

Meter every model call and store the result: one row per request with the user, the feature, the model and the token counts the response reports — input, cached input, output. Multiply each by that model's published per-million rate and sum thirty days by user. Without that table, any claim about AI margin is an estimate.

Does prompt caching actually reduce API costs?

It does on the requests that hit, and the hit is the part you must verify. Caching is a prefix match: mark the stable system and context block, and keep everything that varies after it. A timestamp near the front invalidates everything below it, silently and at full price. It also engages only above roughly a thousand tokens of stable prefix. Confirm with a non-zero cache read.

Which Claude model should you use to keep AI costs down?

Route rather than pick one. Haiku 4.5 handles classification and extraction, Sonnet 5 carries the main work, and Opus 5 is kept for escalation. Depth is a separate dial on the larger two: effort runs from low to max, and lowering it buys less preamble rather than a worse model.

pricingai costsunit economicsmonetization
Found this useful? Send it to a founder who needs it.

Building something?

Put it in front of founders who read this — free listing, community-voted, reviewed before it goes live.

Submit your project →
Monetization3 min read Pricing your first SaaS: the anchor, the ladder, and the free-tier trap Most first-time founders price from fear. A simple structure — one anchor, three rungs, and a free tier with a job to do — beats agonizing over the number. Read the article → Shipping3 min read The blocker list: what actually stalls solo builders It is almost never the hard technical problem. Weeks disappear into decisions that were never worth making, and into work that could have waited a year. Read the article → Growth3 min read Your first hundred users will not come from a launch Launch days produce a spike and a lesson. The founders who get to a hundred real users almost always get there through channels that look too small to bother with. Read the article →