What an AI Agent Really Costs Per Month: A Cost Model Including Usage, Control and Corrections

A monthly AI agent bill has seven line items, and model usage is only one of them. The rest are failed runs that get retried, the retrieval and embedding side, storage, the human review time the design requires, monitoring, and upkeep when a prompt or a source document changes.

The seven line items that make up the bill

The common mistake in pricing an agent is to open the model vendor's billing screen and assume that is the bill. That screen measures one thing: tokens sent and returned. It cannot see who read the output, who corrected it, or who maintains the documents the agent leans on.

Those seven rows are the model. Nothing in them requires insider knowledge, and everything in them is present except the numbers, which have to be measured or read.

Why is the model line only a small part of the cost?

Because an agent whose output nobody checks is not an agent, it is a text generator. The moment the design includes a person who approves, corrects or escalates, a cost enters the bill that is measured in minutes rather than tokens, and priced in wages rather than on a vendor page.

That explains a result which looks strange at first. Halving the token price barely moves the bill, while cutting the review rate from twenty percent to five percent transforms it. Both numbers sit in the same table, but they are not the same order of magnitude.

A worked example with placeholder rates only

Every number below is a placeholder, not a price. Replace each one with what you read on your vendor's pricing page on the day you build the model, and write that date beside it.

1. Fix the volume: 4,000 runs per month.
2. Measure the average run: 3,000 input tokens and 600 output tokens. Measure it, do not guess it.
3. Multiply out: 12 million input tokens and 2.4 million output tokens per month.
4. Apply placeholder rates of one dollar per million input and four dollars per million output: 12 dollars plus 9.6 dollars, so 21.6 dollars.
5. Add an eight percent retry rate: roughly 23.3 dollars.
6. Add retrieval, storage and monitoring at a placeholder 55 dollars.
7. Add human review: fifteen percent of runs are checked at two minutes each, which is twenty hours a month.

The point lands at the last step. Twenty hours of review costs, at any sane wage, several times all six rows above it combined. If your own arithmetic comes out the other way round, the likely reason is that human time was never counted.

What happens to the bill when volume doubles?

Not every row responds the same way, which is exactly why the model should be a formula rather than a single number.

• Model usage grows linearly with volume. Twice the runs, twice the tokens.
• Storage and embeddings barely move, because they track document count rather than question count.
• Monitoring usually steps up once, when a metric or log-retention ceiling is crossed.
• Human review grows linearly, and it is the row that breaks first. Twenty hours a month is part of a job. Forty is not.
• Maintenance does not scale with volume at all. It scales with how often the sources and the requirements change.

So the first investment that pays for itself is almost always reducing the share of runs that need a human eye, not switching to a cheaper model.

Where you can cut cost without breaking the output

• Shorten the context. Sending a whole document when three paragraphs would do is the most common waste, and the unit itself is explained in tokens and context windows.
• Cap the output length. A free-form answer costs more than a structured one with named fields.
• Cache results for repeated questions instead of running them again.
• Split the work by stage. Not every step in a flow needs the most expensive model.
• Stop retrying errors that a retry cannot fix, such as malformed input.
• Measure before you change anything. A prompt edit that looks free can double output tokens.

How to measure cost per run inside the system

The durable answer is not to read the bill at the end of the month but to record a cost against every single run as it happens. In a call-transcription feature I built, each record stores the audio minutes, the prompt tokens and the completion tokens, and converts them to dollars through one rate table defined in code. The result is that you can ask "what did that call cost" rather than only "what did the month cost".

• Store per run: an id, the model, input tokens, output tokens, attempt count and duration.
• Keep the rates in a single constant in code, annotated with when they were read and from where.
• Compute the cost at run time and persist it, so history does not silently change when a rate changes.
• Aggregate by customer, by task type and by day, not only by month.
• Add a threshold alert for an outlier run, the same discipline applied to silent failures in automations.

The difference between an estimate and a measurement is that an estimate answers one question once, and a measurement answers every future question. After a month of real data, the model you built at the start becomes a control instrument instead of an excuse.

Sources

• OpenAI API pricing
• Claude platform pricing documentation