Usage-based pricing is great for getting started. You pay for what you use. No upfront commitments. No wasted capacity.
Until your product takes off and your API bill triples in a month.
The challenge with usage-based APIs — OpenAI, Anthropic, Twilio, Stripe, any pay-per-call service — is that costs scale with your customers, not with your infrastructure. You can't forecast by looking at server capacity. You have to forecast by predicting user behavior.
Here's a practical framework for doing that.
Why Traditional Forecasting Breaks
Traditional cloud forecasting works because costs are capacity-based. You provision an RDS instance, you know what it costs. You scale up an ECS cluster, you can estimate the increase. The relationship between action and cost is direct.
API spend breaks this model. Your costs depend on:
- How many users you have
- How active those users are
- What features they use
- How many tokens/calls each feature generates
A single viral feature can 5x your API bill overnight. A customer onboarding a large team can shift your cost curve permanently. Traditional month-over-month forecasting can't capture these dynamics.
The Unit Economics Approach
Instead of forecasting total spend, forecast spend per unit. The "unit" depends on your product:
- Per user: What does one active user cost in API calls per month?
- Per request: What does one end-user action cost in API spend?
- Per feature: What does each AI feature cost to run?
Once you know your unit cost, forecasting becomes multiplication:
Forecasted spend = (Expected active users) x (Cost per user per month)
If one active user costs $0.85/month in OpenAI API calls, and you expect 3,000 active users next month, your forecast is $2,550.
How to Calculate Unit Costs
Step 1: Tag your API calls. Track which feature, user, or request triggered each API call. Most API providers give you usage data; you need to map it to your product.
Step 2: Calculate cost per unit over a stable period. Take the last 30 days. Divide total API spend by total active users (or requests, or feature invocations). That's your unit cost.
Step 3: Watch for drift. Unit costs change when you change prompts, models, or feature behavior. A prompt that used 500 tokens last month might use 800 tokens after an update. Recalculate unit costs after any change.
Accounting for Growth
Your user count isn't static. If you're growing 15% month-over-month, your API spend should grow roughly 15% too — assuming stable unit costs.
Build growth into your forecast:
Next month forecast = Current spend x (1 + growth rate)
But watch for non-linear growth. If you're launching a new AI feature, the growth in API spend may outpace user growth. Account for feature launches separately.
The Pace Check
Forecasts are projections. Reality diverges. That's why pace tracking matters.
On day 10 of the month, check:
- How much have you spent so far?
- At this pace, what will the month total be?
- Is that pace above or below your forecast?
If your forecast is $3,000 and you've spent $1,500 by day 10, you're pacing at $4,500. Something changed — more users, higher usage per user, or a code change that increased token consumption.
Pace checks turn a static forecast into a dynamic one. They tell you when your assumptions are wrong, early enough to act.
Model-Specific Considerations
Different API providers have different cost dynamics:
OpenAI / Anthropic: Cost scales with tokens. Input tokens are cheaper than output tokens. A chatbot feature that generates long responses costs more than a classification feature that returns a label. Forecast separately by model — GPT-4 vs. GPT-4o have very different per-token costs.
Twilio / SendGrid: Cost scales with messages. Forecast based on user communication patterns, not just user count.
Stripe: Cost scales with transaction volume and value. Forecast based on GMV projections.
For AI APIs specifically, track tokens per request, not just requests. A feature that sends a 2,000-token prompt costs 4x more than one that sends 500 tokens.
The Simple Framework
- Calculate unit cost: Cost per active user per month.
- Project user growth: How many active users next month?
- Multiply: Forecasted spend = unit cost x projected users.
- Add launches: Any new features this month? Estimate their incremental cost.
- Pace-check weekly: Compare actual spend to forecast. Adjust if diverging.
This won't be perfect. But it'll be within 20% — which is far better than guessing.
When to Worry
Your forecast is a target. Divergence from target is information.
- 5-10% above forecast: Normal variance. Monitor but don't panic.
- 10-25% above forecast: Investigate. Something changed — user growth, feature usage, or a code change.
- 25%+ above forecast: Act immediately. Check for runaway usage, bugs, or unexpected adoption of expensive features.
The goal isn't a perfect forecast. It's a forecast good enough to tell you when reality diverges — before the invoice forces you to notice.
Get started: Connect OpenAI and Twilio to StackSpend for usage-based cost tracking and pace checks.