MyDot Consultancy

Featured image: AI-generated conceptual illustration. Sources checked 26 October 2026.

A cheap model call can sit inside an expensive workflow. If the agent retries repeatedly, produces drafts that require extensive correction or leaves tasks for employees to restart, the price of one prompt says little about the cost of delivering the result. Evaluate the complete task, including the work that does not succeed.

Cost per completed task is an operating measure, not a universal return-on-investment formula. Its usefulness depends on a clear definition of completion and transparent assumptions about labor, infrastructure and quality. Start with those definitions before comparing model prices.

Define the unit you are buying

Imagine a hypothetical procurement assistant that prepares supplier comparison briefs. A completed task might be a source-linked brief covering the approved suppliers, required criteria and unresolved gaps, accepted by a reviewer. A generated document that lacks evidence is not the same unit of work.

Write the acceptance criteria and record how often outputs meet them. If a reviewer must rebuild a brief, include that effort in the workflow. If the agent correctly reports that necessary evidence is unavailable, classify the outcome separately rather than quietly treating it as a completed comparison.

The OpenAI evaluation guide recommends task-specific success criteria. That principle matters to cost analysis: a denominator built from model responses can make an unreliable system look economical, while a denominator built from accepted outcomes exposes the real delivery burden.

Create a cost ledger for the whole run

Track model usage, paid tools, retrieval or storage services, execution infrastructure and any relevant monitoring costs. Include all attempts associated with a task, not only the final successful call. Record retries and delegated work under the same task identifier when possible.

Add human effort in a transparent way. Separate initial instructions, review, correction and exception handling. If you convert time into money, state the labor-rate assumption and whether it represents salary, fully loaded cost or another internal convention. Do not present an assumption as an observed saving.

Some costs are shared across the service, such as integration maintenance and evaluation work. Keep those visible rather than forcing them into a misleadingly precise per-run figure. A useful report can show direct variable cost per accepted task alongside recurring operating costs and one-time implementation work.

Count unsuccessful work honestly

Suppose a briefing requires several attempts and still ends in a manual handoff. Its model and review costs did not disappear. Allocate them to the service’s total operating cost and report the handoff rate separately. Excluding failed tasks creates a survivorship bias in the business case.

Likewise, do not count every retry as another delivered task. A run identifier and a business-task identifier may differ. The business-task identifier should connect repeated attempts, revisions and approval cycles that belong to the same intended outcome.

The Agents SDK tracing documentation provides mechanisms for linking execution events. Those traces can support cost attribution, but the application must define the relationship between a run and the business task. Technical telemetry does not automatically supply an accounting model.

Segment by task complexity

A short comparison of known suppliers and an open-ended search for alternatives may have very different workloads. Report them separately. An average can conceal a small group of long, expensive tasks that create most of the review burden.

Useful segments might include the number of required sources, availability of structured data, need for approval and degree of ambiguity. Choose categories that operators can identify before or during the task. That allows routing decisions rather than merely explaining costs afterward.

Compare the agent with a realistic baseline for the same scope and quality. A manual process that produces a shorter, less thoroughly sourced brief is not directly comparable to a broader agent-generated report. Either align the deliverables or state the difference clearly.

Optimize the expensive decision, not the visible token count

Inspect where the run spends resources. Repeated searches may indicate a poor retrieval contract. Long outputs may reflect an unnecessarily verbose format. A costly review step may result from unsupported claims rather than model pricing. Fix the cause before swapping components at random.

The OpenAI latency guidance includes reducing requests and avoiding unnecessary model use. Those design choices can also affect cost, but any benefit must be measured for the actual workload. Do not infer a guaranteed saving from a general optimization principle.

A less expensive model may be appropriate for a bounded classification step if it meets the evaluation criteria. A deterministic lookup may replace a model call entirely. A stronger model may be worthwhile if it reduces repeated attempts or review. The comparison should use accepted outcomes rather than a single-call price.

Use a review sheet that separates facts from assumptions

• Observed: tasks attempted, accepted outcomes, tool calls, retries and billed usage.
• Observed: reviewer time and correction categories, measured consistently.
• Assumed: labor rates, future volume and allocation of shared operating costs.
• Excluded: costs or benefits not measured in the pilot.
• Quality guardrails: unacceptable errors that cannot be traded for lower cost.
• Sensitivity: how the conclusion changes if volume or review effort differs.

Keep current vendor prices in a dated calculation rather than embedding them permanently in a process document. Pricing, model availability and service terms can change. A reusable cost model should accept updated inputs without changing its definition of a successful task.

Decide what the result justifies

A pilot may show that the assistant is useful only for a specific task segment. That is a valid outcome. Route routine work to simpler automation, reserve the agent for cases where it adds value and retain a human path for unresolved exceptions.

The strongest business case explains what was delivered, at what quality, with what total effort. Cost per completed task helps make that explanation honest. It shifts attention from an attractive prompt price to the actual service the organization is trying to provide.

Sources and further reading

OpenAI: Evaluation best practices. Task-specific success criteria; checked October 2026.

OpenAI Agents SDK: Tracing. Execution-event linkage mechanisms; checked October 2026.

OpenAI: Latency optimization. Request reduction and non-model design alternatives; checked October 2026. No price or savings claims asserted.