AI Agent Token Cost per Task: Measure the Result, Not Just the Prompt

Measure Cost per Completed Task

AI agent token cost per task should be measured by completed result, not by a single prompt. A phone task may include planning, context, screen reading, model output, user review, retries, and a final supported Android action. The clean metric is: total measured cost for the batch divided by verified completed tasks.

Define completion before you measure. For a message workflow, completion might mean “a reviewed draft appears in the correct visible message field, and the user has not sent it yet.” For a calendar workflow, it might mean “the event is saved in the chosen writable calendar with the actual saved time verified.” Automate Multi-Step Tasks on Android With Confirmation and Recovery is useful background for defining what a complete supported phone task means.

Keep cost categories separate: model API usage, subscription or credit allowance if applicable, external tool fees, cache charges, human review time, and incremental device energy. Do not double-count included charges. If a subscription already covers a usage bucket, record the allowance separately instead of adding it again as per-task spend.

Build a Ledger from Provider Usage

Start from provider usage fields whenever they are available. Google’s Gemini token counting documentation explains that token accounting can include text and other modalities such as images, and that response usage can include input, output, thinking, and cached context fields. Google’s Gemini API pricing documentation also notes that rates differ by model, modality, and tier, and that some output prices include thinking tokens while caching, storage, or grounding may be billed separately.

The reusable model-token formula is: for each disjoint token category, divide the token count by 1,000,000, then multiply by that category’s USD-per-million rate. In compact form: model cost = (uncached input tokens / 1,000,000 × uncached input rate) + (cache-read tokens / 1,000,000 × cache-read rate) + (billable output tokens / 1,000,000 × output rate). Add applicable cache creation, cache storage, tool, service, or subscription allocation costs as separate lines. If cache-write input is already counted in a provider’s cache creation line, do not also count it as ordinary uncached input.

A reusable ledger uses disjoint categories:

• Uncached input: ordinary input tokens that were not served from cache.
• Cache reads: cached tokens read from an eligible cache, priced according to the provider’s rules.
• Billable output: output tokens, including thinking tokens when the provider bills them as part of output.
• Cache creation or storage: added only when the provider bills it separately.
• Tools and services: search, grounding, external APIs, app services, or other non-model charges.
• Subscription or credits: recorded separately so included usage is not counted twice.

Prompt caching needs its own line. Anthropic’s Claude prompt caching documentation distinguishes cache writes, cache reads, and ordinary uncached input, and says usage fields help confirm whether a cache was actually used. The same discipline applies across providers: do not assume a cache hit; check the usage fields or billing report.

Screenshots, UI context, and image inputs should be counted according to the provider’s billing rules. If image tokens already appear in input usage, do not add a separate invented image charge. If failed attempts are included in the total usage export, do not add those retries again manually.

Recalculate One Hypothetical Batch

The following ledger is hypothetical teaching math, not a vendor quote, FoneClaw price, or measured benchmark. The rates are invented so the formula is easy to recalculate.

The cost per verified completion is $3.34 divided by 90, or about $0.0371 per completed task. The denominator is verified completions, not attempts. The failed or incomplete attempts are already in the numerator because all calls and retries were included in the usage totals.

This example includes no cache write fee, cache storage fee, subscription allocation, currency conversion, or human time cost. Add those only when they apply to your actual provider setup. If there are zero verified completions, the metric is undefined for that batch; it is not zero cost per success.

What Phone-Side Execution Can Change

Phone-side execution can change cost by reducing repeated interpretation, repeated context transfer, and failed loops for supported Android tasks. It does not prove that inference is local, free, or absent. At FoneClaw, the configured model helps interpret and plan, while FoneClaw performs supported Android actions such as reading current visible state in supported apps and entering text into an identified editable field. Configured online models may process supplied task context.

The current FoneClaw Features page describes the Android task surface. For example, FoneClaw can help draft text and fill a supported visible message field, but that input does not send, submit, or press Enter. The user still verifies the recipient, message, and final action. For the permission and confirmation model behind this, AI Agent Phone Control on Android: Intent, Confirmation, Action explains how supported phone actions are prepared and reviewed.

Saved workflows can store reusable supported tool steps, which may reduce repeated setup work. Measure actual model calls and billing after using them; a saved workflow does not guarantee zero future model usage. Also avoid assuming that a text accessibility tree is always cheaper than a screenshot. Screenshots and visible UI reading are different methods, and their cost depends on provider billing and the task.

Run a Small Repeatable Task Check

Use a small same-task check before making cost claims. Pick one low-risk workflow, such as “prepare a reviewed reply in a visible draft field and stop before sending.” Run it 10 times with the same app, same device, same input style, same approval policy, and the same success definition. Record attempted tasks and verified completions separately.

For each run, record:

• Provider usage: uncached input, cache reads, output, thinking if billed, image or multimodal usage if applicable, and tool fees.
• Retries: permission missing, screen changed, recipient ambiguous, app unsupported, or user correction.
• Outcome: completed, incomplete, manually recovered, or intentionally stopped.
• Review time: how long the user spent checking recipient, field, content, and result.
• Approvals: whether the configured approval policy matched the consequence of the action.
• Energy: incremental device energy if you measure it separately.

Compare total measured cost divided by verified completions. Keep human time and energy separate unless you have a consistent way to monetize them. For failed runs, diagnose before retrying; Phone Agent Debugging and Recovery: Fix Failed Android AI Assistant Tasks gives a safer way to inspect app state before repeating billed work.

Reduce Waste Without Dropping Checks

The best savings come from reducing waste, not removing safeguards. Use clear inputs, shorter relevant history, provider-confirmed cache hits, stable task templates, and fresh screen state after the target app changes. When a task fails, inspect the actual app state before repeating the same model call or phone action.

Keep required permission and confirmation checks. Reducing recipient review, payment approval, app permission review, or send confirmation is not a good cost strategy. Consequential actions need configured global and per-tool approval policies that match the risk.

If you measure energy, use a separate simple formula: incremental watt-hours divided by 1000, multiplied by your local electricity price per kWh. Do not mix that with model cost unless you intentionally convert both into the same currency. For the broader trust difference between local phone action and online model processing, AI Agent Trust: Local Android Phone Control vs Cloud Security is the next guide to read.