The token price is not the cost of the task.

Use this guide to: plan a bounded AI workflow and measure the accepted result.

Choose the outcome before the model

Suppose a team wants to extract a set of fields from supplier documents. The relevant output is an accepted record that meets the team's requirements. It is not a generated paragraph or a successful API response. Define the fields, tolerance for errors, handling of missing values and the situations requiring a human decision.

Once that acceptance rule exists, model selection becomes an experiment. Run representative tasks through each candidate workflow. Keep the input set and review standard consistent. Record the date and configuration, since a result without those details is difficult to interpret or reproduce.

Count the whole path to acceptance

For each accepted task, count model calls, retrieval or other tooling, retries, review time and exception handling. A low-priced call may need several attempts or more review. A more expensive call may still fail on an important class of inputs. Neither conclusion follows from the price sheet alone.

A useful working equation is: cost per accepted task equals total delivery cost divided by accepted tasks. The numerator must include failed attempts if they were part of delivery. Report acceptance rate and quality alongside the cost, so a workflow cannot appear cheaper merely by discarding difficult work.

A deliberately simple comparison

In a hypothetical batch, Workflow A costs $20 in model and tooling charges and needs $80 of review. Workflow B costs $40 in model and tooling charges and needs $30 of review. If each produces 100 accepted tasks at the same required quality, the simplified costs are $1.00 and $0.70 per accepted task.

Those numbers are constructed, not observed product results. They exclude development, integration, security review and ongoing monitoring. Their purpose is to show how a model with a higher direct charge could support a lower delivery cost. Change the review assumption and the conclusion can change too.

Treat errors as operating events

A field-level error, a delayed answer and an unauthorized action can have very different consequences. Separate errors that a reviewer can cheaply correct from those that should stop the workflow. Specify escalation, rollback and ownership before expanding access. Do not reduce unlike consequences to an arbitrary average accuracy score.

NIST's AI Risk Management Framework offers a voluntary approach to managing AI risks. The task-cost worksheet here is our own operational framework; it is not a NIST certification or a claim that a workflow meets a standard. Use risk assessment to choose the boundaries within which a cost comparison is meaningful.

Scale only after the operating loop works

A pilot should reveal who reviews exceptions, how changes are evaluated and what evidence would trigger a pause. Repeat the evaluation when the input distribution, model configuration or business process changes. Lower token prices can be helpful, but the useful gain is a reliable outcome delivered at an acceptable total cost.