Guides / cost per feature
What is cost per feature?
Cost per feature is model spend grouped by the product surface that caused it, rather than by model or by day. It answers which part of your product burns the budget. Culpa, a local-first LLM cost, margin, and forecast ledger, tags every call to a feature at request time and rolls the spend up, so you can rank surfaces by what they actually cost.
Why this happens
Provider billing groups by model and by date, because those are the only two things a provider knows about you. Your product doesn't work that way. One model serves six features, and one feature calls three models. The grouping you need doesn't exist in the invoice and can't be recovered from it afterwards, because the tag was never attached. That's why cost per feature is an instrumentation decision, not a reporting one.
What this usually looks like
- You can rank your models by spend but not your features, so roadmap decisions get made on intuition about cost.
- A feature you assumed was cheap turns out to dominate the bill once someone finally counts it by hand.
- Shipping a new surface moves the total, and you can't isolate how much of the move was that surface.
- Nobody can answer whether the free tier's most-used feature is subsidised by paying customers.
Free, no card, no account
Run the free Cost Leak Scan
It shows your most expensive conversation before you install anything.
Mistakes that cost the most
| Mistake | Why it hurts | Do instead |
|---|---|---|
| Inferring the feature from the model name. | The mapping isn't one to one. As soon as two surfaces share a model the attribution silently becomes wrong, and it stays wrong. | Attach an explicit feature tag to every outbound call, chosen from a fixed list rather than a free string. |
| Tagging at the service level instead of the feature level. | A single service usually backs several product surfaces, so service-level tags aggregate away the distinction you needed. | Tag at the surface a user would name. If a product manager wouldn't recognise the label, it's the wrong granularity. |
| Letting untagged calls fall into a default bucket and ignoring it. | The untagged bucket grows quietly and becomes the largest line, at which point the whole breakdown stops being trustworthy. | Track untagged spend as its own number and treat any growth in it as a bug in the instrumentation. |
Run this check tonight
- List your product surfaces that call a model. Most teams find more than they expected, especially background jobs.
- For each one, check whether an outbound call carries a tag naming it. If not, that surface is invisible in your cost data.
- Add up spend that carries no feature tag at all, and express it as a percentage of the total.
- Rank your tagged features by spend and compare the top one against your own guess before you looked.
- Check whether your most expensive feature is on your cheapest plan. That's the margin question hiding underneath.
Why the model breakdown and the feature breakdown disagree
Illustrative example
A product with three surfaces sharing two models. Monthly volumes are modelled, and the rates are real: GPT-5.4 at $0.0025 per 1k input and $0.015 per 1k output, GPT-5.4 mini at $0.00075 and $0.0045.
Same $169, two different conclusions. The model breakdown points at a model. The feature breakdown points at a decision you can actually make about your product.
Every number, with its confidence and source
| Figure | What it means | Confidence | Source |
|---|---|---|---|
| $169 | modelled monthly spend across three surfaces sharing two models | calculated | Sum of three feature totals using real GPT-5.4 and GPT-5.4 mini rates from the price book (effective 2026-07-02). Token volumes are modelled, arithmetic shown in the teardown. |
| $50 | modelled monthly cost of a low-traffic report-drafting surface | calculated | (2,000 x $0.0025) + (3,000 x $0.015), GPT-5.4 rates per 1k tokens from the price book. |
What a generic answer can’t know
No provider can tell you which of your features made a call, because your feature names don't exist on their side of the wire. Recovering the mapping later is impossible once the calls are anonymous in an invoice. The tag has to travel with the request, which means capture happens in your own stack. Culpa runs there, keeps your prompts and responses on your infrastructure, and counts the calls to run your plan.
Questions founders ask next
Can I work out cost per feature from my provider invoice?
No. An invoice groups by model and date. It carries no reference to your product surfaces, and there's no field in the response that maps back to one. The attribution has to be attached when the call is made.
How granular should a feature tag be?
Granular enough that a product manager would recognise the name, coarse enough that the list stays short. Ten to thirty tags suits most products. Hundreds of tags means you're tagging code paths, not features.
What do I do about background jobs and evaluation runs?
Tag them too, as their own features. Evaluation and batch jobs are frequently the largest untagged line, and because they aren't user-facing nobody thinks to look at them until the bill forces it.
On your infrastructure
Culpa runs on your infrastructure. Your prompts and responses never leave it. Culpa counts calls to run your plan, and it fails open, so if it ever breaks your app keeps running.
Free, no card, no account
Run the free Cost Leak Scan
It shows your most expensive conversation before you install anything.
Keep reading
Sources: OpenAI API pricing. Last reviewed 2026-08-01. Plain text version.