AI Model Prices Fell Again on 22 September. Your AI Bill Won't Simply Follow the Price List — Here's the Arithmetic

Abstract illustration of a price tag shrinking while the container it fills expands, shown as nested outlines in blue

AI Model Prices Fell Again on 22 September. Your AI Bill Won't Simply Follow the Price List — Here's the Arithmetic

A worked example: what one routine finance task actually costs, once you count retries, re-sent context and the long-request cliff. Token price is the input. Cost per accepted output is the number that belongs in your budget.

On 22 September, Anthropic released Claude Opus 5.5 at $4 per million input tokens and $20 per million output — about 20 per cent below the model it replaced. The same day, OpenAI released GPT-6 Sol at $2 and $10, half the price of the GPT-5.6 version it replaced, and GPT-6 Luna at 10 cents and 50 cents. All prices here are in US dollars per million tokens.

I am not going to relitigate whether cheaper tokens make AI cheaper; we made that point in Saturday's wrap and I would rather not repeat it. What that argument almost never includes is the actual sum. So here is the sum, on one ordinary finance task, with every assumption stated so you can substitute your own.

Step one: pick a task with a countable output

Take supplier invoice coding — GL account, cost centre, and for our sectors the funding stream or program the cost belongs to. Say 1,200 invoices a month. It is a good example because the output is discrete and countable, and because "correct" is checkable by a human in seconds.

The unit is one accepted coded invoice: coded by the model, reviewed by a person, and posted without change. That last clause is the whole trick. An output your AP officer has to rework is not an output; it is a draft that also cost you tokens.

Step two: the naive calculation, which everybody does

Assume each invoice sends about 2,000 input tokens — the extracted invoice fields plus a short instruction — and returns about 150 output tokens. At Sol's $2 / $10:

Input: 1,200 × 2,000 = 2.4 million tokens = $4.80.
Output: 1,200 × 150 = 180,000 tokens = $1.80.
Total: $6.60 a month, or about half a cent per invoice.

This is the number that gets put in the business case, and it is the number that makes people say AI is basically free. It is also wrong — typically by several times, and by far more once agents are involved — for three reasons that have nothing to do with the price per token.

Multiplier one: the context you re-send every single time

A model that codes your invoices correctly needs to know your chart of accounts, your cost centre list, your funding streams, and your coding conventions. In a small NFP that is perhaps 8,000 tokens; in a multi-program NDIS provider with a long GL it can be 30,000 or more. And it goes with every request, because the model has no memory between calls.

At 10,000 tokens of standing context per invoice, input rises from 2.4 million to 14.4 million tokens a month. The bill goes from $6.60 to about $30. Prompt caching helps a great deal here — cached input on Sol is quoted at 20 cents per million, a tenth of the standard rate — but only if the context is genuinely stable and the cache is actually being hit, which is an engineering question, not a pricing one. Ask whoever built the integration to show you the cache hit rate. If nobody can, assume you are paying full freight.

Multiplier two: agent loops turn one call into six

If the task is wired as an agent — look up the supplier, check the last three invoices from them, check the PO, then code — each of those steps is a separate call, and each carries the whole conversation so far. Five steps with a growing transcript is not five times the cost of one call: if each step adds as much context as the first call carried, the input sums to fifteen call-equivalents (1 + 2 + 3 + 4 + 5), because it grows at every hop.

This is the single biggest driver in most real deployments, and it is invisible in a per-token comparison. It is also why a model that is 20 per cent cheaper but needs two extra reasoning steps is more expensive, not less.

Multiplier three: the rejects, and the long-request cliff

If 15 per cent of coded invoices need rework, you paid for 1,200 outputs and received 1,020 accepted ones. Divide by accepted, not by attempted, and the unit cost rises by about 18 per cent before anyone has touched the price list.

Then there is the step-up nobody models. GPT-6 Sol moves to a higher long-context rate once a single request exceeds 272,000 input tokens — and the higher rate applies to the whole request, not just the tokens above the line. For its predecessor, GPT-5.6 Sol, OpenAI priced that tier at twice the input rate and one and a half times the output rate. Do not assume the multiplier carried over unchanged, and do not take it from a comparison site, including this one. Read the vendor's own pricing page, then work out whether any of your workflows can cross 272,000 tokens in one request. Anything that loads a full general ledger extract, a year of bank statements, or a folder of contracts can, and a workflow that quietly crosses that line mid-month is how a stable AI bill becomes a surprising one.

$6.60
Illustrative naive monthly cost for 1,200 invoices at Sol's headline rates — tokens in, tokens out, nothing else counted.
≈5× to 27×
Illustrative, standard rates, no caching: about $36 a month once 10,000 tokens of standing context and a 15% rework rate are counted (≈5×); about $180 if the same task runs as a five-step agent re-sending that context at every step (≈27×). Your own multiple depends on context size, loop depth and accept rate — measure all three.

None of these figures are a forecast of your bill. They are a worked shape, and the shape carries two lessons. First, the multipliers — not the price list — decide what a task actually costs. Second, and this is the part the headline misses: if the multipliers stayed exactly the same on the new model, a 50 per cent price cut really would halve the bill. It rarely works out that way, because they don't stay the same. A new model may need more or fewer tokens to reach an accepted answer, you may move to a different model or effort setting, and the review time and integration work around the task do not move with the token price at all.

The 22 September releases show both directions at once. Anthropic says Opus 5.5 costs about 40 per cent less than Opus 5 on a typical workload — double its 20 per cent price cut — while one independent code-review pipeline found it used about 49 per cent more tokens than its production baseline. Same price list, opposite effects. That is why a price cut is a hypothesis about your bill, not a forecast of it, and why the denominator below matters more than the rate card.

The number to put in the budget

Cost per accepted output. One line, one denominator, tracked monthly:

(total API spend for the task) ÷ (outputs accepted without rework)

Compute it per task, not per department, because the tasks behave completely differently — invoice coding and variance commentary do not belong in the same average. Track it for three months before you conclude anything. And record the accept rate alongside it, because a falling cost per accepted output usually means the accept rate improved, and that is a process win worth naming rather than a procurement one.

This matters beyond housekeeping. Deloitte's global survey of 1,434 finance leaders across 26 countries, at companies with revenue above US$1 billion, found 60 per cent expect AI costs and technical complexity to rise substantially through 2027. Yet only around a quarter say their main route for approving large AI and technology investments is a formal process requiring quantified ROI and a business case — and almost as many, 23 per cent, say executive or board mandates drive most of those decisions. Those findings sit badly together. Smaller organisations are not exempt from the arithmetic; they just have less room to absorb getting it wrong.

All dollar figures and token counts in this post are illustrative and stated with their assumptions. Vendor pricing changes frequently — confirm current rates and any tiered thresholds on the vendor's own pricing page before modelling them.

On AI and your data: invoice, payroll and participant data is sensitive. Before routing any of it to a model, confirm whether the vendor retains customer inputs for model training. The safest posture is a tool where your data is not retained for training, and that question belongs in the procurement conversation alongside price. In line with OAIC guidance, keep names and identifiers out of anything you send wherever the task allows — a no-training setting does not change your Privacy Act obligations.

Can you state your cost per accepted output?

If the answer is a monthly API invoice with no denominator under it, the number is not telling you anything yet. PFL provides senior-level outsourced finance, management reporting, and AI automation for Australian NFP, NDIS, and SME organisations.

Talk to PFL →
Timothy, CPA is Managing Director of Professional Financelink (PFL), providing senior-level outsourced finance, management reporting, and AI automation for Australian NFP, NDIS, and SME organisations. 20+ years in finance leadership across NFP, NDIS and SME.

Comments

Popular posts from this blog

Google Gemma 4 Just Launched — And It Might Solve Finance's Biggest AI Privacy Problem

Claude vs Gemini for Australian Finance: An Honest Comparison After 12 Months of Using Both

Why NFP Boards Are Finally Talking About AI — And What the Finance Team Should Do Before They Ask