Cost-to-serve per product feature dashboard
A single “we spent X on the LLM API this month” number tells you nothing about where the money went. Unit economics demand feature-level attribution: which features are cheap, which are expensive, and which one feature is quietly eating half the bill. This dashboard breaks monthly LLM spend down per feature so you can prioritize cost-reduction work with data instead of guesswork.
How it works
Each feature has a token profile and a model. The monthly cost is:
feature_monthly = daily_calls × 30
× [ (input_tokens / 1e6) × input_price
+ (output_tokens / 1e6) × output_price ]The dashboard sums every feature into a total, then shows each feature’s cost and its percentage of that total, sorted from most to least expensive. Because each feature carries its own model, you can model a realistic product where cheap features run on a small model and a few premium features run on a frontier model.
Illustrative feature breakdown example
To illustrate how spend typically concentrates, consider a hypothetical SaaS product with five AI features. The numbers below are illustrative — real figures depend on pricing and volume — but the pattern is representative:
| Feature | Daily calls | Avg tokens (in+out) | Model tier | Monthly share |
|---|---|---|---|---|
| Document summarization | 200 | 4,000 + 800 | Frontier | ~58% |
| Smart search | 2,000 | 500 + 100 | Mid-tier | ~18% |
| Classification | 5,000 | 200 + 20 | Small model | ~7% |
| Suggestion autocomplete | 8,000 | 100 + 30 | Small model | ~8% |
| Report generation | 30 | 6,000 + 2,000 | Frontier | ~9% |
Document summarization dominates despite fewer daily calls because each call uses a large frontier model with a long context. The first optimization pass should focus there: a 30% token reduction in that one feature would save more than eliminating the bottom three features entirely.
Common optimization paths by feature type
High-volume, simple classification: These are almost always using a model that is more powerful than needed. Even a significant quality drop may be acceptable for binary or small-category outputs. Benchmark a smaller model before assuming quality requires the frontier.
Low-volume, long-context analysis: These often dominate spend despite low call counts. The levers are: chunking documents to avoid maximum-context calls, caching summaries of recurring documents, and tiered model selection (use a cheaper model for document pre-processing and a frontier model only for final synthesis).
Chat and suggestion features: These typically benefit most from aggressive max_tokens capping and prompt compression. Users rarely read more than a few hundred tokens in a chat reply.
Tips and notes
The breakdown almost always follows a power law — one or two features dominate. Attack the largest share first; a 20% cut on the top feature beats eliminating three small ones. The reliable levers, in order: route to a cheaper model where quality holds, trim the prompt (drop unused few-shot examples and verbose system text), cache repeated or near-identical calls, and batch where latency allows. After each change, re-run the dashboard to verify spend actually fell — assumptions about token counts are frequently wrong until you measure. Pair this with the LLM API cost calculator to model a single feature in more depth before rolling a change out.