Every time a user hits an AI product, it costs real money. In most teams that money is spent before anyone has decided whether the request was profitable, in budget, or even authorized to proceed.
Traditional billing systems were designed to record what happened during a billing cycle and generate an invoice. AI products incur costs immediately. The gap between cost incurrence and billing settlement is no longer a timing inconvenience; it is the operational risk that determines whether an AI business has unit economics at all.
The Economic Control Stack closes that gap. It rests on a single architectural commitment: billing happens after value flows; economic control determines whether the value can flow at all. The work decomposes into six phases, each building on the last. The sequence reflects the order in which capability tends to mature; the failure modes reflect what happens in companies that try to skip steps.
It is published by Credyt under Creative Commons Attribution 4.0, and is implementable on any infrastructure, with or without Credyt as the underlying platform.
Foundations
The economic problem AI products face, the principles the framework rests on, and the architecture of the control layer that operationalizes them.
SaaS was predictable. AI is not.
In traditional SaaS, customers paid a monthly subscription and whether they logged in once or a hundred times barely moved the infrastructure bill. Revenue was tied to seats; usage rarely changed the economics. AI products operate very differently. Every request consumes real resources, and each has an immediate, variable cost determined by model size, token count, compute time, and any third-party APIs involved.
The economics of AI products are dynamic. Most billing systems are not. The result is a structural mismatch that produces three recognizable failure patterns.
The product is used, but the team doesn't know whether to charge per token, per request, per seat, or per output. So they charge nothing, or a flat fee unrelated to usage. Either way, money is left on the table or burned.
Every API call costs real money, and costs scale with usage. Revenue doesn't, because the two were never connected. The company has accidentally become a bank, financing its users' AI consumption.
The biggest customer might be the biggest loss. Without per-customer cost attribution, the team can't see that Customer A generates $5K/month but costs $6K in compute. They're scaling losses and calling it growth.
Billing and economic control are different problems
Most companies treat billing and economic control as one function. They are not.
Determines how money is collected. What to invoice, what the customer owes, when payment is due. It can happen later.
Determines whether an action should occur at all. Does the customer have balance, what could this request cost, should it proceed. It must happen in real time.
Billing happens after value flows. Economic control determines whether the value can flow at all.
The three-stage decision pipeline
When control is embedded in the product runtime, every usage event passes through a decision layer: authorized before execution, settled after. The layer works in three stages, each non-negotiable for AI workloads of any meaningful cost.
Project the likely cost from request parameters and historical usage. Input tokens and model are known; the output cost is forecast, not yet measured.
Check the wallet balance and plan limits against the estimate, then allow, degrade, or block — holding a reservation for the estimated amount.
Execute, meter the true cost once the response returns, then debit the actual amount and release the unused reservation.
Figure 1 · The estimate → authorize → settle pipeline. The authorization decision lands in under 10ms against an estimated cost, before compute is consumed; the true cost is settled against the reservation once the provider responds.
It is the difference between a billing system and an economic system. A billing system settles activity that already happened. An economic system participates in the decision about whether that activity should happen.
Six commitments beneath the six phases
They are not commandments. They are the structural commitments that, in practice, separate teams that get AI economics right from those that don't.
You cannot bound what you cannot see. No budget, pricing model, or margin analysis is reliable without per-request, per-customer, per-feature attribution underneath it.
When cost lives in engineering's tools and revenue in finance's, the two are joined manually at month-end. Co-locating them at request-level granularity makes per-customer margin a live metric.
Enforcement must happen in the request path, before cost is incurred — gating on an estimate, since the true cost is not known until the action completes. Analysis can happen afterward, at whatever cadence the question requires. Conflating them serves neither.
Each phase needs what the ones before produced. Control needs Observe's attribution data; Optimize needs Monetize's revenue data. Skipping ahead produces predictable failure modes.
Binary on/off limits produce cliff-edge experiences where the first warning is a failed request. Mature enforcement layers degradation: model downgrade, caching, queueing, throttling, soft warnings.
The control layer normalizes provider differences so higher layers stay neutral. Lock-in becomes a multi-quarter rebuild; it is materially cheaper to build neutrality in than to bolt it on.
One economic control layer, four functions
The premise is a single economic control layer between applications and model providers. What matters is not which implementation pattern is used, but that every AI request flows through the layer.