Credit-Based Pricing for AI Software: The Six Fatal Flaws

TL;DR — Credit-based pricing isn’t the AI default — it’s the infrastructure default that application companies inherited without doing the value metric identification work (the licensing component of a complete pricing architecture). Six structural flaws make credits a revenue ceiling, not a scaling mechanism: they expose your cost structure, become incomprehensible at scale, mask the pain of paying until renewal, invite exchange-rate manipulation, hide pricing problems behind prepaid cash flow, and cap revenue at infrastructure margins. The alternative isn’t a different abstraction — it’s identifying the value metric that credits were invented to avoid choosing.

---

Walk through any AI conference, and you’ll hear the same pricing conversation on repeat: tokens, credits, API calls. The infrastructure companies set this narrative — OpenAI charges per token, the cloud providers bill per compute unit — and it’s loud enough that it sounds like consensus. It isn’t. Most B2B software companies adding AI features actually did something different: they bundled AI into existing packages without charging separately, avoiding the pricing question entirely. A smaller group went the opposite direction — passing AI costs to customers as tokens, credits, or consumption charges. And when an enterprise procurement survey asked buyers directly, 76% rejected technical usage metrics like tokens or API calls as “economically and operationally misaligned” with how they budget.

So credit-based pricing isn’t the industry default. It’s the infrastructure default that gets outsized attention because the most visible AI companies use it. The real problem is that B2B software companies — the ones building AI-augmented applications, not selling raw compute — are copying an infrastructure pricing model without understanding why it works for some products and fails for others. Credits can mask fundamental pricing problems while creating the illusion of aligned incentives.

Copying without understanding is a pattern across SaaS pricing models — not a problem unique to AI. But AI exposes it faster. The infrastructure costs are volatile, the adoption curve is steep, and the gap between a defensible pricing architecture and a cost-plus passthrough becomes visible within a quarter, not a fiscal year.

Why Credit-Based Pricing Became the AI Default (And Why That’s Problematic)

Credit-based pricing didn’t emerge from careful analysis of AI software value delivery. It bled downward from the infrastructure layer — and understanding that history explains why so many application companies are stuck with a pricing model that was never designed for them.

2011–2015: AI wasn’t priced at all. In the early years, AI capabilities were bundled into cloud compute. Google and Amazon offered basic machine learning APIs — image recognition, translation — included in broader cloud usage like AWS EC2 or Google Cloud credits. There was no separate AI pricing decision because nobody thought of AI as a distinct product. It was a feature of infrastructure.

2016–2018: Cloud providers create the first AI meters. As the transformer architecture and NLP capabilities matured, Google Cloud ML Engine and AWS SageMaker launched with usage-based pricing — per training hour, per prediction. Microsoft Azure Cognitive Services introduced tiered pricing for vision, speech, and language APIs. These are infrastructure meters for infrastructure products. Per-training-hour makes sense when you’re selling compute time to data scientists. The pricing matched the product.

2019–2020: Token pricing enters the vocabulary. OpenAI released GPT-2 and GPT-3 via API with token-based pricing — charging per 1,000 tokens processed. Microsoft invested $1B in OpenAI and began integrating GPT models into Azure. This is the critical moment: an infrastructure company priced its API by the token, and every application company building on top of that API inherited the token as their unit of measurement. Not because tokens measure application value, but because tokens are what the cost structure is denominated in.

This is the same pattern you see whenever a software company embeds a third party’s product: they inherit the vendor’s pricing model and pass it through to their own customers. A company that resells an embedded analytics engine often just passes the vendor’s per-user or per-query pricing straight to its buyers — not because that metric captures how the buyer derives value, but because it’s how the vendor’s invoice arrives. The embedded vendor’s pricing model becomes the default because redesigning it requires work that most companies skip.

2021–2022: The bundling trap, the add-on trap, and the passthrough trap. AI tools increasingly shipped as add-ons to existing software suites. GitHub Copilot launched at $10/month, later raised to $19/month — Microsoft subsidized the inference costs because they couldn’t make the per-token economics work at consumer scale. Adobe Firefly integrated generative AI into Creative Cloud using value-based pricing for premium features.

The market split three ways — and all three had problems. Some companies bundled AI into existing packages to avoid the pricing question entirely. Others passed infrastructure costs through as tokens or credits. And a third group — arguably the largest — packaged AI as a paid add-on, made significant investments in AI capabilities, and launched expecting upgrades and upsells. The attachment rates were dismal. Many of these AI add-ons failed to generate enough revenue to cover the investment in building them, let alone contribute to growth. The core issue wasn’t the AI capability — it was the packaging decision. Bolting AI onto an existing product as a separate line item forces the customer to make a standalone purchase decision about a capability they haven’t experienced yet and can’t estimate the value of. It’s the endowment effect in reverse: buyers undervalue what they don’t yet have, and a separate AI add-on price tag puts a number on something the buyer has no frame of reference for. The companies that tried this didn’t address the underlying pricing architecture — they treated AI as an upsell lever instead of rethinking how the entire product delivers and captures value.

None of these three groups had solved the underlying problem. They’d either hidden the cost, delegated the pricing decision to their cloud provider, or slapped a price tag on a capability without doing the packaging work to make it succeed.

2023–2025: The infrastructure model breaks for applications. The market fragmented. OpenAI’s ChatGPT Enterprise launched at a flat $30/user/month, then shifted to credits. Intercom adopted per-resolution pricing at $0.99 per resolved ticket — an outcome-based model that worked because the metric measured what the buyer actually cared about. Seat-based pricing collapsed from 21% to 15% of the market in a single year. Meanwhile, agentic AI obscured actual API and token counts entirely — an agent might make dozens of model calls behind a single user action, making token-based estimation impossible for buyers.

2024: Infrastructure price wars. Pricing became a strategic lever to capture market share. OpenAI cut GPT-4 Turbo prices by 50% on input tokens in January, then released GPT-4o in April at 3x cheaper input and 2x cheaper output than the original GPT-4. Google launched Gemini 1.5 Flash as its most affordable model for high-volume use. Amazon introduced the Nova model series, undercutting both. Open source models and specialized hardware drove costs down further. For application companies pricing on token passthrough, every infrastructure price cut compressed their margin — the exact cost-exposure problem we unpack in Flaw #1 below. The price cuts that were supposed to help application companies instead hurt the ones whose pricing was tethered to infrastructure costs.

Late 2025–2026: Everything fragments. Every unresolved tension from the eras above is surfacing at once. AI agents are collapsing the per-seat model — when one user equipped with agents accomplishes the work of five, per-seat economics don’t survive the math. The companies that built their entire revenue architecture on seats are now staring at a pricing model that punishes their best customers for adopting the product’s most valuable capability.

The replacements haven’t converged. Billing platforms and pricing consultancies publish surveys claiming the majority of SaaS companies now use “usage-based pricing” — but as we’ve argued elsewhere, when the same label describes fundamentally different approaches, the label has stopped communicating anything useful. Hybrid subscription-plus-usage, outcome-based models (Intercom charges $0.99 per resolved ticket), agentic pricing (OpenAI introduced $20,000/month for a research agent), and credits in various forms are all competing. Nobody has converged on a standard because there isn’t one to converge on — each AI product delivers value differently, and the companies that recognize this are the ones breaking free.

Credit adoption in particular draws inflated headlines. One widely cited analysis reported credit-based pricing “surging 126%” year-over-year — but the base was roughly 35 companies growing to 79. Against a universe of 30,000+ SaaS companies globally and 10,000+ AI startups, that’s less than 1% of the market. A separate analysis of 800 AI agent companies found only 13% using credits as their primary pricing metric. The “surge” is a percentage trick on a tiny base. Credits are loud in the conversation; they are not dominant in practice.

The fragmentation itself isn’t unprecedented. Every technology layer goes through the same pricing fracture when application companies build on top of raw infrastructure. Cloud compute started with metered pricing — pay per compute hour, per GB stored. That metric worked when buyers were engineers running infrastructure. When SaaS companies built on top of AWS and started selling to business users, compute hours became invisible underneath per-seat and per-module pricing. The infrastructure metric couldn’t survive the shift from technical buyer to business buyer. Telecom went through the same fracture: per-minute and per-SMS pricing collapsed when apps embedded communication capabilities and priced on completely different units. Payment processing followed the pattern — Stripe’s per-transaction fee became an embedded cost underneath commerce platforms pricing on subscription, GMV percentage, and add-on modules.

AI is mid-fracture. The foundation models price in tokens because they are infrastructure — the same way AWS priced in compute hours. Application companies building on top of those models are discovering, one by one, that the infrastructure metric doesn’t capture the value their product delivers. Credits are the intermediate step — an attempt to bridge the infrastructure metric and the application metric without committing to either. The companies that commit to the application metric first are the ones that will capture the value. The ones that stay on credits will watch the fracture complete around them.

The academic evidence reinforces this. Peer-reviewed modeling of competitive software markets found that fixed-pricing firms consistently achieve higher profits than usage-based firms — because the revenue from low-usage customers acquired through consumption pricing can’t compensate for the monitoring costs the model imposes. In a monopoly, usage-based pricing can work because there’s no alternative for the buyer. In competitive markets — which describe every B2B software category — the monitoring overhead and customer acquisition economics tilt against it. The same research found something counterintuitive: the costs of metering usage can actually benefit both competitors by reducing price competition intensity, but only up to a point. Beyond that threshold, the usage-based firm becomes uncompetitive entirely. Credits sit squarely in this zone — adding monitoring complexity without capturing the competitive benefit that a value-aligned metric would produce. And a separate finding from the same body of peer-reviewed work deserves attention: B2B software usage is largely inelastic to per-unit price changes, because usage is driven by business needs, not by how much the unit costs. The person using the software and the person paying for it are rarely the same. That means consumption-based pricing — including credits — doesn’t actually modulate demand the way its advocates assume. The customer’s usage doesn’t flex with the credit price. It stays constant while the bill fluctuates, which is the opposite of what a well-designed pricing metric should do.

One structural reality that credit advocates overlook: AI usage inside a customer’s organization is never evenly distributed. A small percentage of power users will consume the vast majority of tokens — the same concentration pattern that shows up in every software product with a consumption component. The credit advocate’s response is that heavy users just buy more credits, and that’s expansion revenue. On paper, it works. In practice, it creates a problem the vendor doesn’t see but the customer feels immediately. The heavy users aren’t the customer’s CEO deciding to scale up. They’re a handful of people inside the organization consuming tokens at a rate nobody budgeted for. The customer’s internal response isn’t to buy more credits — it’s to create a governance layer: usage dashboards, consumption alerts, approval workflows, and eventually someone whose informal job becomes telling colleagues to stop using the AI features so aggressively. We’ve seen this exact pattern with bandwidth-based licensing — customers designated someone as the internal usage police, adoption declined, and when renewal came, the customer argued they’d been rationing usage all year and deserved a lower commitment. The credit model didn’t drive expansion. It drove self-suppression — and the vendor interpreted the flat usage curve as “the customer doesn’t need more” when the reality was “the customer trained themselves to need less.” The capacity-gating response (daily limits, fair-use caps) is the infrastructure company’s version of the same dynamic. It rations access by time window instead of connecting price to value.

The credit model in particular took a public beating. A prominent AI coding tool shifted from a flat response model to credit-based consumption pricing, triggered immediate user backlash when allotments evaporated after two or three complex prompts, and forced a CEO apology within weeks — followed by a reported 20x effective price increase through credit redenomination months later. The full Cursor case study is in Flaw #4 below. The pattern it illustrates: credit abstraction doesn’t create pricing clarity. It creates the conditions for opacity that compounds with every change.

Meanwhile, the consumer-facing AI companies moved to a pattern that looks like subscription pricing but functions as capacity gating: a flat monthly fee with daily session limits, weekly message caps, or “fair use” ceilings that throttle heavy users. This isn’t a pricing model — it’s a cost-containment mechanism dressed as one. The daily cap exists because inference is expensive and unlimited access at a flat fee is economically impossible at current model costs. But from a pricing-to-value perspective, it reveals something important — these companies still can’t connect price to value, so they’re rationing access by time window instead. The cap has no relationship to the value the customer extracts. A researcher who hits their daily limit in two hours solving a $50,000 problem pays the same as someone who uses it all day for casual questions. The pricing penalizes the highest-value users and subsidizes the lowest-value ones — the exact opposite of what a well-designed metric would do.

The caps also create a behavior the provider’s growth metrics are blind to: power users maintain multiple accounts, rotating between them to work around daily and weekly limits. The provider sees account growth and interprets it as market expansion. It’s not — it’s a single user fragmenting their usage because the pricing architecture gives them no other option. The “growth” is phantom demand generated by the cap itself, not by the product attracting new users. Meanwhile, the value that power user extracts across those accounts vastly exceeds what they’re paying — exactly the buyer surplus the provider is failing to capture.

For B2B software companies watching this and thinking “maybe we should do daily limits too” — remember that these are consumer products managing millions of users at low price points. The rate-limit pattern solves a consumer-scale infrastructure problem. It doesn’t solve a B2B pricing problem. Enterprise buyers don’t want daily caps — they want predictable costs tied to business outcomes.

As we’ve written about GenAI pricing challenges, many software companies rely on “fair use” clauses in contracts that leave both salespeople and customers guessing what actual usage looks like and what it will cost. Fair use language isn’t inherently wrong — but most companies deploy it as a placeholder for pricing decisions they haven’t made yet. The clause goes into the contract because nobody did the work to model usage patterns, cost exposure, and packaging boundaries before launch.

Fair use done properly is a different discipline entirely. It means the company has vetted the assumptions behind the clause — projected usage across customer groups, cost modeling at different consumption levels, packaging and pricing that account for realistic scenarios rather than theoretical ones. Those assumptions are factored into the pricing architecture from the start, not patched in after the first customer complaint. And critically, those assumptions are treated as hypotheses that get validated over time through real usage data, with an explicit plan to iterate and tighten the higher-risk assumptions as the data accumulates. That’s continuous monetization applied to a fair use boundary — not a vague clause that nobody revisits until it causes a problem.

The difference between lazy fair use and disciplined fair use is the difference between a placeholder and a pricing decision. One defers the work. The other does the work upfront and commits to refining it.

The pattern across all of these eras is clear: capabilities mature on top of infrastructure, customers demand predictability as the opacity of estimating usage becomes untenable, and the industry keeps wandering through the licensing model woods looking for a metric that actually scales with value instead of compute. Most companies haven’t found it yet. Many remain on credits, daily caps, or vague fair use language — not because any of these work, but because redesigning the pricing model requires the kind of strategic work that’s easy to defer.

The idea that there’s one universal pricing strategy for AI that everyone can discover and adopt is the same fallacy as copying your competitor’s pricing model and expecting a better outcome. Just because everyone’s doing it doesn’t mean it’s a best practice. That’s especially true in pricing. Sometimes you have to swim against the current.

We’ve seen this pattern repeatedly: a platform with hundreds or thousands of API calls defaults to a credit model that charges for all of them indiscriminately — core algorithms and basic database reads alike. The fix is classification, not credits. Separate the calls that represent your IP (the proprietary operations customers actually pay for) from the infrastructure calls that have to exist but deliver no direct value. Price on the former. Blend out the latter. The customer should never see a line item for a database read — they should see a price tied to the work the platform does for them.

This isn’t theoretical. During the cloud transition era, clients brought us in specifically to eliminate infrastructure metrics from their pricing — blending out compute, storage, bandwidth, and API call counts that had bled into the customer-facing model from the technology stack underneath. The pattern was always the same: the technical metrics had made it into the pricebook because the engineering team built the billing system, and the billing system metered what the engineers could measure. Nobody stopped to ask whether those meters captured value. The result was sales processes gummed up in technical discussions — reps explaining what an API call was, customers asking why a database read costs anything, procurement demanding per-unit cost justifications on metrics that had no relationship to the business outcome the software delivered. Every conversation that should have been about ROI became a conversation about infrastructure. We still do this work. The infrastructure metrics haven’t disappeared — they’ve just migrated from cloud compute to AI tokens. The underlying problem is identical: a technical meter in a customer-facing pricebook that forces the sales conversation into the wrong register.

The Six Fatal Flaws in Standard AI Credit Models

Flaw #1: Credits Expose Your Cost Structure and Invite Margin Compression

Credits are pitched as abstracting your pricing away from raw infrastructure costs. In practice, they do the opposite. When your credits roughly correlate with tokens, API calls, or compute units — and your customers know that because the infrastructure providers publish their prices — you’ve made your margin visible. The buyer can look at the public token price from your cloud provider, look at your credit price, and calculate the markup. At that point, you’re not selling your intellectual property. You’re selling a spread, and the buyer’s job is to compress it.

Peer-reviewed economics research on information goods documents this precisely: when products with high fixed costs but near-zero marginal reproduction costs face competitors offering undifferentiated alternatives, competition drives prices toward that visible marginal cost. It’s the economic disaster scenario for digital goods — and credit-based pricing walks directly into it by making your cost basis legible to every buyer with a calculator.

This is why credit-priced renewal conversations are painful. Instead of discussing ROI and business impact, you’re defending unit costs and usage patterns. Customers start asking “Why does generating an image cost 50 credits while writing a blog post costs 25?” — questions that force you to justify your cost structure rather than demonstrate value. Worse, they start benchmarking your credits against the raw infrastructure price, asking why your credit costs 3x what the underlying API call costs their engineering team directly. Every credit on the invoice is an invitation to disaggregate the bundle and negotiate the margin down.

And sometimes the conversation never gets to renewal. We know of an application monitoring company that used a consumption metric — a mixed bag of units similar to credits — across their product suite. They landed an enterprise client and were thrilled. After the first month of usage, the client received a $600,000 bill — twelve times higher than they’d estimated. The pilot was terminated immediately, and the relationship was over. The product worked. The value was there. But the pricing model made costs impossible to predict, and a single invoice destroyed what should have been a seven-figure annual contract. No amount of product quality recovers from bill shock at that scale.

The companies that escape this trap are the ones whose pricing has no visible relationship to infrastructure costs. When your metric is tied to a business outcome — simulations completed, tickets resolved, reports generated — the buyer can’t reverse-engineer your cost basis because the unit of value has no direct analog in your cloud provider’s pricing table. The margin becomes invisible, which is exactly where it should be.

This matters because of how buyers actually behave. Working with B2B software companies has made one thing clear: customers don’t want to pay for your value. What they really want is to pay slightly under your costs — just enough to keep you alive, profitable enough to answer the support line, but not a dollar more. That’s not cynicism; it’s rational procurement behavior. When your cost structure is visible — and credit-based pricing makes it visible — the buyer has exactly the information they need to execute that strategy. They’ll benchmark your credits against your provider’s published rates and negotiate you down to a thin spread above infrastructure cost. When the metric is an outcome with no visible cost analog, the buyer has to evaluate the price against the value they receive instead of the cost you incur. That’s a fundamentally different negotiation — and one where the software company has leverage instead of the procurement team.

Flaw #2: Credit Systems Become Incomprehensible at Scale

Credit models sound simple when a company has one product and one credit type. They become incomprehensible when the product portfolio grows — and this isn’t a new problem. Credit-based licensing predates AI by decades.

In the on-premise era, software companies created credit and token-based licensing systems for the same reason AI companies adopt them today: they had a portfolio of products with different cost structures and wanted a universal currency that let customers move fluidly across the suite. The logic was the same then as it is now — a shared credit pool would stimulate cross-selling by showing how credits purchased for one product could be applied to another. Enterprise software vendors built elaborate entitlement management systems, floating license pools, and capacity-unit models that promised flexibility and portfolio adoption.

What they delivered was complexity. We’re working with a platform that has tens of thousands of SKUs and a credit system that originated in the on-premise days from exactly this desire — create a portfolio of interchangeable products to stimulate cross-selling for the sales team. The system is now nearly incomprehensible to both buyers and sellers. Different products consume credits at different exchange rates. Different bundles carry different credit ratios. Corner cases multiply with every new product addition — what happens when a customer buys a bundle that includes products at three different credit rates, then wants to reallocate unused credits from one product to another? The rules governing these scenarios have accumulated into a thicket of logic that requires specialized knowledge to navigate. New salespeople can’t learn it quickly enough to sell confidently. Buyers can’t predict what their annual spend will be. And internally, the pricing team spends more time managing credit exchange rate exceptions than analyzing whether the pricing actually captures value.

AI makes this trajectory worse, not better. As AI capabilities expand, the number of use cases that AI agents address will vary dramatically in complexity, token consumption, and ultimately the value they deliver. A simple summarization task might consume a handful of tokens. A multi-step research agent might chain dozens of model calls, each with different cost profiles, to produce an output the customer values at thousands of dollars. The natural impulse is to attach different per-unit credit prices to each of these operations — the summarization costs 1 credit, the research agent costs 50. But now you’ve recreated the same multi-layered matrix of exchange rates that the on-premise vendors built, except the number of distinct operations is growing with every product sprint instead of every annual release. As we’ve written about GenAI pricing challenges, with the advent of AI agents, algorithms send requests back to LLMs consuming tokens behind the scenes where users can’t fully understand their consumption — and layering a credit system on top of that opacity doesn’t create transparency. It creates the illusion of a pricing model where none exists.

This is the trajectory of every credit system at scale, whether on-premise or cloud, whether 2005 or 2025. What starts as “1 credit = $1” evolves into a matrix of exchange rates, consumption rules, product-specific ratios, and exception policies that nobody fully understands. The administrative complexity doesn’t just add cost — it actively undermines the cross-selling motion the credits were designed to enable, because nobody can explain the economics of buying across the portfolio without a spreadsheet and a 30-minute walkthrough.

Flaw #3: Credits Reduce the Pain of Paying — Then Deliver It All at Once

Behavioral economics research has documented a phenomenon called the “pain of paying” — the psychological discomfort people experience when parting with money. Neuroimaging research showed it’s not metaphorical: paying activates the anterior insula, the same brain region that processes physical pain. The more tightly coupled the payment is to the consumption (seeing cash leave your hand), the stronger the pain. The more abstracted the payment (credit cards, tokens, chips), the weaker the pain — and the more people spend.

Casinos understood this decades ago. That’s why they use chips instead of cash. Research on poker chips found that participants gambled significantly more with chips than with real money — because chips feel like game pieces, not currency. The conversion from dollars to an abstract unit reduces friction at the point of spending. The loss doesn’t feel real until you convert back.

Software credits exploit the same psychology — usually unintentionally. A buyer who approves “5,000 credits” feels less friction than one who approves “$50,000.” The abstraction makes the initial purchase easier. But the pain doesn’t disappear — it defers. When the invoice arrives and the buyer converts credits back to dollars, the full cost hits at once. That’s the $600,000 bill shock from the application monitoring case. The customer didn’t feel the spend accumulating because credits decoupled the payment from the consumption. The reconciliation delivered all the deferred pain in a single invoice — and killed the relationship.

A peer-reviewed meta-analysis across 71 studies and 392 effect sizes confirmed the pattern: people consistently spend more when removed from cash. For software companies, this means credit-based pricing may actually accelerate initial adoption — but at the cost of renewal conversations, budget reviews, and procurement audits where the deferred pain surfaces. You’re borrowing goodwill from the first transaction and paying it back with interest at renewal.

Flaw #4: Credits Create Exchange Rate Risk You Can’t Resist Exploiting

When your pricing is denominated in credits instead of dollars, you control the exchange rate. And the temptation to change it is structural.

The airline industry is the clearest precedent. Frequent flyer miles are a credit system — earn miles through flying or credit card spend, redeem them for flights at an exchange rate the airline sets. The data on what happens next is damning: airline miles devalue at approximately 15% per year, five to seven times the rate of actual inflation. Airlines change the exchange rate unilaterally and retroactively — increasing the miles required per flight, adding blackout dates, eliminating redemption options — reducing the value of miles customers already earned. The U.S. Department of Transportation launched a federal investigation into the four largest airlines’ loyalty programs. The CFPB called the practice an “illegal bait-and-switch.”

You wouldn’t dream of doing this with dollars. If a software company told a customer “the price for the same product just went up 15% and we’re applying it retroactively to the contract you already signed,” procurement would be on the phone within the hour. But when the exchange rate changes from 100 credits per report to 115 credits per report, it feels like a minor adjustment — a tweak to a conversion factor, not a price increase. The abstraction provides cover for changes that would be unacceptable in direct currency.

Every credit-based software company faces this temptation. When costs rise or margins compress, raising the credit-to-dollar ratio is easier than raising the price — because it’s less visible. Cursor, the AI coding tool valued at $9 billion, shifted its $20/month Pro plan from 500 fast responses to a credit-based system billed at API rates in June 2025. Users ran out of their allotment after two or three complex prompts. The CEO issued a public apology. Then in early 2026, effective per-unit rates were reported to have increased by more than 20x through further credit redenomination. The trust damage compounded with each change.

The risk isn’t just that you’ll exploit the exchange rate — it’s that the market has been trained by airlines, gaming platforms, and now AI companies to expect that you will. Enterprise buyers entering a credit-based contract know the exchange rate will move against them. That expectation poisons the negotiation before it starts. They’ll demand contractual rate locks, minimum redemption guarantees, and price protection clauses — complexity that a dollar-denominated pricebook simply doesn’t require.

Flaw #5: Prepaid Credits Mask Pricing Problems

Most credit systems require customers to buy credits upfront, creating a cash flow pattern that can hide fundamental pricing issues. When customers prepay for $10,000 in credits, you book revenue immediately — even if those credits deliver $50,000 in customer value over time. The disconnect between when you collect revenue and when the customer realizes value makes it hard to read the signal that matters: whether your pricing is actually capturing what the product delivers.

The artificial cash flow boost compounds the problem. You see strong top-of-funnel numbers — new customers buying credit packages, existing customers refilling — and interpret it as product-market fit. What’s often happening underneath is that your customers are scaling their operations and buying more of something they were already under-paying for. Volume growth masquerades as pricing power. The finance team reports healthy expansion revenue. The pricing team never learns that a better metric would have captured three times the revenue at the same customer engagement level.

The reconciliation comes at renewal. When the contract comes up for negotiation and the customer’s procurement team calculates what they actually spent over the year, the deferred pain surfaces in a single conversation. The cash flow pattern that looked like momentum on the quarterly dashboard is revealed as a pricing problem that compounded over twelve months. This is where credit-based companies lose customers they didn’t realize were at risk — because the billing model hid the strain until renewal exposed it all at once.

There’s a deeper problem underneath: usage in software is never normally distributed. We recently analyzed over $1 billion in B2B software transactions in LevelSetter across numerous engagements — every dataset was skewed, no exceptions. A small number of customers consume disproportionately while the majority use far less than the “average.” Credit packages designed around average usage serve nobody well. Heavy users blow through credits in the first week and hit bill shock or throttling. Light users accumulate unused credits and feel they’re overpaying for capacity they don’t need. Both groups are frustrated, but for opposite reasons — and the average credit depletion rate the finance team reports represents neither of them. When companies set credit allotments, tier boundaries, or fair-use limits using averages, they’re designing for a customer that doesn’t exist.

Flaw #6: Cost-Plus Credits Cap Revenue at Infrastructure Margins

The most dangerous flaw is how credit pricing trains you to think like an infrastructure company. When you price based on compute costs plus margin, you’re implicitly accepting infrastructure-level economics as your ceiling. That ceiling is dramatically lower than what value-based pricing can capture. An AI capability that takes seconds of compute to deliver but saves the customer hours of professional work has a value-to-cost ratio that supports pricing well above any cost-plus markup — but only if the pricing architecture allows the market to discover it. Credit pricing doesn’t.

The ceiling becomes permanent because credits create customer expectations around unit economics. Once customers understand that credits roughly correlate with your compute costs, they resist any pricing that moves significantly beyond that baseline. Every contract renewal becomes a negotiation about credit conversion rates and volume discounts, not about the value your product delivered over the prior year. The anchor you set at launch determines what the customer will tolerate at renewal — and cost-plus anchors tolerate cost-plus renewals.

The counterfactual is the case study from above: a product sold for $2,500 every three years — roughly $833 per customer per year — that closed a renewal at $300,000 per year after the metric changed. Same product, same feature set. The difference was exiting a unit of pricing that tracked operational cost and entering one that tracked the business outcome the customer was already getting. That’s the revenue ceiling that credit pricing quietly caps. Companies on credit models will never discover their actual ceiling because the pricing architecture prevents it from surfacing.

Are Credits Ever the Right Answer?

In most cases, credits are a cop-out. They substitute an abstraction layer for the harder work of choosing a metric that captures value. But there are edge cases worth acknowledging — even if the honest assessment of each is that credits are rarely the best option, even where they seem defensible.

Before examining those edge cases, it’s worth noting what’s absent from the credit advocacy: buyer preference data. The billing platforms that promote credit-based pricing cite vendor adoption statistics — 77% of large software companies use consumption pricing, 85% of SaaS leaders have adopted usage-based models, 59% expect usage-based revenue to grow. These are supply-side numbers. They tell you what vendors are doing, not what buyers want.

And the supply-side enthusiasm has a predictable arc. Software companies see the adoption numbers, watch the infrastructure providers price by usage, and race to get as close to the wire as possible. They mistake “usage-aligned” for “value-aligned” and price aggressively on technical metrics — API calls, compute minutes, data volume, tokens consumed. The closer they get to the infrastructure cost line, the more their revenue starts behaving like infrastructure revenue: cyclical, volume-dependent, and exposed to every contraction in customer activity. When a downturn arrives and customers cut usage, consolidate tools, or freeze budgets, consumption-priced revenue drops in lockstep. The companies that priced on predictable value metrics weather it. The ones that priced on raw consumption take a bath. One company learned both lessons. They priced their software on per-attendee usage in a seasonal industry. When COVID eliminated attendance, revenue went to zero overnight — the metric was perfectly usage-aligned, and that alignment was the problem. They nearly went under, brought in a major pricing consultancy to restructure, and the consultancy’s willingness-to-pay analysis recommended a tenfold price increase. Demand never recovered. The consumption metric exposed them to the shock. The overcorrection — built on survey data that overestimated what a decimated market would tolerate — made it permanent.

The demand-side evidence tells a different story. Enterprise surveys consistently show buyers prefer predictable pricing tied to business outcomes. An enterprise technology procurement survey found 76% of decision-makers rejected technical usage metrics like tokens or API calls, calling them “economically and operationally misaligned” with how they budget. An earlier industry survey found only 14% of enterprise software users preferred usage-dependent pricing — 58% preferred models with predictable per-user costs. Even credit advocates acknowledge the gap: one monetization director at an enterprise software company admitted “credits gave us breathing room while we figured out the real value metric — but they’re not intuitive to buyers.”

If buyers reject the raw technical unit, adding a credit abstraction on top of it doesn’t solve the problem — it buries it under another layer. Here’s what actually happens: your cloud provider charges you in tokens. You convert tokens to credits at an internal exchange rate. Then you rename credits to something friendlier — “AI units” or “compute credits” or whatever your marketing team invents — and present that to the buyer. The buyer is now three layers removed from the actual cost unit, but their invoice still scales with the same underlying token consumption they already said they can’t predict or budget for. You haven’t changed what drives the price. You’ve just made it harder to see. Vendors adopting credits doesn’t mean buyers prefer them. It means vendors haven’t done the metric work yet and credits were the path of least resistance.

Infrastructure products where others embed your capabilities. If your product is an API or engine that other software companies build on top of — extending their capabilities as part of their own product — then you are infrastructure, and infrastructure pricing can work. AWS Bedrock and Anthropic’s API for Claude Code are evidence: token pricing tracks real marginal cost because these companies are close to the wire, scaling the hardware and compute that the tokens represent. Their growth shows the model is viable at that layer.

But notice what’s happening on the buyer side. For the value a developer extracts from Claude Code running against a complex codebase, the tokens cost peanuts — the buyer is getting the deal of the century, paying infrastructure prices for application-level value. That gap is acceptable for the infrastructure provider because they win on volume and scale economics. The buyer’s surplus is the flywheel that makes them the default building block.

The mistake is any company one layer up copying this model. If you’re building on top of infrastructure and passing token-like pricing through to your customers, you don’t have the scale economics that make it work. You have commodity marginal costs without commodity volume — and your customers are getting the same “deal of the century” on application-level value that you’re failing to capture. Infrastructure pricing rewards the infrastructure player. It punishes everyone else who tries to wear it.

For true foundation models — Claude, Gemini, Codex — the use cases are unbounded, and the provider has no control over them. The technology is a general-purpose reasoning engine; any prompt can turn it toward any job. One API serves research, writing, coding, analysis, customer support, and dozens of use cases the provider never designed for. No named operation captures all of that, which is why tokens persist at this layer — they’re the universal substrate, not a substitute for metric work. That’s the narrow case where raw consumption pricing is the best available answer, not because it’s ideal but because nothing better has emerged yet.

The advice to name the unit applies one layer up — to purpose-built products where the platform performs a specific job. A simulation engine has simulations. A document processor has documents. A revenue optimizer has optimized transactions. The choice is rarely clean. Most products have three or four defensible metric candidates:

• A primary operation — the named job the platform performs
• A business outcome — the result the customer cares about (leads, tickets resolved, transactions optimized)
• An input volume — documents processed, data ingested, records scanned
• A seat equivalent — users with access to the capability

Each scales differently, is perceived differently, and lands differently in a contract. And the problem compounds for companies with a portfolio of products — each product may have its own defensible metric candidates, and the real challenge becomes minimizing the number of distinct metrics across the portfolio while still capturing value fairly for each product line. A simulation engine and a reporting tool and an analytics dashboard within the same suite may each want a different unit. Letting each product pick its own metric creates a patchwork that’s hard for buyers to budget and hard for sales to explain. Collapsing everything into credits is the temptation — but as Flaw #2 documented, that’s how you end up with the incomprehensible multi-layered exchange rate matrix that nobody can navigate.

Picking which metrics survive — and which get consolidated — is the hard work. It involves testing candidates against buyer language, unit economics, expansion dynamics, and how the metric behaves when the customer’s usage grows tenfold. Whichever metrics survive that work will beat a credit abstraction, because a “simulation run” tells the buyer what they’re buying and a “credit” tells them nothing. The difficulty isn’t naming the unit — it’s earning the right to name one by ruling the others out. Credits don’t shortcut the work. They just hide the fact that it hasn’t been done.

Even this narrow case has an expiration date. The history above shows pricing architectures rarely survive commoditization intact — and the foundation model layer is already commoditizing. Claude Pro and ChatGPT Plus moved consumer access to subscription with rate limits. Enterprise deals increasingly include capacity reservations instead of pay-per-token. Reasoning modes, tool use, longer context windows, and agentic workflows are where the real competition has shifted. It’s worth asking whether Anthropic wrapping its own model in Claude Code is an early signal of what’s coming. If the pattern holds — and it has held across every infrastructure-to-application transition in software — profits eventually migrate to the purpose-built application that wraps the building block, not the building block itself. That shift may not happen, or may happen differently for foundation models. But the directional evidence is accumulating: subscription tiers replacing pay-per-token at the consumer layer, capacity reservations in enterprise deals, reasoning modes and agentic workflows as the actual competitive frontier. The metric that makes sense at the infrastructure layer rarely survives contact with the buyer at the application layer unaltered.

Even the “honest” unit is already under pressure. Recent reporting documents that Anthropic quietly reduced Claude’s default effort level to “medium” to economize on compute — same token price, lower output quality, no public notice. Senior engineers at AMD and Microsoft reported substantial behavioral regressions; the company acknowledged the change but declined to explain the transparency gap. This is obfuscation on a new axis. The buyer’s bill looks the same, but the capability per token silently dropped. If tokens are the universal substrate, value-per-token becomes a provider lever that can be pulled whenever compute is constrained — another reason to treat “the unit stays the same” as the weakest form of pricing clarity. Unit integrity isn’t value integrity.

Tokens dominate this layer today, but mostly because nothing better has emerged. That’s the incumbent answer, not necessarily the right one — and incumbent answers rarely survive commoditization intact. Which brings us back to the core point: pricing is an ongoing process, never a settled architecture. The foundation model providers are already rethinking it — sometimes in public with new tiers, sometimes in private by changing what a unit actually delivers. Everyone downstream should be paying attention.

Large legacy portfolios with thousands of SKUs. This is where credits have the strongest case — and where the reality is most painful. CAD and engineering companies with vast on-premise portfolios, regional pricing across dozens of currencies, and hundreds of thousands of price points across product combinations have used credits as a simplification layer for decades. A universal credit lets a customer buy across the portfolio without navigating a separate pricebook for each product line. The problem is that these companies desperately want to simplify, and credits haven’t delivered the simplification they promised — they’ve added a layer of exchange rate complexity on top of the existing portfolio complexity. Credits as a portfolio unifier can work, but only when the alternative is genuinely worse — and most companies haven’t tested whether a simplified packaging architecture with fewer SKUs would eliminate the need for credits entirely.

Early-stage products where value metrics aren’t yet clear. This is where the credit temptation is strongest — and where it does the most long-term damage. The argument is that credits buy you time while you figure out the right metric. In practice, they delay the learning. Every month on credits is a month where you’re not testing whether an actual metric resonates with buyers, scales with value, and produces coherent unit economics.

The deeper risk is that credits don’t just defer the metric decision — they make it for you by default. Implementing a credit system requires billing infrastructure, sales enablement, customer documentation, and contract language. Those are real investments. And once they’re made, the sunk cost fallacy takes over. Peer-reviewed research on organizational decision-making found that 85% of participants chose to continue funding a failing project when prior investment was emphasized — compared to only 10% who would invest fresh. Status quo bias compounds the effect: the credit system becomes the default, switching costs accumulate with every new customer onboarded to it, and the decision to move to a value-aligned metric gets harder every quarter. Not because credits are working — but because unwinding them is expensive and nobody wants to write off the investment in the billing system, the sales training, and the customer migration.

If pricing isn’t treated as an ongoing process — with explicit plans to revisit the metric as the product matures — credits get baked in permanently. The temporary strategy becomes the permanent architecture through the act of not making a decision. A better approach: pick the best-guess metric based on how early customers describe the value they’re getting, price on it, and iterate. You’ll learn faster from a real metric that’s slightly wrong than from a credit system that tells you nothing about value alignment. Credits defer the metric decision; testing a metric makes it.

The critical test isn’t whether credits are acceptable. It’s whether the work to avoid them has actually been done. In almost every case we’ve seen, the company that says “we need credits” is really saying “we haven’t done the value metric identification work yet” — the licensing component of the pricing trifecta that determines what unit you charge for, how it scales with customer value, and how it behaves across customer groups. Those are different problems with different solutions, and credits solve none of them.

Value-Aligned Alternatives to Standard Credit Pricing

Moving beyond credits requires identifying pricing approaches that connect directly to customer outcomes rather than your operational metrics.

Outcome-based pricing tied to AI-generated results works well when your AI produces measurable business outputs. Instead of charging per API call, charge per qualified lead generated, per document processed, or per design created. This aligns your revenue growth with customer success.

Hybrid models combining base subscription with usage premiums provide predictable recurring revenue while capturing value from heavy usage. A base subscription covers access to core AI capabilities, while usage charges apply to volume beyond reasonable limits or premium features that require significant compute.

Buyers rarely judge a price in isolation. Show them three packages side by side and they’ll pick by comparison — the expensive tier makes the middle option feel like the reasonable choice. That anchoring effect is why hybrid pricing closes more deals when structured as tiered editions rather than a single plan.

Capability-based packaging that prices AI features as value add-ons treats AI as an enhancement to core software functionality rather than the primary pricing metric. This works especially well for established software companies adding AI features, where the AI improves existing workflows rather than replacing them entirely.

Consider what’s possible when the value metric identification work gets done. A software client had been selling a renewable license at $2,500 that customers renewed on average once every three years — roughly $833 per customer per year in realized revenue. After an engagement focused on identifying the right licensing metric, the same product closed a renewal at $300,000 per year. The negotiation took nearly a year. When the contract signed, the customer wrote a check for $600,000 at close.

The product didn’t change. The feature set didn’t change. What changed was the unit the customer paid for — and how that unit mapped to the business outcome the product was already delivering. A credit abstraction would have hidden the metric that made this deal possible. Finding it was the work.

The full operating framework for doing that work — choosing the value metric, building packaging around customer groups, and validating price points against real demand — is what turns the critique into an executable alternative. Credits defer each of those decisions. The licensing, packaging, and pricing trifecta makes each one explicitly.

Another case, different lever. A cybersecurity client had a $75,000 deal in their pipeline — sold as a single-customer license to a private equity firm evaluating a portfolio investment. The original structure treated the PE firm as one buyer: one price, one case-study deployment, and a pile of warm leads to chase across the PE’s portfolio companies afterward. After recasting the pricing architecture around volume commitment — larger commitments earn better unit economics and expanded packaging — the conversation shifted. Instead of selling the PE firm a tool, the client sold a portfolio-wide program. The PE firm committed upfront to deploy across their holdings in exchange for better unit pricing and packaging built for portfolio scale. The contract closed at $375,000 in the fifth week of the engagement.

This wasn’t a new metric. The metric was already reasonable. It was recognizing that the buyer’s actual buying unit wasn’t a single license — it was a portfolio decision. Once the pricing architecture matched how the buyer was actually thinking, the deal size followed.

Implementation Framework: Moving Beyond Credits Without Losing Customers

Transitioning away from credit-based pricing is a multi-year exercise, and the first goal — the one that ranks above every other consideration — is protecting legacy customer revenue. Every tactical choice in a transition plan either serves that goal or undermines it.

Never force migration. This is the hardest rule to hold and the one that separates transitions customers experience as evolution from transitions they experience as extraction. Legacy customers should have a defined horizon — typically three years or longer — during which their current packaging remains protected, giving them time to evaluate, budget, and plan any move on their own terms. The new pricing applies to new customers and to legacy customers who voluntarily choose to move within that window. Sunset dates themselves aren’t the problem; sunset dates announced with short notice and no service support are. A generous horizon, communicated openly from day one, with service teams ready to help with the more complicated conversions, is what makes the difference between a transition and an extraction — the Klaviyo example below shows what happens when the runway collapses.

Do the line-item impact analysis before rollout, not after. Every existing customer has a contract, a usage pattern, and a budget. Introducing a new metric or packaging without first modeling what happens to each customer individually is how companies discover their new model is worse than their old one — through churn, not through analytics. LevelSetter computes line-item pricing and packaging impacts across every active customer in milliseconds, which turns the homework from a multi-quarter spreadsheet exercise into a pre-rollout check. Whatever tooling you use, the principle holds: you don’t launch new pricing architecture without knowing, customer by customer, what happens on day one.

Create a feature wedge between the old and new packaging. This is where many SaaS transitions unravel. In the on-premise era, new versions were priced separately — customers paid for upgrades, and not every customer upgraded. When the industry moved to SaaS, almost everything collapsed into the subscription stream. Maintenance, support, and ongoing access were bundled into the recurring fee, which made sense. But new features, new capabilities, even game-changing ones, started getting pulled into the same stream — given away free to existing customers. The result: legacy customers have no reason to migrate, because the new package and the old package are converging in capability rather than diverging. A transition plan needs an intentional wedge. New features flow into the new packaging. The old packaging continues to receive maintenance and support but stops receiving new value. Over time, the new package becomes demonstrably more valuable, and legacy customers migrate by choice — because they want what the new package offers, not because the old one is being forced to end.

Forecast revenue across two cohorts. You’re managing legacy customers on the old model and new customers on the new model, possibly for years. Forecasts need to model both cohorts separately: credit depletion and renewal behavior on the legacy side, adoption rates and expansion dynamics on the new side. Over-optimism about how quickly legacy customers will migrate is the most common forecasting error. Many will stay on the old model for the life of the relationship — plan for that as the default, not the exception.

A cautionary public example: in early 2025, the email marketing platform Klaviyo changed its billing approach for legacy accounts, moving from send-volume pricing — where customers paid based on the profiles they actually emailed — to automatic plan upgrades based on total active profile count, including every profile in the database whether emailed or not. The metric change itself was defensible: active profiles track engagement capacity more faithfully than raw sends. What generated the backlash was the execution. A limited band of legacy accounts qualified for an “appreciation discount” capping the increase at 25%, but many customers fell outside that window. For accounts with large inactive contact lists, the tier jump was substantial — reports of price increases of 100% or more surfaced as customers were suddenly billed on their full database rather than on active sends. Community forums filled with migration threads and platform-comparison posts. The underlying pricing logic may have been sound; the transition plan made it look punitive.

The lesson isn’t “don’t change your metric.” It’s that metric changes applied retroactively to legacy customers without explicit transition design produce price shock, not value recognition. A transition handled well is measured in quarters, not weeks: announce early, offer both the old and new metric in parallel for one or two renewal cycles, let the customer pick their migration moment, and use product improvements — not billing enforcement — to make the new model attractive. Compressing this into a single flip day treats the customer’s economics as disposable. The signal the buyer receives is “we raised your price,” not “we aligned our pricing with your value.” That difference is the difference between a clean transition and a churn event.

Pricing is an ongoing process, never a settled architecture. That’s true for the foundation model providers iterating in public and in private, and it’s true for every application company that inherited credits by default rather than designed a metric by intent. The companies that will compound advantage over the next three years aren’t the ones that pick the best current pricing model — they’re the ones that treat pricing as a capability they continuously exercise, with the customer conversations, the line-item analysis, and the operational discipline to keep refining it. Credits defer that work. Metric selection is that work. The companies doing it are the ones that won’t be writing the cautionary case study in someone else’s article three years from now.

FAQs