Intelai
Price per Token Is the Wrong Number for Model Selection
Anthropic cut Opus pricing by about two thirds. The cost that decides a deployment is still the completed task, not the token.
Claude Opus 4.5 cut the price by roughly two thirds (opens in a new tab) against the previous Opus generation, with improvements aimed at coding and long-running tasks.
That is a real change in the market, and it is the wrong number to put in a business case.
Price per token is an input. What a program buys is a completed task, and the two are related by everything the original post did not count: retries, verification, human review, and the cost of the failure that gets through. A model at a third of the price that needs two attempts and a reviewer is not cheaper. It is a different workflow with a different failure mode.
The unit that matters
Take a concrete workflow. An agent reads a contract modification, extracts the changed clauses, updates a tracker, and drafts a summary for a contracting officer.
The invoice for that work has several lines, and only one of them is tokens.
- Attempts. The first output is wrong maybe a quarter of the time on a task like this. Each retry is another full pass, and a cheaper model retries more often.
- Verification. Somebody or something has to check the extraction against the document. If the model is weaker, verification has to be stronger.
- Review. The contracting officer reads the summary regardless. That cost is fixed and large, and it does not fall when inference gets cheaper.
- Failure. A missed clause that reaches a modification is not a token cost. It is a rework cost, and occasionally a legal one.
Add those up and the model price is often a small fraction of the total. Which means the decision framework that compares dollars per million tokens is comparing the cheapest line in the invoice.
A cheaper model is only cheaper if the task is the same task.
Where the price cut actually changes the decision
The cut does change one thing, and it is worth being precise about it.
It moves the crossover point between two architectures. Before, a hard task often justified a small model plus a lot of orchestration: decompose the problem, call the cheap model several times, validate each step, and reassemble. That architecture has engineering cost and latency, and it fails in ways that are hard to debug.
When the strong model gets cheap enough, the simpler architecture wins for more tasks: one call, one long context, one output. Fewer moving parts, less code to maintain, a failure you can reproduce.
For a small team, that is the real benefit. Not the invoice. The reduction in system complexity.
The crossover moves with the task, though, and it does not move to zero. Long-horizon work with tool calls, work where a wrong intermediate step poisons everything after it, still rewards the strongest model you can afford. Work that is high volume and low consequence still belongs on the cheapest model that clears the bar. A price cut does not change that rule. It changes how many tasks fall on each side.
What a federal buyer should do with this
Two things, and neither is a benchmark comparison.
First, measure the task on your own data. Pick twenty real cases, run them through each candidate, and count the ones that pass review without correction. That number, divided into the fully loaded cost including review, is the only cost comparison that means anything. Vendor benchmarks measure the vendor's corpus.
Second, treat a model version as a configuration item. In an authorized environment, the model is part of the system. A version change is a change to the system, and it needs the same review as any other change that can alter behavior. This is where a price cut becomes a procurement question rather than a finance one: if you swap the model to capture the savings, you own the revalidation.
That second point is the one programs underestimate. The savings are visible in the first month. The cost of revalidating behavior shows up in the third, when someone notices the summaries changed style and the reviewers stopped trusting them.
The comparison that survives scrutiny
Here is the test I would apply to any model-selection memo, including one written about this release.
Does it state the task, the pass rate on your own cases, the review cost, and the cost of a failure? If it does, the token price is one line in a defensible argument. If it does not, the memo is a price list with a recommendation stapled to it.
Anthropic's price cut is good news for anyone building on Claude, and it will move real budgets. It does not change the question a program has to answer, which is whether the output can be used without a person redoing the work.