AI App Unit Economics: API Costs, Credits, Pricing and Margin

AI apps have a variable cost attached to the value-producing action, so more engagement can make the product less profitable unless pricing and controls scale with usage. A conventional utility app may pay mostly fixed engineering and infrastructure costs. An AI assistant, image generator or video-analysis app can incur another model charge every time a user asks for value. Growth therefore increases revenue and cost at the same time.

This changes the founder's first question. It is not simply, “How many subscribers can we acquire?” It is, “How much contribution remains after each subscriber uses the product?” The gap matters because the user who buys a monthly plan and makes ten requests is economically different from the user on the same plan who makes one thousand. A subscriber count treats them as equal; a cost ledger does not.

The market evidence makes this distinction more urgent. RevenueCat's State of Subscription Apps 2026 analysis, based on more than 115,000 subscription apps and over $16 billion in tracked revenue, reports higher realised Year-1 LTV for AI apps alongside materially worse 12-month retention for monthly AI plans. That does not prove every AI app has poor economics. It shows why premium pricing or early revenue cannot be mistaken for durable value.

Across our app portfolio, we separate product demand from economic quality before recommending more acquisition. If users love an AI feature but the cost-to-serve distribution is unknown, scaling paid traffic magnifies an unmeasured liability. The safe sequence is instrument the action, price the action, observe the tail, then scale.

Calculate AI app contribution from recognised net revenue after every cost that moves with a user, transaction or generated output. Do not begin with the App Store price and call the remainder “profit”. Taxes, store terms, refunds and consumption all sit between the sticker price and the money available to operate the company.

Recognised net revenue
− store or payment fees
− refunds, chargebacks and credits returned
− model inference and tool calls
− safety, moderation and retry costs
− variable storage, delivery and egress
− usage-driven support or fulfilment
= contribution dollars

Contribution margin % = contribution dollars / recognised net revenue

Use the exact payout basis from finance rather than assuming every platform takes one universal percentage. Apple offers qualifying developers a reduced 15% commission through the App Store Small Business Program, while its subscription terms and alternative regional terms can produce different economics. Google likewise says there is no single service fee and publishes programme- and transaction-specific rules in its service-fee documentation. Record the effective fee observed for each storefront and product instead of hard-coding folklore.

Keep contribution margin separate from company gross margin and operating profit. Contribution is the decision layer for a plan, feature or cohort: should we sell more of this unit under these conditions? Payroll, office costs and most product development do not vary one-for-one with a request, so keep them below this line when diagnosing usage economics. They still matter to the business, but mixing them into request cost makes routing and pricing decisions harder.

There is no credible universal margin target for all AI apps. A consumer image toy, an enterprise document agent and a clinical transcription workflow have different support, risk and acquisition structures. Choose a required contribution margin from your own cash needs, payback window and reinvestment plan; then solve backwards for the usage allowance and price that can support it.

Cost the complete product action from the user's tap to the accepted result, including every hidden retry and supporting service. Provider rate cards are inputs to the calculation, not the calculation itself. A chat answer may involve prompt assembly, retrieval, two model calls, a search tool, moderation and a retry. An image the user keeps may require several generations. A video report may combine upload, storage, transcription, frame analysis and a final written summary.

For token-priced models, start with the provider's billed usage categories. OpenAI explains that input, cached input, output and reasoning tokens can be accounted for differently, and warns that visible response length does not reveal total usage; its token accounting guide is the useful implementation reference. Anthropic's current Claude pricing documentation similarly separates base input, cache operations and output. Google lists token, caching, tool and modality charges in its Gemini API rate card. Prices were checked on 29 August 2026; founders should fetch them again before publishing a plan.

Action cost =
  uncached input tokens × input rate
+ cached input tokens × cached rate
+ output and reasoning tokens × output rate
+ tool calls
+ media generation or processing
+ moderation and safety calls
+ retry and fallback cost
+ variable storage and delivery

Create one cost event for every provider response and join it to a product-action ID. Store the provider, model version, rate-card version, billed units, latency, result status and whether the result was accepted. The product action is the unit the founder understands; the provider request is the unit engineering needs. Keeping both lets you answer why “Generate report” became expensive without losing the request-level cause.

Do not charge failed attempts blindly to either the company or the user. First classify them. A provider error is normally a company cost and should not consume a customer credit. A valid output that the customer dislikes may be a product-quality issue. Repeated regenerations after acceptable outputs may be genuine preference or abuse. Those states require different product rules even when the invoice records identical API spend.

Calculate cost separately for activated users, active users, trial users and paying users because each denominator answers a different business question. “API spend divided by monthly active users” is a useful top-line health check, but it hides whether free users, trials or a small payer segment created the bill.

Cohort the numerator and denominator over the same period. If a user starts a trial in August but generates most outputs in September, a calendar-month average can assign the cost to one group and the revenue to another. A cohort ledger follows the user from activation through renewal, cancellation and refund, while a calendar ledger manages cash and vendor invoices. You need both views.

Mark free allowances as acquisition or activation cost instead of pretending they are free. The right question is whether the expected contribution from converted and retained users covers the inference consumed by everyone who does not pay. This connects directly to our ROAS and CAC framework: trial compute belongs in customer acquisition economics, even when no ad platform generated it.

For a new product with little history, begin with explicit assumptions and replace them weekly. Estimate actions per activated user, conversion, paid usage, retry rate and refund rate. Label every figure as an assumption, observed value or provider rate. The model becomes decision-grade as observed fields replace guesses.

The median tells you what a typical user costs, while p90 and p99 reveal whether the plan survives its most engaged or abusive users. AI usage distributions are often skewed: many people try the feature once, a smaller group builds a habit, and a tiny group automates or repeatedly regenerates. An average blends these behaviours into a customer who does not actually exist.

For every plan and lifecycle state, sort users by monthly variable cost. The p50 value is the cost at which half of users sit below and half above. p90 means nine in ten cost no more than that value; p99 exposes the extreme tail. Also record the share of total cost consumed by the top 1%, 5% and 10% of users. Percentiles describe individual risk; concentration describes portfolio risk.

Suppose a plan leaves $10.20 after a hypothetical $12 price and 15% store fee, before other costs. If the all-in action cost is an illustrative $0.014, then 60 monthly actions cost $0.84, 240 cost $3.36, and 900 cost $12.60. The median user may look excellent while the p99 user is negative before support, storage or acquisition. These are teaching assumptions, not market benchmarks.

Do not respond by automatically blocking every heavy user. A p99 user may be the product's strongest advocate, an enterprise lead or evidence that a higher-value workflow exists. Segment the tail into healthy power use, accidental loops, quality-driven retries, credential sharing and automation. Each segment suggests a different answer: a higher tier, bulk credits, better output quality, concurrency controls or enforcement.

Different AI modalities need different billable units, but all three examples reach the same conclusion: sell the value unit users understand and map it internally to volatile provider costs. The following scenarios are deliberately illustrative. Their prices, usage and costs are assumptions for modelling—not benchmarks or quotations from a provider.

For a hypothetical text assistant, assume $12 monthly gross revenue, 15% store fee and $0.014 all-in cost per completed answer. A 200-answer allowance would consume $2.80 if fully used, before refunds and support. The founder should then test whether that allowance makes the product useful, whether most payers reach it, and whether top-ups feel natural when it is exhausted.

For an image product, imagine the accepted image costs $0.096 after generation attempts and processing. A pack of 40 accepted images creates $3.84 of variable generation cost; 150 create $14.40. A flat low-priced “unlimited” plan transfers both quality-retry risk and power-user risk to the founder. Credits make the cost boundary visible, but the app should restore a credit when its own system fails.

For a video coach, price in minutes or sessions because users cannot reason about frames, audio tokens and summary tokens. If the illustrative blended cost is $0.05 per analysed minute, 120 minutes cost $6 while 600 cost $30. The plan can include a monthly minute pool, offer extra packs and route short feedback through a cheaper path.

The same design applies if Vmobify's GPS Map Camera Timestamp Photo app later adds an AI-generated field-report summary. The existing product value—capturing timestamped evidence—should not become dependent on a costly model call. Meter the new report action, not the core camera utility. That keeps the free or paid capture experience predictable while exposing the genuinely variable feature as a separate economic unit.

Choose the pricing model that matches how users perceive recurring value and how your marginal cost behaves; for many consumer AI apps, a subscription with included credits and paid top-ups is the safest starting design. It gives the customer a predictable base price, gives the founder recurring revenue and creates an explicit boundary when usage becomes expensive.

Do not use a lifetime plan to fund a feature with an uncapped perpetual API obligation unless the AI usage is separately metered. The sale is collected once while inference continues indefinitely. If a lifetime tier is strategically useful, define what is lifetime—perhaps the non-AI editor, local processing or a fixed founding credit grant—and price future cloud generation separately.

Credits should correspond to customer value, not expose the provider's implementation. “One standard image” or “ten analysed minutes” is clearer than “18,000 tokens”. If different actions have very different cost, publish a simple rate card inside the app. Avoid a currency whose exchange rate changes without explanation whenever you switch models.

Use our mobile app monetisation playbook to choose the broader business model, then the in-app purchase pricing experiment guide to test price and packaging without confusing a model change for a price effect. One experiment should alter one economic assumption at a time.

Set a limit by solving backwards from net revenue, non-AI variable cost, action cost and the contribution margin your business needs. This produces an economic ceiling. Product research then decides whether that ceiling is generous enough to deliver the promised outcome.

Contribution required = recognised net revenue × required contribution margin

Maximum included units =
  (recognised net revenue
  − non-AI variable cost
  − contribution required)
  / cost per successful unit

Use conservative inputs: p90 action cost rather than the cheapest observed request, a realistic retry factor, and the effective store fee for the cohort. Then run sensitivity cases for provider price increases, currency movement, lower renewal, higher refunds and heavier usage. A limit that works only in the optimistic case is not a limit; it is delayed loss.

“Unlimited” should mean what a reasonable customer thinks it means. A hidden fair-use ceiling, undisclosed throttling or arbitrary queue demotion creates support cost, refunds and distrust. If legitimate infrastructure constraints exist, describe them before purchase: concurrency, monthly fast generations, file duration, resolution or a clearly stated fair-use policy. Google Play's subscription policy requires transparent pricing and sustained recurring value, and prohibits deceptive purchase experiences.

Give users a usage meter, warnings before exhaustion and an explanation of what consumes a unit. Show the renewal date and whether unused credits roll over. When the service fails, restore the unit automatically. When the user requests another valid result, charge according to the published rule. Predictability is part of the product value.

Protect costly actions with server-side entitlements, quotas, idempotency and risk signals; client-only limits are interface decoration, not economic control. A modified client can bypass a local counter, replay requests or extract a provider key. The mobile app should request an action from your backend, and the backend should decide whether the account is entitled, within quota and low enough risk to proceed.

1. Keep provider credentials on the server. Never ship a reusable AI API key in Android or iOS code.
2. Reserve quota atomically. Check and reserve the unit before inference so concurrent requests cannot spend the same balance.
3. Use idempotency keys. A network retry for the same action must not trigger a second paid generation.
4. Bind expensive requests to identity and device risk. Combine account age, payment state, velocity, network patterns and app-attestation signals.
5. Return or finalise the unit by outcome. Restore it for your infrastructure failure; finalise it for a successfully delivered result.
6. Review before hard blocking. Start with telemetry, challenges or slower queues so legitimate edge cases are not punished blindly.

On Android, the Play Integrity API can help the backend assess whether requests come from a recognised app, Play-licensed account and genuine device, and it includes signals for anomalously high recent device activity. Google explicitly recommends using the verdict as one signal in a tiered anti-abuse strategy, not as the only mechanism. On iOS, Apple's DeviceCheck and App Attest documentation supports app-integrity assertions and limited per-device state useful for promotional-offer abuse.

Do not rely on a device fingerprint as if it were a person. Families share devices, people replace phones, privacy controls change identifiers and fraudsters rotate accounts. Use a risk score and proportional responses: smaller trial allowance, payment verification, cooldown, CAPTCHA, manual review or a hard deny for the clearest automated attack.

Track abuse cost separately from healthy p99 use. Otherwise the founder may shrink the plan for every paying power user when the actual problem is a small automated cohort. For broader acquisition and install manipulation risks, link the operational controls into the mobile ad-fraud prevention framework.

Reduce cost by routing each task to the least expensive path that still passes a product-specific quality test. Switching every request to a cheaper model can save invoice cost while increasing retries, churn and support. Optimise accepted outcomes, not tokens in isolation.

• Route by difficulty: use rules or a small model for classification and simple transformations; escalate only tasks that need deeper reasoning or richer media.
• Reduce repeated context: summarise old conversation state, retrieve only relevant documents and use provider caching where the workload has stable prefixes.
• Cap output deliberately: many product actions need a concise answer, not the model's maximum response.
• Batch non-urgent work: asynchronous reports, enrichment and evaluations may qualify for lower-priced batch processing. Anthropic documents a 50% token discount for its Batch API, while Google publishes separate Batch and Flex rates; verify the current rate and latency before routing.
• Cache deterministic product results: do not regenerate the same safe output when inputs and model version are unchanged.
• Fix the quality loop: better prompts, validation and user controls can reduce costly regenerations more than a rate-card negotiation.
• Move eligible work on-device: local rules, OCR or smaller models can remove cloud cost and improve privacy where device capability and quality are sufficient.

Create an evaluation set from real product actions before changing models. Score task success, safety, latency, accepted-result rate and cost per accepted result. Run the old and new route against the same cases. A model that costs half per call but requires twice as many attempts has not improved the unit economics.

Track orchestration depth for agentic features. A single user request can create a loop of model calls and tools whose intermediate reasoning is also billed. Google's current pricing documentation explicitly says managed-agent inference includes intermediate inputs and reasoning tokens, with tool fees applied separately. Set maximum steps, maximum spend per run and a human-readable stop reason.

In our portfolio reviews, the most useful cost optimisation is often a product decision: which result does the customer actually need? Removing an unnecessary high-resolution generation or repeated “polish” pass can improve speed and margin simultaneously. Infrastructure optimisation matters, but product clarity decides how much infrastructure is required.

Model cash only after the store, tax and refund state are known, while recognising that inference may already be irrecoverably spent. An AI app can pay for a trial session or generation, refund the customer later and receive no corresponding refund from the model provider. That is why refund rate and compute-before-refund must appear in the same cohort ledger.

Do not use a universal “Apple and Google take 30%” assumption. Apple says eligible Small Business Program members receive 85% of subscription price minus applicable taxes at each billing cycle, while other subscription and regional arrangements differ. Google currently publishes 15% for automatically renewing subscription products in its general service-fee table, but 2026 regional and programme changes make transaction context essential. The implementation should store gross proceeds, tax, store fee, net proceeds and storefront—not infer net from a single global constant.

Google's official order and refund documentation explains that developers can issue full or partial refunds, that cancelling does not itself issue a refund, and that “refund and revoke” can remove subscription access immediately. Entitlements must follow the actual purchase state. The cost ledger, however, retains the inference already consumed before revocation.

Separate four failure classes. Provider failures restore the customer's credit and remain company cost. App transport or orchestration failures do the same. Safety refusals follow the disclosed product rule, because some represent correct service behaviour and others indicate a poor promise. User-requested regeneration after a delivered valid output normally consumes another unit unless your quality policy says otherwise.

Add a refund reserve to pricing rather than treating every refund as an exceptional surprise. Use your own cohort's observed rate; do not borrow an unrelated app benchmark. Review support tickets behind refunds to distinguish price shock, poor output, accidental purchase, misleading allowance and abuse. Each cause has a different fix.

The dashboard should connect every customer plan and lifecycle cohort to accepted outcomes, variable cost and recognised net revenue. A provider invoice alone cannot tell you which feature, plan or user segment produced the spend. Product analytics alone cannot tell you whether engagement was economically healthy.

At minimum, log: account and anonymous-user identifiers; plan and entitlement state; product action; provider and model version; input, cached, output and reasoning units; tool calls; latency; provider charge; retry chain; result status; customer acceptance; credits reserved, finalised or restored; platform; storefront; gross proceeds; effective fee; refund; and abuse decision. Do not put sensitive prompt content into analytics merely to improve a finance chart.

Build five operational views: daily provider spend versus budget; unit cost by product action and model; p50/p90/p99 monthly cost by plan; contribution by activation or purchase cohort; and failed-generation/refund/abuse cost. Alert on rate-card drift, cost per accepted result, tail concentration, repeated retries and contribution turning negative for a plan.

Assign an owner and response to every alert. Finance can own effective net revenue, engineering can own metering and rate-card versions, product can own accepted-result and retry quality, and growth can own trial cost against converted retained value. A dashboard without a decision owner becomes an expensive wallpaper.

Connect this ledger to the mobile app LTV/CAC calculator. LTV for an AI payer should be contribution-based, not gross-revenue-based. Otherwise a heavy-use cohort can appear more valuable because it pays longer while quietly consuming nearly all of the revenue in inference.

Treat provider price, tokenisation, model behaviour, availability and tool billing as versioned dependencies with tested fallbacks. A model alias can change, a promotional price can expire, a tokenizer can alter billed volume, or a new reasoning mode can create more hidden output. The response is not to predict every change; it is to make the economic effect observable and reversible.

1. Version the rate card. Store provider, model, region, service tier, unit rates, currency, collection date and source URL.
2. Pin production model versions where supported. Test aliases before adopting the new behaviour.
3. Maintain a shadow evaluation. Run representative tasks against the candidate route and compare quality, cost and latency.
4. Set a per-action spend ceiling. Stop agent loops and oversized media jobs before one request becomes an open liability.
5. Keep a degraded mode. Queue the task, use a smaller model, disable an optional enhancement or offer a transparent retry rather than failing the whole app.
6. Review pricing every quarter. This pillar is classified for a three-month freshness review because rate cards and store programmes change quickly.

Run four sensitivities before launching a plan: provider unit cost rises; usage shifts from median towards p90; refunds increase after compute is consumed; and currency moves against your billing currency. Then test the opposite case: a cheaper model arrives. Decide whether the gain funds a larger allowance, stronger margin or lower price instead of passing it through accidentally.

Keep customer promises independent of vendor names. Sell a reliable field report, image, lesson or answer—not permanent access to a particular model. This lets the team route for quality and economics without rewriting the paywall whenever the underlying stack changes.