Abhilash John The Rationalization Engine: The Missing Layer Between AI COGS and SaaS Pricing
Why the existing stack of revenue and cost systems isn't enough, and why AI SaaS companies need a rationalization engine to bridge the gap.
AI Summary
Here’s the problem that most AI SaaS companies are quietly carrying into 2026.
You sell a product. You charge customers in some customer-friendly unit: credits, resolved tickets, drafted contracts, hours of transcription, generated images. Underneath each of those units, your product fans out into a cocktail of downstream costs: one or more LLM API calls across different models, cached versus uncached tokens, vector database queries, embedding generations, third-party tool calls, orchestration overhead, and your own compute and storage. Each of those downstream costs has its own price, its own unit, its own provider, and its own rate of change.
The question is: who, in your system, is responsible for reconciling those two worlds? Who takes the stream of downstream costs and turns it into a conversion rate that says “an Opus-powered contract draft should cost 12 credits, not 8” or “we can afford to charge $1.25 per resolved ticket, but not $0.99”?
For most AI SaaS companies in 2026, the answer is: a finance analyst, a spreadsheet, and a quarterly pricing review. That worked when you were figuring out whether subscriptions should cost $9 or $19 a month. It does not work when your unit economics move weekly, your customer mix is concentrated in a long tail of power users, and your model provider just deprecated the SKU you’d built a whole feature around.
What’s missing is a system. Not a dashboard, not a report, not a finance calculation a rationalization engine that lives in the billing stack and continuously converts observed COGS into customer-facing conversion rates, feeds those rates to the revenue system, and flags when reality has drifted too far from assumption. This post is about what that engine has to do, why existing billing platforms don’t quite do it yet, and why the first ones that do are going to own the next wave of the billing infrastructure market.
Why the Existing Stack Doesn’t Quite Do This
Modern billing has two stacks, and they don’t talk to each other well enough.
On one side are the usage-based billing platforms Orb, Metronome, Lago, Chargebee, and a half-dozen newer entrants. These are fundamentally revenue systems. They ingest product events, apply pricing logic, track entitlements, and produce invoices. Their core job is turning “what happened” into “what the customer owes.” They’ve gotten very good at high-volume metering, tiered rating, and multi-dimensional pricing. Credit burndown and outcome-based pricing support are standard features now.
On the other side are the cloud cost management tools CloudZero, Vantage, Kubecost, and similar platforms. These are cost systems. They ingest infrastructure bills, tag costs to teams and features, track per-request cost where possible, and help finance and engineering teams understand where the money is going. CloudZero has been explicit about this: they argue that “if you track only one API metric in 2026, it should be cost per API call” because a new feature can materially change your COGS without changing the request count at all. Adjacent to this layer are AI-aware FP&A platforms like Drivetrain that consolidate billing, usage, and financial data to help finance teams track unit economics and COGS across hundreds of upstream systems. These two categories overlap but aren’t identical: cost management tools live closer to the infrastructure, FP&A tools live closer to the general ledger.
Both of these stacks are good at what they do. The problem is the gap between them.
Revenue systems don’t, by default, ingest COGS data at the same fidelity as the usage events they bill on. Cost systems don’t know which customer or which product action a particular underlying cost belongs to. When you want to know “what’s the margin on a single resolved ticket for this specific customer segment,” you’re pulling data from two stacks, joining it in a spreadsheet, and producing a number that’s already stale by the time the PDF goes out.
This is starting to change. Metronome, notably, markets the ability to “correlate revenue with COGS for margin analysis” as a feature for infrastructure companies, and the Metronome team has written publicly about why cost-plus credit models “work until they don’t” which is an argument that implicitly acknowledges the rationalization problem. They’re the closest thing to a billing platform that’s trying to host the whole loop. But even there, the framing is “margin analysis as a reporting layer” rather than “conversion rate calculation as a first-class output of the billing system.”
The gap is real, and it’s where I think the rationalization engine belongs.
What the Rationalization Engine Actually Does
Strip away the naming and the engine does six things. Each of them is doable in isolation today; the value is in doing them all together in the same loop.
1. COGS ingestion across all downstream providers. Every cost that could possibly be attributed to a customer action has to flow into the engine. LLM API bills from OpenAI, Anthropic, Google, your self-hosted inference clusters, your vector DB, your embedding provider, your tool-use integrations, your own compute and storage. Each provider has its own billing format, its own latency for cost visibility (OpenAI’s usage data lags by minutes; AWS by hours), and its own unit (tokens, queries, GB-seconds, calls). The ingestion layer normalizes all of these into a common schema: event ID, timestamp, provider, quantity, unit, and a normalized USD cost based on the provider’s current rate card.
2. Attribution to parent customer actions. This is the hardest engineering problem in the whole stack, and the one most people underestimate. When a customer asks your product to “draft a contract based on these inputs,” your orchestrator might make four LLM calls across two models, three vector DB lookups, two embedding calls, and a web search tool call. Each of those is a separate cost event from a separate provider, and they arrive at the rationalization engine asynchronously, in no particular order, over a window of seconds to minutes. The engine has to stitch them all back together and attribute the total cost to the single parent action “draft contract event #12345 for customer X” so that it can compute the cost per outcome. This is a distributed tracing problem wearing a billing disguise. If you don’t already propagate trace context through your orchestration layer, you cannot do this cleanly. You’ll end up with a pile of costs you can’t attribute and a pile of outcomes whose true cost you can only estimate.
3. Provider price book with temporal versioning. The engine needs its own internal representation of what every downstream provider charges, and crucially, what they charged at any specific point in the past. Because AI provider prices change constantly new models, structural repricing, cache tier changes, negotiated enterprise discounts, commitments drawing down a cost event from two weeks ago has to be rated against the price that was in effect two weeks ago, not today’s price. This is the same “time-versioned price book” problem I’ve written about before, but on the COGS side rather than the revenue side. Both sides need it, and the engine needs to keep them in sync.
4. Conversion rate calculation. This is the core output. Given a stream of attributed cost events aggregated by action type, customer segment, or outcome, the engine computes the average (and distribution) of COGS per unit of customer-facing value. Then it applies a configurable margin target which is a strategic input, not a mechanical one to produce a target conversion rate. For a credit-based product, the output is something like “a contract draft costs 12 credits” or “a short-context summary costs 1 credit.” For an outcome-priced product, the output is a target list price: “a resolved support ticket should be priced at $1.45 to hit our 60% gross margin target.” The rate is the engine’s deliverable. It doesn’t get directly charged to the customer; it gets handed to the revenue system, which then applies customer-specific contracts, discounts, commitments, and entitlements on top.
5. Drift detection and alerting. Conversion rates go stale. Model prices change. Cache hit rates shift as customer prompts evolve. A new feature changes the ratio of input to output tokens. A major customer’s usage pattern skews toward expensive long-context requests. Any of these can turn a previously-profitable conversion rate into a money-loser without anyone noticing until the quarter closes. The rationalization engine has to watch the delta between the currently-published conversion rate and the current observed COGS, and fire alerts when drift crosses a threshold. This is the “operational control loop” version of margin management, and it’s what turns pricing from a quarterly finance exercise into a continuous capability.
6. Simulation and what-if analysis. Before you change a rate, you need to know what the change would do. If I raise the credit cost of a particular action from 8 to 10, which customers hit their credit ceiling earlier, and by how much? If I drop the outcome price of a resolved ticket from $1.99 to $0.99, how much additional usage do I need to make it up in volume, and how does that interact with my capacity plan? The simulation layer runs proposed rate changes against historical event streams and projects the impact. Without this, every repricing is a leap of faith.
Those are the six jobs. Together, they form a loop: ingest costs, attribute them, price them against the right historical rate, calculate conversion rates, detect drift, and simulate changes before committing them. A fully-built rationalization engine runs this loop continuously, with new rates published on whatever cadence the business decides daily, weekly, event-triggered.
Credits and Outcomes: Same Engine, Different Output
One of the more useful insights that comes out of framing this as a rationalization engine is that credits and outcome-based pricing are not different architectural problems. They’re the same problem with different consumption patterns on the output side.
In a credit-based pricing model, the engine’s output (the conversion rate) becomes the drawdown rate: how many credits does action X cost today? Because credits are an abstraction layer between the customer’s dollar purchase and the vendor’s metering, the drawdown rate can change dynamically without touching the customer’s contract. The customer bought 10,000 credits for $500; the vendor controls how many credits each action consumes, and can adjust as costs shift. This is precisely why credit models are so popular with AI vendors right now Microsoft Copilot’s structure, for example, charges 10 Copilot Credits for tenant-graph grounding plus 2 credits for generation, totaling 12 credits for a single complex prompt, with the vendor retaining the right to change those numbers as the underlying infrastructure costs evolve. The flexibility is the whole point.
In an outcome-based pricing model, the same rationalization output becomes a contract negotiation input: what’s the floor price at which a resolved ticket remains profitable? Here, the rate is typically locked into the contract at deal time, which means the margin discipline has to happen before the ink dries. If COGS drifts after contract signing, the vendor eats the difference until the renewal. Metronome has written about this as the failure mode of “cost-plus credit models that work until they don’t” the moment when observed costs exceed the assumptions baked into the contract, and the vendor has no mechanism to claw back.
The critical point is that both models depend on the same underlying calculation. The difference is only in how the output is used: credits give you a live knob; outcomes give you a number you have to get right before you commit. A good rationalization engine supports both simultaneously, because most mature AI SaaS companies end up with hybrid contracts a base subscription, a credit pool for variable use, and outcome-priced components for specific high-value actions.
The Usage Event Question: Who Should Do the Math?
Here’s the concrete architectural decision every AI SaaS company has to make, and most make it badly.
An LLM provider has already done one level of rationalization for you: they’ve collapsed the mess of GPU cycles, memory bandwidth, and inference compute into tokens. That’s the output-facing unit they hand you. Now you have to decide: do you pass that event to your billing system and ask the billing system to apply the conversion rate? Or do you do the conversion yourself calculating the credit deduction or outcome value in your own application layer and send only the final number to the billing system?
Let’s call them what they are.
Option A: Raw events, rating in the platform. You emit token-level events (input tokens, output tokens, cache reads, tool calls) to your ingestion layer with a trace ID tying them to the parent customer action. The rating system applies your configured conversion rate and produces the credit deduction or billable amount. The platform holds the pricing logic.
Option B: Calculated value metrics, dumb ingestion. Your application layer receives the token counts, applies the conversion rate to calculate “this action costs 12 credits,” and sends that single deduction to the ingestion layer. The billing system is a ledger. The pricing logic lives in your code.
Option B feels simpler because it is simpler until it isn’t. The problem isn’t day one. The problem is month seven, when you need to:
Reprice. You want to change the credit cost of a specific action. With Option A, you update a rate in the billing platform, and you can retroactively rerate historical events to understand the revenue impact of the change. With Option B, you push a code change, and you’ve permanently destroyed your ability to rerate historical events. Any simulation of “what would have happened under the new pricing” now requires reconstructing what the raw events were if you even logged them.
Detect drift. The rationalization engine described in this article detects margin drift by watching the gap between your published conversion rate and the actual observed COGS per action. That gap can only be measured if the engine can see both the raw token events (actual cost) and the conversion rate you applied (expected charge). If you collapsed the math client-side before the events arrived, the engine only sees the output it can’t reconstruct whether that output was still margin-positive given today’s model prices.
Price outcomes. This is the one that makes Option B structurally impossible for outcome-based models. When a customer requests a support ticket resolution, you don’t know at event time whether the resolution will succeed. The billing decision happens post-hoc, after the user has indicated the ticket is closed or the LLM has triggered a completion signal. You cannot pre-calculate a value metric for an event whose value hasn’t been determined yet. Option A handles this naturally: the raw action events accumulate, the outcome determination arrives as a separate event, and the rating system closes the loop and produces the billable amount.
Run pricing experiments. If you want to A/B test credit costs across customer segments, or simulate how a volume discount tier would affect net revenue, you need raw events to replay against alternative pricing configurations. Option B has already collapsed the information you’d need.
Stripe’s “Billing for LLM tokens” feature currently in private preview as of March 2026 is a concrete bet on Option A. Stripe syncs token prices for OpenAI, Anthropic, and Google models, lets you configure a markup percentage in the dashboard, and handles the conversion automatically when token events arrive through their AI gateway or supported partner gateways (Vercel, OpenRouter, or self-reported). You set the markup; Stripe does the math. The pricing intelligence is in the platform. And their $1 billion acquisition of Metronome completed January 2026 is the scaling move for exactly this architecture: they needed Metronome’s high-volume metering and usage-based rating infrastructure to support the kind of granular, per-token, multi-model event streams that make Option A work at AI scale.
The market is signaling the answer.
There’s one important nuance: “raw events” doesn’t mean every internal operation your orchestration layer makes. Your LLM provider has already done the rationalization from GPU cycles to tokens; you don’t need to go below that. What you do need is to preserve the natural event boundaries the token counts by type (input, output, cache read, cache write), the model identifier, the trace context, the timestamp, and the parent action ID without collapsing them into a pre-applied conversion result. That’s the appropriate granularity for the rating system to work with. Everything else is implementation detail.
The practical recommendation: treat the rating system as the place where your pricing intelligence lives, and treat your application as the system that emits faithful usage observations. The boundary should be at the level of what your provider invoices you for. Anything you collapse before that point is information you’re voluntarily giving up.
The Hard Parts People Underestimate
Four things about building this are harder than they look.
The fat-tail problem. Token consumption in AI SaaS is consistently heavy-tailed: a small share of users drives a large share of cost, and two customers on the same plan routinely generate dramatically different costs-to-serve. I’m not going to put a specific percentage on it because the exact shape varies wildly by product, but every AI billing team I’ve compared notes with has told me some version of “our top few percent of customers are a different business from the rest.” This matters enormously for the rationalization engine, because it means the average COGS per action is almost useless. You can be profitable on average and deeply unprofitable on your top-decile customers, and an average-based conversion rate will mask the problem until quarter-end. The engine needs to compute conversion rates at the segment level (and ideally per-customer for the biggest accounts), and flag when the distribution is dangerously skewed. A single conversion rate for a heterogeneous customer base is a statistical lie.
Defining “successful” for outcome pricing. If you charge per resolved ticket, what counts as resolved? If the customer reopens the ticket two days later, did the resolution fail? If the LLM drafted a contract but the user edited 40% of it, was it a successful draft? These definitional questions are hard because they live at the intersection of product, finance, and legal, and the rationalization engine needs a clear programmatic answer to know what to attribute costs against. In practice, most teams punt on this for the first year and pay for it later.
Strategic margin targets. The conversion rate is COGS times some margin multiplier, but the margin multiplier is a strategic choice, not a mechanical one. Are you buying growth and willing to run negative margin on the top of the funnel? Are you defending a gross margin floor because the board wants the numbers to look SaaS-like? Are you cross-subsidizing a flagship feature by over-pricing a commodity one? The engine doesn’t make these decisions, but it has to expose the right knobs so that the humans who do make them can set policy in a single place rather than scattering it across spreadsheets. In my opinion, the best rationalization engines will treat margin policy as a versioned, auditable configuration not a one-off parameter.
Price book churn from upstream providers. Model vendors change constantly. New models ship monthly. Older models get repriced (usually down, sometimes with structural changes). Cache tiers get introduced, batch discounts get restructured, volume commits get renegotiated. The provider price book inside the rationalization engine has to stay fresh, because a stale price book produces stale conversion rates, which produce invisibly-eroding margin. There’s no clean way to automate this model pricing is not exposed through a standard machine-readable API across providers so most teams will have to build scrapers, watchers, or manual update workflows and treat the freshness of the upstream price book as a monitored service level.
Why This Is a New Layer, Not a Feature
I want to close by pushing back on the obvious objection: “isn’t this just a reporting feature on top of existing billing?”
I don’t think so, and the reason is that the rationalization engine produces a write operation, not a read. A reporting dashboard tells you your margin was 47% last quarter. The rationalization engine says: “effective immediately, a contract draft costs 13 credits instead of 12, pushed to the revenue system at 09:00.” It’s in the critical path of what the customer gets charged. That makes it operational infrastructure, not analytical infrastructure, and the engineering requirements are very different durability, auditability, rollback, approval workflows, rate-of-change limits, kill switches.
It also sits in an awkward place organizationally. The revenue system is owned by billing engineering and finance. The cost system is owned by platform engineering and FinOps. The rationalization engine has to cross both boundaries, which is part of why it doesn’t exist as a clean category yet nobody wants to own the thing that sits between two already-complicated stacks. But someone has to, because the alternative is what most AI SaaS companies are doing today: running their unit economics on trust, hope, and quarterly spreadsheet rebuilds, and discovering margin erosion only after it’s already a board-level problem.
The market isn’t waiting for the 18–24 month thesis to play out. Stripe’s $1 billion acquisition of Metronome in January 2026 is the clearest signal available: a payment infrastructure company paying nine figures for a usage-based billing platform specifically to support “multidimensional metering for the complex product catalogs of AI infrastructure companies.” Patrick Collison’s framing at announcement was direct “metered pricing is the native business model for the AI era.” They’re not just adding features. They’re assembling the stack that makes Option A work at scale: high-volume metering (Metronome) plus model price tracking plus markup configuration plus gateway event ingestion (Stripe), all in the same infrastructure. What I described as the rationalization engine is what they’re building in practice.
The remaining question is which end of the market gets there from the other direction. There’s a version of this where cost management platforms with strong COGS-attribution capability (CloudZero-shaped companies) absorb billing capability and meet Stripe/Metronome in the middle. The converged stack will have the rationalization layer at its center regardless of which direction the acquisitions flow. The name might be different. The architecture will be the same.
The companies that figure this out first won’t just have better margins. They’ll be the ones that can actually reprice confidently, experiment with new pricing structures safely, and negotiate outcome contracts without wincing. In a market where AI gross margins are being squeezed from above and below, that’s not a nice-to-have. It’s the operational capability that decides who’s still in business in 2028.