How do I log AI cost per feature?
Record every model call with feature, agent, user, model, tokens in and out, and cost, then roll it up daily. Without per-feature cost, you cannot cap spend, price a plan, or cut a feature that isn't earning its keep.
The short answer
- Log every model call at the application layer, not only at the provider's billing dashboard. Six fields: which feature triggered it, which agent (if any), which user, which model, tokens in and out, and the resulting cost.
- A provider's dashboard shows cost per API key, which is not the same as cost per feature. If several features share a key, only logging inside your own application can tell you which feature is driving the spend.
- Roll the logged calls up daily, so a cost trend or a spike is visible quickly rather than discovered a month later when the bill arrives.
- Without this breakdown, you cannot make the decisions that depend on it. Setting a sensible spend cap. Pricing a plan that includes AI usage. Deciding a feature costs more than it delivers and should be cut or reworked.
Why the provider's dashboard is not the same as your own log
A model provider's billing dashboard is built to answer one question: how much did this API key spend? That is useful for a total. It cannot answer the questions that matter for running a product. Which feature is expensive? Which agent is driving usage? Is a specific user's activity unusually costly? If several features in your product share the same provider key, which is common, the provider's dashboard has no way to separate their spend.
The only way to get that breakdown is to log it yourself, at the point where your application makes the call, before the request goes to the provider. That log is what turns "we spent $400 on AI last month" into "drafting cost $250, summarization cost $100, and scoring cost $50". That is the level of detail that supports a decision.
What to log, and why
| Field | Why |
|---|---|
| Feature | Lets you answer 'what is this costing us' per feature, not only in total |
| Agent (if applicable) | Separates cost driven by automated agents from cost driven by direct user requests |
| User | Surfaces unusually heavy individual usage, useful for both cost and abuse investigation |
| Model | Shows whether a feature is using an appropriately priced model tier for its task |
| Tokens in and out | The raw units cost is computed from; needed to explain a cost change after a model price update |
| Cost | The bottom line, computed at logging time so it does not need to be recalculated later |
Turning the log into an actual decision
A log that only accumulates rows is half the job. The daily rollup is where the data becomes usable. A simple report showing cost by feature and by agent for the day, trended over the past month, is enough to spot a feature whose cost jumped, or an agent whose usage grew faster than the value it produces. That report is also the input to a spend cap that means something. A cap without this breakdown can only say "stop", never "stop this specific thing".
Disclosure: SalesCrew is our product. Its `ai-complete` gateway logs every model call to an `ai_runs` table with the feature, the agent, the user, the model, tokens and cost, rolled up for the usage and billing view. This is the same data the platform's spend caps and cost tracking are built on. It is what makes a per-feature answer possible rather than a guess.
Provider dashboards show cost per key, not per feature
Questions
- Why isn't a provider's billing dashboard enough on its own?
- A model provider's dashboard shows cost per API key. That tells you how much you spent in total, but not which feature or agent inside your product generated that spend. If several features share one key, the dashboard cannot separate them. Only application-level logging can.
- What is the minimum set of fields worth logging?
- Feature, agent (if applicable), the user who triggered it, the model used, tokens in and out, and the resulting cost. Fewer fields than this leaves gaps that make later questions, like 'why did this feature get expensive', unanswerable without guessing.
- How often should the rollup happen?
- Daily is a reasonable default for most teams. Frequent enough to catch a cost spike quickly, infrequent enough not to be noisy. A team running near a spend cap might want it more often. A team with light, steady usage might check weekly instead.