Estimating cost per task

Why this matters #

Most software features cost almost nothing per extra use. AI features pay for every request, which means a feature can be popular and unprofitable at the same time. The worst time to discover that is after launch, when users depend on it and the invoice has arrived.

The good news is that cost is one of the most predictable things about an AI feature. With a token count, a price and a few honest assumptions, you can estimate cost per task to the right order of magnitude before writing the feature. This article shows how, and how to turn cost per call into the number that matters: cost per successful task.

Tokens in, tokens out #

Model APIs charge per token, separately for input and output. A token is a chunk of text, often part of a word. Output tokens cost more than input tokens, typically several times more.

What drives each:

• Input tokens: the system prompt, the user’s message, any documents or retrieved context, tool definitions, and the conversation history in multi-turn features. Context-heavy features are dominated by input.
• Output tokens: the visible response, plus thinking. On models that reason before answering, thinking tokens are billed as output tokens, so effort settings affect cost as well as quality and latency.

Current prices for the models this wiki uses:

Prices change, and the pricing page has details such as discounts for cached input and batch processing. The table above is generated from the same configuration file as every example on this site, so it’s only as current as the date shown.

From cost per call to cost per success #

Cost per call is where the estimate starts, not where it ends. Three things stand between a call and a successful outcome for the user:

• Calls per attempt. One user action can trigger several calls: a classification step, a retrieval step, the answer, an automatic retry on error. Count them all.
• Retries by the user. If users regenerate an answer one time in four, every attempt costs about a quarter more.
• Success rate. If only 60% of outputs are actually used, the 40% that aren’t still cost money. Divide by the success rate to get cost per successful task, the number to compare with what a success is worth.

Cost per success is why quality and cost aren’t separate concerns. Improving the success rate from 50% to 75% cuts cost per success by a third, often more than switching to a cheaper model would.

A cost estimator #

This script counts the real input tokens for a representative request with the token counting (opens in a new tab) endpoint, then applies your assumptions. Counting doesn’t generate a response, and it’s far more accurate than estimating from word counts.

import Anthropic from '@anthropic-ai/sdk';

const client = new Anthropic();

// USD per million tokens for the model below. Check the pricing page before relying on them.
const PRICE = { inputPerMTok: 4, outputPerMTok: 20 };

interface Assumptions {
  /** Average usage.output_tokens from a few real responses. Includes thinking, so measure it, don't guess. */
  outputTokens: number;
  /** Model calls one user attempt makes: multi-step flows, automatic retries. */
  callsPerAttempt: number;
  /** Share of attempts that end in success (used, accepted), from a prototype, evals or analytics. */
  successRate: number;
  attemptsPerMonth: number;
}

async function estimate(system: string, sampleInput: string, a: Assumptions) {
  const { input_tokens: inputTokens } = await client.messages.countTokens({
    model: 'claude-opus-5-5',
    system,
    messages: [{ role: 'user', content: sampleInput }],
  });

  const perCall = (inputTokens * PRICE.inputPerMTok + a.outputTokens * PRICE.outputPerMTok) / 1_000_000;
  const perAttempt = perCall * a.callsPerAttempt;
  return {
    inputTokens,
    perCall,
    perAttempt,
    perSuccess: perAttempt / a.successRate,
    perMonth: perAttempt * a.attemptsPerMonth,
  };
}

const usd = (n: number) => `$${n < 1 ? n.toFixed(4) : n.toFixed(2)}`;

const result = await estimate(
  'You draft replies to customer support tickets using the help articles provided.',
  // Use a realistic input: a typical ticket plus the help articles retrieval would attach.
  'Ticket: How do I export my invoices as CSV?\n\nHelp article: To export invoices, open Billing > History and choose Export...',
  { outputTokens: 450, callsPerAttempt: 1.25, successRate: 0.6, attemptsPerMonth: 20_000 },
);

console.log(`Input tokens per call: ${result.inputTokens}`);
console.log(`Cost per call:    ${usd(result.perCall)}`);
console.log(`Cost per attempt: ${usd(result.perAttempt)} (includes retries)`);
console.log(`Cost per success: ${usd(result.perSuccess)}`);
console.log(`Monthly cost:     ${usd(result.perMonth)}`);

Run it with npx tsx scripts/estimate-cost.ts. The assumptions are where the estimate lives or dies:

• Measure output tokens from a handful of real responses (usage.output_tokens on each response) rather than guessing. Thinking makes guesses unreliable.
• Use a realistic input. The example ticket is short; real tickets with several retrieved articles are much longer.
• Be honest about success rate. If you don’t know it yet, run the estimate at 30%, 60% and 90% to see how sensitive the result is.

Check the estimate against reality once the feature runs: every response reports its token usage, and cost dashboards track it per feature.

Levers that cut cost #

When the estimate is too high, these levers usually help, roughly in order of how often they’re worth trying first:

Two warnings. First, measure quality after every cost change: a cheaper call that fails more often can raise cost per success. Second, don’t optimize too early. Prove the feature works with a capable model, then cut cost with evidence.

Common mistakes #

Try it #

Check your understanding #

Key takeaways #