Skip to main content
An aggregate provider invoice tells you how much you spent, but it rarely explains which product behavior caused the spending. In this step, turn usage records into a baseline that the owner from Step 1 can act on. Start with the feature you intend to optimize and expand coverage as you learn where costs are missing.

​
The aggregation problem

A higher bill can result from more customers, longer conversations, additional model calls, or higher prices. Those causes require different responses. Reducing a model’s rate does not explain why a deployment suddenly doubled the number of retries, and a growing total can be acceptable when successful outcomes grow faster. Track volume and unit cost separately. In an illustrative support workflow, 1,000for100,000successfullyroutedemailsis1,000 for 100,000 successfully routed emails is 0.01 per outcome. If spending rises to 1,500whilesuccessfulroutingrisesto200,000emails,unitcostfallsto1,500 while successful routing rises to 200,000 emails, unit cost falls to 0.0075. The total increased, but the service became less expensive per success. Compare both measures with the objective you agreed upon.

​
Break down the spending

Capture the model/provider pair, reported token usage, calculated cost, timestamp, and a request identifier. Attach the app, feature, environment, and owner. Use Customer Tagging to connect usage to a stable tenant or user ID when you need customer-level economics. Keep sensitive prompt content out of cost records unless your evaluation requires it and your data handling permits it. The following is an illustrative attribution record, not an API request schema. Its purpose is to make the reporting dimensions explicit.
A workflow identifier connects several generations to one outcome. Include retries, fallbacks, and tool-driven follow-up calls in that group. Otherwise, a configuration that fails repeatedly can look cheap when you inspect only its last successful generation. Keep failed and canceled calls in the cost population when they consumed billable resources.

​
How to track spending at the source

Application middleware is useful when several customers share one provider account. The Narev SDK can capture generation usage and send billing events to a configured destination. Add tags at the point where the authenticated customer and feature are known. Infrastructure resource tags alone cannot distinguish tenants sharing the same model endpoint. Separate provider keys or projects can help divide spending between applications where the provider exposes that breakdown. They still need a mapping to your ownership records, and they do not automatically provide feature-level or customer-level attribution. Use tracing when you need to understand how several calls contribute to one task. If Langfuse already has usage but lacks costs, the backfill guide explains how to reconstruct estimates and preserve existing observation IDs. Keep the source usage and the rates used to price it. The Narev Cloud cost endpoint gives a catalog-based estimate at lookup time. That differs from an invoice when historical rates, negotiated discounts, credits, or additional charges apply. Treat those differences as reconciliation items rather than adjusting token counts to make totals match.

​
Reconcile the baseline

Choose a closed time window and compare your recorded usage with the provider’s usage report for the same account, environment, and timezone. Investigate missing applications, incomplete streams, duplicate events, and retries before trusting a cost-per-outcome metric. Record unattributed spending as an explicit category so it stays visible while coverage improves. For a broader product margin calculation, include infrastructure COGS such as retrieval storage and compute. Narev Self-Hosted provides an infrastructure cost path, including the FOCUS format. Keep that cost boundary distinct from inference-only measurements and avoid counting the same provider charge twice across imported and application-level data.

​
Identify the owners

Group the reconciled baseline by feature and assign a person who can approve changes. Compare total spend, cost per successful outcome, error rate, and traffic volume. The largest feature may deserve attention, but a smaller feature with repeated failures or a clear low-effort fix can be a better first experiment. Share the breakdown and unresolved gaps with the decision-maker. You are ready for Step 3 when you can reproduce the baseline for the selected feature, explain its cost boundary, and identify who will review the candidate’s result. Perfect coverage across the entire organization is not required to run a well-bounded experiment.