How is each feature's cost computed?

For one call, cost = (input tokens × input rate) + (output tokens × output rate), divided by a million. That is multiplied by the feature's daily call volume and by thirty days to get a monthly figure, using the model assigned to that feature.

Why attribute cost per feature instead of total?

A single total spend number hides where the money goes. Per-feature attribution usually reveals that one or two features dominate the bill, so you can focus optimization — cheaper model, prompt trimming, caching — exactly where it moves the needle.

Why can features use different models?

Real products route by need: a high-volume search feature might use a cheap small model while a low-volume summarization feature uses a frontier model. Mixing models per feature is the most common cost-control pattern, so the tool supports it directly.

How do I act on the breakdown?

Target the largest share first. The usual levers are downgrading to a cheaper model where quality allows, trimming prompts and few-shot examples, caching repeated calls, and batching. Re-run the dashboard after each change to confirm the spend actually dropped.

Is my data sent anywhere?

No. The dashboard runs entirely in your browser. Nothing you enter is uploaded, stored or logged.

Cost-to-Serve per Product Feature Dashboard

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.

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.