LLM Cost Per Task: How to Actually Measure It

What "cost per task" actually means

LLM cost per task is the total amount you spend to complete one unit of real work — one support ticket resolved, one document summarized, one code review, one lead qualified — rather than the raw price of the tokens involved. It's the metric that actually matters for budgeting, because a "cheap" model that needs five retries to finish a task can end up costing more than an "expensive" model that gets it right on the first pass.

Most pricing pages only tell you the cost per million input/output tokens. That number is useless on its own until you multiply it by how many tokens a task realistically consumes, how often the model fails and needs a retry, and whether the task involves tool calls or multi-turn conversation. This article walks through how to calculate cost per task properly and how to keep it visible once you're running in production.

Why token price is the wrong unit to optimize

Token pricing tells you the cost of the ingredient, not the cost of the meal. Two tasks that look similar on paper — say, "summarize this document" and "extract structured data from this document" — can have wildly different real costs:

• A summarization task might use 2,000 input tokens and 200 output tokens, done once.
• A structured extraction task might need a system prompt, a few-shot example, a tool call, and a retry when the JSON doesn't validate — easily 4-6x the token volume of the first task, even though both are "one task."

If you only track $/1M tokens, you'll miss this entirely. If you track $/task, it shows up immediately.

How to calculate cost per task

The formula is straightforward once you define what a "task" is in your system:

cost_per_task = (input_tokens_used × input_price)
              + (output_tokens_used × output_price)
              + (retry_cost, if any)
              divided by
              (number of completed tasks)

The tricky part isn't the math — it's instrumenting your system so you actually capture these numbers per task rather than as a monthly aggregate.

Step 1: Define the task boundary

Decide what counts as "one task" before you start measuring. Is it one API call? One full conversation with multiple turns? One completed workflow that might involve several model calls plus a tool call to a database? Be consistent, or your cost-per-task number will drift depending on how chatty a given conversation happens to be.

Step 2: Capture token usage per call, not per month

You need usage metadata attached to each request, not just a total on your invoice. At minimum you want:

• Input tokens
• Output tokens
• Whether the call was a retry or a fresh attempt
• Which model handled it (if you route between models)

const response = await fetch("https://api.subtoapi.app/v1/messages", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.SUBTOAPI_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    model: "claude-3-5-sonnet",
    max_tokens: 1024,
    messages: [{ role: "user", content: "Summarize this ticket: ..." }]
  })
});

const data = await response.json();
console.log(data.usage); 
// { input_tokens: 812, output_tokens: 194 }

Log usage alongside a task_id in your own database. That's the raw material for every cost-per-task calculation you'll ever need. See /docs/messages for the full response shape.

Step 3: Account for failure and retry cost

A task that fails validation and gets retried costs you the failed attempt's tokens plus the successful attempt's tokens. If 15% of your extraction tasks need a retry, your real cost per task is higher than the "happy path" number by roughly that same margin. Track retries explicitly — don't average them away.

Step 4: Separate fixed costs from per-task costs

If you're paying for seats or infrastructure on top of usage, decide how you want to allocate that. A common approach: divide monthly infrastructure/seat cost by expected task volume and add it as a flat per-task overhead. This matters more once you're running at scale with a team, since a €19/seat or €49/seat plan should be spread across the tasks that team is producing, not treated as a separate line item nobody looks at.

A worked example

Say a support-ticket triage task averages 1,500 input tokens and 300 output tokens, with a 10% retry rate that adds another 1,500/300 on the retry attempt.

Base call cost:   1,500 in + 300 out
Retry cost (10%): 0.10 × (1,500 in + 300 out)
Effective tokens: 1,650 in + 330 out per task

Multiply by your provider's per-token pricing and you get a real, defensible cost-per-task figure — one you can compare against the cost of a human doing the same triage, or against a different model/prompt combination.

Why this matters for planning, not just accounting

Once you know cost per task, three decisions get much easier:

1. Model selection — a smaller/cheaper model with a higher retry rate might lose to a larger model with near-zero retries, even though its per-token price is higher.
2. Prompt engineering ROI — shrinking a bloated system prompt by 500 tokens matters more when you see it multiplied across 50,000 tasks a month.
3. Pricing your own product — if you're building on top of an LLM, cost per task is what you actually need to know to price your own offering with margin.

Streaming (see /docs/streaming) doesn't change the token math, but it does affect perceived latency per task, which is worth tracking alongside cost if user experience matters to your use case. Tool use (see /docs/tools) adds another variable: each tool call round-trip consumes tokens too, so multi-step agentic tasks should be measured end-to-end, not per individual model call.

If you're already using Claude through your own subscription and want a straightforward way to get usage data per request without building your own metering layer, SubToAPI exposes usage metadata on every response so you can attach it to a task ID and build this reporting without extra infrastructure. Check /docs/quickstart to get an API key running in a few minutes, or /pricing if you're comparing plans for a team.

questions

Is cost per task the same as cost per token? No. Cost per token is the unit price charged by the model provider. Cost per task is the total spend needed to complete a real unit of work, which includes token volume, retries, and any multi-step tool calls that a single task might require.

How do I estimate cost per task before shipping a feature? Run a representative sample of real inputs through the model, log input/output tokens for each, average them, then multiply by your provider's pricing. Include a realistic retry rate based on early testing, not zero.

Does a cheaper model always mean lower cost per task? Not necessarily. If a cheaper model has a higher failure or retry rate, or needs longer prompts to get comparable quality, its effective cost per task can end up higher than a pricier model that succeeds more consistently on the first attempt.