Define one completed task
An invoice with ten correct fields and one unusable total is not necessarily a successful invoice. Before comparing architectures, write the acceptance policy for one completed task: required fields, permitted corrections, disqualifying failures and whether human review is part of delivery. Apply the same policy to every candidate. Count retries as extra attempts, never as extra completed tasks.
Build the recurring numerator
Include inference, retries, review labour, hosting, monitoring, support and the engineering time needed to keep the service reliable. Direct API bills already include billed attempts; do not add retry charges again. If using token estimates instead, multiply tokens per attempt by the original task count and additional-attempt rate. Keep data preparation and development investment outside recurring cost.
Work through the example
Our synthetic fixture starts with 100,000 original tasks. The API costs $9,000 each month and produces 94,000 accepted tasks: approximately $0.0957 each. The specialist costs $7,900 and produces 96,000 accepted tasks: approximately $0.0823 each. Monthly cash savings are $1,100. A $60,000 investment therefore takes about 54.5 months to recover at unchanged volume and cost. These are assumptions, not benchmark results.
Make the decision reversible
A lower unit cost does not settle the purchase. Check the quality gate first, then compare the cash recovery period with the intended service life and your financing constraints. Test lower volume, more manual review and cheaper APIs. Keep the API if the specialist cannot meet quality or recover its investment within the period you are willing to fund. Export all assumptions so finance and engineering can challenge the same model.
Bring to the decision review
A useful approval pack has the dated API bill, accepted-completion count, review sample, specialist capacity assumption and a named owner for each cost line. Reconcile the model to a representative billing period. If the period was unusual, show the difference rather than smoothing it away. Record which assumptions are measured and which are still provisional; the approval should say what evidence will replace each provisional input.
Sources & editorial record
This is Frontier Development’s decision framework. The references below support the general technical concepts; the worked scenarios and procurement questions are our analysis.
References accessed 16 October 2026. No current price, product availability or legal clearance is asserted. Published study findings are attributed above; this guide reports no Frontier Development experiment. Read the comparison method.
Review history and research boundary
Edition 1.1 · 16 October 2026: added claim-level attribution, explicit evidence boundaries and links to the flagship synthesis. Published by Frontier Development. No named external technical reviewer is recorded. This guide provides a decision framework; it is not a Frontier Development experimental result.
Read the primary-study synthesis →Open the cost tool
Explore a complete synthetic example before using your own inputs.