If you can estimate tokens, you can estimate cost before you ship. The trick is to model the feature as a workload, not a model choice, then price the workload at per 1M token rates.
That sounds obvious until a “small” feature turns into retries, long context, tool calls, and output-heavy completions. Once you break the feature into input, output, and cache behavior, the bill stops being a mystery and starts looking like a spreadsheet.
Start with the workload, not the model
Most teams ask the wrong first question: “Which model should we use?” The better question is, “How many tokens will this feature consume per successful task?” That is the number that drives your spend.
A useful estimate has four parts:
- Prompt and system tokens you send in.
- Output tokens the model returns.
- Any repeated context, such as chat history or retrieved docs.
- Retries, tool calls, and failed attempts.
If you are building a coding assistant, a support bot, or a report generator, the output pattern matters just as much as the prompt size. A feature that emits short structured JSON behaves very differently from one that writes long explanations or code diffs.
For a quick sanity check, compare your feature against the AI Cost Index. It gives you a blended view of frontier and budget pricing, which is useful when you want a rough ceiling before you pick a provider.
Do the math with one worked example
Let’s say your feature does one successful task with the following usage:
- 12,000 input tokens
- 3,000 output tokens
- No cache discount for simplicity
Now price that task on a few models. The formula is:
cost = (input_tokens / 1,000,000) * input_price + (output_tokens / 1,000,000) * output_price
Using gpt-4o-mini at $0.15 input and $0.6 output per 1M tokens:
(12,000 / 1,000,000) * 0.15 + (3,000 / 1,000,000) * 0.6
= 0.0018 + 0.0018
= $0.0036
So one successful task costs about a third of a cent.
Now price the same workload on gpt-4o at $2.5 input and $10 output per 1M tokens:
(12,000 / 1,000,000) * 2.5 + (3,000 / 1,000,000) * 10
= 0.03 + 0.03
= $0.06
Same feature, same tokens, different model, 16.7x more expensive. That is why “cheap enough” needs to be measured, not guessed.
Model choice changes the shape of the bill
Here is a small comparison using only the current figures we know. Note that these are per 1M tokens, and input and output are priced separately.
| Model | Input | Output | What it means for feature cost |
|---|---|---|---|
| gpt-4o-mini | $0.15 | $0.6 | Very low-cost for high-volume, short-output workflows |
| deepseek-chat | $0.28 | $0.42 | Cheap on both sides, especially if output stays short |
| gemini-2.5-flash | $0.3 | $2.5 | Low input cost, output starts to matter fast |
| claude-3-5-haiku | $0.8 | $4 | Still economical, but output-heavy features cost more |
| gpt-4o | $2.5 | $10 | Good for higher-stakes tasks, expensive at scale |
| claude-sonnet-4-5 | $3 | $15 | Output can dominate if your feature talks a lot |
| gemini-2.5-pro | $1.25 | $10 | Moderate input, pricey output |
| claude-opus-4-1 | $15 | $75 | Use when quality matters enough to justify premium pricing |
The pattern is simple. If your feature is input-heavy, the prompt price matters most. If it is output-heavy, the output rate can dominate the whole bill. That is why a “cheap” model can still get expensive if your app generates long answers, verbose code, or repeated retries.
If you want a broader view of how models stack up on value, the value-for-money view is the better lens than raw price alone.
Budget by successful task, not by API call
One of the easiest ways to underbudget an AI feature is to count only successful calls. Real systems retry. They replan. They call tools. They regenerate. They sometimes fail after spending a lot of tokens.
So instead of saying, “This call costs 2 cents,” ask, “What does one completed task cost after retries and tool use?” If the average successful task takes 1.4 calls, your cost estimate should be multiplied accordingly.
Here is a practical budgeting formula:
- Estimate average input tokens per attempt.
- Estimate average output tokens per attempt.
- Multiply by expected attempts per successful task.
- Add a buffer for long-context outliers.
For example, if a code review feature usually uses 8,000 input tokens and 2,000 output tokens per attempt, and you expect 1.5 attempts per successful review, then your cost estimate is based on 12,000 input tokens and 3,000 output tokens per successful task. That is the same arithmetic we used above, just adjusted for retries.
This is also where provider mix matters. A feature might use a cheap model for classification and a more expensive model only for the final response. That hybrid setup often beats using one premium model for everything.
How to estimate before launch without guessing
Before you ship, build a tiny test harness and run a representative sample of prompts. You do not need production traffic to get a useful estimate. You need a realistic prompt set, a realistic output target, and enough samples to see the spread.
Track these fields for each run:
- Provider and model
- Input tokens
- Output tokens
- Cache hits, if any
- Latency
- Success or failure
Then group the results by use-case. A summarizer, a code generator, and a support assistant should not share one budget line. They have different token shapes, different retry rates, and different output lengths. If you need live pricing for more models, check the model catalog instead of guessing from memory.
One more practical note: if you are using cached tokens, do not assume the discount is automatic. Cache behavior depends on the provider and the exact request pattern. If the same prompt prefix is reused often, cache can materially reduce spend, but only if your workload actually hits it.
How to track this in the real world
Once the feature is live, the fastest way to stop guessing is to track actual usage from the tools your team already uses. MyTokenTracker reads local usage logs from coding agents and can show a 30-day cost table at API prices without sending usage data off your machine.
To try it, run npx mytokentracker. If you want a synced dashboard, create a free account and run npx mytokentracker init. It uploads history, then syncs every 30 minutes. It works with Claude Code, Codex, GitHub Copilot CLI, Antigravity, OpenCode, Amp, Qwen Code, and more.
Only daily totals per agent and model are uploaded, never prompts, code, or file names. That makes it useful for budget reviews without turning your logs into a privacy problem.
If you are comparing spend across teams or projects, the open data and the public data set make it easier to audit assumptions instead of relying on screenshots from vendor dashboards.
FAQ
How do I estimate cost if I do not know the output length yet?
Use a range. Estimate a short, typical, and worst-case output length, then price all three. Output is often the most volatile part of the bill, especially for chatty assistants and code generation features. A conservative launch budget should assume the upper-middle case, not the best case.
Is the cheapest model always the best choice for a new feature?
No. Cheap models are great when the task is repetitive, short, and tolerant of occasional misses. If the feature is high-stakes, user-facing, or quality-sensitive, the cheapest option can create hidden costs through retries, user frustration, and manual cleanup.
What should I track after launch to keep spend under control?
Track cost per successful task, not just total spend. Then break that down by provider, model, platform, and use-case. If cost per task drifts upward, you usually have one of three problems: longer prompts, longer outputs, or more retries.
The practical takeaway is simple: estimate tokens first, price them second, and measure the real workload after launch. That is how you avoid surprise bills and ship features with your eyes open.