A single model release can eat your roadmap or pull it forward by years. Design, product, engineering don’t look the same as they did 3 months ago, let alone a year ago.
Your pricing model shouldn’t either.
What models will cost in 18 months. The price of an outcome. Which provider wins. All open questions.
In a market this fluid, optionality beats prediction.
Every month you spend picking “the right” pricing model or “the right” model provider is a month you’re not shipping.
The companies that will look smart in 2027 aren’t the ones who guessed right in 2026. They’re the ones whose architecture let them change their mind cheaply.
Two dimensions matter most right now: what you charge for, and who you depend on.
When people say “pricing model” they usually mean a stable thing: per-seat, per-user, per-transaction. Those shapes didn’t move much in SaaS. You picked one and held it for years.
The unit of value in AI keeps moving. Per-token was useful when models were expensive and tokens mapped to cost. Per-seat is coming back for co-pilot patterns. Per-agent is new. Per-outcome is what everyone wants, but “outcome” isn’t a stable primitive yet: what counts as completion, how you attribute success across a multi-step chain, how you handle partial or disputed results. The harness is still fluid. That’s another fog inside the fog.
The question isn’t “which pricing model is right?” It’s “when the right one changes, or the thing you’re measuring changes, how fast can you ship it?”
The easy change is the rate. The hard change is what you’re charging for. Per API call. Per successful answer. Per business outcome. Each one means counting something different. Your product has to record it. Your billing has to add it up.
In most stacks, changing what you charge for means engineering goes back to the source, adds new tracking, rebuilds the counter. A pricing change that should have taken a week becomes a quarter of work.
That’s the rate trap.
At Lago, events come in raw. The billable metric (that price is built on) is defined on top, at rating time. Change the metric, re-rate history, ship a new model without touching your pipeline. The events don’t care.
Rate trap: Product ──▶ Events carry only what pricing needs today ──▶ Billing
Decoupled (Lago): Product ──▶ Raw events (everything kept) ──▶ Pricing ──▶ Billing
The scenario that matters right now?
Your upstream model provider (e.g., OpenAI) cuts prices by 50%, or decides to price on a new dimension. It happens every few months. Overnight your margin structure is wrong. In most billing stacks, figuring out what to charge customers under the new cost is a migration project. In a decoupled one, you re-rate the last weeks against a new pricing model on Tuesday and decide by Friday whether to pass the savings through, hold margin, or split the difference.
That’s optionality in practice. Not “we can change the tier.” We can change what we’re pricing on.
If I want to split a metric mid-period, does it require a new event stream, or does it re-slice events already in the system? One question separates the two camps in any billing stack you evaluate.
The tradeoff is real. Raw-event ingestion is more complex than a tightly-coupled pipeline. In a stable market, tight coupling wins. In a foggy one, decoupling wins. We’re in a foggy one.
You don’t want to be married to OpenAI, or Anthropic, or even to your payment processor or billing vendor.
Every lock-in looks fine at commit time. It stops looking fine when the fog lifts and the thing you committed to isn’t where the value went. Hard-coding to one model provider was defensible when one lab was clearly ahead. In 2026, when different providers win different workflows and open-weight catches up on a subset, that commitment is a migration project blocking other work for two quarters.
The pattern cascades. Model-provider lock-in turns their pricing changes into your pricing problem. Commit to a single payment processor and you can’t route around regional weakness or regulatory shifts. A rigid billing vendor bakes their data model into every customer conversation you’ll have.
We built Lago to be open-source. Events come in raw, so whatever you’re running upstream stays yours to swap. The payment processor is your choice, and all the connected tools as well. Pricing shape is never hardcoded.
The further downstream, the more expensive to unwind.
You can’t predict the pricing model you’ll need in 18 months. You can only decide whether your architecture will let you switch when the fog lifts.
The companies that stayed flexible through the last fog are the ones running the current one comfortably. The ones who hard-coded their foundation to a single provider spent years unwinding it.
The current fog is thicker. The move is the same.
The details, for anyone who wants them. The filters doc shows how the decoupling works in practice. The rate trap wiki is the architectural argument in full.
No posts
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.