Do You Actually Know Where Your AI Spend Goes?
Most teams using AI APIs know their monthly bill. Almost none of them know which features are driving it.
That gap matters more than it sounds. Your bill is a number. Your feature-level breakdown is a map. The number tells you how much you are spending. The map tells you whether you are getting what you are paying for — which features are cost-efficient, which ones are burning money on calls that return low value, and where you need to rethink the implementation before the spend scales.
If you are running AI in production without feature-level attribution, you are flying on the total. Every feature team thinks it is not their problem. Nobody owns the number.
The instrumentation pattern
The core idea is simple: every AI call gets tagged at the call site with a feature label before it is dispatched. Not retroactively, not inferred from logs — tagged at the source.
What you tag: the feature name, the model, the calling context. What you get: a record with those tags attached to the actual token counts from the API response. What you do with it: aggregate by feature over time, build a cost-per-call and cost-per-feature view, set thresholds, watch trends.
The implementation is a thin wrapper around your AI client. You instrument once, and every call through the wrapper is automatically tracked. The wrapper writes to a Postgres table. The table is queryable. You get dashboards.
Regex first, LLM fallback
The most impactful cost reduction I have found is not switching models or compressing prompts. It is eliminating LLM calls for work the LLM does not need to do.
For classification and routing tasks, a significant portion of real-world inputs are predictable enough to handle with a fast regex match. You try the rule first. If it matches with sufficient confidence, you never make the API call. If it does not match, you fall back to the LLM for the genuinely ambiguous cases.
When I measured this pattern against production traffic on a support message classification feature, the rule-based path handled roughly 73% of messages correctly. LLM calls dropped by that proportion on that feature alone. The 27% that needed the LLM were the cases where having a language model actually matters. That is the right division of labor.
The pattern generalizes anywhere you have classification, extraction, or validation tasks where the input space is partially predictable.
Why this is a business argument, not just a technical one
Feature-level cost tracking changes the conversation about AI spend at the product level. When you can show that a specific feature costs $0.04 per user invocation and converts at 12%, you have a business case. When you can show that another feature costs $0.31 per invocation, runs hundreds of times a day, and nobody has measured whether it drives any outcome at all, you have a different conversation.
Without attribution, AI costs are treated as infrastructure overhead — something to minimize in aggregate. With attribution, they become product decisions. You can optimize, justify, cut, or double down based on actual signal.
I do not have patience for spend that does not connect to value. Feature-level tracking is how you enforce that discipline at the system level, not just in your head.
Build From These
The artifacts from this article. Grab them, run them, adapt them.
AI Spend Tracker Starter Kit
The instrumentation wrapper, Postgres schema, SQL dashboard query, and regex-first pattern template. Adapt to your AI client of choice, point at your database, drop in your feature labels, and you will have feature-level visibility within a sprint.