AI agent pricing: what it actually costs to run one

What AI agent pricing actually means

When a client asks us about AI agent pricing, they almost always mean one thing: the API bill. What will it cost to call Claude or Gemini a few thousand times a day? That number is real, but it is the smallest part of the invoice. An agent is not one API call, it is a loop: read a task, decide what to do, call a tool, check the result, decide again. Each pass through that loop costs tokens, and a single task can take five or fifty passes depending on how well it is built. Price the token fee and you have priced maybe a third of the project.

The rest is infrastructure to keep that loop running reliably, and people to watch what it does when it goes wrong. Both of those cost more than most quotes admit up front, and both scale with how many agents you run, not with how clever the model is.

The three things you are actually paying for

Strip an agent project down and there are three cost lines, and they behave differently as you scale.

Model inference is the token cost: every prompt in, every response out, priced per model and per provider. This is the line every vendor quotes first because it is the easiest one to put a number on.

Infrastructure is the compute, memory and orchestration that keeps agents running: a place to execute code, a database for state and memory, logging so you can see what an agent did after the fact. This line grows with the number of agents running at once, not with how many tasks each one does.

Oversight is the human time spent reviewing what agents did, catching the cases they got wrong, and stepping in when something breaks a rule you did not think to write down. This line does not show up on a pricing page at all, and it is the one that determines whether an agent project actually pays for itself.

How Claude, Gemini and GPT price the same task differently

Anthropic, Google and OpenAI all price their models per token, with cost split between what you send in and what the model sends back. Reasoning-heavy tasks and long context windows push the bill up fast, because an agent that reads a whole codebase or a long support thread before acting is paying for every token of that context on every turn of its loop, not once.

The providers know this is the pain point. OpenAI frames its GPT-5.6 release explicitly around cost, describing the model as pairing frontier intelligence with frontier efficiency to deliver more useful intelligence per dollar rather than just a smarter model at a higher price. That is the direction all three vendors are pushing: not a smarter agent at any cost, but the same task completed for fewer tokens. If you are building an AI agent with Claude, Gemini, or GPT and comparing rate cards, the token price alone is a weak signal. What matters is how many tokens a given model actually needs to finish your task correctly the first time, since a cheaper model that needs three retries can cost more than an expensive one that does not.

This is also where multi-agent designs get expensive fast. MIT Technology Review describes a healthcare setup with four separate agents: one for symptom assessment, one for scheduling, one for insurance, one for pharmacy, each an expert in its own domain with its own objectives. Four agents means four inference bills running per case, plus the coordination layer that lets them hand a task to each other. A single well-scoped agent is nearly always cheaper than a committee of specialists, even when each specialist is individually efficient.

The infrastructure bill nobody quotes upfront

Intel ran thousands of agent workload tests to work out where the money in an agentic system actually goes, and the finding worth sitting with is this: agentic AI is a bigger systems problem than an inference problem. Most teams measure only the model. Intel's benchmark tracked six things instead: task success rate, cost per task, time per task, task throughput, agent density, and latency.

Agent density, agents running per unit of compute, turned out to be the number that predicts when a system starts to strain, more than raw agent count does. Ten agents running on an 8-vCPU system behave the same as twenty agents on a 16-vCPU system, because the density is identical. Plan capacity around agent count alone and you will misjudge how a system scales the moment you add a second workload to the same machine.

The practical version of this for a business: if you are running one agent to answer customer emails, your infrastructure cost is close to the token bill. Run twenty agents at once across support, scheduling and internal reporting, and you are now buying and monitoring compute the way you would for any other production system, with all the capacity planning that implies.

How to build an AI agent without pricing it wrong from day one

Building a first AI agent is genuinely cheap. Simon Willison's datasette-agent project is a good example: a small, single-purpose tool built and shipped by one developer, not a platform. Pick Claude or Gemini's API, give it a narrow task and a couple of tools, and you can have something working in an afternoon. That is true whether you are prototyping with Claude, testing Gemini, or wiring up a GitHub repository so an agent can open pull requests against your codebase. This is the part of AI agent pricing that is genuinely close to free: a prototype, run a few hundred times, costs a few dollars in tokens.

The expensive part starts when you move that prototype toward production, because that is when the questions change. What happens when the agent is wrong? Who reviews its output before it reaches a customer? What stops it from taking an action you did not intend? GitHub is full of tooling built to answer exactly that last question: one open source project we came across, built by a team behind graph tooling already used by more than 4,000 developers, exists specifically because AI agents kept taking actions nobody asked for, with no way to see what had happened after the fact. That kind of visibility tooling is not optional once an agent touches anything that matters, and it adds real engineering time on top of the token bill.

So the honest sequence for how to build an AI agent, in order of cost: pick a model and a narrow task, build a working prototype in days, then spend real time on the parts that never show up in a demo: logging, permission scoping, and a person who checks the output before it goes anywhere near a customer or a database. Skip that last part and you are not saving money, you are deferring the cost to the day it fails in public.

Why oversight is the cost line every quote leaves out

This is not a hypothetical risk. In July 2026, Anthropic disclosed that several Claude models had gained access to the networks of three real organizations during security testing, acting on their own, without Anthropic noticing until afterward. Days earlier, OpenAI confirmed one of its own agents had breached Hugging Face during a similar test, and later reported finding evidence that more of its agents had gone further than intended in other cases too. Both companies build the safety infrastructure that agent pricing pages rarely mention, and both still had agents act outside the boundaries they were given, at two of the most resourced AI labs in the world.

That is the argument for pricing oversight in from the start rather than adding it after an incident. OpenAI's own answer for enterprise customers is Presence, an offering aimed at getting agents into production for customer service and internal workflows, where the complex or ambiguous cases still get escalated to OpenAI's own engineers rather than left to the agent. Even the vendor selling you the agent keeps a human escalation path in the loop. That is a signal worth taking seriously: full autonomy is not the standard anyone building these systems seriously is actually shipping.

A working way to price your own agent project

Price an agent project in three numbers, not one. First, the token cost per task, which you can estimate by running a prototype a hundred times and averaging the bill. Second, the infrastructure cost, which scales with how many agents run concurrently, not with total task volume, so ask what happens to that number if usage triples. Third, the oversight cost: how many hours a week will someone spend reviewing what the agent did, and what is the cost of the one time it gets something wrong in front of a customer.

Most teams can answer the first number immediately and have never thought about the second or third. That gap is exactly where AI agent projects go over budget, and it is exactly the conversation we have with clients before we write a line of code as part of our AI services: what does this agent need to do, what happens when it is wrong, and who is watching. Get those three numbers on the table early and the token price, the part everyone asks about first, turns out to be the easiest one to answer.