The app had 80 users when Priya first showed it to friends. The monthly infrastructure bill was $12. A blog post brought in 4,000 sign-ups over a single weekend. By the following Friday, the same app was costing $1,840 a month, and the projected next-month total was four times that. Nothing had broken. Nothing was wasted. It is just that usage-based pricing rewards growth in a particular shape and punishes the wrong assumptions.
This is the guide for the planning conversation that should happen before that weekend, not after.
What "API cost" actually means in the wild
When people say API cost, they usually mean the running cost of all the services a product calls into, on a usage-based or hybrid plan. That can be the obvious things: the model provider, the third-party data API, the email sender. It can also include the platform layer that hosts the app: compute, database reads and writes, log ingestion, queue messages, egress bandwidth, storage. Most modern stacks have at least four meters running at the same time.
The two questions that matter are: which meter is the dominant one today, and which meter scales fastest with your traffic? Those are rarely the same line item, which is why post-launch bills surprise teams that planned around only one.
Fixed pricing vs usage-based pricing
A fixed plan charges the same amount regardless of usage, often with a soft cap on what you can do before being asked to upgrade. Usage-based pricing scales with what you actually consume: requests, tokens, gigabytes, seat-hours.
Neither model is universally better. Fixed plans give predictability and are kinder during slow months. Usage-based plans avoid paying for capacity you do not use, which is helpful for early-stage products with spiky traffic. The mistake is mixing them up in your head: assuming a usage-based bill will plateau like a fixed plan, or worrying about the fixed plan ceiling when nothing about your traffic is close to it. Read each line item carefully and label it before doing the math.
Requests per user: the hidden multiplier
Every cost projection starts here. A user is not a request. A single user can issue dozens or hundreds of requests during a session, especially in apps with auto-complete, polling, real-time updates, or AI-assisted writing.
If you charge yourself $1 per user per month in your head, but each user generates 200 requests, the per-request cost has to come in under half a cent to break even. That is a tighter constraint than most teams realize. The shape of the app drives this. A weekly report generator might be 4 requests per user per week. A code-suggestion editor can be 200 requests in a single coding session.
A useful exercise: log a representative power user for a single day and count the requests they actually generated. Use that number rather than an aspirational one.
Monthly active users and how their cost adds up
The standard mental model, "we have 10,000 users, so we cost 10,000 × X," usually overcounts. Not every registered user is active. Of those who do log in, only a fraction visit in any given month, and within that group, usage follows a long-tail distribution where roughly the top 10% drive the majority of the cost.
A better framing for planning: estimate monthly active users (MAU), then assume the active group splits roughly into a small group of heavy users (call them 10%), a middle band of regulars (40%), and an occasional band (50%). Multiply each band by an honest estimate of their requests, and combine. The result is usually far less alarming than a flat per-user model, and highlights that the cost of growth is dominated by the heavy band.
Reasonable cost planning also separates baseline cost (what the app costs when nobody is using it, due to idle infrastructure) from per-user cost (what each active user adds). Early on, baseline dominates. Past a certain scale, per-user cost takes over. The shape of your bill changes as you cross that line.
Overages, tiers, and the cliff effect
Usage-based plans rarely scale perfectly smoothly. Most providers offer tiers: a free quota, then a paid tier with a soft cap, then either overage rates or a hard cap.
The number to watch is the overage rate, because it is often expressed in a way that hides its size. $5 per million requests sounds tiny when your app makes 80,000 requests a day. Until your app makes 800,000 requests a day, and the same line reads $40 a day, $1,200 a month.
A cliff is when the next tier requires an annual commitment, a custom contract, or moves you to a different billing model entirely. Cliffs are not necessarily bad; they are simply features of the contract you should know about before you cross them. Plot your projected usage against the tiers explicitly. Knowing you are 70% into a tier is far calmer than discovering it after the fact.
AI tokens versus ordinary API calls
If your app uses a language model, you have two separate cost meters. There is the request cost (the API call itself, mostly negligible) and the token cost (the model usage, often the dominant line on the bill).
A traditional API call, such as fetching a weather report, sending an SMS, or looking up an exchange rate, has a flat or near-flat per-request price. Doubling traffic doubles cost roughly linearly.
A model call's price depends on what is inside the prompt and what comes back. A 200-word reply on Monday and a 2,000-word reply on Tuesday cost very different amounts, even if the input was the same. For a deeper look at how tokens are counted, the AI Token Calculator is the right starting point. The takeaway is that model bills move with content size, not just request count, and they deserve their own row in any projection.
Bandwidth and data transfer
Egress, the cost of sending data out of a cloud provider's network, is one of the more confusing meters because the per-gigabyte rate looks small. A photo-heavy product, a video pipeline, or a model that returns large attachments can quietly run up bandwidth costs that exceed the rest of the stack combined.
A rough rule for video: at modern bitrates, an hour of HD video is around 1.5 GB. A user who streams an hour a day generates roughly 45 GB a month from one device. Multiply by your user count and the meter starts to register. The Bandwidth Calculator is a quick way to translate user behaviour into transfer volumes before you commit to a pricing model.
Storage costs and how they accumulate
Storage is the meter most teams under-plan. It looks small at launch and grows monotonically; last month's data does not go away unless you delete it. Logs, user uploads, model embeddings, queued messages, backups, and historical snapshots all stack up.
The trap is that storage cost is small now and frighteningly large later. A 1 GB/day log stream is invisible at week one and 365 GB at the end of year one. The Data Storage Converter is helpful when negotiating retention policies, because it lets you compare what "30-day retention" actually means in terabytes against what "90-day retention" means.
A worked example: a small B2C app
Imagine a writing-assistant side project with the following expectations after launch:
- 8,000 active users in month one
- Each user has, on average, 12 sessions in the month
- Each session is roughly 15 model calls
- Average call: 800 input tokens, 400 output tokens
- Static API calls (autosave, sync, telemetry): about 60 per session
- 2 MB uploaded per session, 0.5 MB downloaded per session
- 30-day retention on all session content
Some quick arithmetic. Total model calls per month: 8,000 × 12 × 15 = 1,440,000. Static API calls: 8,000 × 12 × 60 = 5,760,000. Total upload: 8,000 × 12 × 2 MB ≈ 188 GB. Total download: ≈ 47 GB.
Using illustrative prices ($0.50/M input tokens, $1.50/M output tokens, $0.10 per million static calls, $0.05 per GB egress, $0.02 per GB-month storage):
- Model input: 1.44M × 800 × $0.50 / 1M = $576
- Model output: 1.44M × 400 × $1.50 / 1M = $864
- Static API: 5.76M × $0.10 / 1M = $0.58
- Bandwidth: 235 GB × $0.05 = $11.75
- Storage (30 days): 188 GB × $0.02 = $3.76
- Estimated total: about $1,456
The dominant line is model usage. Static API calls, the thing most people worry about, are essentially free at this scale. Storage and bandwidth are noticeable but small. Doubling users would roughly double the bill; doubling response length would add about $864 with no change in headcount. That second sentence is the planning insight.
For modelling this kind of scenario, the API Cost Calculator is built around exactly this layered breakdown.
Common mistakes worth avoiding
Pricing the average user, then sizing for the heavy user. Both numbers matter. The average drives the bill, but the heavy user drives the fairness of your own pricing.
Assuming free tiers are protection. A free tier protects you up to its quota, after which the bill behaves like any other. Free tiers are useful for prototyping, not for production reassurance.
Confusing burst and steady-state. A weekend launch that triples traffic for three days is not a baseline; it is a spike. Don't plan capacity, or pricing, around it.
Mixing currencies and units across line items. Vendor pricing pages routinely use a different unit (per-call, per-thousand-calls, per-million-tokens, per-GB) on the same product. Convert everything to the same base before adding.
Underestimating retention costs. Storage looks cheap monthly. Multiply by 12 and a year of growth, and it can match compute spend on data-heavy products.
Skipping the model side. AI features ship as line items shaped completely differently from the rest of the stack. They should be planned alone, not folded into "API costs" as if they were similar.
When each calculator is the right next step
Use the AI Token Calculator when the question is how big is one prompt? How does the bill change if I shorten the system prompt? It is a request-shaping tool.
Use the Bandwidth Calculator when the question involves transfer, such as video, downloads, or syncing, and you want to translate a user behaviour into gigabytes.
Use the Data Storage Converter when negotiating retention windows or comparing storage estimates that mix units.
Use the API Cost Calculator when stitching all of the above into a monthly projection. It is the only one of the four that asks "what does next month look like at this growth rate?"
FAQ
What is usage-based pricing? A pricing model where the bill scales with what you consume, such as number of requests, tokens, gigabytes transferred, or seat-hours used, rather than a flat monthly amount.
How do I estimate API costs for a side project? Start with one representative user. Count the requests, response sizes, storage written, and bandwidth used over a typical session. Multiply by the number of sessions and users you expect, then add baseline costs that exist whether users show up or not.
Why did my bill jump when I had more users? Usually because the dominant cost line was per-user, not baseline, and you crossed into a higher tier or overage band. Inspect the meters individually rather than the total. One line is almost always responsible.
Do free tiers really protect against surprise bills? Only up to the quota. Past that, you are paying retail unless you have explicitly set a hard cap, which not every provider supports. If a hard cap matters to you, confirm it is available before launch.
Are AI tokens billed differently from normal API calls? Yes. Token billing scales with content size, both the input prompt and the model's reply, while traditional API calls are billed per request, regardless of payload. They should be modelled separately.
Should I worry about bandwidth and storage at small scale? Probably not for bandwidth, unless you serve large files. Storage is the sneakier one: small today, larger later. Set a retention policy early; it is far harder to retrofit one after the data is in.
Closing thought
Most bills do not blow up because of a single bad decision. They drift, one cheap call at a time, until the per-user cost stops fitting the per-user revenue. The defence is not better engineering; it is a clearer mental model of which meter scales with which behaviour, and a habit of checking that before adding the next feature. The arithmetic is not hard. It is the awareness that takes practice.