Three AI Models at $2/$10: Compare the Full Task Cost

Three major model announcements now share a $2 input and $10 output price per million tokens. That is a useful comparison point, not an industry-wide default or a promise of equal bills. Argon’s rate is introductory and access is restricted; task length, caching and retries can outweigh a matching list price.

Prepared October 1, 2026. Launch announcements are dated through September 30, 2026; GPT-6.1 Sol and Gemini 3.1 pricing documentation was checked on October 1, 2026. Later product developments are outside this article’s scope.

Anthropic’s Sonnet 5.5 announcement lists $2/$10 and $0.20 cache reads. OpenAI’s GPT-6.1 Sol documentation lists $2/$10 and $0.10 cached input. Google’s Argon announcement specifies introductory $2/$10 and a 95% input-cache discount, with $4/$20 after the introductory period. Argon begins with vetted access; an announced price is not general API availability.

The last two rows prevent an overbroad conclusion. Google’s pricing page and xAI’s September 21 release notes show different output rates at the same input price. Our maintained price index carries the wider model catalog; this article addresses the purchasing implication of the launch cluster.

Consider an illustrative task with 10,000 uncached input tokens, 100,000 cache-read tokens and 5,000 output tokens. At $2/$10 with $0.10 cache reads, its token cost is $0.02 + $0.01 + $0.05 = $0.08. At the same input/output rates with $0.20 cache reads, it is $0.09. This is arithmetic on an assumed workload, not a measured benchmark.

The example excludes cache creation, storage, tools, regional premiums and accelerated service, each of which can be the largest line for a particular workload. It also assumes the cached input qualifies for the vendor’s discount. A prompt that looks similar to a previous prompt does not establish a cache hit. Use actual usage records to distinguish cached input from input billed at the ordinary rate.

Use the same task set and output contract when comparing candidates. A concise answer that omits a required check should not win because it costs less. Conversely, a longer response is not more valuable simply because it consumes more output tokens. Judge whether the work meets the requirement before interpreting the bill.

Keep reasoning settings explicit. A model may offer several effort levels, and a default setting can change the amount of computation used. Our routing guide describes a task-based comparison that can include a cheaper first attempt and a stronger fallback without hiding the fallback cost.

For Argon, calculate a later-price scenario before designing a workflow around the introductory offer. On uncached input and output, the announced $4/$20 is twice $2/$10. Do not infer an introductory end date or additional pricing tiers that Google has not published. The Argon launch guide preserves those availability and pricing limits.

A budget should also identify the operational condition that changes the rate: long prompts, faster service, regional processing or a different serving provider. Write that condition alongside the estimate. Otherwise, the number can remain in a planning spreadsheet after the workload no longer qualifies for it.

Matching headline rates make it easier to justify testing alternatives; they do not justify switching without evidence. Choose one representative workload, retain the same permission boundary and compare accepted-result cost. Our AI transformation service helps teams connect that evaluation to a controlled routing decision.

The illustrative task in the arithmetic section used three token classes, uncached input, cache reads and output, and that is the whole worksheet. Take one representative workload, run it for a day on your current model, and pull the three totals from the usage records rather than estimating them. Then apply each candidate’s published rates to the same three totals. The result is a per-task figure for each model on your traffic, which is the figure the list prices cannot give you.

Two columns need care. Cache reads count only where the vendor’s discount actually applied, so take the cached figure from the billing record and not from the number of prompts that looked similar. Output includes any reasoning tokens the model billed as output, so a model run at a higher effort setting is a different row, not the same model at a different price.

Then divide by accepted outputs rather than attempts, as the callout above says. A model that needs a retry on one task in ten has a per-accepted-task cost ten percent higher than its per-attempt cost, and that difference can exceed the gap between two vendors at the same list price.

Each illustrative case below is a team reading $2/$10 as “the same price” and discovering a different bill. They are the reasons the sections above keep attaching conditions to the headline rate.

The assumed cache: a budget counts every repeated prompt as a cache read at the discounted rate, and the invoice shows most of it billed as ordinary input because the prefix did not qualify. The long prompt: a workload that routinely exceeds a vendor’s long-context threshold is priced at the short-prompt rate the announcement led with, and pays the higher rate the pricing page lists for longer prompts. The permanent promotion: a forecast is built on Argon’s introductory $2/$10 with no row for the announced $4/$20, and the model is baked into a workflow before the price it will carry is known. The uncounted retry: two models are compared per attempt, the cheaper one needs more attempts to pass the same check, and the comparison picks the model that costs more per accepted result.

The worksheet catches the first two by reading the bill rather than the brochure, the forecast section catches the third, and dividing by accepted outputs catches the fourth.

The forecast section says to write the operational condition that changes the rate alongside the estimate. In practice that is a short list that travels with every cost figure in a planning document, and it is the difference between a number that can be checked later and one that quietly stops being true. For the three $2/$10 models in the table, the conditions are the ones this article has already attached: the standard tier rather than an accelerated one, prompts under any long-context threshold the vendor publishes, cached input that actually qualified for the discount, and, for Argon, the introductory period with its vetted access.

Write them as a sentence a reviewer can test, not as footnotes. An illustrative line, using the worked example above: “$0.08 per task on GPT-6.1 Sol, assuming 100,000 cached tokens billed at the cached rate, 10,000 uncached, 5,000 output, standard tier, prompts under the long-context threshold” can be compared with one month’s usage record line by line. “About 8 cents a task” cannot, and six months later nobody will remember which of those assumptions it rested on.

The same habit protects the comparison between vendors. Two estimates that carry their conditions can be judged like for like; two headline figures cannot, which is the whole point of this post. When a condition changes, the estimate is re-run rather than adjusted by feel, and the change is visible in the planning record rather than discovered on the invoice. Our maintained price index, linked above, is where the rate side of each condition is checked; the usage side can only be checked against your own records.

For a team that runs several models, one shared template for the condition sentence is worth more than any single estimate, because it makes every figure in the plan answer the same questions in the same order and shows at a glance which assumptions differ between vendors, and which of them a single vendor announcement could change overnight.