What does an AI assistant cost per request it actually resolves?

The price of a million tokens does not tell you the cost of a usable assistant. It describes a billing unit, whereas an organisation needs an outcome: a resolved request, a correctly processed document or a completed action. To compare two solutions, follow the entire chain, include rework and divide expenditure by an outcome defined consistently for both.

This is the distinction proposed by the FinOps Foundation in its unit economics framework: connect a technical measure to a unit that reflects the activity. The method below is Pnebbula’s proposal for applying this principle to a document assistant. It provides neither supplier prices nor a universal profitability estimate.

Start by naming the expected outcome

“A response generated” and “a request resolved” are not interchangeable. If the assistant replies quickly but forces the reader to check everything, counting each generation as a success conceals the remaining work. A correct response that arrives after the useful deadline may also fail to deliver the expected service.

For an internal assistant, a testable definition might be: a response supported by an authorised source, containing the necessary information, with no critical error and delivered within the deadline. This is an example rule to adapt to the business context. You must also decide how to handle a justified abstention. Refusing to answer for lack of evidence can be good behaviour without constituting automatic resolution.

Keeping these statuses separate prevents a misleading metric. You can track requests received, responses usable without rework, requests resolved after intervention and unresolved requests. The total should reconcile with incoming requests, without counting several attempts on the same case more than once.

Map the chain before filling in the budget

A document assistant may retrieve passages, rank them, call a model and then send a response to a tool. The guide to RAG (in French) explains this preliminary retrieval. A single visible interaction can therefore involve several technical operations.

The table is a data collection checklist, not a claim that every assistant incurs every cost listed.

Cost to examine	Data to collect	Mistake to avoid
Generation	Billed usage by call and model	Counting only the tokens visible in the response
Retrieval and tools	Calls, indexing, storage and services used	Overlooking a second bill
Operations	Attributable hosting, monitoring and maintenance	Comparing a complete service with an isolated computation
Rework	Time spent checking or correcting results	Presenting all generation time saved as time freed up
Setup	Development, document preparation and integration	Making the initial investment disappear
Leaving the service	Export, migration and restoration work specified in the contract	Assuming a change of supplier will be free

An API bill and staff time cannot be combined without an accounting convention. Specify the period, currency, treatment of taxes and value assigned to time. If infrastructure serves several applications, document the share allocated to the assistant. A debatable allocation remains a calculation assumption, even when the bill total is accurate.

An example where the price per call gives the wrong ranking

Consider two entirely fictional configurations handling 1,000 identical requests. The amounts do not illustrate any market price. The resolution criterion is fixed before the test; rework costs are included in the scope.

Fictional monthly figure	Configuration A	Configuration B
Generation and tools	€100	€180
Allocated operations	€200	€200
Review and rework	€900	€420
Total included	€1,200	€800
Requests ultimately resolved	800	900
Cost per resolved request	€1.50	About €0.89

The calculations are 1,200 ÷ 800 and 800 ÷ 900. B costs more for generation but less per resolution in this example. This does not demonstrate that more expensive models are better: the result follows from the explicit assumptions about rework and success.

The 200 requests left unresolved by A do not disappear. Their costs are included in the numerator, but they do not increase the number of outcomes achieved. Show their number alongside the unit cost. Two services can have the same cost per resolution while leaving very different volumes of requests unresolved.

Make comparisons robust to changes in scope

The previous table deliberately excludes setup. For an investment decision, add a view over a chosen period: initial investment plus expected operating expenditure. Show separately what has already been paid, what will be committed and what remains uncertain. Spreading an initial cost over twelve months or three years changes the result; the period must be visible, not hidden in a formula.

Next, test sensitivity. Repeat the calculation with fewer resolved requests, more rework or lower usage. A fixed subscription spread over a small volume does not produce the same unit cost as a heavily used resource. These scenarios are conditional calculations, not demand forecasts.

Also compare comparable tasks. A solution aimed at simple questions should not be credited with the performance of another that handles difficult cases. A table by request category helps reveal whether the improvement comes from better performance or a change in the population being served.

Measure human work without inventing savings

A shorter processing time does not automatically mean expenditure has been avoided. It may free up capacity, reduce waiting or allow more thorough review. These are possible benefits, but they differ from an observed reduction in invoices or payroll.

The FinOps Foundation specifically distinguishes savings, cost reduction and cost avoidance. For your assessment, record the time observed before and after on equivalent tasks, then explain what the organisation does with it. If that second element is not measured, report an observed time saving, not a certain financial return.

Nor should verification disappear simply to make the budget look favourable. The NIST AI Risk Management Framework addresses trustworthiness and evaluation throughout the system lifecycle. It does not prescribe a review rate suitable for every use. The level of oversight depends, among other things, on the severity of an error and the opportunities to correct it.

The document to request before choosing

A useful comparison can fit into a file where each row connects a request, its calls, its outcome and any rework, without retaining more personal data than necessary. Shared expenditure can stay in a separate sheet, together with its allocation rule.

Attach three elements to the summary: the definition of “resolved”, the list of included expenditure and the distribution of outcomes by request type. Any missing data should remain marked as unknown. A very precise average calculated over an incomplete scope is no more reliable than an honestly bounded estimate.

To decide between an internal installation and a remote service, complement this checklist with the scope of a local or remote pilot (in French). The useful outcome is a reproducible comparison of the expected service, with observed costs kept separate from assumptions.

Sources and scope

Sources consulted on 22 October 2026: FinOps Foundation, Unit Economics, an evolving professional framework; NIST, AI Risk Management Framework, a voluntary risk management framework. The checklist, calculation conventions and fictional amounts are educational material developed by Pnebbula. No quotation or enterprise deployment was evaluated here.