# Why Subscriptions > Credits for AI Products

*By Carson Shaar · September 2, 2026 · 7 min · All*

We built our first monetization path around credits because AI costs are variable. Customers taught us that accurate metering and a good buying experience are not the same thing.

Usage-based pricing feels like the inevitable default for AI products. 

Every model call, web search, image generation job, and paid third-party API has a cost. If the underlying infrastructure is metered, the obvious assumption for the cleanest product pricing model seems: convert those costs into credits and let customers pay for exactly what they use. 

That was our starting point at Vellum. It was economically accurate and technically clean, but it was not the strongest way to sell the product.

Subscriptions were, here’s why.

## Why credits was the first bet

There is a real argument for credits because AI software does not have a uniform cost per user.

One person might send a few messages a week. Another might run expensive models, generate images, search the web, and keep an assistant working in the background all day. 

A flat price hides that variance, while credits expose it, making the system transparent: buy a balance, consume against it, add more when needed.

From the infrastructure side, this is great. It keeps revenue tied to cost, makes heavy users fund heavier usage, avoids forcing light users into a large commitment, gives Finance a clean ledger, and lets Engineering enforce limits. 

From the customer side, however, the experience starts with accounting. 

### A technically accurate unit can still be the wrong buying unit

Credits communicate cost precisely but capability poorly. A balance of 50 credits does not tell someone whether their assistant can become part of their daily workflow. It does not describe reliability, storage, compute, identity, or the ongoing infrastructure required to keep that assistant available. It mostly tells them that the number will go down.

Before someone has fully decided what the assistant is worth, we ask them to estimate how much of an unfamiliar unit they might consume, choose a top-up amount, monitor a declining balance, and make the purchase decision again when it runs low. 

The model optimizes for buying precision rather than buying confidence, especially when the customer needed it the most.

| Unit | The question it answers |
| --- | --- |
| Credits | How much variable usage occurred? |
| Subscription | What ongoing capability am I buying? |

Past conversions, this model creates a strange emotional inversion for users: the more successfully a customer uses the product, the faster they watch something disappear. Every meaningful action becomes depletion, and every top-up becomes another moment to reconsider the purchase. 

Instead of building a habit around the product, the customer repeatedly encounters a stopping point.

This is not unique to AI. Prepaid systems are good at making spend visible and bad at making value feel durable. In our case, the problem was amplified because customers did not yet have an intuitive sense for how credits translated into work, so we were teaching the meter before we had finished selling the outcome.

That mismatch took us too long to see because credits made so much sense inside the building. We understood what generated usage, why one task cost more than another, and how to translate a balance into model calls. New customers could not make that translation, and the point here is that they shouldn’t.

## What changed when we made plans the primary path

Instead of erasing credits entirely, we tested which decision we surfaced first. At the exhausted-credit wall, free users used to see **Add Credits** and open a top-up checkout. We decided to change that single CTA to **Upgrade** and sent them to the plan-selection flow. Paid users still saw **Add Credits**. 

That changed the framing from credit inventory to access. Instead of making a free user’s next decision “How many credits should I buy?”, we made it “Which level of assistant do I want?” 

A plan could bundle the durable parts of the product into one coherent promise:

- A machine that stays available
- Persistent storage for files, notes, and conversation history
- A visible monthly credit allowance for real usage
- Higher tiers for more compute, capacity, and identity features
- A predictable monthly price

Our current subscription offering has three named packages: Mighty, Super, and Ultra plus a Custom configuration. The names matter less than the structure. Each package represents a level of capability rather than a pile of credits. The customer can look at a plan and understand what kind of system they are putting into their life.

The subscription also creates a different relationship with the product. A top-up says, “Here is another finite batch.” A subscription says, “Keep this running for me,” which is closer to what a personal assistant actually is. 

An assistant is not a one-off API call. It has memory, storage, integrations, background processes, a machine, and an identity. Customers expect it to be there tomorrow with the same context it had today, so recurring infrastructure should feel like recurring infrastructure. 

Once we offered that promise clearly, subscriptions became the stronger monetization path because the pricing model finally matched the shape of the product.

### How we proved it

To solidify our thinking, we ran a billing CTA experiment at the credit paywall from July 23 through August 17, 2026.

The control showed free users **Add Credits** and opened the top-up flow. The treatment showed **Upgrade** and sent them to plan selection. Paid users continued to see Add Credits in both arms. 

After the experiment, we removed the flag and made that branch the product default: free plans point to **View plans**; paid plans point to **Add credits**.

The treatment did cannibalize some credit purchases with credit-purchase cash falling by 44% but, more prominently, overall revenue grew **28%** higher over roughly three and a half weeks.

## More than a checkout conversion problem

It would be easy to describe this as a checkout-conversion problem: customers prefer one recurring purchase over repeated credit purchases. That is true, but incomplete because the credit-first model created friction throughout the lifecycle.

### 1. Customers had to forecast unfamiliar usage

Before building a habit with an AI assistant, nobody knows exactly how much they will use it. A credit purchase asks for a forecast when the customer has the least information, so people either underbuy and hit the wall early or overbuy and feel like they have stranded money sitting in an account. A plan reduces the precision required. The customer chooses a capability band, starts using the product, and adjusts later if needed.

### 2. Successful usage looked like loss

A declining balance makes every action visible as spend. Transparency is good, but constant depletion is not the only way to provide it. 

With a subscription, the primary purchase is access to an ongoing system. The credit model remains visible around it: plan cards show the included monthly allowance, the product shows usage balance, low-balance warnings still point to Add Credits, and paid users who exhaust their balance still get the top-up path.

Credits explain and control consumption; the plan explains what the customer is signing up to depend on.

### 3. Top-ups introduced recurring chances to churn

A manual top-up is better viewed as a recurring sales process rather than reoccurring revenue. Every exhausted balance asks the customer to stop what they are doing, open billing, select an amount, complete checkout, and decide again whether the product is worth funding. 

That pause can sometimes be useful, but it is usually just an interruption that can expedite churn. Auto-reload reduces the interruption by turning credits into something that behaves more like a subscription.

### 4. Credits compressed different kinds of value into one number

Model usage is variable, storage is durable, compute capacity is provisioned, and a custom domain or assistant email is an entitlement. These are not the same economic object, and a single balance is a poor way to explain all of them. Subscriptions gave us a stable layer for infrastructure and entitlements. Credits could then do the job they were actually good at: account for variable consumption.

## Credit <> Subscription hybrid

We did not conclude that credits were bad; we concluded that they were being asked to do the wrong job, so we made our billing model hybrid:

| Layer | What it prices |
| --- | --- |
| Subscription | The durable system: machine, storage, platform capabilities, and included monthly credits |
| Credits | Variable consumption: model inference, web search, image generation, and paid third-party APIs |

Pro packages include credits each month. Custom plans can add an optional recurring credit bundle. Customers can still purchase pay-as-you-go credits, and they can use auto-reload to avoid interruptions.

Credits remain both the accounting system and a customer-visible control surface, so our plan selection shows included credits. 

On selected current-plan surfaces, we translate the raw bundle amount into a plan-relative **Usage Balance** and copy like “Mighty usage, reset monthly.” Billing still shows the remaining credit balance. Low-balance warnings and exhaustion states name credits directly. Customers can add credits manually, configure auto-reload, and, on Custom plans, choose a recurring credit bundle.

What changed is that credits no longer carry the entire value proposition by themselves. They let us pass provider costs through transparently, attribute usage, enforce budgets, and avoid pretending every customer costs the same amount to serve. The subscription packages those mechanics with the machine, storage, and capabilities the customer is actually adopting.

This distinction matters because “subscriptions beat credits” can easily turn into bad product advice: hide usage, offer unlimited everything, and hope the unit economics work out. 

That is not what we learned. The better principle is:

> **Price in the unit your customer understands. Meter in the unit your infrastructure requires.**

For us, customers understand a plan as a level of dependable capability. Our infrastructure requires granular usage accounting. The hybrid model lets both be true.

### Subscription-first does not mean hiding credits

Our implementation is deliberately not credit-free. The sequencing is what changed. Credits still appear where customers need to understand or control consumption, but they do not have to dominate the first decision about whether the assistant is worth adopting. 

The order should be:

1. **Lead with capability:** Explain what the assistant can reliably do and what the plan provides.
2. **Include a reasonable monthly credit allowance** Give customers room to experience the product without immediately managing a wallet.
3. **Keep the economics visible:** Show the included credits on the plan, then show usage, balance, limits, and attribution as the customer consumes them.
4. **Provide an overflow path:** Let heavier users buy more without forcing every customer to think like a procurement analyst. The old experience reversed this order by beginning with the economics and hoping the capability became obvious later.

## What I would do differently next time

If I were pricing a new AI product from scratch, I would not begin with “What is the cleanest way to pass through model costs?” I would start with three different questions:

### What durable promise is the customer buying?

Is this a tool they open occasionally, or a system expected to stay available and accumulate context? The more persistent and relational the product, the more natural a subscription becomes.

### Which costs actually vary with usage?

Not every cost belongs in the meter. I’d separate provisioned infrastructure, durable storage, support, identity, and entitlements from genuinely variable services like inference and paid APIs.

### Where should the customer encounter complexity?

Complexity cannot always be removed, but it can be sequenced. 

A customer choosing whether to adopt the product needs a clear promise, while a customer administering an adopted product needs detailed controls. Those two people should not be forced into the same screen or mental model. In practice, that means:

- Sell a small number of opinionated packages.
- Make each package describe a real level of capability.
- Include enough monthly credits for the package to feel complete.
- Keep granular metering and credit controls intact.
- Let advanced customers customize and buy overflow.
- Keep detailed controls in billing and administration, while surfacing balance and recovery context in-product when it matters.

This is not the only pricing model that can work for AI. Products that are truly transactional may still fit pure usage pricing, developer infrastructure with highly legible units may benefit from leading with consumption, and enterprise contracts can combine commitments, platform fees, and negotiated usage rates in different ways. But for an ongoing assistant, agent, or coworker, asking customers to begin with a wallet is probably the wrong abstraction.

## What we learned

### The tl;dr:

- **Our cost unit was not the customer’s buying unit: **Credits mapped cleanly to variable AI costs, but customers were deciding whether they wanted an ongoing assistant, not whether they wanted a batch of inference.
- **Subscriptions made the value legible:** A recurring plan could package compute, storage, capabilities, and included monthly credits into a promise customers understood.
- **Manual top-ups created repeated friction:** Each depleted balance interrupted the workflow and forced another purchase decision.
- **Credits still matter:** They remain the right primitive for transparent usage accounting, budgets, overages, and provider-cost pass-through.
- **The durable model is hybrid:** Plans lead the purchase decision; visible credits handle included usage, top-ups, and granular metering.
- **Sequence the complexity:** Sell the capability first. Explain the meter clearly when the customer needs operational control.

Our mistake was assuming the best cost-accounting unit would also be the best monetization unit. We exposed the system in the unit that made the most sense to us as builders, then asked customers to translate it into value themselves. 

Subscriptions worked better because they handled that translation at the moment of purchase. They let us describe the thing customers actually wanted, a capable system they could depend on every month, while credits remained visible for the usage decisions that came after.

Credits still answer an important question of how much variable work did the system consume. They just should not have to answer the bigger one.

For AI products like ours, the pattern is straightforward: make the subscription the promise, and let usage accounting keep the promise economically honest.