Methodology

A calculator is only worth trusting if you can see what it assumes. This page lays out how we put the estimates together - where the maths is exact, and where we use a sensible approximation. The goal isn't to make a number look certain. It's to let you check our working.

We start with one unit of work

Every calculator begins by pricing one thing: one API request, one agent task, one chat, one support ticket, one answer, or one active user. We work out what that single unit costs first, then multiply by how many you expect in a month.

That makes the estimate easy to question. If the monthly total looks off, you can ask whether the per-unit cost is wrong, the volume is wrong, or both - something a single lump-sum number could never tell you.

The basic token formula

cost = (input_tokens × input_price + output_tokens × output_price) ÷ 1,000,000

Public model prices are normally quoted per million tokens, with separate rates for input and output. We keep those sides separate because output is often more expensive. When a provider publishes a cached-input rate, only the tokens expected to be read from cache use that rate. When eligible work is assigned to batch processing, the configured batch share receives the corresponding discount.

How we estimate token volume

When the user supplies token counts, we use them directly. When the Token Counter estimates tokens from text, it blends two common English-language rules of thumb: roughly four characters per token and roughly 0.75 words per token. This is deliberately an estimate, not a replacement for a provider's tokenizer.

Tokenization varies by model, language, punctuation, code, numbers, and formatting. JSON and source code can use more tokens than ordinary prose. For a serious budget, sample production-like requests and use token counts returned by the API.

From one request to a month

Monthly usage is built from observable product activity. An API feature uses requests per month. A chatbot uses conversations and the context carried by each message. An agent uses tasks, steps, calls per step, tool calls, and retries.

Where conversation history grows over time, the calculators approximate the average history rather than charging every message as if it contained the full final transcript. This keeps the model understandable, but a production log will always be better.

Failures and successful work

A retry rate increases the number of paid calls. If a workflow makes 10,000 initial calls and retries 10% of them once, the estimate includes roughly 1,000 additional calls. More complex retry trees are simplified into an average rate.

For agents, nominal cost is not enough. If a task succeeds 80% of the time, the failed runs still cost money. Failure-adjusted cost divides the total operating cost by successful outcomes so the result answers the more useful question: what does one delivered task cost?

Agent calculations

calls_per_task = steps × calls_per_step
retry_calls   = calls_per_task × retry_rate
task_cost     = planning + execution + final_answer + retries + tools

Planning, execution, tool calls, and final-answer calls can use different models. Tool calls are included as additional workflow activity where the calculator supports them. Human approval or review is added as labor, using minutes per task and an hourly rate.

Chatbot and RAG calculations

Chatbot usage starts with conversations and messages. Each message can include a system prompt, the new user message, prior conversation history, and retrieved knowledge. Human escalations are modeled separately so a low model bill is not mistaken for a fully automated support operation.

RAG separates one-time indexing from recurring queries:

indexing   = corpus_tokens × embedding_price
per_query  = query_embedding + retrieved_context + generated_answer
monthly    = index_updates + queries × per_query + vector_db + reranking

In many workloads, answer generation dominates. That is why chunk count and answer length are exposed rather than hidden in a single RAG multiplier.

Self-hosting calculations

monthly_capacity = GPUs × tokens_per_second × seconds_per_month × utilization
monthly_cost     = GPU_rental + engineering + storage + monitoring

Published throughput is not treated as guaranteed capacity. The user supplies expected throughput and utilization. The result should be checked against a benchmark using the intended model, hardware, context lengths, batching, and serving engine. If required demand exceeds calculated capacity, the calculator flags the gap rather than quietly assuming the hardware can keep up.

ROI and payback

monthly_savings = manual_cost − ai_assisted_cost
net_benefit     = monthly_savings − ai_operating_cost
ROI%            = net_benefit ÷ ai_operating_cost × 100
payback_months  = setup_cost ÷ net_benefit

ROI is only as credible as the baseline. A fully loaded hourly cost may include salary, benefits, management, and overhead, but the calculator uses the rate entered. Time saved is not automatically cash saved; a team may use the recovered time for more work rather than reducing headcount. We therefore present ROI as a planning scenario, not a promised return.

Support automation details

manual = tickets × handle_time_hrs × hourly_cost
ai_assisted = escalated × handle_time_hrs × hourly_cost
            + tickets × ai_cost_per_ticket + platform + QA

Only tickets fully resolved by automation count as deflected. Escalated tickets retain human handling cost. Platform and setup costs are kept visible. Resolution rate, handling time, support cost, and deflection rate should be replaced with measured figures whenever possible.

Safety margins and scenarios

A safety margin increases the modeled total to absorb normal uncertainty such as traffic spikes, longer prompts, minor pricing differences, and imperfect averages. It is not a substitute for taxes or a known cost that should have its own line.

We recommend running more than one scenario:

• Low: cautious adoption and efficient usage.
• Expected: the operating plan you currently believe.
• High: stronger adoption and longer context.
• Stress: more retries and weaker cache performance stacked on top of the high case.

The spread between scenarios is often more informative than the expected number. It shows which assumptions deserve measurement first.

Pricing data and rounding

Underlying provider prices are stored in USD. Displayed conversions use static rates for convenience and are not live foreign-exchange quotes. Calculations use full internal precision; displayed totals are rounded for readability. Very small costs may show additional decimal places.

Unless explicitly entered, estimates exclude sales tax or VAT, enterprise discounts, committed-use pricing, free credits, payment fees, and region-specific adjustments. Public list prices may not match a private contract.

How to reproduce an estimate

1. Record every visible input and the selected model.
2. Find the model rates on the Data Sources page.
3. Calculate input, cached input, and output separately.
4. Add workflow multipliers such as messages, steps, retries, and human review.
5. Apply discounts and the safety margin last.

If a result cannot be reproduced from the visible assumptions and documented formulas, that is a bug. Send the page, the inputs, the expected result, and what you actually saw to [email protected].

Limits of the methodology

These calculators simplify systems that can be messy. Provider billing rules change. Token estimates differ from exact tokenizers. Human behavior and model quality are uncertain. Latency, compliance, reliability, and opportunity cost cannot always be reduced to one dollar figure.

Use the estimate to compare scenarios and identify expensive assumptions. Before committing money or making a high-impact decision, confirm current provider terms and run a representative pilot.