Goal
Price an API workload from input/output token counts and per-million rates.
AI API Usage Cost
Price an API workload from input/output token counts and per-million rates.
Key facts
- What it does
- Price an API workload from input/output token counts and per-million rates.
- Formula
Cost = in/1e6 × inPrice + out/1e6 × outPrice.- You enter
- Input tokens · Output tokens · Input price per 1M · Output price per 1M
- Worked example
- Total $3.00 ($1.50 input + $1.50 output).
A clearer path to an answer
From your question to a useful result
This page keeps the calculation transparent: define the goal, enter the matching values, inspect the method, and decide what the result means in your situation.
Inputs
Input tokens · Output tokens · Input price per 1M · Output price per 1M
Method
Cost = in/1e6 × inPrice + out/1e6 × outPrice.
Next step
Calculate, review the assumptions below, then compare a related tool when the decision needs more context.
AI API Usage Cost
Price an API workload from input/output token counts and per-million rates.
Open the AI API Usage Cost pageMore technology tools
Download PDFDownload Word (.doc)
Result
Enter your values above and choose Calculate to see the result here.
Calculation map
Follow the path from input to answer
01
Inputs (4)
- Input tokens Ready
- Output tokens Ready
- Input price per 1M Ready
- Output price per 1M Ready
02
Formula
Cost = in/1e6 × inPrice + out/1e6 × outPrice.
Bounded, transparent calculation
03
Result
- Calculate to preview the result.
Recent runs
Your recent runs stay in this browser session only.
Formula, assumptions, and example
Formula: Cost = in/1e6 × inPrice + out/1e6 × outPrice.
Providers bill input and output tokens at different per-million rates. Cached, batch, or tiered pricing needs its effective rate entered manually.
- Linear per-token pricing; no free tier, minimums, or volume discounts.
- One consistent currency.
- Check live provider pricing — defaults are illustrative.
Worked example: Total $3.00 ($1.50 input + $1.50 output).
Displayed input contract
- Input tokens · minimum 0 · maximum 1000000000000
- Output tokens · minimum 0 · maximum 1000000000000
- Input price per 1M · minimum 0 · maximum 100000
- Output price per 1M · minimum 0 · maximum 100000
The displayed limits are checked before the handler runs. Model-specific domain checks may also reject impossible or non-finite inputs.
Methodology: This calculator follows the WorldCalculate input, formula, precision, and boundary policy. Read the official methodology.
Calculator usage statistics
Usage of this calculator and related tools
This section counts anonymous successful Calculate submissions, not unique visitors. Counts and top tools appear only when trusted aggregate data is available; country analysis is shown only under the same condition and reporting threshold.
Total successful calculations
Top tools
Country analysis
Most-used tools
Where usage is reported
Answer-first guide
How to use the AI API Usage Cost for a real question
Price an API workload from input/output token counts and per-million rates. Start with one clearly defined goal, enter values in the units shown, and keep the result attached to the assumptions below.
What this answers
This tool is useful when your question includes API cost, token pricing, LLM cost calculator. It returns the outputs declared in the calculator contract rather than a live quote, approval, diagnosis, or professional sign-off.
What you enter
Input tokens · Output tokens · Input price per 1M · Output price per 1M. Keep the same time period, unit system, and currency wherever the form requires comparable values.
How to check it
Run the worked example first, compare its output with the page's example, then change one input at a time. This makes an unexpected result easier to trace to a unit, boundary, or assumption.
Three checks before you rely on the answer
- Match the question. Confirm that the result means the quantity you need, not a similar-sounding percentage, balance, rate, or estimate.
- Match the inputs. Use the requested units and period, and read each hint before replacing the example values with your own.
- Read the boundary. Review the assumptions and limits. Linear per-token pricing; no free tier, minimums, or volume discounts.
Need a wider view? Browse Technology Calculators or compare the related tools below. The WorldCalculate methodology explains how formulas, examples, limits, and revisions are reviewed.
How to use the AI API Usage Cost
- Enter Input tokens.
- Enter Output tokens.
- Enter Input price per 1M — Copy the current rate from your provider; rates change often.
- Enter Output price per 1M.
- Choose Calculate and read the result panel.
- Use Download PDF or Download Word to save a result sheet.
Formula
Cost = in/1e6 × inPrice + out/1e6 × outPrice.
Providers bill input and output tokens at different per-million rates. Cached, batch, or tiered pricing needs its effective rate entered manually.
Worked example
Total $3.00 ($1.50 input + $1.50 output).
Assumptions and limits
- Linear per-token pricing; no free tier, minimums, or volume discounts.
- One consistent currency.
- Check live provider pricing — defaults are illustrative.
Context and background
The representations behind technical results
Computing tools distinguish number bases, decimal and binary storage, network prefixes, transfer units, and visual ratios before performing the arithmetic.
Technical systems use several measurement conventions because software, hardware, networks, and design each describe quantities differently. Explicit representation prevents a familiar abbreviation from hiding a different definition.
Research and review
How this guide was researched
Researched by Hassan ALRowaie, Founder and editorial researcher at WorldCalculate.
This guide follows the live calculator's declared inputs, formula, worked example, assumptions, validation boundaries, and source-backed methodology. The review date describes editorial review of the calculator explanation; it is not a promise that external facts or rates remain current.
Estimating an AI API bill is less about multiplying a single token total and more about keeping two different kinds of usage attached to their own rates. This calculator asks for input tokens, output tokens, an input price per million tokens, and an output price per million tokens. It then converts each token count into million-token units, prices the two streams separately, and adds them. That simple structure is useful for a request estimate, a monthly forecast, or a comparison between workload designs, provided the entered prices actually describe the billing situation being studied. This guide explains what token counts include, how to keep units consistent, how to validate the four inputs, and how to handle cached, batch, and tiered rates without hiding important assumptions. It also shows why batching and concurrency affect operations even when they do not change linear token arithmetic. The result is a transparent usage estimate, not a live quote, capacity assessment, privacy review, or model-selection decision.
The question this calculator answers
The calculator answers a deliberately narrow question: given a number of billable input tokens, a number of billable output tokens, and one rate for each direction, what is the arithmetic usage charge? Input is the material sent for processing, while output is the material returned by the service under the billing definition you are using. The page does not need the actual text of a prompt or response. It needs the counts that a usage record, measurement process, or forecast supplies. That makes the result easy to reproduce and easy to place in a spreadsheet or planning note.
The two directions remain separate because they often have different prices and because a workload can be dominated by either one. A long conversation may send a large history on every turn, producing a high input count with modest responses. A summarization or generation job may send a compact instruction and receive a much larger output. Combining the counts before applying one average rate would hide that distinction and can produce a materially wrong estimate. Keeping the streams separate is the central design choice of this page.
A result should therefore be read with its four inputs attached. A statement such as a request costs three currency units is incomplete unless it also says how many input and output tokens were assumed and which rates were used. If the rate schedule changes, or if the measured tokenizer counts differ from the forecast, the result changes even though the formula has not. The calculator exposes those dependencies instead of presenting a universal cost for an unnamed workload.
- The calculation prices input and output usage independently.
- The page works from aggregate counts and rates rather than prompt text.
- A total is conditional on the four entered values and their billing interpretation.
- The result is an estimate of usage charges, not a complete service quote.
What a token count represents
A token is a unit produced by a text tokenizer, not a synonym for a word, character, or sentence. Common words may occupy one token, while an uncommon word, a long identifier, punctuation, whitespace pattern, or a non-English string may occupy several. The exact count depends on the model family and the encoding rules used by the service. A rough words-per-token shortcut can be useful for an early sketch, but it is not a reliable billing measurement for a final estimate. Use an actual usage count whenever one is available.
Input usage can include more than the visible question a person typed. Depending on the service contract, it may include system instructions, conversation history, role markers, retrieved passages, tool descriptions, structured fields, or other request scaffolding. A request sent repeatedly with the full history can grow in input tokens even when the newest user message is short. The calculator does not infer any of these components. Add them before entering the input total, and document whether the count came from a single request, a turn, a job, or an entire reporting period.
Output usage should likewise be based on emitted billable material rather than a maximum setting. A response limit describes an upper bound or control, not necessarily the number of tokens produced. If a service reports hidden reasoning, tool-call text, or another separately priced output class, follow that service's usage record and decide whether the reported figure belongs in the output field or requires a separate calculation. Do not treat a user-visible character count as interchangeable with the billable output count without a documented conversion.
- Tokens are tokenizer units, so words and characters are only rough proxies.
- Input may include history, instructions, retrieved material, and request structure.
- Output should reflect what was actually billed, not merely a configured maximum.
- Use the usage definition for the selected service and model before entering totals.
Separate input from output
Start an accounting record with two columns: input tokens and output tokens. For a single call, use the counts associated with that call. For a set of calls, sum each column independently. Do not add input and output together and then assign the sum to the cheaper direction. That shortcut loses the price asymmetry the calculator is designed to show. The same separation is useful when comparing prompt-heavy, response-heavy, and balanced workloads.
Conversation history deserves special attention. In a multi-turn exchange, the service may receive earlier messages again on each turn unless a different state mechanism is used. The output from one turn can become input to a later turn, and retrieved context can change from request to request. The correct monthly input total is consequently the sum of all billable request-side tokens, not just the sum of new user messages. A forecast that ignores repeated history can look efficient on paper while understating the actual input stream.
Output can also be multiplied by retries, refusals followed by a new request, continuation calls, or post-processing passes. If each attempt is billed, include every attempt that reached the service. If a failed request is not billed, exclude it based on the usage record rather than a general assumption. The calculator has no event log, so the quality of the answer depends on whether the entered totals represent billable events rather than an idealized happy path.
- Sum input tokens into the input field and output tokens into the output field.
- Repeated history can make later turns much more input-heavy.
- Retries and continuation calls belong in the totals when they are charged.
- A maximum output setting is not a substitute for an observed output count.
Formula and units
Let I be the input-token count, O be the output-token count, P_i be the input price per 1,000,000 tokens, and P_o be the output price per 1,000,000 tokens. The calculator uses Cost = (I / 1,000,000 x P_i) + (O / 1,000,000 x P_o). Dividing a token count by 1,000,000 changes raw tokens into million-token units. Multiplying by a price quoted for one million tokens then produces an amount in the same currency as the rate. The final addition combines the two currency amounts.
The unit conversion is not optional. If 500,000 input tokens are entered, the input volume is 0.5 million tokens. If the input rate is 3 currency units per million, the input charge is 0.5 x 3, or 1.5 currency units. A rate of 3 per thousand would be a different rate and would need to be converted to 3,000 per million before entry. Conversely, a per-token rate must be multiplied by 1,000,000 to fit the input fields. Label each rate with its denominator while collecting it.
The formula assumes that the entered price applies uniformly to every token in its direction. That is a useful base case, not a statement that every billing schedule is uniform. If a workload contains several classes with different rates, calculate each class separately or derive a defensible weighted effective rate before using one field. The output remains in the rate currency; the calculator does not perform currency conversion, exchange-rate adjustment, tax calculation, or invoice reconciliation.
- Input charge = input tokens / 1,000,000 x input price per million.
- Output charge = output tokens / 1,000,000 x output price per million.
- Total cost is the sum of those two currency amounts.
- Keep token counts, rate denominators, and currency units consistent.
Validation and accepted boundaries
The Input tokens and Output tokens fields accept whole, finite, nonnegative numbers from 0 through 1,000,000,000,000 inclusive. The whole-number rule matters because a token is counted as a discrete billing unit. A decimal such as 1.5 tokens is not a valid token count, even though it would be easy to multiply. Zero is valid: it represents a request with no billable usage in that direction, such as an input-free or output-free scenario used for a boundary check. The upper limit is a bounded planning range, not a claim that every account has that capacity.
The two price fields accept finite, nonnegative numeric values from 0 through 100,000 inclusive and allow decimal rates. A zero rate can represent a deliberately free or waived class for the scenario, but it should not be entered merely because a rate was not found. A missing rate is an information problem, not proof of a zero charge. Decimal prices should be entered at the precision supplied by the billing schedule. Negative prices are rejected because a usage charge cannot be represented as a discount in this formula.
Values at the exact endpoints are valid when they satisfy the type rules. Values just outside them, nonfinite values, blank values, malformed numeric text, and fractional token counts are invalid. A valid but very large total is not a validation error; it may simply indicate an unrealistic scenario or a large batch. Likewise, an input count of zero with a positive output count is mathematically valid for a specialized estimate, though the surrounding service may impose its own request requirements. Validation checks arithmetic eligibility, not business plausibility.
- Token counts: whole, finite, nonnegative, and at most 1,000,000,000,000.
- Prices: finite, nonnegative, and at most 100,000 per million.
- Zero is accepted; a missing rate should not be disguised as zero.
- Out-of-range, fractional-token, blank, malformed, and nonfinite values are invalid.
Worked example with the default values
Use 500,000 input tokens, 100,000 output tokens, an input rate of 3 currency units per million, and an output rate of 15 currency units per million. First convert the input count: 500,000 / 1,000,000 = 0.5 million tokens. The input charge is therefore 0.5 x 3 = 1.5 currency units. The output count converts to 100,000 / 1,000,000 = 0.1 million tokens, so the output charge is 0.1 x 15 = 1.5 currency units.
Add the two directional charges rather than adding the raw token counts first. Total cost = 1.5 + 1.5 = 3 currency units. In a dollar-denominated rate schedule, this would display as 3.00 dollars when rounded to cents. The equal contributions are a consequence of the particular counts and rates; they do not mean input and output are priced equally. The output rate is five times the input rate, but the input volume is five times the output volume, so the products happen to match.
This example is also a good audit trail. Someone reviewing it can see the raw counts, the conversion into million-token units, each partial charge, and the final sum. If the input count later changes to 600,000 while everything else stays fixed, the input charge becomes 1.8 and the total becomes 3.3. If the output count changes instead to 200,000, the output charge becomes 3 and the total becomes 4.5. Small changes in either stream can be traced without rebuilding the whole estimate.
- Input: 500,000 tokens = 0.5 million; charge = 0.5 x 3 = 1.5.
- Output: 100,000 tokens = 0.1 million; charge = 0.1 x 15 = 1.5.
- Total: 1.5 + 1.5 = 3 currency units.
- The balance comes from the volume-to-rate relationship, not equal rate values.
Worked examples for different workloads
Consider a prompt-heavy retrieval workflow with 2,400,000 input tokens and 300,000 output tokens. At 0.80 currency units per million input tokens and 4.50 per million output tokens, the input portion is 2.4 x 0.80 = 1.92. The output portion is 0.3 x 4.50 = 1.35. The total is 3.27 currency units. Even though the input rate is much lower, its larger volume makes its contribution slightly larger than the output contribution. This is why looking at the high rate alone can misidentify the main cost driver.
Now consider a response-heavy job with 80,000 input tokens and 600,000 output tokens. At 0.25 per million for input and 12.50 per million for output, the input portion is 0.08 x 0.25 = 0.02, while the output portion is 0.6 x 12.50 = 7.50. The total is 7.52 currency units. Reducing the prompt by a few thousand tokens would have little effect in this case; controlling response length or the number of generated attempts may matter much more.
A zero case is useful for checking boundaries. If both token counts are zero, both partial charges and the total are zero regardless of the entered nonnegative prices. If input is 1,000,000 tokens, output is zero, and input price is 2.25, the total is 2.25. If the input rate is zero but output is 250,000 tokens at 8 per million, the total is 2. A zero in one component removes only that component; it does not make the other stream free.
- 2.4 million input at 0.80 plus 0.3 million output at 4.50 gives 3.27.
- 0.08 million input at 0.25 plus 0.6 million output at 12.50 gives 7.52.
- A zero token count removes its own charge only.
- Compare partial charges to find which stream deserves optimization attention.
Choosing provider rates responsibly
The rate fields are intentionally manual because price schedules vary by model, account arrangement, geographic billing context, service mode, and time. Before entering a value, identify the exact model or deployment category that produced the usage count. Check whether the published number is for input, output, cached input, asynchronous work, a special modality, or another class. A rate copied from a nearby but different row can be numerically plausible and still make the estimate wrong. Record the rate label and the date or billing period in the surrounding planning document.
Convert the quoted denominator before entry. A rate stated per thousand tokens must be multiplied by 1,000 to become a per-million value. A rate stated per token must be multiplied by 1,000,000. If a schedule is quoted per billion, divide it by 1,000 to get a per-million value. Perform this conversion once and keep the converted unit visible. Applying a per-thousand rate to a field that expects per-million produces a result off by a factor of 1,000, a mistake large enough to survive a quick plausibility check.
Use one currency for both rate fields. If a source lists one direction in a different currency, convert it before entry using an exchange-rate assumption that is recorded separately, or keep the scenarios separate. The calculator does not add subscription fees, reserved commitments, taxes, minimum monthly charges, payment processing costs, network charges, credits, or account-level rebates. Those may be important to a total budget but are outside this four-input usage formula.
- Match each price to the exact usage class and model context.
- Convert per-thousand, per-token, or per-billion quotes to per-million values first.
- Keep the two rates in one currency and record the conversion assumption if needed.
- Treat fixed fees, credits, taxes, and account adjustments as separate budget lines.
Cached input and effective rates
Some billing schedules price input tokens differently when a reusable prefix or other cache condition is met. The important accounting question is not whether the request was intended to be cacheable; it is how many tokens were actually billed in each class. Separate the input stream into ordinary input tokens and cached input tokens when the usage record exposes that distinction. If both classes are charged, both belong in the total. Removing cached tokens from the input count entirely would understate the bill whenever the cached rate is nonzero.
For example, suppose a job has 900,000 ordinary input tokens at 3 per million and 600,000 eligible cached input tokens at 0.30 per million. The input charge is 0.9 x 3 plus 0.6 x 0.30, which equals 2.70 + 0.18 = 2.88 currency units. If the calculator offers only one input-rate field for this scenario, an effective input rate can be formed as 2.88 divided by 1.5 million, or 1.92 per million. Entering 1.92 with the combined 1.5 million input count reproduces the same input charge.
An effective rate is safe only when the mix of classes is clear and stable for the estimate. Cache eligibility can depend on prefix length, request order, expiration, content changes, or an exact matching rule. A forecast that assumes every request receives the cached rate may be too optimistic. For a changing mix, calculate ordinary and cached portions separately for each scenario, or use a range that reflects a conservative and an optimistic cache-hit share.
- Count cached tokens when they are billed, even if their rate is reduced.
- Use separate calculations or a weighted effective rate for mixed input classes.
- A weighted rate must reproduce the combined partial charge, not merely average prices.
- Cache eligibility and hit share are operational assumptions that need evidence.
Batch pricing and scheduled work
A batch or scheduled processing mode may use a different price from immediate interactive work. The cost calculator can represent that mode by entering the applicable effective input and output rates, as long as the counts and rates describe the same batch class. If a workload mixes immediate calls with scheduled calls, do not apply the lower batch rate to all tokens. Split the counts by mode, calculate each charge, and add the results. The arithmetic is still linear within each class, but the rate is not shared across the entire workload.
Suppose a scheduled job contains 40 million input tokens at 0.60 per million and 8 million output tokens at 3.00 per million. Its input charge is 40 x 0.60 = 24, and its output charge is 8 x 3.00 = 24, for a total of 48 currency units. If another 2 million input tokens and 200,000 output tokens are processed interactively at 2 and 10 per million, they add 4 + 2 = 6. The combined workload estimate is 54, not the result of applying one blended rate without documenting the mix.
Discounted scheduled work can have different completion-time, retry, cancellation, or result-availability behavior. A lower token price does not describe those operational properties. Confirm that the usage is eligible for the mode, that the job's outputs are billed under the expected direction, and that any resubmitted or partially completed work is counted according to the actual account record. Use this calculator for the charge arithmetic and a separate operational plan for timing and reliability.
- Use the batch rate only for tokens processed under the eligible batch mode.
- Mixed interactive and scheduled work should be split into separate calculations.
- A lower rate does not imply the same completion time or retry behavior.
- Confirm billing eligibility before using a discounted rate in a forecast.
Tiered and bracketed pricing
Volume pricing cannot always be represented by one rate. A schedule may charge the first portion of usage at one price and later portions at another, or it may switch the entire volume to a new rate after a threshold. Those are different tier rules. The calculator's formula accepts one rate for each direction, so a tiered workload must either be split into multiple calculations or represented by a weighted effective rate whose derivation is recorded. Do not choose the lowest visible tier merely because the forecast crosses its threshold.
For a cumulative bracket example, imagine 1 million input tokens at 3 per million and the next 4 million at 2 per million. The input charge is 1 x 3 + 4 x 2 = 11 currency units. The combined 5 million tokens have an effective rate of 11 / 5 = 2.20 per million. Entering 5 million and 2.20 reproduces the charge. Output may have its own brackets, so it must be calculated independently rather than sharing the input effective rate.
If the schedule instead uses an all-units rule, crossing the threshold may reprice the whole volume. In that case, the effective rate is based on the rate that applies to all eligible tokens after the threshold, not on a cumulative average of lower and higher portions. When the contract is unclear, produce separate low, middle, and high scenarios rather than presenting a single precise number. The calculator cannot infer the tier rule from token volume alone.
- Split cumulative tiers by token band or derive a documented weighted rate.
- Calculate input and output brackets independently.
- Distinguish cumulative pricing from a rule that reprices the whole volume.
- If the tier rule is uncertain, show scenarios instead of inventing one rate.
Forecasting budgets from usage
For a forecast, decide whether the input counts describe one request, one user session, one job, one day, or a reporting period. Then estimate the number of such units and multiply the partial charges at the aggregate level. For example, if 10,000 requests each average 12,000 input tokens and 800 output tokens, the aggregate counts are 120 million input tokens and 8 million output tokens. At 2 per million input and 8 per million output, the forecast is 120 x 2 + 8 x 8 = 240 + 64 = 304 currency units. Aggregating first avoids losing scale through premature per-request rounding.
Averages need to be weighted by request volume. If one endpoint handles 90 percent of calls and another handles 10 percent, averaging their token counts equally gives the wrong forecast. Build the total from endpoint counts, user cohorts, or job classes. Include expected retries, continuation calls, cache-hit shares, batch eligibility, and growth. If traffic is seasonal or spiky, a monthly average should sit beside a peak-day estimate so that a total budget is not mistaken for a capacity plan.
A useful forecast has at least three cases. A lower case can use a smaller call count, shorter context, and favorable cache share. A base case should reflect the current measured distribution. A higher case can include growth, longer conversations, retries, and less favorable pricing eligibility. Keep the rate date and all scope assumptions with each case. A single total without a usage driver cannot explain why the budget changed or which lever could bring it back under control.
- Aggregate counts before applying the per-million rates.
- Weight averages by the number of requests or jobs in each class.
- Include retries, continuations, cache mix, growth, and peak usage in forecasts.
- Use lower, base, and higher cases when traffic or rates are uncertain.
Batching, retries, and concurrency
Under a truly linear per-token price, combining requests into a batch does not change the charge if the total billable input and output tokens stay the same. Ten requests containing 1,000 input tokens each still contribute 10,000 input tokens. Batching can change scheduling efficiency, queueing, rate-limit behavior, or eligibility for a separate price class, but those effects must be represented by their own assumptions. Do not claim a cost saving from batching merely because fewer transport operations were made.
Concurrency changes how work is arranged in time. Running several requests at once can improve throughput until a service or account limit is reached, while it can also increase the number of in-flight retries, queue delays, or peak resource needs. The token formula has no concurrency field and therefore does not estimate throughput, parallel capacity, latency, or the number of workers required. A concurrency experiment should measure actual token totals and failure behavior, then feed the resulting counts into the cost estimate.
Retries are a cost multiplier when the retried request is billed. A timeout at the client does not by itself prove that the service did or did not charge the attempt; inspect the usage record or billing rule. If a retry repeats a large input history, it can add nearly the entire input count again. If a response is truncated and followed by a continuation call, count the continuation's input and output separately. Operational safeguards such as backoff and idempotency can reduce waste, but they are outside the arithmetic page.
- Linear pricing depends on total tokens, not the number of transport batches.
- Concurrency affects timing and capacity, not automatically the per-token charge.
- Count a retry or continuation when its usage is billable.
- Use measured failure and retry rates to improve a forecast.
Uncertainty and rounding
Token counts are discrete, but forecasts are often uncertain. A projected 1,200 tokens per request may conceal a wide distribution in which some requests are short and a few are very long. The arithmetic can be exact for the average while the total forecast is still uncertain because the average may move with conversation length, retrieved context, or user behavior. Preserve the observed range, percentile, or confidence assumption in your notes rather than presenting an average as a guaranteed limit.
Rates also have precision and timing uncertainty. A displayed price may be rounded, may change after a billing-period boundary, or may apply only to a particular account condition. Enter the published precision and avoid inventing extra digits. For a scenario comparison, calculate with full available precision and round the displayed result only at the end. Rounding every request to cents before multiplying thousands of requests can create a noticeable difference, especially when individual charges are small.
A useful sensitivity check is simple. Increasing input usage by one million tokens changes the total by exactly the entered input rate under this formula. Increasing output usage by one million changes it by the output rate. A one-unit change in either rate changes the corresponding million-token volume by one currency unit per million tokens. Near a budget limit, show a margin or range rather than relying on a rounded value that appears just below the limit.
- Keep token forecasts with their distribution or range, not only a central average.
- Use the available rate precision and round the final display, not each small event.
- One extra million input or output tokens changes cost by its respective rate.
- Show a budget margin when rounding could change the decision.
Privacy and operational boundaries
This calculation requires counts and prices, not the text that produced them. That is useful for privacy because a planning worksheet can omit prompts, responses, credentials, customer identifiers, and retrieved documents. Do not paste confidential content into a cost form merely to estimate its size. If a count came from a sensitive usage report, minimize the surrounding data and share only the aggregate values needed for the estimate. The formula cannot inspect content, determine whether a token count contains personal information, or replace an organization's data-handling review.
The page also does not establish what happens to data in an API account, a logging system, a proxy, a monitoring tool, or a browser session. Retention, access control, encryption, residency, deletion, and contractual handling require separate operational and legal checks. A cost number can be correct while the proposed workflow is still unsuitable for confidential material. Keep financial estimation, privacy review, and security approval as separate decisions with their own evidence.
Operationally, the calculator has no live connection to an account balance, usage dashboard, rate feed, invoice, quota, or service health signal. Its rates can become stale, and its four fields cannot describe every possible charge class. It is best used as a transparent arithmetic layer after the relevant billing definitions have been identified. When actual usage becomes available, compare the estimate with a redacted aggregate record and update the assumptions rather than treating a discrepancy as proof that the formula is wrong.
- Enter aggregate counts rather than confidential prompts or responses.
- Cost arithmetic does not answer retention, access, residency, or deletion questions.
- The page does not read an account balance, invoice, quota, or live rate feed.
- Keep privacy, security, and operational approval separate from the cost estimate.
What the calculator does not decide
A lower estimated charge does not identify the best model or service for a task. The calculator does not assess answer quality, factual reliability, safety behavior, context support, tool compatibility, language performance, or suitability for a particular user group. It does not compare the value of two systems or decide whether a quality change is worth a price change. Those questions need task-specific evaluation and acceptance criteria, not more arithmetic on the same four inputs.
The result is not a latency, throughput, or capacity prediction. It does not determine how many concurrent requests an account can accept, how long a batch will wait, how much memory a client needs, or whether a rate limit will be reached. It also does not calculate fixed platform charges, network transfer, storage, observability, human review, support, tax, foreign-exchange effects, credits, or contractual commitments. Add those items in a broader financial model when they apply.
The calculator does not decide whether a workload should be cached, batched, truncated, summarized, retried, or moved to a different service. Those choices have effects on correctness, freshness, privacy, reliability, and user experience. It can show the charge implied by a chosen token mix and rate mix. It cannot choose the acceptable tradeoff. The responsible interpretation is that the page informs a decision while leaving technical, financial, and governance ownership with the people planning the system.
- Not decided: model quality, safety, compatibility, or task suitability.
- Not decided: latency, throughput, quotas, concurrency capacity, or batch completion time.
- Not included: fixed fees, taxes, transfer, storage, credits, or account commitments.
- Not recommended: a caching, truncation, retry, or migration strategy.
A repeatable estimation workflow
First define the accounting boundary. Decide whether you are estimating one request, one conversation, a batch job, a day, or a month. Identify which model and service mode produced the usage, then list any special classes such as cached input, scheduled processing, or volume tiers. This step prevents a rate from one context being paired with tokens from another. Write down whether the counts are measured, sampled, or projected, and whether retries and continuation calls are included.
Next separate and aggregate the tokens. Put every billable request-side count in the input total and every billable response-side count in the output total. If several rates apply, split the work into classes before using the calculator, or derive a weighted effective rate with a visible calculation. Convert all rates to the per-million unit and one currency. Check that token totals are whole, finite, nonnegative, and within the page limits, and check that prices are finite, nonnegative, and within their limits.
Finally calculate, review the two partial charges, and compare them with the purpose of the estimate. If input dominates, inspect repeated history and retrieved context. If output dominates, inspect response length and retries. Run a low, base, and high scenario when the token distribution or rate eligibility is uncertain. Save the inputs beside the result, then compare later with an aggregate billing record. This workflow keeps the arithmetic simple while making the assumptions auditable.
- Define the time and billing scope before collecting counts.
- Separate input, output, cache, batch, and tier classes before pricing them.
- Convert rates to one currency and a per-million denominator.
- Record partial charges, scenarios, assumptions, and later measured results.
Interpreting differences from an invoice
When a forecast differs from an invoice, begin with scope rather than changing the formula. Check whether the forecast covered the same date range, model, account, region, service mode, and currency. Confirm that the invoice's token definitions match the counts used in the estimate. A common mismatch is comparing visible prompt and response text with usage totals that also include conversation history, instructions, retrieved material, tool definitions, or other billable request components.
Then reconcile special rates and event counts. Look for cached and uncached input, interactive and scheduled work, tier thresholds, free or credited usage, minimum charges, and retries. Check whether a request was counted once in the forecast but several times in the service record, or whether a failed attempt was excluded by one side and charged by the other. Compare input and output partial charges separately. A total-only comparison can hide a swapped field or a wrong denominator.
Rounding is usually the final check, not the first explanation. If the difference is large, suspect a unit, scope, rate-class, or count problem before blaming decimal precision. If the difference is small, inspect display rounding, invoice line aggregation, exchange-rate timing, and the precision of the entered rates. Once the cause is known, update the scenario assumptions and retain the original estimate as an audit trail. Do not silently overwrite a forecast that was correct for its original scope.
- Reconcile date, model, mode, account, currency, and usage definitions first.
- Compare input and output charges independently rather than only comparing totals.
- Check cache, batch, tiers, credits, minimums, and retries before changing arithmetic.
- Keep the original assumptions when revising a forecast.
Using the result for decisions
The most useful decision record includes more than a final amount. Include the four entered fields, the scope of the token counts, the date of the rates, the currency, and any effective-rate derivation. State whether the result represents a measured workload or a forecast. Include input and output partial charges so a reviewer can see which stream controls the total. This level of detail makes a later update inexpensive: a new rate or token distribution can be substituted without reconstructing the whole reasoning chain.
For optimization work, change one major assumption at a time. Hold traffic constant while changing input context to see the effect of prompt and history reduction. Hold token counts constant while changing the output rate to understand pricing sensitivity. Hold rates constant while changing retry or cache shares. Comparing isolated changes helps distinguish arithmetic savings from a change in workload volume. It also prevents a lower total from being attributed to a technique when the actual cause was fewer requests or a different billing class.
Use the result as one input to a broader decision. A cost reduction that harms correctness, freshness, reliability, or privacy may not be worthwhile. A more expensive configuration may be justified if it meets a response-quality or operational requirement. The calculator supplies a common numeric language for those conversations, but it does not assign value to the outcome. Pair cost scenarios with the performance and governance evidence needed for the actual project.
- Record inputs, scope, rate date, currency, and partial charges with the total.
- Change one cost driver at a time when comparing optimizations.
- Separate arithmetic savings from reduced traffic or changed eligibility.
- Balance cost against quality, reliability, freshness, privacy, and operations.
Questions to ask before trusting a total
Ask what exactly was counted as input and output. Does the input include all history and request scaffolding? Does the output include every billable generated class? Were retries, continuations, and background jobs included? If the answer is uncertain, label the number as a scenario rather than an observed charge. A transparent uncertainty label is more useful than a precise-looking total built from incomplete counts.
Ask whether the two entered prices are comparable. Do they share a currency, denominator, model context, billing period, and service mode? Are cached or batch rates mixed into a standard rate? Does a volume threshold use cumulative or all-units pricing? A rate field can accept a valid number that is still the wrong number for the selected tokens, so the surrounding provenance matters as much as the arithmetic.
Ask what decision the number is being used to support. If it is a budget, is there a peak and a margin? If it is a design comparison, are quality and latency measured separately? If it is a privacy-sensitive workflow, has data handling been reviewed independently? If it is an invoice check, do both sides cover the same scope? These questions keep a small calculator result in its proper role: a clear, bounded cost calculation that supports review without pretending to settle every related question.
- What request and response components are included in each token count?
- Do both rates share the same unit, currency, model context, and billing period?
- Are cache, batch, tiers, credits, retries, and peaks represented explicitly?
- What separate quality, operational, privacy, or invoice evidence is still needed?
Frequently asked questions
What is the AI API Usage Cost?
Price an API workload from input/output token counts and per-million rates.
What is the formula for the AI API Usage Cost?
Cost = in/1e6 × inPrice + out/1e6 × outPrice. Providers bill input and output tokens at different per-million rates. Cached, batch, or tiered pricing needs its effective rate entered manually.
What do I need to use this calculator?
Enter Input tokens, Output tokens, Input price per 1M, Output price per 1M, then choose Calculate.
What are the limits of this calculator?
Linear per-token pricing; no free tier, minimums, or volume discounts. One consistent currency. Check live provider pricing — defaults are illustrative.
Methodology
This calculator is part of the WorldCalculate library. Its formula, example, assumptions, input bounds, and output formatting follow the official methodology.
Use this calculator as part of a bigger plan
These WorldCalculate collections connect this tool with related questions while keeping each calculation separate and transparent.