What an AI agent really costs per month: a model you can check yourself

"How much will this cost per month?" is the first question in every conversation about an AI agent, and almost the only one that gets answered with "it depends". The answer is honest and useless: it gives you neither an order of magnitude nor any idea what to change if the number turns out wrong. Yet the question is perfectly computable. It needs three things: a formula, a reference configuration, and assumptions written down in the open. What follows has all three — plus the anatomy of the bill, four typical budget leaks, four levers, two tables, and a calculator you can put your own numbers into.

One caveat first, and it matters more than any figure below: this is a calculation model, not our invoices. The configuration is invented as a typical tool-heavy agent, not lifted from anyone's production. Every number comes out of the formula applied to declared assumptions; change an assumption and the number changes with it. Prices are taken from OpenAI's pricing page as of 2026-07-25 and they move, so check them before you commit to a decision.

Why "$X per million tokens" is not an answer

A price list gives you a unit price, not a bill. Here is the current line-up as of 2026-07-25, USD per 1M tokens, in the order input / cached input / output: gpt-5.6-sol — 5.00 / 0.50 / 30.00 · gpt-5.6-terra — 2.50 / 0.25 / 15.00 · gpt-5.6-luna — 1.00 / 0.10 / 6.00 · gpt-5.5 — 5.00 / 0.50 / 30.00 · gpt-5.4 — 2.50 / 0.25 / 15.00 · gpt-5.4-mini — 0.75 / 0.075 / 4.50 · gpt-5.4-nano — 0.20 / 0.02 / 1.25.

You cannot get a monthly bill out of that table, because it is missing the three quantities that decide everything: how many tokens go into one request, how many requests the agent makes per task, and what share of the request is served from cache. The middle column — cached input — is about 90% cheaper than regular input, and it is the one most often ignored in an estimate, even though it separates an expensive configuration from a cheap one on the very same model.

There is a second reason. The spread between models doing identical work is enormous: in the configuration below the same volume of tokens costs $50.34 per month on gpt-5.4-nano and $1254.00 on gpt-5.6-sol — almost 25 times more. Until the assumptions are pinned down, arguing about whether a model is "expensive" leads nowhere.

You are paying for re-sending, not for intelligence

A model has no memory between calls. Every step of the agent is a separate request that packs everything in again: the system prompt, the schemas of every bound tool, the conversation history, and whatever the retrieval step found. The model does not remember the previous step — it gets retold, in full. So most of the bill is driven neither by what the user asked nor by what the model answered, but by what is re-sent on every lap of the loop.

The orders of magnitude under these assumptions: the user's question is tens of tokens, while the stable prefix of system prompt plus tool schemas is 15,600 tokens. One step carries 19,100 input tokens against 300 output tokens — 98.5% of all tokens in the exchange are input, and 82% of the input is the prefix that never changes from task to task. Over a month that adds up to 229.2M input tokens against 3.6M output tokens.

The anatomy of one task's bill

flowchart TB
  SP["System prompt"] --> REQ
  TS["Schemas of every tool"] --> REQ
  H["Conversation history"] --> REQ
  RAG["Retrieved context"] --> REQ
  REQ["One request to the model"] --> OUT["Model output"]
  OUT --> MUL["x steps per task"]
  MUL --> BILL["Cost of one task"]

The formula is short enough to hold in your head: cost of a component = (component tokens × steps ÷ 1,000,000) × price per 1M tokens. The bill for one task is the sum over five components; the monthly bill is that sum multiplied by the number of tasks. Everything else in this article is an argument about which numbers to substitute.

stateDiagram-v2
  state "request assembled" as req
  state "model thinking" as model
  state "tool call" as tool
  state "answer to user" as done
  [*] --> req
  req --> model: prefix re-sent
  model --> tool: a tool is needed
  tool --> req: result appended to history
  model --> done: answer ready
  done --> [*]
  note right of req
    Every lap re-sends the prompt
    and all tool schemas
  end note

The five components behave differently, and that is the key to everything that follows. The system prompt and the tool schemas form the stable prefix: identical across requests, and therefore cacheable. Conversation history grows with every step. Retrieved context changes from request to request. Model output is billed at the highest rate — on gpt-5.4-mini output is six times the price of input — but there is little of it, so it moves the total least.

The split that matters here is cacheable versus non-cacheable, not the familiar "prompt versus answer". Only what sits at the front of the request and stays identical between calls can be cached. History, retrieved context and output are never cached — not by provider policy, but because they are different every time.

Four places the budget leaks

flowchart TB
  L["Where the budget leaks"] --> A["Every tool in every request<br/>schemas ignore the task at hand"]
  L --> B["Retrieval set too wide<br/>chunks nobody needed"]
  L --> C["Retries after a failure<br/>a failed tool call costs a full lap"]
  L --> D["History never trimmed<br/>grows with every step"]

Every tool in every request. Schemas go to the model in full whether the task needs one tool or forty. In the configuration below that is 14,400 tokens of schema in every single request — and the largest line on the bill.

Retrieval set too wide. The retriever returns twenty chunks where three would do, and the surplus chunks ride along, billed, through every remaining step of the task.

Retries after a failure. A tool call fails, the model tries again — and that is another full lap with a full prefix. This leak is sneaky because it is invisible in the prompt: it only shows up in the distribution of steps per task.

History never trimmed. Every step appends its result to the conversation, and the next request carries the whole tail. On long tasks history goes from the smallest component to one of the largest.

Four levers

flowchart LR
  subgraph Before
    B1["Every schema every time"]
    B2["Prefix not cached"]
    B3["One expensive model for everything"]
    B4["Full history"]
  end
  subgraph After
    A1["Tool subset<br/>chosen by intent"]
    A2["Stable prefix first<br/>cached tokens cost about ten times less"]
    A3["Cheap model to route<br/>expensive one to decide"]
    A4["History trimmed and summarised"]
  end
  B1 --> A1
  B2 --> A2
  B3 --> A3
  B4 --> A4

Before going through the levers, one caveat without which the last two diagrams read wrong. The four leaks and the four levers are two independent lists, not four pairs. Tool subsetting does answer the every-tool-in-every-request leak, and history trimming does answer the untrimmed-history leak. But caching and model tiering answer none of the named leaks, and neither over-wide retrieval nor retries after failure has a lever of its own on this list: those are handled in the architecture of retrieval and error handling, not on the price list. Both lists happen to have four items; nothing else follows from that.

A tool subset chosen by the request's intent. Give the model the schemas that relate to the task instead of all of them. Under these assumptions, going from 80 tools down to 12 moves the bill from $188.10 to $77.94 per month — 59% off, without editing a single word of the prompt.

Caching the stable prefix. This lever works on a fundamentally different principle from the other three: it does not remove tokens from the request, it makes the same tokens cheaper. Cached input is about 90% cheaper than regular input — roughly ten times cheaper — but only on the part of the request that is cacheable, which is the prefix: the system prompt and the tool schemas. History, retrieved context and output stay at full price. So under these assumptions the total does not fall ten times, it falls 2.5 times: from $188.10 to $74.38 per month. "An agent ten times cheaper" is simply the wrong claim, and the honest figure is impressive enough.

In practice this lever is a discipline of request layout: stable content first, volatile content last, and never reorder between steps. One block moved at the front of the prompt wipes out the cache hit for everything after it.

Model tiering by stage. Routing, classification and field extraction go to a cheap model; the decision goes to an expensive one. The spread on this configuration — from $50.34 to $1254.00 per month on identical work — shows how much sits here, though this lever needs quality measurement at every stage, or the savings get paid for in mistakes.

Trimming and summarising history. On this configuration it is the most modest lever: taking history from 2000 down to 800 tokens gives $188.10 → $177.30, 6% off. Its value is elsewhere — it stops the bill growing non-linearly on long tasks, and long tasks are exactly where history becomes the problem.

Under the same assumptions, holding the model fixed, the other three levers compose with each other: 12 tools instead of 80, a 90% cache share and 800 tokens of history give $42.65 per month against $188.10 — 4.4 times less for the same work.

The reference calculation

Below is the configuration every figure in this article is computed on. Every row is an assumption, not a measurement: it is what we supposed a typical tool-heavy agent looks like. The values match the calculator's fields below. To reproduce this section's figures in it, set both step fields to 8 and the cache share to 90: the calculator opens with a 4–12 step range and no cache at all.

Now the same calculation before and after caching — the one lever that does not change the content of the request at all. Steps: 8. Tasks: 1500 per month (50 per day × 30 days). Model: gpt-5.4-mini. No European-region uplift.

On rounding, so the columns do not puzzle you: components are shown to the cent, so the right-hand column adds up to $74.37, while the model's exact value is $74.376 — which the calculator below displays as $74.38.

Two figures from that table are worth remembering, and both belong to this configuration and no other. First: tool schemas are 69% of the bill before a single lever is pulled, $129.60 out of $188.10. Not the model, not the length of the answers, not the history — the descriptions of tools, most of which the model does not even call on any given step. Second: caching the prefix takes the total from $188.10 to $74.38 — 2.5 times less, with the same set of tools, the same model and the same answer quality. The only thing that changes is the order of blocks in the request.

One question that comes up almost immediately in Poland and across the EU: what keeping the processing inside a European region costs. Per the 2026-07-25 pricing snapshot: regional data-residency processing costs +10% — not on every model, but on those released on or after 2026-03-05 that are also eligible for data residency. It is an uplift on the whole token bill, not a separate plan and not a separate contract. The pricing page publishes no release dates, so whether a particular model falls under the rule has to be established separately. For a model that does, under these assumptions the uplift turns $188.10 into $206.91 without caching, and $74.38 into $81.81 with it. For projects where residency is a question at all, ten percent is usually easier to pay than to argue about — but it belongs in the estimate from the start rather than in the first invoice. The calculator has a checkbox for it.

The calculator: your own inputs

Here is the same model, interactive. The fields correspond to the rows of the assumptions table, and the step range gives you a lower and an upper bound, because steps per task is the least stable quantity in the whole model. Start with the number of tools and the number of steps — they move the total more than anything else.

How to check the model against your own case

A model is only as useful as its inputs are true — and the inputs are measurable, on your systems rather than ours. Four measurements settle the question.

Count the prefix with a tokenizer. Take exactly the system prompt and exactly the tool schemas that actually go into the request, and count the tokens. This is where people most often discover there is an order of magnitude more schema than they eyeballed.

Read the usage fields in the API responses. The provider returns the actual numbers for every call, including how much of the input was served from cache. It is the only way to know your real cache-hit share instead of assuming it.

Collect the distribution of steps, not the average. Long tasks make the bill. A median of 4 steps with a tail at 20 produces a very different month from "about 6 on average", which is exactly why the calculator takes a range rather than a single number.

Run a week and compare it against the model. A gap almost never means the formula is wrong — usually it is an assumption nobody wrote down: retries after failures, tools nobody thought to count, retrieval wider than expected. Finding those before rollout is cheaper than after.

If you are sizing an agent for your company and want the calculation done on your tools, your tasks and your data policy, write to us at [email protected]. We build this model before the work starts — together with an honest read on which levers are actually available in your case and which ones run into the architecture.