Working premise
Aggregate spend cannot tell an engineering team whether an AI feature is economically healthy. Cost becomes actionable when it is attributed to a stable task, feature, customer segment, and accepted outcome.
Operational context
Provider invoices and token dashboards describe consumption, not product economics. A task-level model connects every model call, retry, cache event, retrieval operation, and tool call to a stable business or user outcome. The denominator must be defined before cost can be interpreted.
Success is rarely identical to a technically completed request. A support answer may require customer acceptance, a document workflow may require valid structured output, and an agent task may require a tool-side confirmation. Failed, escalated, abandoned, and partially successful outcomes should remain separate rather than being forced into one rate.
Historical analysis also depends on price provenance. Teams need to distinguish provider list price, negotiated rate, committed-spend allocation, and internal platform cost. The rate used for a past trace should remain reproducible after a provider changes pricing.
Questions to resolve first
What observable event proves that the task achieved its intended outcome?
Which calls, retries, tools, and shared services belong in the task cost?
How are missing outcomes classified rather than silently treated as success?
Which price source and effective date should historical reporting preserve?
Recommended method
- P1
Define the success event for each AI-assisted task.
- P2
Aggregate model calls, tool calls, retries, and cache operations across the complete trace.
- P3
Separate provider list cost, contracted cost, and internal allocation assumptions.
- P4
Compare cost distributions for successful, failed, escalated, and abandoned tasks.
Common failure modes
Teams optimize cost per request while retries or poor outcomes increase the cost of completed work.
Secondary models, tools, and retry loops are excluded from the task total.
Current provider pricing is applied retroactively, changing previously reported economics.
Control points
- Do not hide failed retries or fallback-model usage outside the task total.
- Version price tables and preserve the rate used for historical calculations.
- Flag missing outcome labels rather than treating them as success.
- Review material model-routing changes through the release process.
Implementation sequence
- S1
Define task, success, failure, escalation, and abandonment events with product and finance owners.
- S2
Join trace-level usage to provider billing dimensions and document allocation assumptions.
- S3
Publish distributions by outcome and segment instead of a single blended average.
- S4
Review routing, prompt, cache, and context changes through a quality-cost frontier rather than cost alone.
Measures worth reviewing
Cost per successful task is the anchor metric, but it should be decomposed into model, retry, tool, retrieval, and platform components. Pair it with outcome rate and latency so a cheaper route cannot look efficient by producing more failures.
Primary references
This note is an editorial synthesis of public standards, primary institutional guidance, and common engineering control patterns. It is intended to support engineering design and review. It is not a substitute for legal, security, safety, audit, or other professional advice for a specific system.