Saphan
Guides & FAQ

ECONOMICS / COST OF COMPLETED WORK

A response costs little.
What about the finished case?

An API bill measures calls. Your business needs usable results. To compare two workflows, you have to link spending to the work actually accepted.

Written by Saphan · 7 September 2026

Define what counts as a result

Choose a unit of work: a request classified correctly, a record imported with no further correction, or a validated summary. Write down the criterion before the trial. A generated response, even a convincing one, does not automatically count as a completed case.

Fictional example: out of fifty requests given to an assistant, forty end in an accepted record during the observed period. The other ten remain pending or need to be redone. The cost incurred on the fifty requests must not be divided by fifty successful results.

Gather the costs for the same scope

Record the calls made to the model, including retries and resent context. Add document search, text recognition, storage and any other services actually used. For a local route, separate hardware, energy and operations from any API usage.

Also measure the time spent on preparation, correction and manual handling of exceptions. Putting a value on that time remains a management convention that should be stated openly, separate from an invoiced expense. Finally, separate the initial build from recurring operation: allocating them requires an explicit duration and volume of use.

Calculate without hiding the difficult cases

A first measure is: workflow costs over the period ÷ cases accepted over that same period. Specify what goes into the costs. Show alongside it the number of cases submitted, rejected and still open; the quotient alone can hide a growing queue.

If no case is accepted, the unit cost cannot be interpreted: the trial has not yet produced the expected unit. To compare two solutions, use cases of similar difficulty and the same acceptance criteria.

Reduce the cost item that really weighs on the total

If correction dominates, improve the source or the format before looking only for a cheaper model. If retries dominate, examine the errors and how the calls are split. If volume stays low, a simpler workflow may be preferable. Then run the measurement again: a technical saving is only useful if the case remains acceptable.