The first time I tried to ship a small SaaS on top of Claude API, I spent two full days completely stuck — not on the API, but on a single question: how do I charge for this? The exact same product can succeed or fail depending on whether you charge monthly, per token, or as a one-time purchase. The numbers differ, but more importantly, so does how mentally exhausting the business becomes after a few months.
This article compares the four pricing models you'll most often see in Claude-powered services: pay-per-use, subscription, one-shot, and revenue share. I'll write from the perspective of an indie developer — someone who can't afford to redo their billing system every quarter.
Why pricing model decides profitability for AI services
What makes Claude-powered products structurally different from "normal" SaaS is that variable cost scales with users × token consumption, not just user count. If your users send ten short messages a day, your costs are negligible. But a single power user sending long-context summaries every hour can wipe out the margin from your other 100 customers.
If you copy a $10/month SaaS pricing template into an AI product, the moment a heavy user signs up, you go negative. On the flip side, if your audience is casual users and you charge per token, the psychological friction kills conversion. Nobody signs up to a service where the bill is unpredictable.
So the first thing to do is imagine your users — what do they do, how often, and how heavy is each request? Then pick a model that survives that distribution. I got this wrong on my first product, and it cost me three months.
Model A — Pay-per-use: the cleanest, the trickiest
Charge users by request count or generated tokens. This is exactly what Anthropic does at the API layer, so the structure is the most economically aligned: your revenue scales with your costs.
When pay-per-use fits
- Developer or B2B tools where users already expect metered pricing
- Chatbots or summarizers where per-request value is easy to estimate
- API resellers thinly wrapping Claude API for downstream apps
The trap
Consumers hate unpredictable bills. Even enterprise buyers have a hard time getting an unpredictable amount approved through procurement. If you go this route, you must build a real-time "estimated bill this month" dashboard. Stripe's usage-based billing handles the metering, but the UX is your job.
In my own experience, "I can't see what I'll pay" is one of the top three churn reasons in AI products. Skip the dashboard and you're shipping a stress generator, not a service.
How to set the markup
Use Anthropic's pricing page as your raw cost basis, then add overhead for system prompts, tool-use loops, and prompt prefixes you bake in. As a rule of thumb I land at 2.5× to 4× actual cost before margin appears after support, refunds, and Stripe fees. Anything thinner gets eaten alive.
For careful per-request cost modeling, see Claude API token counting and cost optimization guide.
Model B — Subscriptions: predictable revenue, hidden danger
A flat monthly fee for a "Pro" or "Premium" plan, with internal usage caps. This is how Claude.ai itself, ChatGPT Plus, and most consumer AI products work. It's by far the most stable revenue model because predictability is what consumers crave.
When subscriptions fit
- Consumer-facing products where price predictability is the whole pitch
- Tools with uniform usage like translation, proofreading, summarization
- Indie devs who want MRR visibility — knowing your number this month and next is psychologically huge
The required defense: hidden heavy users
Pure unlimited monthly plans die the moment one user sends 100k tokens a day. You need at least one of these mechanisms:
// Soft-block when monthly token quota is exceeded
async function checkMonthlyQuota(userId: string): Promise<boolean> {
const usage = await getMonthlyTokenUsage(userId);
const plan = await getUserPlan(userId);
if (usage.input + usage.output > plan.monthlyTokenCap) {
// Show "limit reached" UI, route them to top-up purchase
return false;
}
return true;
}This "cap + sell additional tokens" pattern is now industry standard. Anthropic's Pro and Max plans follow it. Truly unlimited plans are something an indie developer should never offer.
Realistic price tiers
On my own sites (Dolice Labs), I run a Pro tier around $5/mo plus a lifetime Premium option. Pairing a subscription with a one-time purchase recovers users who are subscription-fatigued — a much larger group than developers tend to assume.
Model C — One-shot purchases: the easiest entry
A single payment delivers a single result, feature, or piece of content: "$5 to translate this resume," "$8 to get the AI-generated analysis of this document." Stripe Checkout in mode: 'payment' handles it in a few hours of work.
When one-shot fits
- Self-contained tasks the user only needs once
- Content products like reports, briefs, generated artifacts
- Audiences that hate subscriptions — creators, students, occasional users
Why it's the right starting point for indie devs
You skip every painful subscription detail: cancellation flows, prorations, dunning. If this is your first time building paid software, start here. The same product can graduate into a subscription later once you understand your users' real frequency.
The trap
LTV plateaus. Without a follow-up funnel, you have to keep filling the top of the funnel forever. Build a "one-shot → adjacent one-shot → subscription" ladder from day one, not as an afterthought.
Model D — Revenue share and affiliate income
You don't charge users directly. Instead, the AI-generated content (comparisons, recommendations, reviews) drives affiliate revenue or commission.
When it fits
- SEO-driven content sites monetizing search traffic
- Open-access generators that need a low-friction front door
- Existing media presences (YouTube, blogs) layering AI content on top
My honest take
Affiliate income alone almost never covers Claude API cost on its own. A typical article earns a few cents to a few dollars while costing real tokens to generate. As a sole revenue model, this loses money.
But as a secondary revenue stream layered onto a subscription or one-shot product, it works beautifully. On my sites, free articles end with affiliate book links, while the actual revenue comes from membership. The lesson: stack two or three models so the math closes.
Common combinations indie developers end up with
In practice almost nobody runs a single pure model. Three combinations dominate.
Pattern 1: Subscription + metered overage The Claude.ai-style structure. Most stable revenue, but hardest to implement well. Probably overkill for a first product.
Pattern 2: Free reading + one-shot purchases + Pro subscription (media model) This is exactly what I run. Articles are free; deeper guides are sold as $1.75 one-shots or a $5/mo Pro plan. SEO traffic ladders into one-time purchases, then into membership. Easy to start, scales surprisingly far.
Pattern 3: One-shot + affiliate (lightweight) For solo developers targeting low five figures a month, this is the gentlest path. No subscription management, no churn drama. I personally consider this the right starting point for first-time monetizers.
I've been shipping indie apps since 2014, and even after years of AdMob-driven mobile income, the lesson that holds up best in the AI era is the same one: pick the model your future self can sustain emotionally, not the one with the highest theoretical revenue. Building on Claude API is more tiring than building a normal app, because every request costs real money. Choose the pricing structure that lets you keep showing up.
For a step-by-step launch playbook covering Stripe implementation, SEO funnels, and pricing experiments, continue with the deep-dive: Indie Developer's Claude API SaaS Launch Blueprint.