Answer in brief
This SMART guide gives a reusable cost formula for agent runs. Enter your own token rates, volume, tool fees and retry assumptions, then compare the forecast with actual usage.
Write the formula before entering prices
An AI-agent budget needs a unit of work. Define a run, the expected number of model steps in that run, average input and output tokens per step, and expected runs per month. For one model, a simple monthly model-cost estimate is runs times steps times the sum of input tokens times input price and output tokens times output price, with both prices expressed per million tokens. Divide the token products by one million and then apply a retry multiplier if the stated averages exclude retries. This is an estimate, not a bill. Keeping variables visible is more useful than entering an attractive total whose assumptions nobody can recover.
Use the provider's current rate card
OpenAI and Anthropic publish model pricing on their official sites. Prices can differ by model, token direction and feature, and they can change. A reusable calculator therefore asks the reader to enter rates and record the date checked, rather than embedding a fixed 2026 number as if it were universal. Do not infer that two models have equal quality merely because their rate cards can be put in adjacent cells. A team should evaluate the task first and then compare the cost of models that meet its requirements. The formula supports that decision without pretending to replace a technical trial.
Add steps the compact expression misses
An agent may call a paid search service, run a tool multiple times, store files, generate embeddings or require human review. Those costs belong in separate lines rather than being hidden inside a model-token estimate. Also consider that later steps may carry a longer conversation history than the first one. If every step uses more input tokens, a single average should be measured from a representative trace. Retry rates matter for timeouts and malformed outputs, but a retry multiplier is a scenario assumption until real runs provide data. Separate fixed monthly infrastructure from variable cost per run so that volume changes can be modelled cleanly.
Show a range instead of false precision
Set low, base and high scenarios for volume, steps, token use and retries. The point is not to predict exactly which month will occur; it is to see which variable drives risk. If doubling the number of steps makes the high case unaffordable, design a step ceiling and a fallback. If output length dominates cost, test whether a shorter answer still meets the user's need. If tool fees dominate, examine when the tool is genuinely necessary. Every proposed saving should be checked against quality and safety on the same evaluation set. A cheaper run that makes more wrong decisions is not automatically a better product.
Reconcile the estimate with real usage
Once a service has actual traffic, compare invoices and usage logs with the assumptions in the worksheet. Record differences in volume, average tokens, retries, tool charges and any change to the provider's prices. Use the discrepancy to improve the next forecast and, where needed, the workflow itself. This SMART article gives a formula and a method, not a functioning price quote from either provider. It is also distinct from the clothing-store launch calculator elsewhere in VJOURNAL; mixing those two cost models would mislead readers. Our cover illustrates planning, not a screenshot of an official vendor calculator.
Worked example: model the cost before choosing a vendor
Consider a purely illustrative workflow with 10,000 runs in a month, three model steps per run, 2,000 input tokens and 500 output tokens per step. If the quoted input rate is I dollars and output rate is O dollars per million tokens, the model-only estimate is 10,000 × 3 × ((2,000 × I + 500 × O) / 1,000,000). Leave I and O as live inputs from the provider's pricing page rather than publishing a price that may change. The example describes arithmetic, not a current vendor quote or the expected bill for a real application.
Now add the costs the compact formula does not capture. A run may include a search or other billed tool, a longer context after a failed step, a retry when an external service times out, and separate storage or monitoring costs. If retries increase the average number of steps, use an observed multiplier rather than quietly assuming every run succeeds first time. A high-volume team should inspect the distribution of run lengths, not only the mean: a small number of unusually long sessions can change both latency and spend. Keep each assumption visible in the calculation sheet.
Sensitivity testing is more useful than one exact-looking total. Calculate a low, base and high case for monthly runs, average steps and output length. If the high case is unaffordable, the design question may be whether every step needs the same model, whether the prompt can be shorter without losing evidence, or whether a human review should replace an expensive loop. Avoid making quality claims about a cheaper model before testing it on the task. A budget is a guardrail for design choices, not proof that an agent will perform well.
Finally, reconcile the estimate with a real bill once the service has a sample of production traffic. Compare logged token use, tool calls and retries with the assumptions used to get approval. Investigate differences rather than simply updating the spreadsheet's total. Keep model rates linked to the provider's official page and record the date they were checked. This SMART article offers a reusable method, separate from the clothing-store budget calculator elsewhere in the journal. Its illustrative cover and formula do not imply that a universal fixed AI-agent price exists.
How to make the estimate reusable next month
Store the assumptions as named inputs rather than burying them in one spreadsheet cell. The reader should be able to change monthly run count, steps per run, input and output tokens, the two unit rates, tool charges and a retry factor independently. Record the date on which each price was checked and link to the official provider page. If a vendor adds a new billing category, the formula needs a new line; it should not be silently folded into the model-token rate. This makes the calculator useful after the article's publication date and lets a colleague understand where a changed total came from.
A budget limit should be connected to behaviour in the application. Decide what happens if a run nears its step or spend ceiling: stop, ask the user to confirm a more expensive path, or hand off to a person. Measure the proportion of tasks that reach those limits and whether shorter prompts or different tool ordering change the result. An agent that costs less but fails more often may be a worse choice after retries and human repair are included. The arithmetic in this article is a planning aid. It needs a real usage sample and quality evaluation before it can become a production budget.
A handoff a colleague can use
The final worksheet should show the formula, unit conventions, scenario inputs and links to the current rate cards on one screen. A colleague should be able to change the monthly volume without editing hidden cells or guessing whether a price is per token or per million tokens. Add a note explaining which charges are excluded, and never label a scenario as a provider quote. When actual usage arrives, preserve the original estimate alongside the new observation so the forecasting error is visible. That comparison can expose a workflow design problem, not merely a pricing change. Clear assumptions are the most useful feature of a budget calculator.