AI App Gross Margin Calculator: Per-User Margin After Model Cost and Payment Fees

You priced your AI tool at Rs 499 a month because it felt right. Then a user sent 6,000 requests in a week. AI app gross margin per user is what stops that being a surprise: price, minus payment fees, minus model cost for what they actually use. The formula is three lines. The useful part is running it per usage tier and finding the request count where you stop making money.

The short answer: for a Rs 499 plan on a mid-tier model, the median user can be comfortably profitable and the heavy user deeply negative, as the output below shows. Below is a script I ran, prices read from vendor pages on 2026-10-09, and a way to turn the result into a request cap. If you haven't yet worked out what one request costs, start with LLM API cost per 1,000 requests.

The formula

gross margin per user = price
                      - gateway fee (rate x price, plus 18% GST on that fee)
                      - model cost (requests x cost per request x FX rate)
                      - other per-user costs (email, storage, support tooling)

margin % = gross margin per user / price

"Gross" margin here means variable costs only. It leaves out your salary, hosting base cost, and marketing. You need those for profit, but gross margin is the number that tells you if each extra user helps or hurts.

Inputs I used and where they came from

A caution on the Razorpay figure. The page content reached me through a summarising fetch, so check the exact wording yourself. It listed standard domestic cards and netbanking at 2 percent, said UPI had zero MDR but that the 2 percent platform fee applied, and put international cards at up to 3 percent. Whether UPI really carries a 2 percent fee for your account is something to confirm on your dashboard, because the page text read oddly on that point. Cashfree's pricing page returned an access error on one URL; another Cashfree page, again as summarised, listed 1.95 percent and 2.0 percent without clear labels for which payment mode each applied to, and 2.99 percent for international Visa and Mastercard cards. On my editing pass the same day, the Razorpay page also advertised a promotional 0 percent fee for the first 90 days, and the Cashfree page showed a limited-period headline of 1.95 percent for sales up to Rs 20 lakh (festive offer to 31 March 2027). Promotions end, so I'm treating both as inputs to replace with your actual contract rate. Our Cashfree vs Razorpay comparison covers the other differences.

Some links on this page are affiliate links; they cost you nothing and I only link tools I'd mention anyway. If you don't have a gateway yet, Razorpay is one of the two common options in India. Cashfree is the other, and both are fine for this calculation. The numbers matter more than the choice.

The script

Python 3, standard library only. Replace the dictionaries with your own prices and the profiles with token counts from your logs.

FX = 95.7            # INR per USD (assumption, not live)
GST_ON_FEE = 0.18

# (input $/MTok, output $/MTok, cache-read $/MTok)
MODELS = {
    "Haiku 5.5":  (0.10, 0.50, 0.01),
    "Sonnet 5.5": (2.00, 10.00, 0.10),
}

def llm_cost_inr(model, requests, fresh_in, cached_in, out):
    pin, pout, pc = MODELS[model]
    usd = requests * (fresh_in * pin + cached_in * pc + out * pout) / 1e6
    return usd * FX

def gateway_fee_inr(price_inr, rate):
    fee = price_inr * rate
    return fee + fee * GST_ON_FEE

def margin(price_inr, rate, model, requests, fresh_in, cached_in, out, fixed_inr=0.0):
    gw = gateway_fee_inr(price_inr, rate)
    llm = llm_cost_inr(model, requests, fresh_in, cached_in, out)
    gross = price_inr - gw - llm - fixed_inr
    return gw, llm, gross, 100 * gross / price_inr

What does the margin look like per usage tier?

Four invented usage profiles on a Rs 499 plan, each request 1,800 input and 250 output tokens, gateway at 2 percent plus GST. The profiles are illustrative; the arithmetic is real. Output of the script:

Plan Rs 499/month, gateway 2% + 18% GST on the fee, FX Rs 95.7/USD
profile                  model        gateway      LLM  gross Rs  margin%
light  (60 req/mo)       Haiku 5.5      11.78     1.75    485.47    97.3%
light  (60 req/mo)       Sonnet 5.5     11.78    35.03    452.20    90.6%
median (300 req/mo)      Haiku 5.5      11.78     8.76    478.47    95.9%
median (300 req/mo)      Sonnet 5.5     11.78   175.13    312.09    62.5%
heavy  (1,500 req/mo)    Haiku 5.5      11.78    43.78    443.44    88.9%
heavy  (1,500 req/mo)    Sonnet 5.5     11.78   875.66   -388.43   -77.8%
abuser (6,000 req/mo)    Haiku 5.5      11.78   175.13    312.09    62.5%
abuser (6,000 req/mo)    Sonnet 5.5     11.78  3502.62  -3015.40  -604.3%

Three things stand out.

• The gateway is the small cost. Rs 11.78 on a Rs 499 plan, about 2.4 percent. The model is what moves the margin.
• Model choice swings the picture by an order of magnitude. The heavy user is at 88.9 percent margin on Haiku 5.5 and minus 77.8 percent on Sonnet 5.5, for the same plan. Test whether the cheaper model is good enough for the job before you set a price.
• Averages hide the loss. If your median user is at 62.5 percent and one heavy user costs you Rs 388, it takes about 1.2 median users' margin to cover that one account, and the abuser row needs nearly 10.

Where is the break-even request count?

Solve for the request count where gross margin is zero:

Break-even requests per month (gross margin = 0), Rs 499 plan, 1,800 in / 250 out:
  Haiku 5.5   Rs 0.0292 per request -> 16692 requests
  Sonnet 5.5  Rs 0.5838 per request -> 834 requests

On Sonnet 5.5, a user past 834 requests a month loses you money, which is under 28 requests a day. That number is your real product limit, whatever the pricing page says.

How do you turn a target margin into a request cap?

Pick the margin you need, work out the model budget, divide by cost per request:

Request cap for a 70% target margin (Sonnet 5.5, Rs 499 plan):
  LLM budget per user Rs 137.92 -> 236 requests/month

So if you want a 70 percent gross margin on Sonnet 5.5 at this price, cap the plan near 236 requests a month, or sell credits beyond that. The 70 percent target is an example, not a benchmark. Choose yours from how much you need to cover support, hosting and your own time.

Enforcement matters as much as the number. A cap in the pricing table without a limiter in the code is just a wish; see rate limiting a free tier AI app for a token bucket, per-user budget and global breaker you can adapt.

How sensitive is it to the gateway rate?

Gateway rate sensitivity on a Rs 499 plan (fee incl. 18% GST on fee):
  rate 1.95% -> Rs 11.48
  rate 2.00% -> Rs 11.78
  rate 2.99% -> Rs 17.61

The gap between the headline domestic rate and an international card rate is about Rs 6 on this plan. It matters more at low prices: on a Rs 99 plan the same percentages work out to a few rupees, but any fixed per-transaction charge would loom larger. Check whether your gateway adds a flat fee.

If you take recurring payments through UPI Autopay, there can be a per-debit charge instead of, or on top of, the percentage. Cashfree's page, as summarised on 2026-10-09, listed Rs 7.5 plus Rs 5 for an auto-debit under Rs 1,000. On a Rs 499 plan that is Rs 12.50, about 2.5 percent of the price before GST on that fee. I couldn't confirm how Razorpay prices the same thing from the pages I read, so check your own quote.

Ways to improve the margin without raising the price

In rough order of effort:

1. Move easy requests to a smaller model. The Haiku versus Sonnet rows above are the biggest lever in this post. See AI model routing.
2. Cache the stable prefix. On the pricing page, a cache read costs a fraction of normal input. It only helps if a big chunk of each prompt is the same; see prompt caching.
3. Trim retrieved context and output length. Output is the expensive side of every price in the table.
4. Cap or meter the heavy tail. Credits, fair-use limits or a higher tier for power users. Our AI wrapper SaaS playbook covers the wider business side.
5. Raise the price for the segment that uses the most. Often cheaper than engineering around it. The credits model post covers selling usage instead of a flat plan.

A checklist before you set a price

1. Pull a week of real usage data (input, output, cached) per user from your API logs.
2. Compute cost per user at the median, 90th and 99th percentile, not just the mean.
3. Run the script with those profiles and your actual gateway rate.
4. Find the break-even request count for your model, and the cap for your target margin.
5. Decide what happens at the cap: block, slow down, or sell credits.
6. Re-run when you change the model, the prompt, the retrieval depth or the vendor price. Vendor prices change, so the table above is a snapshot from 2026-10-09.

Not covered here: tax treatment, refunds and chargebacks (which also eat margin, see the refund policy template), and the cost of free-tier users who never pay. Treat the free tier as a marketing expense with a budget, and cap it.