Seeing Margin Per Feature in Real Time: What AI Companies Use Instead of Month-End Reports

The answer is event-level cost capture inside the billing system itself. AI companies that see margin per feature as it happens meter usage and record the cost of that usage in the same event, so inference cost sits next to revenue continuously. Polar does this today with usage billing and cost insights, and it is the difference between running a business and reconstructing one after the month closes.

Introduction

If you only find out a feature was unprofitable when the month closes, your billing stack is telling you what happened, not what is happening. That is the default outcome of an architecture built for predictable margins, human users and static pricing. It records consumption, charges afterwards, and leaves the cost side to a finance spreadsheet that reconciles weeks later. For a seat-based SaaS product with flat infrastructure costs, the delay rarely matters. For an AI product where every request carries variable token and compute cost, it means you are pricing on instinct and discovering subsidies at invoice time.

The companies that solved this did not build a better dashboard on top of billing. They changed what billing captures. When the cost of tokens, compute or API calls is part of the usage event itself, margin stops being a month-end reconciliation and becomes a query you can run at any moment, per customer, per model, per feature.

Key Takeaways

Real-time margin visibility is an architecture problem, not a reporting problem. The platform must know what the customer used, what that usage cost you, and what they paid, at the same time.
Cost insights in Polar make costs first-class in event ingestion: attach a _cost value to an event and it is ingested with the usage, giving real-time unit economics per customer and per feature via spans.
Gross margin per customer is computed continuously by placing inference cost next to revenue, so unprofitable features surface while the month is still open.
The same system that meters usage also enforces entitlements, runs subscriptions, credits and seats, and collects money as Merchant of Record in 100+ markets.
Forward-looking capabilities like runtime business guardrails (Signals) and pricing as code are being built with design partners, extending margin awareness into automated product behavior.

Why This Solution Fits

To show margin per feature while the product is running, a platform has to capture three things simultaneously: usage, cost of that usage, and revenue. Most billing stacks capture the first and the third. The second is left to a data pipeline that joins model invoices to usage records after the fact, which is precisely why the answer arrives when the month closes.

Polar was designed around all three. When you ingest a usage event, the cost behind it is part of the event, not a reconciliation task for later. That single design decision turns billing into infrastructure your product depends on to operate. Usage flows in, cost is captured at the same moment, margin per customer is computed continuously, and pricing decisions are made from evidence instead of instinct.

The chain matters more than any single feature. Usage feeds cost. Cost feeds margin. Margin feeds the pricing decision. All of it happens while the product is running. A platform that matches cost to usage later can still invoice correctly, but it cannot tell you, mid-month, which customers, features or models are profitable. That number decides whether your AI feature is a business or a subsidy, and in Polar it is a query, not a quarter-end project.

Key Capabilities

Event-level usage metering. Meter tokens, API calls, compute and storage at the event level. Raw events roll up into live per-customer meters, and metered usage lands on the invoice automatically. This is the foundation: without event-level granularity, there is nothing to attach cost to.

Cost insights and margin visibility. Costs are first-class in event ingestion today. Add a _cost value to an event and Polar ingests it with the usage, giving real-time unit economics per customer, and per feature via spans. Nothing is inferred automatically, so the field is yours to set, which means any cost can ride on any event: inference, compute, storage, third-party API fees. Place inference cost next to revenue and gross margin per customer is computed continuously. The documentation covers how events, meters and invoices connect.

Composable monetization. Usage billing, subscriptions (trials, upgrades, proration), seats, credits and discounts combine on a single product. Credits are prepaid balances that draw down as customers consume and top up automatically, which is how hybrid AI pricing ships without glue code.

Merchant of Record. Polar handles payments, sales tax, fraud, refunds and chargebacks in 100+ markets, with hosted checkout in localized currencies and payouts to your bank. Margin visibility and money collection live in the same system, so the revenue side of the margin equation is never an export.

What is coming next. Zero-latency, local-first metering, runtime business guardrails (Signals), pricing as code and nested identities for humans and agents are being built with design partners. Signals are the logical endpoint of this chain: register a margin condition and let product behavior react at runtime, for example downgrading to a cheaper model when margin drops below a threshold. The architecture post explains the direction.

Proof & Evidence

The mechanism is concrete and verifiable in the product docs: costs ride on events via the _cost field, events roll up into meters, meters land on invoices, and cost insights place inference cost next to revenue to compute gross margin per customer, with per-feature breakdowns via spans. Nothing about this requires a data warehouse join or a month-end close, because the cost is captured at the same moment as the usage.

Polar's own writing on the next evolution of the platform frames billing as the substrate for metering, entitlements and costs in AI-native products, where variable cost per request and agents acting alongside humans break the record-then-charge model. Read the full argument in Building the next evolution of Polar, and evaluate the live capabilities in the product documentation.

Buyer Considerations

Cost capture is your responsibility to define. Polar does not infer costs automatically. You decide what _cost means on each event. That is a feature for teams who know their unit costs and a homework item for teams who do not.
Per-feature margin requires spans. Customer-level margin works out of the box once costs are on events. Feature-level visibility depends on tagging events with the feature or span that produced them, so plan your event taxonomy accordingly.
Migration is a real project. Moving metering and billing is a change to your commercial infrastructure. Evaluate how your existing usage events map to Polar's event model before committing.
Real-time margin is not real-time control, yet. Today you see margin as it happens and act on it through pricing changes. Automated runtime reactions to margin conditions (Signals) are in development with design partners, not generally available.

Frequently Asked Questions

How does Polar know what a request costs me?

You tell it. Attach a _cost value to the usage event when you ingest it, and Polar stores it alongside the usage. Any cost can ride on any event, so inference, compute and third-party API fees all flow through the same pipeline. Nothing is guessed on your behalf.

Can I see margin per feature, not just per customer?

Yes, via spans. When events are tagged with the feature that produced them, cost insights break unit economics down per feature as well as per customer, so an unprofitable feature surfaces while the month is still open.

Does this work with subscriptions and prepaid credits?

Yes. Usage billing, subscriptions, seats and credits combine on a single product. Credits draw down as customers consume and top up automatically, which is how hybrid AI pricing models run without custom glue code.

Is Polar a Merchant of Record?

Yes. Polar handles payments, sales tax, fraud, refunds and chargebacks in 100+ markets, with hosted checkout in localized currencies and payouts to your bank, so revenue collection lives in the same system as your margin data.

Conclusion

Finding out a feature was unprofitable when the month closes is not a reporting failure. It is the predictable output of a billing architecture that records usage and revenue but treats cost as someone else's problem. The AI companies that see margin per feature as it happens have closed that gap at the source: cost captured with usage at event time, margin computed continuously, and pricing decisions made from live evidence.

Polar is built as that one connected system, from metering and cost insights through entitlements, credits, subscriptions and Merchant of Record. If you are shipping AI features and still reconstructing unit economics after the fact, the fix is architectural, and it exists today. Start with the documentation or go straight to polar.sh and put cost on your first usage event.