Does a model have to compute on every single run?

“We'll put AI on that.” In many conversations that sentence closes the question of automation, when in fact the real decision starts there. It is not whether a model is involved, but when: once at build time, or on every single run. That question decides the cost, the reproducibility, and only last of all the electricity.

What one run costs, it costs again every month

A model that computes on every run consumes tokens on every run. A program built once consumes them while it is built and never again. The difference is not a matter of opinion, it is a curve: one line rises with every pass, the other stays flat.

One study measured exactly this. When a workflow is translated into code once rather than sent to a model on every execution, the effort breaks even after roughly 17 passes; at 1,000 passes token consumption is lower by a factor of 57 (Compiled AI 2026). For an analysis you run monthly, that is not quite a year and a half. For one that runs daily, it is a good two weeks.

The same question twice, a different number twice

In a finance department the second difference weighs more than the first. A program you start twice with the same figures returns the same result twice. With a language model that is not a given, not even when it is set to its most uniform setting.

One study had five models compute the same task sixteen times each, at temperature zero, the setting meant to rule out randomness. Small models of seven to eight billion parameters answered identically across all passes. The largest model tested, at 120 billion parameters, repeated itself in 12.5 per cent of cases (LLM Output Drift 2026). For a summary that is bearable. For a figure that goes into a closing, it is not.

«A report you cannot produce identically a second time is not a basis. It is a snapshot.»

Whoever checks your figures asks for exactly that: the same input, the same result, repeatable at any time. A workflow in code does this by itself. A model in live operation has to be forced into it, and the proof is owed by you.

Electricity is the weakest argument

Energy consumption is often held against language models. Of the three arguments it is the weakest, however, and it is fair to say so. Google measured the consumption in its own production, across the whole chain from the chip to the cooling: a median text prompt to Gemini takes 0.24 watt-hours (Google 2025). That is little.

The figure holds for a short question, though. It grows with the volume the model has to read. For a comparable request with 10,000 tokens of input the estimate rises to around 2.5 watt-hours, and to around 40 at 100,000 tokens (Epoch AI 2025). A monthly analysis is not a short question. It pushes whole tables through the model, and it does so again every month.

Where a model is the right choice

It does not follow that models have no place in operation. They are the right choice wherever the task is genuinely new each time: writing a text, reading a document whose structure you do not know in advance, answering a request in your own words. That work cannot be translated into fixed rules, because the fixed rules do not exist.

The difference lies in repetition. What runs the same way every month belongs in code. What differs every time may go to a model, and a person releases it before it leaves the house. We hold ourselves to this: the reply to an enquiry through our contact form is drafted by a model and only goes out after review.

What you can ask the provider

• Does a model compute on every run, or only at build time?
• How often does the workflow run per year, and at which run is the build time paid off?
• If I have the same month computed twice: does the same thing come out twice?
• What happens when the model's provider replaces the model?

The question, then, is not whether you use AI. The question is where it sits: once at build time, where it does a great deal and repeats nothing, or in every pass, where it costs again every month and has to be justified again every month.