Claude API Revenue Models Compared — Pay-per-Use, Subscription, One-Shot, and Revenue Share for Indie Developers

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.

Here is the shape of the conclusion up front — the four models scored on what an indie developer actually worries about first.

The "tracks your cost" column is the AI-specific one. In ordinary SaaS, it simply never came up.

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.

Pricing your model against the September 1 change

Everything above assumes your unit cost stays where it is. It does not. The Sonnet 5 introductory promotional pricing ($2 in / $10 out per Mtok) ends on August 31, 2026, and standard pricing of $3 / $15 takes over on September 1. On the sticker, that is a 1.5x increase.

That 1.5x understates what you will actually pay. Sonnet 5's updated tokenizer maps the same content to roughly 1.0x–1.35x as many tokens. Rate increases and token inflation compound — they multiply, they don't add.

So that you can check it against your own numbers, here is the calculation as a script rather than a claim.

# Break-even for a pricing model, including both the rate change and tokenizer inflation
PROMO = {"in": 2.0,  "out": 10.0}   # through 2026-08-31
STD   = {"in": 3.0,  "out": 15.0}   # from 2026-09-01
 
def cost_per_req(price, tok_in, tok_out, infl=1.0):
    """Actual cost per request in USD. infl = tokenizer inflation factor."""
    return (tok_in * infl / 1e6) * price["in"] + (tok_out * infl / 1e6) * price["out"]
 
def breakeven_requests(plan_usd, target_margin, price, tok_in, tok_out, infl=1.0):
    """Max monthly requests per user that still hits your target gross margin"""
    api_budget = plan_usd * (1 - target_margin)
    return int(api_budget // cost_per_req(price, tok_in, tok_out, infl))
 
# A request size typical of summarization features: 4,000 in / 800 out
for label, price, infl in [("promo", PROMO, 1.00), ("std", STD, 1.00),
                           ("std x1.18", STD, 1.18), ("std x1.35", STD, 1.35)]:
    c = cost_per_req(price, 4000, 800, infl)
    n = breakeven_requests(5.0, 0.70, price, 4000, 800, infl)
    print(f"{label:10s} 1req=${c:.6f}  breakeven={n} req/user/mo")

Running it at 4,000 input and 800 output tokens per request gives this.

At the top of the inflation range, your real cost slightly more than doubles. Budget from the sticker difference alone and you will read the September invoice twice.

Leaving your caps untouched quietly eats the margin

Same conditions, now solving for how many requests a $5/month plan supports at a 70% gross margin.

A plan sized around "93 requests keeps us at 70%" now tops out between 46 and 62. If you carry your existing caps into September unchanged, the difference comes straight out of gross margin. If you would rather not raise prices, revise the caps first — that is the honest lever.

Your heaviest user gets heavier by the same multiple

Hidden heavy users were already the danger in subscriptions. After the change they cost proportionally more. Below: 1.18x inflation, $5/month, 70% target margin, with a light user defined as 30 requests per month.

At 100 paying members, a single person sending 3,000 requests a month erases that month's gross margin. That is why I said caps are not a nice-to-have — without them the model does not close.

Where to set your markup on pay-per-use

I said 2.5x–4x of actual cost earlier. Here is the arithmetic behind it, with Stripe's processing fee taken at 3.6%.

At 2x, one support thread and one refund wipe out the month. I treat 2.5x as the practical floor.

Before the date passes

• Check which rate applies to a billing cycle that straddles September 1
• Measure token counts on your own prompts rather than assuming the 1.35x upper bound
• Update plan caps and per-unit prices before the change and announce them — retroactive increases convert directly into cancellations

Prices and deadlines move, so confirm the current numbers on the Anthropic pricing page before committing a design. The formulas above keep working; you only swap the rates.

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 came to this from a world where unit cost was fixed, so Pattern 1 was the one I admired at first. What I actually settled on was Pattern 2, and the reason had nothing to do with revenue: pick the model your future self can sustain, not the one with the highest theoretical revenue. What wore me down was not small numbers — it was not knowing my gross margin until the invoice arrived. 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.