Cost Split by Feature
Paste tagged usage and get spend per feature, ranked, with each one's share of the total.
4 features from 4 rows. Largest: search-summary at 66.0%.
- search-summary · 48.00M in / 2.10M out
- $175.50 · 66.0%
- checkout-assistant · 12.00M in / 900,000 out
- $49.50 · 18.6%
- internal-eval · 3.00M in / 800,000 out
- $21.00 · 7.9%
- support-triage · 5.40M in / 240,000 out
- $19.80 · 7.4%
- Every row, summed
- $265.80
Attribution is a tagging problem, not a maths problem
The arithmetic on this page is one multiplication per row. The reason per-feature spend is hard is upstream of it: something has to have attached a feature name to every request at the moment it was made, and survived every refactor since. Providers give you a bill and, usually, a per-key or per-tag breakdown; what they cannot give you is the meaning of the tag. That is yours to design.
What the split is for is deciding where an optimisation is worth anyone’s week. A feature at two percent of spend cannot be worth a sprint however inefficient it looks, and the feature at sixty percent is worth a fortnight even if it already looks tidy. The ranking is the output, not the total — the total is on your invoice already.
The two numbers this will not show you
It has no view of value, so the most expensive feature may well be the one you should spend more on. And it counts only the model bill: the engineering time that feature consumes each month, its share of your vector storage, its retries, its evaluation runs. Those are frequently larger than the inference line and they are attributed to nobody by default.