AI Cost Calculator

Every large language model API — OpenAI, Anthropic, Google, and the open-model hosts — bills the same way: you pay per token, with separate prices for the tokens you send in (input) and the tokens the model generates (output). This AI cost calculator turns that pricing model into numbers you can budget with. It multiplies your average input tokens per request by the model's input price, your average output tokens by the output price, adds the two, and scales the result across your daily request volume to daily, monthly (30 days), and yearly totals.

The formula behind every number on this page is deliberately simple:

• ✓Cost per request = (input tokens ÷ 1,000,000 × input price) + (output tokens ÷ 1,000,000 × output price)
• ✓Cost per day = cost per request × requests per day
• ✓Cost per month = cost per day × 30  ·  Cost per year = cost per day × 365

The comparison bars below your result answer the question teams actually argue about: "what would this exact workload cost on a different model?" The same token profile is priced across every model in the list, so you can see at a glance that switching a summarization pipeline from a frontier model to a small model can cut the bill by 90% or more — and decide whether the quality difference is worth it for your use case.

One honest caveat: providers reprice frequently, launch new model versions, and offer volume discounts, cached-input rates, and batch tiers that list prices don't capture. Treat this LLM cost calculator as a planning tool that gets you within the right order of magnitude, use the custom-price option to mirror your actual negotiated rates, and verify against the provider's pricing page before you commit a budget.

A token is the unit language models actually read and write: a chunk of text, usually a word fragment, produced by the model's tokenizer. "Entrepreneurship" might be three tokens; "the" is one; code and non-English languages often tokenize less efficiently, so the same content costs more tokens in German or in JSON than in plain English prose. Every provider's meter counts these tokens on both sides of the conversation, and everything you pay follows from that count.

Three pricing mechanics matter more than everything else once you run in production:

• ✓Output costs a multiple of input. Across nearly all providers, generated tokens are priced 4–8× higher than input tokens, because generation is the computationally expensive part. A model at $3 input / $15 output makes verbose answers five times as expensive as verbose questions.
• ✓Context is resent on every turn. Chat APIs are stateless: each new message resends the system prompt and the whole conversation history as fresh input tokens. Turn ten of a conversation can cost ten times as much as turn one — the quiet driver behind most surprise bills.
• ✓Capability tiers are price tiers. Every provider ships a frontier model, a mid-tier, and a fast/cheap tier, with roughly 5–25× price spreads between them. Matching each task to the cheapest tier that handles it well is the highest-leverage cost decision you'll make.

Why has "AI cost calculator" become such a common search only in the last couple of years? Because the cost structure of software changed. Traditional features cost almost nothing per use; an LLM feature has real marginal cost on every single request. That makes token economics a unit-economics problem: if your $20-per-month subscriber triggers $30 of model usage, no amount of growth saves you — growth makes it worse. Teams now model token costs at the design stage, the same way they model hosting or payment fees.

The good news is that per-token prices have fallen dramatically year over year for equivalent capability, and mechanisms like prompt caching and batch processing (covered below) cut real-world bills well below list price. The teams that get burned are rarely the ones paying list price — they're the ones who never measured their token flow at all.

Because output tokens carry the premium price, the input/output shape of your workload determines which lever to pull first. Use the calculator's two token sliders to see this directly — the same total token count produces very different bills depending on which side it sits on.

• ✓Input-heavy workloads — RAG search, document analysis, "chat with your PDF", code review — send thousands of context tokens and get short answers back. Here the win is trimming context: better retrieval, tighter chunks, summarized history, prompt caching.
• ✓Output-heavy workloads — content generation, long-form writing, code generation — pay mostly on the expensive side. Here the win is constraining length: explicit output limits, structured formats instead of prose, and "be concise" as a hard instruction, not a suggestion.
• ✓Balanced chat workloads drift input-heavy as conversations grow, since history is resent every turn. Cap the history window or summarize older turns once a conversation passes a few thousand tokens.

A concrete example: a support bot sending 3,000 input tokens and generating 400 output tokens per turn on a $3/$15 model costs about $0.015 per turn — 60% of it input. The same bot on a $1/$5 tier costs $0.005. At 2,000 turns a day, that single model decision is the difference between $300 and $900 a month, before any prompt optimization. Run your own numbers above; the shape of your workload will tell you exactly where to optimize first.

Most production teams that take cost seriously end up 5–20× cheaper than their naive first implementation, with little or no quality loss. The playbook is well established by now:

• ✓Route by task, not by habit. Use the frontier model only where its quality is provably needed; send classification, extraction, and routine summarization to the fast tier. Many teams route 80–90% of traffic to cheap models and reserve the expensive one for the hard 10%.
• ✓Use prompt caching. Providers charge a fraction of the input price — often 90% less — for repeated prompt prefixes like your system prompt and static context. For chat apps with long system prompts, caching alone can cut input costs by more than half.
• ✓Batch what isn't real-time. Batch APIs typically run at 50% of list price in exchange for asynchronous delivery. Nightly summarization, enrichment, and evaluation jobs have no business paying real-time rates.
• ✓Trim the prompt. Audit your actual requests once: most teams find redundant instructions, oversized few-shot examples, and retrieved chunks the model never uses. Cutting 2,000 wasted input tokens per request at scale is free money.
• ✓Cap and structure the output. Set hard output limits, request JSON instead of essays, and stop generation early where possible — every saved output token is worth 4–8 input tokens.
• ✓Cache whole answers. If many users ask the same questions, serve repeated queries from your own cache instead of regenerating them. FAQ-style traffic often has 30%+ exact or near-duplicate rates.
• ✓Measure per feature from day one. Log tokens and cost per request, tagged by feature and user tier. You cannot optimize a bill you can't attribute — and per-user cost data is what tells you whether your pricing actually covers your usage.

Work the list top to bottom: routing and caching are architecture-level decisions with the biggest payoff, prompt hygiene is a one-day cleanup, and measurement is what keeps the bill from creeping back up as the product grows. And revisit the list quarterly — new model releases regularly make yesterday's frontier quality available at yesterday's fast-tier price, which means the cheapest way to cut your bill is sometimes simply re-running your evaluation suite against the newest small model.

Pre-launch, you won't have real token logs — but you can get close enough for budgeting with three rules of thumb:

• ✓1 token ≈ 0.75 English words ≈ 4 characters. A page of text is roughly 500 words, so about 650–700 tokens. Non-English text and source code run 20–50% heavier.
• ✓Draft your real prompt and count it. Write the actual system prompt you plan to ship, add a realistic user message and (for RAG) realistic retrieved chunks, and run it through the provider's tokenizer tool. Guessing "about 500 tokens" when the truth is 4,000 is the most common budgeting error.
• ✓Budget the conversation, not the message. For chat products, multiply per-turn cost by expected turns per session (typically 4–8 for support, more for companion-style apps) and remember input grows with each turn as history accumulates.

Then add a safety factor. Real usage is spikier and more verbose than the median scenario: power users write longer messages, edge cases trigger retries, and agents that call tools multiply request counts per user action. Doubling your calculated monthly estimate is a reasonable planning buffer for a v1 — you can tighten it once you have two weeks of real logs.

If you're building an AI product — or adding AI features to an existing one — token costs belong in the same spreadsheet as hosting, payment fees, and support headcount, because they scale with usage in a way traditional software costs never did. Three questions every founding team should be able to answer before launch:

• ✓What does one active user cost per month? Requests per user × cost per request. If that number is a meaningful fraction of your price, your margin lives or dies on the optimizations above.
• ✓What happens to the bill if usage 10×es? The scenario you hope for is also the one that bankrupts an unoptimized architecture. Model it now, while changing course is cheap.
• ✓Does the free tier have a cost ceiling? Unlimited free AI usage is a pricing decision, not a growth hack. Rate limits and cheap-tier routing for free users are standard practice for a reason.

Investors ask these questions too. A pitch that includes realistic per-user AI costs — and a plan for driving them down — signals operational maturity in a way "we'll figure out costs at scale" never does. Run your scenario in the calculator above, put the monthly number next to your projected revenue per user, and you have the core of your AI unit economics slide.

Abstract token prices become much easier to reason about with concrete scenarios. All four examples below use mid-tier model pricing ($3 per 1M input tokens, $15 per 1M output tokens) and can be reproduced exactly with the sliders above:

• ✓Customer support chatbot. 3,000 input tokens (system prompt, knowledge snippets, short history) and 400 output tokens per turn ≈ $0.015 per message. At 2,000 messages a day that is roughly $900 per month — and about $180 on a fast-tier model, which handles most support traffic just as well.
• ✓Document summarization pipeline. A 20-page contract is around 13,000 input tokens with a 600-token summary ≈ $0.048 per document. Summarizing 500 documents a night costs about $720 per month at list price — or roughly $360 through a batch API at half price.
• ✓Email drafting assistant. 1,200 input tokens of instructions and thread context, 350 output tokens per draft ≈ $0.009 per email. A team drafting 300 emails a day spends under $85 per month — the kind of feature where cost is a rounding error and quality should drive the model choice.
• ✓AI agent with tool calls. One user task triggering six model calls at an average of 8,000 input and 800 output tokens each ≈ $0.216 per task. At 500 tasks a day that is about $3,240 per month — agents are where routing, caching, and context trimming stop being nice-to-haves and become survival.

Notice the two-orders-of-magnitude spread between the cheapest and the most expensive scenario at similar user counts. The driver is never the headline price per token — it is the token volume your architecture generates per user action. That is exactly what the calculator above lets you interrogate before you write a line of code.

• ✓Counting only the user's message. The system prompt, retrieved context, and conversation history usually dwarf the visible question. Estimate the full request payload.
• ✓Ignoring the output-price multiplier. Averaging input and output prices understates generation-heavy workloads badly. Always model the two sides separately — as this calculator does.
• ✓Forgetting that conversations compound. Ten-turn chats resend history ten times. Per-conversation cost, not per-message cost, is the number that matters for chat products.
• ✓Overlooking retries, tools, and agents. One user click can trigger several model calls behind the scenes. Count model requests, not user actions.
• ✓Budgeting on stale prices. LLM pricing changes several times a year. Re-check the official pricing pages — or plug current numbers into the custom fields — every time you revisit the budget.
• ✓Defaulting to the biggest model everywhere. The most expensive model is the right choice for some tasks and pure waste for most. Benchmark the cheap tier on your actual task before paying 10× on principle.