What an AI answer really costs

A fast answer is not a finished task. A draft that someone spends two hours fixing has only moved the work. It moves from the computer to the person. An extra check can be worth it when it catches a mistake early. So we look at the whole path, from the first request to a usable result. Preparation, questions, waiting and corrections all belong in that view.

This matters at three points our products address. People work with AI. AI systems work with each other. And ordinary programs exchange data. A person needs an answer they understand. An AI system needs the result of the previous step. A program needs data in a format it can read. A better handover often helps more than a faster calculation.

Every task needs a clear standard. Take an AI writing a decision paper from five documents. The requirements might be these. All the important options appear. Every number has a current source. Open questions are listed at the end. Only then can you compare two approaches fairly. A short text that drops the decisive exception is not finished.

A comparison can start small. Ten typical tasks already show a lot. The hard cases matter most: documents that contradict each other, missing details, a request that changes halfway through. We want to know where an approach holds and where it needs help. Those limits are part of the result, just like the runs that went well.

One of the things we built into LeanCTX is a ledger for savings. It records how much a prepared output shrank. Aggregated entries can be signed. A signature shows whether someone changed an entry and which key it came from. It says nothing about whether the answer was good. And it does not measure electricity saved. [1]

That distinction matters to us. A token is a small unit of text that many AI systems count in. Fewer tokens can mean less transfer and less processing. How much time, money or energy that saves depends on the whole workflow. Selecting and preparing information costs computing time too. We count that effort in rather than leaving it out.

Before a decision we put several observations side by side. Was the task done correctly? How long did it take in total? How much did a person have to fix? How much computing was involved? An improvement can be large on one point and small on the next. That picture helps more than a single big number.

Repeatability gives a comparison weight. We record what we started from, which information we used and the conditions we tested under. Then the same question can be asked again later. One especially good run is a hint, no more. A poor run belongs in the picture too. It shows when a shortcut creates extra work.

Software runs on real devices. The Software Carbon Intensity Specification separates three things: the electricity, the emissions of that electricity and a share of the emissions from making the hardware. It also asks for a defined unit of work and clear system boundaries. That separation helps us. Energy, emissions and text volume are three different things. [2]

We want to use time, computing power and energy carefully. Where we have no energy measurement, we say so. We do not turn saved tokens into a measured climate benefit. And one thrifty run says little about the total. If a workflow is used ten times as often, the overall volume matters too.

A plain way of working follows from that. We pick one step we can improve. We check what it does for the task. Then we look at what it changes in the rest of the workflow. Sometimes better selection of information helps. Sometimes a clearer question does. Sometimes a small, ordinary software function is enough, with no AI at all.

In our products, efficiency should show up as a task done well with sensible effort. We hold to that even when a single metric then looks less impressive. People working with our products should be able to judge the difference themselves. The time gained belongs to them: for the next idea, for a more careful decision, or simply for something else.