AI API costs incurred to deliver a paid AI feature are a direct service-delivery cost. Calculate them per paying customer and include them in an operational cost-of-goods-sold (COGS) model. The formula is:
gross margin % = (net customer revenue − customer-level service-delivery COGS) ÷ net customer revenue × 100
Use revenue net of discounts, credits, refunds, and taxes collected on another party’s behalf. A model pricing page supplies unit rates. Your usage ledger supplies the customer’s input, cached input, output, tool, media, retry, and workflow quantities. You need both before the margin percentage means anything.
What counts as AI COGS?
For internal unit-economics decisions, include costs incurred to operate the delivered service:
- model input, cached-input, and output tokens;
- embeddings, image, audio, search, or other billed tool calls;
- per-job inference, GPU, transcription, or document-processing charges;
- paid retries and duplicate work;
- other per-unit infrastructure directly triggered by the workflow.
Allocate committed inference capacity or other fixed delivery infrastructure when it serves the product even if the invoice does not change with each request. Do not treat all company spending as COGS. General founder compensation unrelated to service delivery, product development, and administration belong elsewhere in the operating model. Direct support or service labour can require a different classification. Payment processing fees also vary by accounting policy. Formal financial statements require a consistent policy and may need an accountant; this article is an operational gross-margin model, not accounting advice.
If you subtract variable sales, support, or payment expenses beyond service-delivery COGS, label the result contribution margin rather than silently mixing the two measures.
LLM cost per user: calculate the numerator first
Model rates change. Use the current OpenAI API pricing or Claude API pricing for the exact model, feature, region, and processing mode used during the billing period.
Then normalize every quantity to the unit on the pricing page and calculate each completed workflow:
workflow cost = Σ(quantity ÷ quoted billing unit × quoted rate) + tool fees + per-job compute
If a provider quotes dollars per million tokens, divide token counts by 1,000,000 before multiplying by that rate. Sum workflow cost by customer and billing period. Add other direct service-delivery costs, then compare the total with net customer revenue for the same period. Keep rates versioned by effective date so a model switch does not rewrite the economics of historical usage.
The table below uses an illustrative blended cost of $0.007 per completed workflow on a $19 monthly plan. It is not a quote for a model, provider, or AxonBuild customer.
| User tier | Workflows/month | Blended cost/workflow | Monthly AI COGS | Revenue remaining after AI cost |
|---|---|---|---|---|
| Light | 100 | $0.007 | $0.70 | 96.3% |
| Typical | 800 | $0.007 | $5.60 | 70.5% |
| Heavy | 4,000 | $0.007 | $28.00 | -47.4% |
The last column subtracts only AI COGS, so it is not the product’s final gross margin. The light-user arithmetic is (19 − 0.70) ÷ 19 = 96.3%; the typical-user result is (19 − 5.60) ÷ 19 = 70.5%. For the heavy user, (19 − 28) ÷ 19 = -47.4%: the plan loses $9 before any other service-delivery cost.
Reading that number back is one query, assuming the endpoint already writes a usage record server-side:
// Reads back this billing cycle's model-call cost for one user,
// keyed to the authenticated session, never a client-supplied count:
async function costPerUser(userId, cycleStart) {
const usage = await db.usageEvent.aggregate({
where: { userId, createdAt: { gte: cycleStart } },
_sum: { costCents: true },
});
return (usage._sum.costCents ?? 0) / 100;
}Subtract that from the plan price and you have the per-customer number this whole post is about, updated every billing cycle instead of guessed at launch and never revisited.
A token rate is a unit price. Margin appears only after usage is grouped by customer.
The measured cost that never became a margin decision
The clearest example I have is my own: a document translation and reconstruction pipeline, one of the five founder apps that went through the identical audit AxonBuild runs for clients. Each job could fan out through four model calls. None set a maximum output-token limit, and an image-heavy document could create many paid OCR calls. The pipeline correctly measured what every job spent in model calls; the number was right there in the logs. What the application never did was compare that number to what the job was worth or use it to enforce a per-job budget.
This is primary evidence about one application, not a claim about the average AI product. Its unit-economics lesson is concrete: a correct usage number has no financial effect until the product compares it with the value and price of the job.
For document work, calculate at job level before rolling up to the customer:
| Job field | Evidence to store |
|---|---|
| Revenue | Net amount attributable to the job or included-plan allocation |
| Model cost | Provider usage by call, model, and pricing version |
| Other variable cost | OCR, storage transfer, GPU, or paid tool use |
| Retry cost | Attempts that billed without producing additional customer value |
| Contribution | Job revenue minus all variable job costs |
That table exposes a job that costs more than it earns even when the monthly average still looks healthy.
The cost line needs a ceiling
In the fixed third-party cohort, [12 of the 14 third-party apps had the identical gap at the outcome level](/blog/vibe-coded-apps-security-statistics/): a stranger or free account could trigger paid AI work without an effective ceiling. The implementations were not identical. This is a historical, lower-bound finding about a selected cohort, not an industry rate.
The COGS consequence does not require an attacker. A legitimate heavy customer, a worker retry loop, or a document with unusual fan-out can cross the same open limit. A monthly average hides the tail, so monitor at least customer, workflow, and feature level.
That capping-and-metering fix belongs to the earlier post; this one takes it as given. Here, the control is a cost budget derived from margin policy: the maximum variable spend allowed per workflow, account, and plan before work is refused, queued for approval, or billed differently.
Four ways to reduce AI API costs
1. Route each task to the least expensive model that meets its quality target
Classification, extraction, and short summaries may not need the same model as complex reasoning. Test quality on a fixed evaluation set, then route by task. A cheaper result that creates more retries or manual correction can raise total cost, so measure completed-workflow cost rather than token rate alone.
2. Reduce paid context and avoid duplicate work
Trim irrelevant history, retrieve only the context required for the task, and cache deterministic upstream results. Include cache-read and cache-write rates separately when the provider prices them differently. Use durable job identifiers so a retry resumes or reuses completed work instead of buying the same result again.
3. Batch work that does not need an immediate answer
Asynchronous processing can change the unit rate. OpenAI’s current Batch API documentation publishes a 50% discount with completion within 24 hours, while Anthropic’s current Message Batches documentation publishes batch pricing at 50% of standard API prices. These are volatile provider terms, so recheck them before using the discount in a forecast.
Batching fits reports, enrichment, evaluation, and background document processing. It does not fit an interaction where the customer needs an immediate response.
4. Enforce budgets before the call
Set a maximum per workflow, account, and billing period. Reserve the worst permitted cost before execution, record actual provider usage afterward, and release the difference. Alert before the hard stop so a valuable customer does not discover the policy from an unexplained error.
Every lever should be measured through the same customer-period ledger. Whether the bill arrives as an OpenAI invoice, an Anthropic key you pay directly, or credits, one platform’s name for this same bill, the four levers and the math behind them are identical. What a Base44 plan costs once users arrive is that same bill under a builder’s label.
What the model APIs charge, and why this page does not keep a price table
Read the rates off the provider, not off an article. Model prices change on the provider’s schedule, and a stale number inside a margin model is worse than no number, because it makes a broken plan look priced. Each provider publishes its own current rates: OpenAI, Anthropic, Google, xAI, Mistral, DeepSeek, and, for voice and audio work, ElevenLabs.
Take four things off whichever page applies to you rather than the headline rate alone: the billing unit the price is quoted in, which parts of a call are priced separately (cached input, output, batch, tool and search calls, image and audio), whether region or processing mode changes the rate, and how a prepaid credit converts into billed units. Those are exactly the inputs the workflow-cost formula earlier in this post expects.
What stays stable, and what this page keeps current instead, is the method: normalize each quantity to the provider’s quoted unit, roll the result up per customer per billing period, and compare it with net revenue for that same period. That arithmetic survives a price change. A copied rate table does not.
Keep COGS separate from metering and price design
Metering answers how many trusted units a customer used. Pricing answers what the customer owes for those units or plan. COGS answers what delivering them cost you. Combining the three into one number makes it hard to diagnose whether a bad margin came from expensive delivery, an overly generous allowance, or an incorrect meter.
Metering an AI feature has its own failure list, separate from this one: a meter that counts requests when the bill counts tokens, an allowance that resets on a different clock than the invoice, and usage records a customer can dispute because nothing server-side recorded them. Those are billing defects rather than margin defects, and they are worth fixing before you conclude the margin math is wrong.
The money-out side belongs beside the checkout paths that leak money coming in and the scale assumptions that fail under real traffic. Evidence for unit economics is also one part of whether an AI-built app is ready to launch.
Common questions about AI API costs
How much does an AI API cost per customer?
Multiply each customer’s measured input, cached input, output, tool, and workflow units by the rates effective when the calls ran. Add per-unit compute and paid retries. There is no reliable universal average because model choice, prompt size, output length, workflow fan-out, and customer behavior differ.
Are AI API costs COGS?
For operating analysis, model usage and the infrastructure directly required to serve the feature belong in customer-level service-delivery COGS. Allocate committed capacity consistently as well as per-unit charges. Accounting presentation can vary, especially for labour and payment fees, so use an accountant for formal reporting or tax treatment.
How do I reduce OpenAI or Anthropic API costs?
Route tasks to the least expensive model that passes a quality test, reduce irrelevant paid context, cache and deduplicate repeat work, batch delay-tolerant jobs, and enforce a cost budget before calls run. Recalculate margin after each change because a lower unit rate can be offset by worse quality or more retries.
Is a flat-rate AI plan a mistake?
No. It becomes a margin risk when usage is unmeasured, the distribution has an expensive tail, or the plan has no enforceable allowance. A flat plan can be healthy when measured customer-level COGS stays within the target margin across light, typical, and heavy cohorts.
When the app carries customer access or revenue
AxonBuild fixes the payment, billing, access, or data-handling failure, verifies the result, and adds a check that catches it before it interrupts the business again.
