AI agent pricing calculator: what to actually calculate
Most AI agent pricing calculator math skips cache reads and tool calls. Here's the formula we use, with real per-token prices from this week's model launches.
Why "how much will this AI agent cost" gets a wrong answer
Ask most vendors for an AI agent pricing calculator and you get a slider: pick a plan, pick a seat count, get a number. That works for software with fixed usage. It falls apart for agents, because an agent's cost depends on what it does on a given run, not on how many people log in. A support agent that reads a 40-page policy document before answering a simple question can cost ten times more than one that already has that document cached. Seat-based pricing hides that difference completely. A calculator worth using looks at tokens in, tokens out, how much of the context gets served from cache, and how many tool calls the agent makes to reach an answer.
We build these systems for clients at Stride, and the first spreadsheet we hand someone is never the pricing page from the model provider. It is a version of that page with their own document sizes, call volumes, and error rates dropped in.
What actually drives the bill
Five numbers decide what an agent costs to run each month:
Input tokens per run: everything you feed the model, the prompt, the retrieved documents, the conversation history. Output tokens per run: what the model writes back. Cache hit rate: how often the model reuses context it has already processed, instead of paying full price to read it again. Effort level: most current models let you dial compute up or down per task, and a lower setting can match a higher one's results on simpler work at a fraction of the cost. Runs per month: how many times the agent actually fires.
Multiply price per million tokens by volume, for each of the three token types, and add them up. That is most of the formula. The part people skip is the cache line and the effort setting, and this week both happen to matter more than usual.
What changed this week, and why the calculator needs updating
Anthropic launched Claude Fable 5.1 on September 1, and the pricing structure is a useful case study for anyone building an AI agent pricing calculator instead of trusting a single quoted rate. Input and output prices held steady at $10 and $50 per million tokens. What moved was the cache read price, cut from $1 to $0.25 per million tokens. Anthropic says that change alone brings typical costs down around 25 percent, and up to 45 percent for heavily agentic tasks: long runs with many tool calls that keep rereading the same cached context.
That detail does not show up on a seat-based price sheet. Two agents on the same model, same input and output volume, can land 45 percent apart in cost purely on how much of their context comes from cache. If your calculator only has one number per model, it is answering a different question than the one you asked.
It is also worth checking a model against its own siblings before assuming the newest release is the cheapest option. Anthropic's Opus 5 runs at $5 input and $25 output per million tokens, half of Fable 5.1's list price. Fable 5.1 scores higher on agentic coding and research benchmarks, so the right pick depends on whether the task needs that extra capability or is happy running on the cheaper model at a lower effort setting. A calculator that only compares sticker prices steers you wrong here.
Google's move with Gemini's video analysis makes the same point from a different angle. Instead of scanning a video frame by frame at a fixed rate, the agent now decides which segments are worth examining and at what resolution, and Google says that cuts token usage by up to 88 percent on that workload. The lesson carries beyond video: a task that looks like a fixed token count on paper often isn't, once the agent gets a say in how much of the input it actually needs to read.
A worked example
Take a support agent that reads a 3,000-token ticket, checks it against cached policy documents, and writes a 500-token reply. Run it 2,000 times a month on Fable 5.1.
Input: 3,000 tokens x 2,000 runs = 6 million tokens x $10/million = $60. Output: 500 tokens x 2,000 runs = 1 million tokens x $50/million = $50.
That is $110 a month before cache reads enter the picture. Now say a third of that input is the same policy document, served from cache instead of read fresh each time: at $0.25 per million instead of $10, that slice drops from most of its cost to nearly nothing. Run the same volume on Opus 5 instead, at $5 and $25 per million, and the input and output lines alone fall to $30 and $25. Small numbers on a single agent, but multiply by twenty workflows across a department and the gap between pricing off the sticker rate and pricing off actual cache and model behavior turns into a real line item on someone's budget.
When a spreadsheet stops being enough
A token calculator gets you close for a single agent doing one job. It stops being enough the moment you run more than one agent that call each other, or call out to APIs, or hand off partial results between steps. At that point the bill includes retries when a tool call fails, the tokens burned rereading context after an error, and the human time spent checking outputs before they go anywhere near a customer. None of that shows up in a per-token rate card, and none of it is optional to plan for once an agent has more than one moving part.
That is usually the point where we get a call. Our AI services start by mapping the actual workflow before touching a model choice: what gets read, how often, what can be cached, and where a cheaper model at a higher effort setting beats an expensive one at a low one. Half the time the answer is that the client does not need the most capable model on the market. They need the cheapest one that clears the bar for their specific task, run through a calculator that accounts for how their agent actually behaves instead of how the pricing page assumes it will.
If you are building your own version of this, start with the five numbers above, not the plan tiers. The plan tiers will change again within a quarter. The formula will not.
Written from
Common questions
Why AI agents are used?
Agents handle work that follows rules but still needs judgement: reading an email, pulling the right record, drafting a reply, updating a system. They run at any volume without adding headcount, and they keep quality steady on repetitive tasks. Most clients use them where staff time is spent on routine handling rather than decisions.
What is custom AI agents?
A custom agent is built around your process, data and systems instead of a generic assistant. It knows your products, your tone and your rules, and it connects to the tools your team already uses. The difference from an off-the-shelf chatbot is that it can act, not only answer.
How to customize AI agents?
Customisation happens on four levels: the knowledge it uses, the instructions and tone it follows, the systems it connects to, and the limits on what it may decide alone. We start from your existing documents and workflows, then tighten behaviour based on real conversations. Most tuning work happens after the first weeks of live use.
How are custom AI agents named nomenclature?
Naming is a practical choice, not a technical one. Some clients name agents by function, such as an intake agent or a quotation agent, which keeps things clear when several run side by side. Others give it a company-branded name for customer-facing use; internally, function-based names cause less confusion.
How to develop custom AI agent?
We start by mapping one concrete process and what a good outcome looks like, then build a working version on your real data. It goes live for a limited group first, so errors surface before they reach customers. Scope, systems to connect and data quality drive the effort, so we quote per project.