What It Really Costs to Run a Custom AI Agent

Everybody asks the same question first: how much will the API cost me. It is the easiest number to find, which is why it gets all the attention, and it is usually the smallest thing on the invoice.

The costs that actually hurt do not arrive as an invoice at all. They arrive as your Saturday, as an evening spent working out why the agent went quiet on Thursday, and as the slow realisation that this thing now needs a person to care about it every month.

So the useful way to price an agent is not per token. It is total cost of ownership over twelve months, with your own time priced at what you would charge a client for it. Do that once and most build or hire arguments answer themselves in about ten minutes.

It is also why Sistava prices the whole thing as one subscription. The model spend, the schedule, the limits, the memory, the run history and the upkeep are inside it, so there is no separate bill to forecast and no maintenance hour to find. You describe the job, connect the accounts, and hire an AI Employee. Building your own is still the right call for some people, and the numbers below will tell you if you are one of them.

What are the actual cost lines of a custom AI agent?

Five, in descending order of surprise. Build time, ongoing maintenance, third party tools and hosting, model tokens, and the cost of being wrong. Only the fourth one appears on a dashboard, and it is the one people spend all their planning on.

Price each in the same currency, which is money per year with your time included. An agent that saves four hours a week and costs six hours a month to keep alive is still a win. An agent that saves twenty minutes a week and costs the same is a hobby, and there is nothing wrong with hobbies as long as you know which one you have.

• Build time. Usually the largest single line. A demo is an afternoon. Something you trust unattended is three to six weeks of part time work for one well defined job, and most of that is triggers, limits, logging and error handling.
• Maintenance. About an hour a month per live agent, forever, because tokens expire, forms gain fields and APIs change versions. This one never ends, which makes it the biggest number over a year.
• Tools and hosting. Somewhere for the agent to run, a queue or scheduler, a log store, and any paid API it calls. Individually small, collectively the line that quietly doubles.
• Model tokens. Real, forecastable, and for most small business jobs the smallest of the five. It only becomes the big line at genuine volume or with a badly shaped loop.
• The cost of being wrong. One wrong message to a customer, one duplicate refund, one week of silence nobody noticed. Rare, uncapped, and the reason guardrails are not optional.

How do you forecast the token bill before you build?

Three numbers multiplied: runs per month, tokens per run, and your model's price per million tokens. Runs you already know. Price is published. Tokens per run is the one people guess badly, and it is the one that decides everything.

Tokens per run is not the length of the question. It is the length of every step, because an agent resends the whole growing conversation on each turn. A task that takes eight tool calls does not cost eight times one call, it costs closer to the sum of a conversation that gets longer each time.

Measure it instead of estimating it. Run the agent ten times on real inputs, read the token count for each, take the worst one and add half again. That is your per run figure. Multiply by monthly runs and you have a forecast you can actually defend, usually within a factor of two.

A worked example: Yusuf and the maintenance inbox

Yusuf manages about ninety rental properties with two staff. Tenants report maintenance issues by email in every possible format. His agent reads each one, works out the property, classifies the urgency, and either raises a job with the right contractor or asks the tenant one clarifying question.

Volume is roughly four hundred emails a month. Each run is short: one email in, a lookup, a decision, one action. When he measured it, the worst run used a fraction of the tokens a long research task would, and the monthly model spend landed in the range of a couple of takeaway coffees. He nearly stopped the analysis there and concluded it was free.

• The build. Five weekends. Two on the fun part, three on duplicates, retries, the contractor allow list and the logging. Priced at his own hourly rate this dwarfed everything else in year one.
• The infrastructure. A small always on server, a managed queue and a log store. Each one modest, together a recurring line about as large as the model spend.
• The maintenance. Two real interruptions in six months, plus a monthly read of the log. Averaged out, close to an hour a month, exactly as predicted and exactly as annoying.
• The near miss. In month two a badly formatted email sent the agent into a loop that re read the same thread over and over. The step limit stopped it after twelve. Without that limit it would have been the largest line on the page.

His verdict after six months was that the agent was clearly worth it, and that the token bill was the least interesting fact about it. What made the decision was two staff getting an hour of their morning back and contractors being called within minutes instead of the next afternoon.

What makes an agent bill blow up?

Four things, and none of them are the price of the model. A loop with no step limit, a context that grows without ever being trimmed, a retry that hammers a failing API, and a trigger that fires more often than the work actually appears. Any one of them can multiply a sensible bill by ten in a weekend.

All four have the same defence: caps enforced in code, outside the prompt. A maximum number of steps, a spend ceiling per run and per day, a rule that stops when the same tool is called with the same arguments twice, and an alert the moment any of them trips.

What does the cost not buy you?

Spending more does not buy reliability. A bigger model reduces some mistakes and changes none of the failures that actually take agents down, which are expired credentials, duplicate triggers, changed forms and silence. Those are fixed with engineering, not with budget.

It also does not buy the things agents simply do not do. It will not chase a person until they reply, hold a plan together across several days without losing the thread, notice that your policy changed, or take responsibility for a decision. No spend level changes any of that.

And it does not buy an end to maintenance. Whatever you build or hire, something it depends on will change this year. The only question is whether that hour lands on your calendar or someone else's.

Work out your own number in an afternoon

1. Count the runs per month — How many times does this task actually happen. Use last month's real count, not the busy month you remember.
2. Measure tokens on ten real runs — Take the worst one and add half again. Guessing this number is the single biggest source of wrong forecasts.
3. Multiply for the model line — Runs times tokens times your model's published price per million. Now you have the number everyone asks about first.
4. Add hosting, tools and any paid APIs — Include the small ones. A queue, a log store and one paid integration together often match the model spend.
5. Price your build time and one hour a month — At what your time is genuinely worth. This is the line that decides most build or hire questions, and it is always the one left out.
6. Compare over twelve months, not one — A one month view flatters building. A year view includes the maintenance, and that is the view you will actually live in.

When people run that calculation properly, the result is rarely close. Either the job is unusual enough that building is clearly right, or the twelve month total is several times a subscription and the argument ends. The uncomfortable cases are the ones where nobody priced their own time.

The takeaway is not that agents are expensive. Most are not. It is that the expensive part is never the part with a published price list, so a budget built only from token costs is a budget that will be wrong by month three.

Count all five lines, over twelve months, with your own time in there at a real rate. Then decide.