October 27, 2026

An AI price sheet answers a narrow question: what does the provider charge for a unit of processing? A product team needs a different answer: what does it cost to finish a useful task, at an acceptable quality and speed?

The distinction is easy to miss. A cheaper rate can be outweighed by a longer response, another attempt, or a result that somebody has to repair. The comparison worth making is not just dollars per million tokens. It is dollars per accepted result.

Here, “token” means a unit a model processes, not a cryptocurrency. Google’s documentation describes tokenization of text and non-text inputs, so a token count is not simply a word count.[7]

This guide uses current provider documentation to explain the billing mechanisms, then a deliberately hypothetical example to show how to compare them. It is not a cheapest-model ranking or a hands-on benchmark.

Start with the job, not the price table

Imagine an application that extracts five fields from a document. Define a successful result before shopping: the fields must be correct, missing information must remain missing, the output must fit the required structure, and the answer must arrive before the application’s deadline.

That definition is a proposed test, not a claim about any model. Its purpose is to stop an inexpensive but unusable response from counting as a success. Keep the same documents, scoring rules and deadline when comparing alternatives. If one route handles the difficult cases poorly, report that separately rather than hiding it in an average.

Use two measures. “Inference cost per accepted result” divides model and related service charges by successful tasks. “Total operating cost per accepted result” also includes the infrastructure and human work needed to deliver those tasks. Do not label the first measure as the second.

What belongs in the bill?

Anthropic’s documentation distinguishes ordinary input, cache writes, cache reads and output pricing; its tool-use section also includes tool definitions and tool-result content in token accounting.[1] Server-side tools can add usage charges beyond those token charges.[1]

Google’s Gemini price tables explicitly include thinking tokens in output pricing and list grounding and, for applicable models, cache-storage charges separately.[4] The important qualification is “applicable”: model, mode and feature selection matter, so one provider’s categories should not be imposed on every API.[1][4]

Build a worksheet with the billable categories for the exact service you intend to use. Multiply each token category by its own rate, then add separately billed tools, storage or capacity. Make the categories non-overlapping: if a provider already includes thinking in billed output, do not add the same tokens again.[4]

For multi-step work, treat the whole task as the unit of comparison. A first response that asks for more information, a follow-up generation and a corrective pass all belong to that task’s cost. Record completed paid attempts even when you reject their answers. Do not assume that every failed network request is billable; reconcile actual usage and invoices instead.

A worked example: lower rates, higher cost

The following numbers are invented assumptions for teaching the calculation, not prices offered by Anthropic, Google or Hugging Face. Assume 10,000 tasks, one completed generation per task, no caching, no tools and no additional fees. For this first comparison, assume every result passes the same acceptance test.

Route A uses 3,000 input tokens and 500 output tokens per task. Its assumed rates are $1 per million input tokens and $5 per million output tokens.

Input: 10,000 × 3,000 ÷ 1,000,000 × $1 = $30. Output: 10,000 × 500 ÷ 1,000,000 × $5 = $25. Total: $55, or $0.0055 per accepted result.

Route B has rates that are 20% lower: $0.80 for input and $4 for output, per million tokens. It uses the same input but, in this example, produces 1,500 output tokens per task.

Input: 10,000 × 3,000 ÷ 1,000,000 × $0.80 = $24. Output: 10,000 × 1,500 ÷ 1,000,000 × $4 = $60. Total: $84, or $0.0084 per accepted result.

The lower-rate route costs more because the assumed output is three times as long. This does not show that any real model behaves that way. It shows why a rate comparison alone cannot establish a workload saving.

Now change Route A’s assumptions. Suppose 2,000 tasks each need one additional completed generation of the same size, and only 9,000 of the original 10,000 tasks ultimately pass. The extra generations cost $11, bringing the bill to $66. Dividing by 9,000 accepted results gives approximately $0.00733 per accepted result, before human review or other operating costs.

Do not divide by 12,000 API calls and call the answer “cost per task.” Attempts are the expense; accepted tasks are the useful output. Nor does this revised example establish a winner over Route B: a fair decision would need both routes’ measured acceptance rates and retry behavior.

Caching helps only when the workload qualifies

Anthropic’s prompt cache reuses a matching prompt prefix; it is not a store of final answers.[2] The documentation describes a default five-minute lifetime, a one-hour option at additional cost, and minimum cacheable lengths that depend on model and platform.[2] It also exposes separate cache-write, cache-read and uncached-input usage fields.[2]

For the document-extraction example, a repeated instruction block is a candidate for reuse, while each new document is variable input. That is a design hypothesis to test, not an assumed discount. Measure which input tokens actually became cache reads, how often new writes occurred, and what happened after inactivity.

A discounted read price is not a discount on the entire request: output and uncached content still have their own accounting.[1][2] Google’s listed cache-storage charges for applicable models add another reason to examine the complete feature bill rather than only the read rate.[4]

A useful comparison therefore includes both a warm, repeatedly used workload and a cold or sporadic one. Keep any extra storage time and cache creation in the cost record. The question is whether caching reduces the bill for your traffic pattern, not whether caching can be cheaper in an ideal example.

Batch processing buys a different service

Anthropic documents asynchronous Message Batches with a 50% discount on input and output tokens.[1][3] Requests are processed independently, and batches expire if processing does not complete within 24 hours.[3] That is a documented processing option, not a promise that a particular job will finish at the moment you need it.[3]

Overnight classification is a plausible batch candidate; a customer waiting for an immediate answer is a different requirement. Compare discounted batch work with other routes that meet the same deadline, not with an interactive service while ignoring the delay.

Check individual results, account for any resubmitted work, and keep separately charged features in the worksheet. Do not turn a token discount into an assumed 50% reduction in the application’s entire operating cost.

Dedicated hosting changes the denominator

Hugging Face Inference Endpoints illustrates another billing model: dedicated instances have hourly-listed rates calculated by the minute, with charges covering initializing and running states for successfully deployed endpoints.[5] Its pricing examples also account for additional replicas.[5] You are comparing capacity time, not simply a token tariff.[5]

Consider a separate hypothetical endpoint at $1 an hour, running for 24 hours. Its capacity cost is $24. If it delivers 1,000 accepted results, compute alone costs $0.024 per result. At 10,000 accepted results, that becomes $0.0024. These are arithmetic scenarios—not evidence that any particular instance can meet either throughput at the required latency or quality.

The same rented capacity can look attractive when busy and expensive when underused. Include initialization, spare capacity, extra replicas and the work of operating the service before claiming an API replacement is cheaper.

Scale-to-zero does not remove every trade-off. Hugging Face warns of cold-start delays, a 502 response while the new replica initializes, and no built-in incoming-request queue for that path.[6] Its documentation recommends client-side queueing and error handling.[6] Those qualifications belong in the design and cost comparison, not in a footnote after a savings headline.

A practical measurement plan

Before a trial, freeze the task set, acceptance criteria, required response time and maximum experimental spend. Include ordinary and difficult cases. Keep a held-out group to check that changes made during tuning still work on unfamiliar inputs.

For each task, record the selected model or endpoint configuration, completed attempts, usage categories, tool charges, elapsed time, acceptance result and human intervention. Google’s token documentation distinguishes pre-request input counting from response usage reporting; the former does not tell you how much output a future generation will produce.[7] Anthropic’s separate cache counters likewise help distinguish actual reuse from an assumed hit.[2]

Then reconcile the service’s usage record with the applicable price sheet and bill. Check category definitions before adding counters together. Keep estimates, observed usage and invoiced amounts visibly separate.

Finally, compare three outcomes: cost per accepted result, the proportion of tasks accepted, and the response-time distribution. Report the difficult cases and expensive failures rather than just the best run. Stop short of a production claim if the experiment has not covered realistic traffic or operating costs.

The cheapest answer is the one that satisfies the job at the lowest complete cost—not necessarily the answer from the model with the smallest number on its price page.

Scope and sources

Provider documentation was checked on October 27, 2026, Eastern time. These are descriptions of currently documented features, not independent tests of their performance, account availability or billing accuracy. The examples are explicitly hypothetical; no inference service was purchased or benchmarked. Living documentation can change, so verify the exact model, platform and terms before making a commitment.

Sources

[1] https://platform.claude.com/docs/en/about-claude/pricing — Anthropic: Pricing [2] https://platform.claude.com/docs/en/build-with-claude/prompt-caching — Anthropic: Prompt caching [3] https://platform.claude.com/docs/en/build-with-claude/batch-processing — Anthropic: Batch processing [4] https://ai.google.dev/gemini-api/docs/pricing — Google: Gemini Developer API pricing [5] https://huggingface.co/docs/inference-endpoints/pricing — Hugging Face: Inference Endpoints pricing [6] https://huggingface.co/docs/inference-endpoints/main/autoscaling — Hugging Face: Inference Endpoints autoscaling [7] https://ai.google.dev/gemini-api/docs/tokens — Google: Understand and count tokens