The AI Price War Is Moving From Token Prices to Cost per Task

Cheaper tokens help, but they do not tell you what an AI workflow will cost. Retries, cache use, reasoning effort and failed results often matter more.

An engineering team is choosing a model for a document-processing workflow. One API is cheaper per million tokens, so the decision appears simple.

Then the trial begins. The cheaper model produces more invalid outputs. Some documents need a second attempt. Difficult cases are sent to a stronger model. Long instructions are repeatedly added to every request. Human reviewers spend more time correcting the results.

The token bill is lower, but the workflow is not.

This is the weakness in many AI cost comparisons. They compare the price of processing text, while businesses pay for completed work. The more useful question is:

How much does it cost to produce one result that the system can actually accept?

That is cost per successful task. It is becoming more important as AI moves from short conversations into agents and multi-step workflows.

Why the latest price cuts matter

On 22 September 2026, Anthropic released Claude Opus 5.5 at $4 per million input tokens and $20 per million output tokens. Anthropic says this is 20% below Opus 5’s token rates and about 40% cheaper on a typical workload because the new model also uses fewer tokens. Cache reads fell from $0.50 to $0.20 per million tokens.

OpenAI released GPT-6 Sol and GPT-6 Luna on the same day. Sol is priced at $2 per million input tokens and $10 per million output tokens. Luna is priced at $0.10 and $0.50 respectively. OpenAI describes both as 50% cheaper than the promotional prices of their GPT-5.6 predecessors.

These are meaningful reductions. They can make an existing workload cheaper and allow teams to consider use cases that were previously too expensive.

They do not, however, prove which model will be cheapest for your application. The figures come from the vendors, and the benchmark results in their announcements were produced under particular prompts, tools, effort settings and evaluation rules. They are useful evidence, not a substitute for testing your own work.

The price sheet shows only one layer

An API invoice normally starts with three quantities:

• input tokens processed for the first time;
• input tokens read from a prompt cache; and
• output tokens generated by the model.

A simplified calculation for one model call is:

Model-call cost = fresh input cost + cached input cost + output cost

Some applications must also account for cache writes, tool calls, web searches, code execution, storage or premium processing modes. The exact billing rules vary by provider.

That formula calculates the cost of a call. A task may contain many calls.

A coding agent might inspect a repository, form a plan, edit several files, run tests, examine failures and try again. A support workflow might classify a request, retrieve customer information, draft a response, check policy and escalate uncertain cases. Every step can add context, output and another chance of failure.

The unit price matters, but so does the amount of work the model consumes before reaching an acceptable result.

A cheaper attempt can produce a more expensive result

Consider a fictional example: an evaluation of 100 invoice-extraction jobs.

Fictional example — not observed market data

Measure	Model A	Model B
Cost per first attempt	$0.08	$0.04
Jobs accepted without correction	80	30
First-attempt spend	$8.00	$4.00
Cost per accepted first-attempt result	$0.10	$0.13

Model B costs half as much for each attempt. Yet its cost for each accepted first-attempt result is higher because fewer results pass validation.

This example does not prove that larger or more expensive models always win. A small model may perform extremely well on a narrow, well-designed task. It shows why the denominator matters. Counting requests rewards activity. Counting accepted results measures useful work.

For a practical evaluation, use:

Cost per successful task = total workflow spend ÷ number of accepted results

Define “accepted” before running the test. For structured extraction, it might mean valid JSON with required fields and values within tolerance. For code, it may require tests to pass, security checks to remain clean and a reviewer to accept the change. Without a quality threshold, a low cost per task can simply mean that the system is producing cheap mistakes.

Caching changes the economics of repeated context

Agents often resend the same material: system instructions, tool definitions, repository context, policy documents or a long conversation history. Prompt caching lets the provider reuse a previously processed prefix instead of charging the full input rate each time.

OpenAI says GPT-6 offers a 90% discount on cached input reads and has added tools for monitoring cache performance. Anthropic prices Opus 5.5 cache reads at $0.20 per million tokens, compared with its $4 base input rate. In both cases, repeated context can be much cheaper than fresh context.

The advertised discount is not the same as the saving your application will receive. A cache helps only when requests reuse an eligible, stable prefix. If an application changes instructions, tool definitions or early context on every turn, the cache-hit rate may remain low.

Measure the following in production-like tests:

• how many input tokens were eligible for caching;
• how many were actually read from cache;
• which prompt changes caused misses; and
• whether cache writes or longer retention add cost.

Prompt design is therefore part of cost engineering. Stable content should usually appear before variable content where the provider’s caching rules support that structure. But do not freeze incorrect or bloated instructions merely to improve the cache rate. A cheap repeated prompt can still waste money if it makes the model less reliable.

Reasoning effort is another price control

Many current models allow developers to adjust how much reasoning effort they use. Higher effort can improve difficult tasks, but it may consume more tokens and take longer. Applying the highest setting to every request is like assigning a senior engineer to every routine ticket.

The opposite mistake is also common. A low-cost, low-effort configuration may fail often enough that retries and escalations erase the saving.

A better design routes work by difficulty. Use a lower-cost configuration for well-understood, easily validated tasks. Escalate uncertain or high-impact cases to a stronger model or higher effort level. The routing decision should be based on measured quality, not on a general belief that one model is “smart enough.”

This introduces a new cost: the router can make mistakes. If it sends a difficult case to a weak path, the workflow may repeat work. If it sends everything to the strongest path, the cheaper tier has little value. Routing quality belongs in the evaluation.

Retries can hide a badly designed workflow

Retries are sometimes necessary. Networks fail, tools time out and models occasionally return malformed results. But an application that quietly tries again can make a weak design look reliable while doubling its consumption.

Track why each retry occurred:

• provider or network failure;
• invalid format;
• failed validation;
• missing evidence;
• tool failure;
• model self-correction; or
• human rejection.

These causes need different fixes. A schema problem may need constrained output. Missing information may require better retrieval. Tool failures may have nothing to do with the model. A harder reasoning problem may justify escalation.

Retries should appear in the cost report, not disappear behind the final successful answer.

The API bill is not the whole operating cost

Cost per successful task is better than token price, but even that can be too narrow if it includes only API charges.

Real systems may also pay for retrieval, vector storage, databases, sandboxes, observability, security controls and human review. Latency has a cost when users wait or infrastructure remains occupied. Incorrect actions can be far more expensive than inference, especially in finance, healthcare, security or production operations.

Keep two figures rather than mixing unlike costs:

1. API cost per accepted task — the direct model and tool charges.
2. Operating cost per accepted task — API cost plus infrastructure and measured human handling.

This separation keeps the calculation understandable while preventing an apparently cheap API from hiding expensive correction work.

How to run a useful cost evaluation

Start with a representative sample of real tasks, with sensitive information removed where necessary. Include routine cases, difficult cases and known failure patterns.

For each model and configuration, record:

• fresh, cached and output tokens;
• number of model and tool calls;
• reasoning or effort setting;
• latency;
• retries and escalations;
• validation result;
• human-review time; and
• final acceptance.

Run enough cases to expose variation. Agent workflows are not perfectly deterministic, so one impressive demonstration is weak evidence. Repeat important cases and inspect the failures, not only the average score.

Finally, set a budget and a quality floor. The winning option is not necessarily the model with the highest benchmark score or lowest invoice. It is the configuration that meets your required quality, latency and risk level at the lowest sustainable operating cost.

What teams should do now

If you already run AI workloads, the September price changes justify a fresh evaluation. Do not simply replace the rate in last quarter’s spreadsheet.

Recalculate actual workflows using current token rates, observed cache hits, retry counts and acceptance rates. Test whether a cheaper tier can handle routine work without increasing correction. Check whether expensive context can be made stable and reusable. Put alerts around cost per accepted task so a prompt or agent change cannot quietly damage the economics.

For teams still experimenting, begin collecting these measurements now. Once an agent reaches production, missing telemetry becomes expensive to reconstruct.

Token prices will continue to fall. That is good news, but it will not remove the need for cost engineering. As AI systems perform longer chains of work, the important question is no longer how cheaply a model can generate text. It is how reliably the whole system can finish a job.

References and further reading

• Claude Opus 5.5 — Anthropic, 22 September 2026. Pricing, cache rates, performance claims and deployment details for Opus 5.5.
• Introducing GPT-6 Sol and Luna — OpenAI, 22 September 2026. API pricing, cost-per-task evaluations and prompt-caching changes.
• OpenAI API pricing — OpenAI. Current API rate card and processing options; recheck before implementation.
• Claude pricing — Anthropic. Current model, prompt-caching and batch-processing prices; recheck before implementation.
• AutomationBench — Zapier. Background on evaluating agents across multi-application business workflows.

Sources reviewed: 25 September 2026.

Related reading: When AI Models Learn From Other AI Models: Distillation, API Abuse and the Limits of Export Controls.