What does a successful voice agent call cost?

TL;DR: Calculate voice-agent cost per success by dividing the full cost of an eligible task cohort by its verified successful outcomes. Include unsuccessful attempts, repeated calls, human work, and allocated operating costs, and keep unknown outcomes visible instead of counting connected calls as success.

A low price per minute can fund an expensive workflow. If callers repeat themselves, reconnect, or require human repair, the rate on the pricing page describes only part of what the business paid to get one task finished.

The useful question is concrete: what did this cohort cost, and how many intended outcomes did the authoritative business system confirm? The outcome metrics guide defines that denominator; this article builds the corresponding cost ledger and comparison method.

This is a reproducible accounting and evaluation protocol, not a published 60db Agent cost benchmark. All worked dollar amounts and success counts below are synthetic examples, chosen to make the arithmetic inspectable rather than imply market rates or observed customer performance.

Reviewed November 9, 2026. Public billing documentation supports the distinctions between usage, call status, and invoice components; no live invoice, customer record, or measured production cohort was accessed.

Table of contents

1. Choose the unit before the price
2. Build the full cost numerator
3. Define a trustworthy success denominator
4. Work through a transparent example
5. Implement an auditable calculation
6. Compare configurations fairly
7. Optimize the actual cost drivers
8. Report product costs without overclaiming
9. Frequently asked questions
10. Make the next decision from a reconciled cohort

Choose the unit before the price

Cost per successful task is a cohort ratio, not a rate-card field. It depends on both the money spent and the meaning of success.

A call is a transport session. A task is an intended business outcome, such as a confirmed booking or a support request resolved under a defined policy, and one task can require several calls.

Choose the unit that matches the decision. Cost per connected call can help diagnose telephony usage; cost per verified booking helps decide whether the booking workflow is economically useful.

Keep both when they answer different questions. Replacing a useful operational measure with a business ratio can hide the mechanism, while replacing the business ratio with a cheap operational measure can hide failure.

The FinOps Foundation's unit-economics capability connects technology spending with meaningful units of value. The method here applies that principle to voice workflows rather than borrowing a universal cost target.

Define the cohort explicitly

A cohort needs an eligibility rule, start period, route, task type, and outcome observation window. Without those fields, the numerator and denominator can describe different populations.

For an outbound booking workflow, eligibility might begin when a valid authorized task enters the queue. That includes attempts that never connect, because the business still paid for parts of trying to complete them.

For a support workflow, eligibility might begin when the caller requests a supported task after the connection opens. That is a different boundary, so the resulting metric should not be compared directly with a queue-entry cohort.

State the choice before seeing the result. Moving the entry point later to exclude difficult attempts can improve the ratio without improving the service.

Distinguish marginal and fully allocated cost

Marginal cost estimates the additional spend caused by another task under current capacity. Fully allocated cost includes an agreed share of fixed operating costs, support, and infrastructure.

Both measures can be useful. A team deciding whether to accept incremental volume needs a different view from a team deciding whether the entire service pays for itself.

Keep the allocation rule visible. A small cohort can look expensive when assigned a large fixed platform fee, while a high-volume cohort can look artificially cheap if all idle capacity is assigned elsewhere.

The FinOps allocation capability describes assigning direct and shared costs through explicit strategies. In a voice-agent report, the practical requirement is that another reviewer can reproduce where each shared charge went.

Do not confuse cost with value

A cheap failed task has low cost and little value. A more expensive task can be worthwhile if it reaches a valuable verified outcome within the required quality and safety constraints.

This article measures cost per success, not return on investment. A value or margin model needs additional business evidence about revenue, retention, avoided work, and causal attribution.

Do not invent those benefits from a satisfied transcript. If the agent sounds helpful but the business system has no completed outcome, the economic report should preserve that uncertainty.

Build the full cost numerator

Start from charges you can reconcile. A voice workflow can incur AI usage, carrier or line charges, external tools, recording or storage, application infrastructure, and human work.

The exact components depend on the route and contract. A managed bundle can include services that a self-managed stack bills separately, so a component appearing absent from one invoice is not proof that the underlying activity is free.

Keep invoice amount, usage quantity, rate version, currency, and allocation basis separate. A single blended cost field is convenient for display but insufficient for explaining an unexpected increase.

Record whether an amount is provisional or settled. Usage dashboards and call-level fields can arrive before invoice adjustments, taxes, credits, or minimum commitments are applied.

Follow each provider's billing unit

Providers can bill by minutes, tokens, characters, requests, storage, concurrency, or a credit conversion. Convert them into one reporting currency only after retaining the original quantity and billing definition.

The Twilio US Voice pricing page illustrates that voice services have route-specific prices and separately listed capabilities. It is a source for its current contract, not a universal price for phone calls in every country or product bundle.

Do not multiply wall-clock call duration by a remembered per-minute rate and call that an invoice. Rounding, multiple legs, direction, geography, add-ons, and contract terms can all affect the billed result.

Where a provider supplies settled cost, use it and reconcile it. Where only usage exists, apply the correct dated rate rule and label the result estimated until it matches the billing record.

Include failures and repeats

A task that fails after a long conversation still consumed resources. A second attempt to finish the same task should remain attached to that task rather than entering the denominator as another independent success opportunity.

Deduplicate the business outcome, not the cost. If three calls produce one confirmed booking, count one success and the cost of all three calls within the declared task window.

A caller may return later for a different request. Your linkage rule needs enough task context to avoid merging unrelated work, while minimizing the personal information used for correlation.

The observability design provides call and task identities for that join. It also explains why a high-cardinality identifier belongs in a ledger or trace rather than a broad metric label.

Count every attributable attempt while deduplicating the business outcome.

Account for tools and human escalation

External tool requests can incur direct charges or meaningful backend capacity. Include chargeable failed attempts and speculative work when the contract bills them, even if their results never become audible.

A speculative tool design can reduce waiting while increasing discarded computation. Whether that trade is worthwhile depends on measured completion and cost, not the elegance of the architecture.

Human escalation also belongs in the task cost when your boundary includes it. Use an explicit labor-cost assumption and observed handling time, and keep it separate from provider charges so finance can change the assumption without recomputing media usage.

A warm handoff may preserve context and reduce repetition, but do not assign a labor saving until you measure the actual human work under comparable conditions.

Avoid double counting bundled charges

A managed AI charge may already include speech recognition, generation, and synthesis. Adding hypothetical standalone prices for those components would count the same service twice.

The inverse error also occurs. A line charge may exclude AI, recordings, or another call leg, so treating it as the full conversation cost understates the numerator.

Build a coverage table from the actual contracts. A checkmark means included in the selected report's numerator, not that every provider charges the item separately.

The table is an accounting checklist. Populate it with invoice evidence instead of treating it as a claim about one vendor's bundle.

Define a trustworthy success denominator

A connected call is not a verified business success. The denominator needs an authoritative event that matches the task definition.

For a booking, that can be a committed reservation with the required fields and a stable business identifier. For a payment workflow, it can be the specific settled or authorized state your business accepts, rather than the agent saying the payment worked.

Use a written outcome contract. It should state which system owns the fact, which event establishes it, how duplicates are handled, and how long the cohort waits for delayed outcomes.

The Twilio Call resource documentation distinguishes call status from what answered the call. A completed call can involve a person, an IVR, or voicemail, so status alone cannot supply a success denominator.

Preserve unknown and pending outcomes

Use at least confirmed success, confirmed failure, pending, and unknown. A missing event is a data-quality problem or an unresolved outcome until evidence establishes which.

A cohort reported too early can make a working system look worse because backend jobs have not settled. A cohort that silently waits forever can make failures disappear from current reporting.

Choose a maturity window based on the workflow. Report provisional results while it remains open, then freeze or version the finalized result according to a documented correction policy.

Unknown outcomes need their own rate. If one configuration has weaker outcome instrumentation, comparing only its known cases with another configuration's full cohort introduces a selection bias.

Make exclusions inspectable

Exclude tasks only through rules declared before comparison. Invalid authorized test inputs, unsupported task classes, or explicitly out-of-scope fraud attempts may need separate reporting, but the costs they incurred still need an accounting destination.

Do not remove a task because the agent performed badly. That is the exact behavior the metric is meant to expose.

Keep an exclusion count and reason table. A reviewer should see how many tasks entered, how many were excluded under each rule, and which cost pool retained the excluded work.

The workflow enforcement guide helps define unsupported requests and authorization failures. An agent correctly refusing a prohibited action can be operationally correct even though it is not a completed booking.

Track quality constraints separately

A business receipt alone can be insufficient if the action was wrong or unauthorized. Define success to include the required validation and authorization conditions, and retain severe failures outside any average cost score.

For example, a booking at the wrong time should not become a success merely because the calendar accepted it. The intended task and confirmed arguments determine whether the receipt corresponds to the caller's request.

A quality model can help find cases for review. It should not replace the authoritative outcome or fabricate certainty from sentiment and fluent language.

The multilingual benchmark applies the same distinction across languages. Recognition accuracy, conversation quality, and task completion are related measurements with different denominators.

Work through a transparent example

The following figures are synthetic and describe no vendor, customer, or measured deployment. They compare two hypothetical configurations on the same 1,000 eligible tasks after the outcome window has closed.

Configuration A incurs $300 in AI and line usage, $60 in chargeable tool and storage work, and $140 in human repair. Its total task-cohort cost is $500, and it produces 400 verified successes.

Configuration B incurs $380 in AI and line usage, $70 in tool and storage work, and $90 in human repair. Its total is $540, and it produces 600 verified successes.

The arithmetic gives A a cost per success of $1.25 and B a cost per success of $0.90. B spends more across the cohort while producing a lower cost per verified outcome under these stated assumptions.

This example proves an accounting possibility, not an empirical performance claim. A real comparison would need comparable assignment, mature outcomes, cost reconciliation, and uncertainty around the observed result.

Understand the ratio

The cohort formula is total attributable cost divided by the number of verified successes. All eligible task costs stay in the numerator, including failed and unresolved attempts under the declared reporting policy.

If there are no verified successes, the ratio is undefined. Report the cost, task count, and zero-success result; do not return zero cost per success or divide by an invented minimum denominator.

If costs are still provisional, mark the ratio provisional. If outcomes are incomplete, show their status distribution and avoid presenting a point estimate with more certainty than the cohort supports.

For the synthetic example, success rates are 400 divided by 1,000 and 600 divided by 1,000. Those rates explain part of the economic difference, but the total-cost breakdown explains which costs changed.

With no verified successes, report the spend and an undefined ratio rather than zero cost per success.

Show sensitivity instead of false certainty

Suppose the human labor rate changes. Recompute that component while preserving the observed handling times, rather than replacing the whole ledger with another opaque blended estimate.

Suppose unresolved tasks all fail or all succeed. Those extreme assumptions provide bounds on the outcome denominator, provided you label them as bounds and do not imply either scenario occurred.

Suppose a fixed monthly commitment is allocated by task count instead of call minutes. Show how that policy changes the fully allocated view and keep the marginal view available for comparison.

Sensitivity analysis reveals which assumption owns the decision. If a small change to an uncertain labor estimate reverses the ranking, the next useful measurement is labor evidence rather than another model-price comparison.

Implement an auditable calculation

Use the existing billing export, task store, and outcome system before building a new platform. A small reproducible query or script is enough when the joins and definitions are clear.

The minimal data model has eligible tasks, call attempts linked to tasks, cost items linked to attempts or shared pools, and authoritative outcomes linked to tasks. Preserve source identifiers so each aggregate can be reconciled.

A cost item needs amount, currency, source, billing period, charge identity, settlement state, and allocation rule where applicable. A task outcome needs status, authority, effective time, and observation time.

Keep private content out of this model. The calculation needs identifiers and categories, not caller transcripts, phone numbers, or the text of a support request.

flowchart TD
    A[Eligible task cohort] -->|Contains| B[All call attempts]
    B -->|Produces| C[Usage and settled charges]
    D[Shared operating costs] -->|Declared allocation| E[Attributable cohort cost]
    C -->|Reconciled and deduplicated| E
    A -->|Joined by task identity| F[Authoritative outcomes]
    F -->|Mature verified successes| G[Success denominator]
    E -->|Numerator| H[Cost per success]
    G -->|Denominator| H

The diagram keeps cost and outcome authority separate until the final calculation. That makes missing joins and inconsistent cohort windows easier to detect.

Use exact decimal arithmetic

The Python decimal documentation explains decimal arithmetic suitable for exact monetary inputs. Construct amounts from strings or integer minor units and apply the rounding rule at the boundary your contract requires.

The following standard-library self-check uses only the synthetic example. It does not estimate a provider invoice or implement currency conversion.

from decimal import Decimal

cohort_cost = sum(map(Decimal, ["380", "70", "90"]))
verified_successes = 600
assert cohort_cost == Decimal("540")
assert verified_successes > 0
cost_per_success = cohort_cost / verified_successes
assert cost_per_success == Decimal("0.90")
print(f"Synthetic cost per success: ${cost_per_success:.2f}")

Run it with Python and retain the assertions. The important production work is validating the ledger inputs and joins; the division itself is straightforward.

Do not round every cost item to the display precision before summing unless the billing contract does so. Premature rounding can create a difference from the invoice even when every individual displayed amount looks reasonable.

Validate the joins

Assert that every eligible task has a declared outcome state, even if unknown. Assert that every included cost item has one accounting destination and that duplicate delivery of the same charge does not duplicate spend.

Check for orphan attempts and orphan receipts. An attempt without a task can leak cost from the numerator, while a success receipt joined to several task rows can inflate the denominator.

Reject mixed currencies unless an explicit conversion rule and rate date exist. Keep original amounts alongside converted amounts so reconciliation remains possible.

Reconcile cohort totals with the source invoice or usage export. A report that cannot explain its difference from billing is an estimate and should say so.

Keep metering separate from business truth

A usage event measures a billable activity under a pricing model. It does not establish that the activity completed the caller's task.

Stripe's pricing-model documentation distinguishes usage-based charging from other subscription structures. That contract can help organize billing records, but it does not supply the success semantics for a voice workflow.

Likewise, a business success event should not be allowed to rewrite usage history. If a refund or correction occurs, append an auditable adjustment with its own identity rather than editing away the original charge.

A reproducible report should identify the query version, cost snapshot, outcome snapshot, allocation policy, and reporting date. That is enough to explain why a later report differs without preserving unnecessary raw conversation data.

Compare configurations fairly

A cost comparison needs equivalent eligible work. If the cheaper configuration receives short easy tasks and the expensive one receives complex cases, the ratio mostly measures assignment policy.

Random assignment can help when it is appropriate and authorized, but it is not always practical. A matched cohort or staged rollout can still be informative if you describe the limitations and avoid causal claims the design cannot support.

Keep route, geography, task mix, supported language, and outcome window visible. These factors can change both spend and completion, so a blended result needs supporting cohort detail.

The local versus managed comparison adds another constraint: equivalent data and operational boundaries. A local experiment that excludes operator time should not be compared with a managed invoice that includes those services without adjustment.

Keep performance constraints fixed

A configuration can lower cost by reducing quality, shortening calls prematurely, or refusing difficult supported tasks. Establish acceptable success, safety, and experience constraints before optimizing the economic ratio.

Endpointing is a concrete example. A shorter timeout can reduce call duration while creating cutoffs that require repeated calls; the turn-detection evaluation measures that mechanism directly.

Similarly, a slower model can be cheaper per request while increasing abandonment or human escalation. Compare end-to-end audible latency and verified outcomes under the same workload rather than equating token price with task economics.

Keep severe failures outside averaging. An unauthorized write should trigger the relevant safety response even if the cohort's average cost per success improved.

Report uncertainty at the task level

Repeated attempts within one task are correlated. Treating every call as an independent observation can make uncertainty intervals look narrower than the actual evidence supports.

Use the task as the analysis unit when the metric is cost per task outcome. If the assignment or data has additional clustering, such as shared customer organizations or time blocks, account for that structure in the analysis.

A bootstrap estimate can resample complete task records with all their costs and outcomes attached. Document the method and sample size, and do not replace a zero-success resample with an arbitrary finite number merely to produce a tidy chart.

For low volume, show the underlying counts and total costs. A precise-looking ratio from a few successes should not decide a long-term migration without more evidence.

Distinguish paired tests from live economics

A fixed synthetic corpus is excellent for comparing conversational behavior under controlled conditions. It can estimate usage for that corpus, but it does not reveal real task demand, repeat-call behavior, or human handling cost by itself.

Live cohorts add operational evidence but introduce assignment, seasonality, and external-system variation. Use both views and state what each establishes.

The regression harness guards behavior before rollout. The settled task ledger measures economics after the workflow has run long enough for outcomes and charges to mature.

Do not promote a small demo into an annual savings claim. Forecasts need explicit volume, mix, price, utilization, and success assumptions, with sensitivity to the assumptions that dominate the result.

Optimize the actual cost drivers

Inspect the ledger breakdown and failed-task traces before choosing an optimization. The biggest economic problem may be retries or human repair rather than model rate.

A cheap component can cause an expensive downstream effect. Poor recognition of reference numbers can create extra turns and human escalation; a fast but unreliable tool integration can produce repeat calls and manual correction.

Use trace evidence to identify the mechanism, then change one relevant boundary and evaluate the resulting cohort. Cost optimization becomes an engineering experiment instead of a shopping exercise.

Reduce avoidable waiting safely

Waiting can consume line minutes and caller patience. Remove unnecessary serial work and fix tool-timeout fallbacks, but preserve caller thinking time and confirmation requirements.

The speculation guide offers a bounded approach for reversible reads. It can improve the critical path while retaining a separate commit boundary for consequential writes.

Measure discarded work alongside the improvement. An optimization that prefetches every possible branch may lower audible delay while raising the total cost enough to worsen cost per success.

Do not shorten silence handling by cutting off callers. Evaluate the endpointing trade-off with supported language and accessibility cases before changing a timer for economic reasons.

Fix repeated failures before trimming small charges

A silent SIP route can create many failed attempts with no chance of success. Repairing the media path can matter more than shaving a small amount from a functioning synthesis stage.

A tool operation that retries without idempotency can create duplicate business work. The cost includes support and correction, while the risk extends beyond the economic ledger.

A handoff that loses context can force the caller to repeat the task to a human. Improve the handoff contract and measure actual handling time before assigning savings.

Prioritize by attributable cost and outcome impact under the supported workload. Keep the evidence for the chosen priority so a later change in traffic mix can trigger a sensible reevaluation.

Right-size capacity and commitments

Self-managed systems can pay for idle capacity, while managed contracts can include minimums or commitments. Those costs need utilization evidence and an allocation policy.

A lower theoretical compute price does not prove lower fully allocated cost. Include operating work, reliability requirements, deployment support, and the capacity needed for peak concurrency under the chosen service level.

Conversely, a managed convenience premium can be worthwhile if it replaces real work your team otherwise performs. Measure that work rather than assigning an invented engineering headcount to either option.

The managed-versus-local framework helps identify those boundaries. Keep the cost comparison tied to the deployment you would actually operate, not an idealized architecture that has never handled the workload.

Report product costs without overclaiming

For 60db Agent, use the documented credit and line billing surfaces and the selected workspace's actual contract. Browser and stream routes avoid Dialer line charges, but they still have AI usage and can incur application or external-carrier costs.

The 60db Agent documentation provides the product's current cost and call surfaces. Reconcile those fields with billing instead of treating a typical marketing estimate as a measured successful-call cost.

No first-party cohort supplied for this series contains a verified success denominator joined to settled costs. Therefore this article publishes a protocol and synthetic arithmetic, with no claim about actual cost per successful 60db Agent call.

That limitation is useful. It identifies the exact missing evidence: eligible tasks, all attempts, attributable settled charges, human work under a declared policy, and authoritative outcomes after a defined window.

Publish a measurement card

A public result should identify task definition, eligibility, dates, sample counts, route, language mix, version, cost boundary, outcome authority, maturity window, unknown rate, and allocation assumptions.

Include failed and excluded attempts with their accounting treatment. Show marginal and fully allocated views separately when both inform the decision.

Publish enough raw-to-aggregate methodology that another reviewer can reproduce the totals without receiving private customer data. A sanitized task-level export can use opaque identifiers and bounded categories where publication is appropriate.

Do not publish a chart until the data exists. A conceptual graphic or explicitly synthetic worked example can teach the method without pretending to be a benchmark.

Close the reporting period deliberately

Before finalizing a cohort, compare the task ledger with three independent totals: eligible task intake, provider billing, and authoritative business receipts. Differences should have named explanations, such as a late charge, an unresolved task, or a shared fee allocated outside the cohort.

Keep a reconciliation table in the private report. It can show source total, included amount, excluded amount, unresolved amount, and the rule that accounts for the difference, without reproducing customer records or invoice credentials.

Do not force every source into the same settlement date. A task can begin in one billing period and finish in another, while a provider posts a correction later; the report needs a declared treatment for those boundaries rather than a convenient date filter.

When corrections arrive, version the result and explain their effect. An additional confirmed success changes the denominator, while a refunded duplicate charge changes the numerator, and those revisions tell different operational stories.

This closure step also tests ownership. If nobody can explain a recurring unmatched charge or an outcome that never resolves, assign that gap to the system that owns the missing evidence before treating the ratio as production truth.

For an experiment, apply the same closure rules to both configurations. A mature baseline compared with a candidate whose most difficult tasks remain pending is an unfair comparison even when both reports use the same formula.

Make the report actionable

End the report with the dominant cost driver, the supported hypothesis for changing it, and the metric that will decide the next experiment. Avoid presenting a ratio without a route to improvement.

If unknown outcomes dominate, improve outcome instrumentation first. If human repair dominates, review failed-task mechanisms; if line charges dominate, inspect duration, repeated attempts, and route terms without weakening conversation quality.

Set a revisit trigger. Material changes to pricing, task mix, language support, or workflow behavior can invalidate a prior result even when the arithmetic remains correct.

The goal is a decision record that stays honest as the service changes. A stable formula and versioned evidence make that possible without building a custom finance platform for one experiment.

Frequently asked questions

What is voice-agent cost per success?

It is the attributable cost of an eligible task cohort divided by its verified successful outcomes. The definition must include the cost boundary, task eligibility, outcome authority, and observation window.

Why is cost per minute insufficient?

Minute rates describe a billing unit rather than a completed task. Failed attempts, repeated calls, external tools, and human repair can change the total cost needed to achieve one outcome.

Should failed calls stay in the numerator?

Include their attributable costs when they belong to the eligible task cohort. Removing failed attempts makes the workflow look cheaper without improving its actual economics.

Is a completed call a successful task?

A completed call describes transport state under the provider's contract. Verify the intended business outcome separately in the authoritative system.

How should I count repeat calls?

Link attempts to the same task when they pursue the same intended outcome within the declared window. Count the outcome once and retain all attributable attempt costs.

What if there are no successes?

Report total cost, eligible task count, and zero verified successes. Cost per success is undefined, so do not return zero or divide by a fabricated minimum denominator.

Should pending outcomes count as failures?

Keep pending separate until the declared maturity window closes or authoritative evidence resolves the task. Report provisional economics and the pending count rather than silently forcing a binary label.

How do I handle unknown outcomes?

Show unknowns explicitly and investigate missing evidence. A configuration with weak outcome collection should not receive an apparent advantage by excluding its unknown tasks from comparison.

Should human escalation cost be included?

Include it when the chosen task boundary covers that work. Use observed handling time and a declared labor-rate assumption, and keep the component separate for sensitivity analysis.

What is fully allocated cost?

Fully allocated cost includes an agreed share of fixed and shared operating costs. Publish the allocation rule so the result can be distinguished from marginal task cost.

Can I compare a managed rate with local compute?

Compare equivalent workloads and operational boundaries. Local compute alone omits work such as capacity, monitoring, support, and reliability that may be included in a managed contract.

How do I avoid double counting?

Map each charge to one accounting destination and document bundle coverage. Do not add hypothetical standalone component prices when the managed charge already includes those services.

Which currency should I report?

Choose one reporting currency with an explicit conversion rule and rate date. Preserve original currency amounts so the calculation remains reconcilable with invoices.

Why use decimal arithmetic?

Decimal arithmetic represents monetary inputs without common binary floating-point artifacts. Apply the contract's rounding rules deliberately and avoid rounding intermediate values merely for display convenience.

Does faster response lower cost?

It can reduce waiting and abandonment, but it can also increase speculative work or premature responses. Measure the complete task cost and verified outcome rather than assuming every latency improvement saves money.

Can a synthetic test estimate real economics?

It can measure usage for its controlled workload and expose failure mechanisms. Real repeat behavior, demand mix, and human work require additional operational evidence.

Are browser calls free of all line costs?

For 60db Agent, browser and stream calls avoid Dialer line charges under the documented route distinction. External carrier or application costs can still exist in the integrating system.

Does this article report 60db cost per success?

No measured successful-call cohort was available for this article. The product example identifies the data needed, while all numerical calculations are explicitly synthetic.

How often should I update the calculation?

Recompute when charges and outcomes mature and when pricing or workload changes materially. Keep snapshots and definition versions so later corrections do not silently rewrite prior decisions.

What should the first cost experiment measure?

Choose one supported task and route, join every attempt and charge to the task, and verify outcomes after a fixed window. Reconcile the numerator before comparing a second configuration.

Make the next decision from a reconciled cohort

Cost per success becomes useful when the numerator and denominator describe the same work. Keep failed attempts, retries, and human repair in scope, and let the authoritative business system establish the outcome.

Preserve uncertainty instead of smoothing it away. Pending receipts, unknown outcomes, provisional charges, and shared-cost assumptions each affect what the result can support.

Use a small ledger and exact arithmetic before building more infrastructure. Reconcile one mature cohort, inspect its dominant failure mechanisms, and test a change that can improve the whole task under fixed quality constraints.

For 60db Agent or your existing stack, begin with one supported workflow and one route. The next deliverable is an auditable cohort report with real charges and verified outcomes, followed by a controlled experiment whose result can be reproduced without exposing private caller data.