Local inference versus a hosted API: compare cost per accepted deliverable
The useful unit for comparing local inference with a hosted API is an accepted deliverable, not an isolated token price or the purchase price of a GPU. Include failed attempts, editing effort and operational work while keeping the same output requirement on both routes.
Define an equivalent task
Choose a representative input set and write the acceptance criteria before running either route. A quick draft and a production-ready image are not equivalent outputs. If the systems expose different capabilities, document that difference instead of forcing an artificial like-for-like score.
Keep the attempt budget and human review process consistent. Record retries, rejected outputs and any editing performed outside the model. A route that produces inexpensive but unusable results can have a higher practical cost than one with a larger per-request charge.
Measure the hosted route
Use the current pricing documentation for the exact endpoint and model. Record the pricing date and the units charged rather than hardcoding a rate into a long-lived article. Include storage, tool use, transfers or other billed components where they apply to the actual application.
Measure the complete request lifecycle and keep failed requests separate from successful ones. Determine which failures can be retried safely. Do not assume that all failures are free or that a consumer subscription includes an unrelated API workload.
Measure the local route
Record the supported hardware and software required for the chosen model. Include setup time, maintenance, energy, storage and the effect of occupying a workstation needed for other work. A machine already owned can still have an opportunity cost, while a new purchase may be unnecessary for a small occasional job.
Measure cold starts and repeated jobs separately. Test the real deliverable at the required settings, not a reduced example chosen only because it fits. Keep model licensing and data handling in the comparison alongside resource consumption.
Choose a workload-specific boundary
Build a decision sheet showing accepted outputs, elapsed time, human intervention and total observed cost for each route. Use current quotations for any purchase decision and avoid extrapolating one trial to every future workload. A mixed route may be appropriate when local drafts and remote final processing have different requirements.
The legacy URL is retained, but the earlier speculative discovery-tax framing is not used as a cost assumption. No universal break-even point is claimed. Recalculate when workload volume, model quality, service terms or local hardware changes, and keep the original evidence so the decision can be revisited.