Which AI agent is cheaper in 2026: the cost of one solved task

Subscription and per-token prices are inputs to a cost comparison, but they are not enough on their own. For the same money, one agent might complete five tasks, or it might complete one. To compare value for your workload, measure how much you spend per task brought to a defined working state, including unsuccessful attempts.

Next, I’ll show the formula for this cost and calculate it using providers’ prices as of early September 2026. I’m using sample usage figures and will make that clear: your figures will be your own. You can recalculate everything below yourself; there are no promises of savings and no magic combinations.

For information about working with the service, see the Ailoot documentation.

Why doesn’t the monthly price tell you which agent is cheaper?#

Most people look at the subscription price when choosing. One agent costs $20 a month, another $200, and it seems the first is ten times better value. The price comparison alone does not establish value: a subscription measures access, while the work completed within it still needs to be measured.

Imagine two taxis with a fixed monthly fee. One gets you where you need to go on the first try, while the other takes a wrong turn on half the trips, so you call it again. Their subscriptions might be the same, but in practice you’ll get to your destination for half the cost with the first one. It’s the same with agents: you pay the same subscription, but how many tasks you complete depends on what’s under the hood.

It’s best to keep the subscription separate from the discussion about the cost of a task. Its advantage is that the amount is predictable. I have a separate breakdown of the choice of pricing model—subscription, pay-as-you-go, or custom development—in what goes into the price of an AI agent. This article addresses a different question: whatever the payment model, which agent delivers results at a lower cost?

Why is the per-token price misleading too?#

The second most popular way to compare is to look at the price per token. A token is a piece of text, roughly part of a word; it measures both what you send to the model and what it writes in response. Providers publish prices per million tokens, and prices vary widely between models. It seems logical: choose the model with the lower price and pay less.

The trap is that the per-token price is the price of raw material, like the price of gas per liter. What you care about is the cost of the whole trip; a liter by itself doesn’t tell you much. An agent solves a task in many steps: it browses files, runs commands, reads errors, rewrites code, and sends the context to the model again at each step. One conversation with an agent can easily turn into dozens of requests, each of which uses tokens.

Two possible effects can change a price-only comparison: a model may need more steps and tokens, or it may complete fewer tasks. Neither effect follows from price alone. Measure both for each candidate on the same tasks, including unsuccessful attempts. I have a detailed breakdown of how the bill grows in how to calculate API token usage, and separately, why vibe coding costs more than it seems.

What is the cost of one solved task?#

Now for the metric this article is about: calculate the cost of one result brought to completion. The plan or token price contributes to that cost but is insufficient on its own; include the actual usage and completed results. The formula is simple:

1. Take the price of one agent run on a task—the cost of all the tokens it uses in one attempt.
2. Estimate the share of tasks the agent actually brings to a working state.
3. Divide the first by the second to get the cost of one solved task.

Here’s why you divide. If an agent completes seven out of ten tasks, three of the ten runs are wasted, but you paid for all ten. That means the cost of those ten runs is spread across seven working results, making each one more expensive than a single run. The lower the success rate, the higher the cost per working task.

The “share of completed tasks” is measurable. It’s measured with benchmarks such as SWE-bench: an agent is given real bugs from real projects and submits fixes, which the system checks with automated tests. The percentage in the table is the share of tasks solved. But a lab percentage is not the same as yours: your share on your own project will differ, so treat the benchmark as a reference point, not a promise. I explain how to read these tables separately in the article on the ranking of AI coding agents.

What are the three factors that make up the cost of a task?#

Let’s break the cost into its components so we can see where the extra spending hides.

First: the per-token price. The model’s base price: how much a million input tokens and a million output tokens cost. There can be dozens of times’ difference between a heavyweight model and a lightweight one.

Second: the volume of tokens per task. How much text the agent runs through the model in one attempt. It depends on how large the task is, how many files the agent rereads, and how many steps it takes. A model that reaches a solution in fewer steps may use fewer tokens; confirm the actual usage rather than inferring it from its price or label.

Third: the share of completed tasks. The percentage of attempts that end with a working result. This factor divides the total cost: holding the run cost fixed, at a 40 percent success rate you pay twice as much for each working task as you do at 80 percent. That comparison does not establish which factor matters most when prices and usage also change.

All the confusion around comparisons comes from people looking only at the first number—the per-token price. But all three numbers determine the final cost. A low price with high volume and a low success rate can easily end up costing more than a high price with low volume and a high success rate.

Combining these three numbers into a working setup requires measuring them together. Clear context and a suitable method may reduce token volume or improve success, but changing the model can affect those numbers too. This example does not measure whether the method or the model’s price has the larger effect.

How much does a run cost for different models?#

To make the formula concrete, I’ll calculate a run using actual listed prices. I’m using a sample nontrivial task on which the agent uses around 300,000 input tokens per attempt (rereading the project and errors over many steps) and around 40,000 output tokens. Again, this is an example for the calculation, not a measurement; your usage will differ.

Here are the prices per million tokens according to providers’ official pricing as of early September 2026:

You can check the formula with a real example from Anthropic’s documentation. For a request to Opus 5 with 50,000 input tokens and 15,000 output tokens, it gives this calculation:

In other words, input and output are added together using their respective prices—exactly as in the formula. All that remains is to divide the run cost by the share of completed tasks, and that’s where a low price starts to behave unexpectedly.

Why can a cheap model make a task more expensive than a powerful one?#

Here’s the point that made it worth doing the calculation honestly. I’ll compare two models by the cost of the result; the run cost itself is no longer the main thing.

Sonnet 5: a run costs about a dollar, and for our sample task, let’s say it completes 70 percent of attempts. The cost of one working task is one dollar divided by 0.7, which is about $1.40.

Haiku 4.5: the sample run costs about 50 cents, and the listed per-token price is half as much. For this illustration, assume it uses about 1.6 times as many tokens and completes 40 percent of attempts. Under those assumptions, a working task costs about $2. The extra usage and success rate are inputs to the example, not observations caused by the model being cheaper.

Within this hypothetical example, the model with half the per-token price has the higher calculated cost per solved task because the assumed usage and failure rate outweigh that price advantage. This demonstrates how the formula behaves, not which model will be better value on your project.

A caveat: I’ve used 70 and 40 percent success rates and sample token volumes to show how the mechanics work. Your numbers will differ, and it’s entirely possible that a lightweight model will handle your workload well and remain the cheapest. A more expensive model isn’t necessarily better value; compare the cost per result using your own three numbers.

How to calculate your cost per task: three profiles?#

To apply this to your own work, estimate which profile is the closest fit. The formula stays the same; only the three numbers change.

Profile one: simple, repetitive tasks. Rewriting text, organizing data, making a small code fix. Test whether a lightweight model such as Haiku or DeepSeek V4-Flash meets your acceptance criteria with low usage and few retries. Compare its measured cost per working result with another candidate before calling either the cheapest or treating Opus as overpayment.

Profile two: complex work with unfamiliar code. Understanding someone else’s project, fixing a non-obvious bug, building a new feature. Measure complete attempts on these tasks. A model with a higher token price can cost less per usable result if improved success or reduced usage offsets that price, but the advantage must be shown by your results rather than assumed from the model’s category.

Profile three: a mixed workload. Compare a single-model setup with routing routine and difficult tasks to different candidates. Count the usage, failures and correction work for the whole workload. Routing may improve cost per result, but this article has not measured it as the cheapest solution. Many agents let you switch models while you work.

Calculate each profile separately using the same formula, and you’ll see where it costs less.

What is the most common mistake people make when choosing?#

A price-only choice can hide different outcomes across workloads. A model may handle routine work economically yet require more attempts on a difficult feature. Whether those attempts make its result more expensive than another model is a question for the measured usage and completion rate, not a conclusion established by its low token price.

The opposite can happen too: if a lightweight model completes the same accepted task at a third of the cost, choosing a higher-priced setup for that task adds unnecessary expense. The comparison is conditional; test the quality, attempts and cost before assuming the lower-priced setup will do so.

A note about my own approach. I work with Claude Code and a subscription; I don’t use the plain API for daily work because I prefer a predictable amount to a meter running. Clear tasks and relevant context are practical things I can improve. They may change token usage and success rate, but this experience does not isolate their effect from model choice or establish that model prices matter less. Compare each setup on accepted results and total cost.

So which agent is cheaper?#

There is no single cheapest agent established by this illustration: cost per result varies by workload. Use the applicable plan or token prices, measure usage and accepted results, and compare the resulting costs. Update the calculation when prices or your workload change.

One last point. Cost per solved task depends on the model’s prices, the tokens used across all attempts, and the share of tasks that actually succeed. Context and working method can change token usage and success rate, and changing the model can change them too. The illustrative success rates above do not measure which factor matters most. Compare candidate models on the same representative tasks, count retries and human correction, and choose by measured cost per usable result.

The agent, model prices, context and working method can all affect cost per solved task. Structured work may change token volume or success; compare those effects using measured results rather than treating the model or its price as secondary.

Get to know Ailoot.