Commercials · 7 min read · Aug 12, 2026

Three cost lines, and what moves them.

Almost nobody publishes this, which is why every buyer assumes the worst. The monthly running cost of a bespoke AI operating system breaks into three lines. Here is what sits in each, and — more useful — which ones grow when you add outlets and which ones don't.

Why the number is usually hidden

Running cost is genuinely variable, so it is easy to justify not quoting it. That is also convenient, because the number is often uncomfortable and it surfaces after the contract is signed. Ontilus sizes all three lines against real transaction volume during technical scoping and gives the figure before signature, including how it grows.

You should expect the same from anyone you are evaluating. If a vendor cannot tell you what their system costs to run at your volume, one of two things is true: they have not built it at your scale, or they do not want you to know before you commit.

Line 1 — AI inference

What you pay the model providers. This is the line most people fixate on, and usually not the largest.

It scales with how much text goes in and out, not with how many outlets you run. A daily briefing across thirty outlets is not thirty times a briefing across one — it is one summarisation over a larger table. What actually moves this line:

  • Frequency. Hourly analysis costs meaningfully more than a daily briefing, and is rarely worth it for decisions nobody makes hourly.
  • Model tier per task. Classification, extraction and routing do not need a frontier model. Reserve the expensive tier for the reasoning that earns it.
  • Context discipline. Sending an entire table when a pre-aggregated summary would do is the most common way this line quietly triples.

The single biggest lever here is architectural, not commercial: aggregate in the database, reason over the aggregate. Groups that send raw rows to a model pay for the same computation twice — once in tokens and once in accuracy.

Line 2 — Cloud infrastructure

Compute, database, storage and egress. This line does scale with outlets, because it scales with the volume of transactions being stored and queried.

The component that catches people out is egress, not storage. Storage is cheap and predictable; moving data out — particularly media — is metered on most platforms and grows with usage rather than with data volume. We have re-architected a media layer mid-project for exactly this reason, moving delivery to storage with unmetered egress so that growth in viewing stopped translating into growth in invoice.

Worth asking any vendor: which parts of my bill grow when my customers use the product more, as opposed to when I add outlets? Those are two very different curves.

Line 3 — Integration middleware

The connectors, sync agents and scheduled jobs that keep source systems flowing in. This line scales with the number of distinct systems, not with the number of outlets.

Twenty outlets on one POS is a cheaper integration surface than four outlets on four different systems. This is the line where a legacy on-premise system costs real money — not because the ingestion is expensive to run, but because it needs an agent deployed, monitored and maintained per site.

How the three behave as you grow

LineGrows with outlets?Main lever
AI inferenceBarelyFrequency, model tier, context size
Cloud infrastructureYesTransaction volume, media egress
Integration middlewareNo — grows with distinct systemsConsolidating source systems over time

The practical consequence: adding your eleventh outlet on a POS you already integrate costs far less than adding your second distinct POS. Groups that understand this tend to make different decisions about which system a new outlet opens on.

What we commit to

Transparent, itemised running costs, confirmed at technical scoping and sized against your actual transaction volume — before you sign, including how each line grows as you add outlets. You will also be told exactly what you own in the codebase up front rather than after.

None of that is unusual to ask for. It is only unusual to be offered.

Dealing with this in your own group?

We answer scoping questions before there's a contract in sight — including the ones about cost and data handling.

Questions

Short answers,
in full.

The questions this article gets asked most, answered so each one stands on its own.

Talk to us
What does an AI operating system cost to run each month?

It resolves into three lines: AI inference, cloud infrastructure, and integration middleware. Ontilus sizes all three against your actual transaction volume during technical scoping and gives you the figure before you sign, including how each grows as you add outlets. A vendor who cannot quote this at your volume has either not run at your scale or would rather you found out afterwards.

Does the cost scale with the number of outlets?

Only partly. Cloud infrastructure grows with transaction volume, so it does scale with outlets. AI inference barely does — a briefing over thirty outlets is one summarisation over a larger table, not thirty briefings. Integration middleware scales with the number of distinct source systems, not outlets, so twenty outlets on one POS is cheaper to integrate than four outlets on four systems.

What is the biggest driver of AI inference cost?

Context size and frequency, not headcount or outlet count. Sending an entire table to a model when a pre-aggregated summary would do is the most common way this line triples. Aggregating in the database and reasoning over the aggregate cuts cost and usually improves accuracy at the same time.

Which part of a cloud bill surprises people most?

Egress rather than storage. Storage is cheap and predictable, while moving data out — particularly media — is metered on most platforms and grows with how much customers use the product, not with how much data you hold. It is worth asking any vendor which parts of the bill grow with usage as opposed to with outlets.