How to estimate AI feature cost before you ship it

If you want a useful pre-launch estimate, start with token math, not model vibes. The fastest way to get close is to estimate input and output tokens per request, multiply by the model’s per-1M-token price, then scale by expected traffic and cache behavior.

Why feature cost estimates go wrong

Most AI cost estimates fail for the same reason: they treat the model like a black box. In practice, your bill is driven by a few measurable inputs, especially prompt length, output length, retries, and how often you reuse cached context. If you ignore any of those, your estimate will drift fast once real users hit the feature.

The other common mistake is comparing model prices in the wrong unit. LLM prices are quoted per 1 million tokens, not per token. That matters because a tiny-looking number can still become a real monthly bill once you multiply it across thousands of requests. If you need a live reference point for market-wide pricing, the AI Cost Index is the cleanest place to sanity-check whether your estimate is in the right neighborhood.

For product planning, think in three layers:

• Per request, how many input and output tokens does one user action consume?
• Per workflow, how many requests does one successful task require?
• Per month, how many tasks will actually run in production?

That structure is boring, but it works. It also makes it much easier to explain the number to a teammate, a PM, or your future self when the invoice arrives.

The token math you should use

The formula is straightforward:

cost = (input_tokens / 1,000,000) * input_price_per_1M
     + (output_tokens / 1,000,000) * output_price_per_1M

If you use cached input tokens, reasoning tokens, or a mix of providers, break those out separately. Don’t average them into one blob unless you want a rough guess instead of a plan.

Here’s a small comparison using only the current prices we know. These are all per 1 million tokens, and the input/output split matters a lot:

That table is already enough to tell you something important: output-heavy workflows get expensive much faster than prompt-heavy ones, especially as you move up to frontier models.

Worked example: a coding assistant feature

Let’s estimate a simple feature: a code-review assistant that reads a PR summary, a diff, and a short project context, then returns feedback. Suppose one request uses 12,000 input tokens and 1,500 output tokens. You expect 8,000 requests per month.

Now run the math for a few models.

gpt-4o-mini
Input: 12,000 / 1,000,000 * $0.15 = $0.0018
Output: 1,500 / 1,000,000 * $0.6 = $0.0009
Per request: $0.0027
Monthly: 8,000 * $0.0027 = $21.60

gpt-4o
Input: 12,000 / 1,000,000 * $2.5 = $0.03
Output: 1,500 / 1,000,000 * $10 = $0.015
Per request: $0.045
Monthly: 8,000 * $0.045 = $360

claude-sonnet-4-5
Input: 12,000 / 1,000,000 * $3 = $0.036
Output: 1,500 / 1,000,000 * $15 = $0.0225
Per request: $0.0585
Monthly: 8,000 * $0.0585 = $468

The point isn’t that one model is always right. The point is that the same feature can land at very different monthly spend levels depending on model choice. If your product has thin margins, that gap matters immediately. If your feature is enterprise-facing, the bigger question is whether the user value justifies the cost, which is exactly the kind of tradeoff the value-for-money view helps you reason about.

Now add one more variable: retries. If 10 percent of requests fail and rerun once, your monthly cost rises by roughly 10 percent before you even touch prompt length. That is why “estimated cost per request” is only useful if you also track success rate.

What to include in a real launch estimate

A good estimate should include more than token counts. Here’s the checklist I’d use before shipping:

1. Average input tokens, including system prompt, tool instructions, retrieved context, and user content.
2. Average output tokens, not the ideal answer length, but the actual length you expect in production.
3. Retry rate, because failed calls still cost money.
4. Cache hit rate, if you reuse long prompts or static context.
5. Model mix, if you route easy requests to a cheaper model and hard ones to a stronger one.
6. Traffic volume, including spikes, not just the average day.

For teams that are still choosing between models, the live catalog at 4,880 models with current prices is useful for checking whether you’re overpaying for a use case that doesn’t need a premium model. If you want the macro view instead of a model-by-model lookup, the public State of AI page is the right place to see broader trends.

One practical trick: estimate with conservative output length first, then run a second estimate with a 25 to 50 percent longer answer. If the business case breaks when the model talks a little more than expected, your margin is too thin.

How to turn estimates into a budget

Once you have a per-request number, budgeting is just multiplication with a few guardrails. Start with monthly request volume, then add a buffer for retries, user growth, and the inevitable prompt creep that happens after launch.

Here’s a simple budgeting pattern:

• Baseline: expected requests at expected token counts.
• Stress case: 2x traffic, 25 percent longer outputs, and a small retry penalty.
• Optimization case: shorter prompts, better routing, and cache reuse.

If you want a quick market benchmark for whether your budget is aggressive or conservative, the AI Cost Index gives you a blended reference point. Right now, the Frontier basket is $4.64 per 1M tokens, blended 3:1 input:output, and the Budget basket is $0.74 per 1M tokens, blended 3:1 input:output. Those are useful anchors when you’re deciding whether your product should behave like a premium assistant or a high-volume utility.

That said, your own feature can still land far above or below those baskets depending on the token mix. A long-context, output-heavy agent will not behave like a short-answer classifier, even if they both use the same provider.

How to track this before and after launch

Pre-launch estimates are only half the job. You also need to verify that the real usage matches the model you built on paper. The easiest way to do that is to log cost, input tokens, output tokens, cache usage, latency, and success by model and use-case, then compare actuals against your estimate every week.

MyTokenTracker is built for exactly that kind of check. To try it locally, run npx mytokentracker. It reads the usage logs coding agents already keep on your machine, prints a 30-day cost table at API prices, and your usage data never leaves the machine. If you want a dashboard, create a free account and run npx mytokentracker init, which asks for the API token, uploads history, and then syncs every 30 minutes.

It works with Claude Code, Codex, GitHub Copilot CLI, Antigravity, OpenCode, Amp, Qwen Code and more. For custom integrations, drop-in wrappers auto-capture OpenAI, Anthropic, Gemini, and Mistral, and any other provider can be sent with a single POST to the events API. The useful part is not just spend, but the breakdown by provider, model, platform, and use-case, so you can see which feature is actually burning tokens.

That matters because estimates get stale fast. A prompt that looked cheap in staging can become expensive when real users paste large files, when output length grows, or when retries increase. Tracking closes that gap.

FAQ

How accurate is a pre-launch AI cost estimate?

It’s usually good enough for planning if you estimate input tokens, output tokens, retries, and traffic volume separately. The biggest misses come from ignoring retries, undercounting context, or assuming outputs will stay short forever.

Should I budget using the cheapest model I can find?

Not automatically. Cheaper models can be great for high-volume, low-risk tasks, but if quality drops and retries rise, the total cost can climb anyway. Budget for the workflow, not just the model sticker price.

What’s the fastest way to know if my estimate is wrong?

Track real usage from day one and compare actual cost per successful task against your estimate. If you see output tokens, retries, or cache behavior drifting, update the model before the bill surprises you.

If you’re shipping an AI feature this week, don’t guess the bill. Measure it locally with MyTokenTracker and compare the real numbers to your estimate.