How much does model inference cost a business each month?

A measured guide to model inference for a customer inbox, invoice entry and month-end close.

A business handling 150 customer emails a day, entering 500 invoices a month and preparing five close packs would have spent about A$75.82 to A$85.43 a month on model inference in my benchmark.

That figure uses only models that scored at least 98% in every official run for their task.

It covers billed model calls only. It excludes implementation, integration, hosting outside inference, monitoring, audit storage, human review, exception handling, retries, reprocessing, extra model-review stages, taxes and foreign-exchange fees.

Model inference is one piece of the cost. It is also the piece most businesses have no feel for yet.

This benchmark puts a monthly figure on model inference at defined workloads.

What I measured

I tested 30 model configurations on inbox triage and invoice entry, and 18 current configurations on month-end close.

The three tasks were:

1. Triage 20 messages in a shared inbox.
2. Enter a supplier invoice through a browser.
3. Prepare a month-end close pack.

Each task ran three times per cell. The invoice task used two documents, giving each model six invoice runs.

For this article, I have included only models graded Good. That means every official run for the task scored at least 98%.

The included models were:

• Inbox: GPT-5.6 Terra, Qwen3.7-Max, Qwen3.8-Max, GPT-5 and Claude Opus 5.
• Invoice: Claude Sonnet 5.
• Close: Gemini 3.7 Flash, Grok 4.6 and Claude Opus 5.

A Good grade qualifies a model for a larger trial. It does not turn three successful repeats into a production guarantee.

All projections use billed OpenRouter API costs from the August 2026 benchmark. I converted them at US$1 = A$1.398, the Frankfurter rate dated 25 August 2026.

The three workload guides

I used 22 business days in a month.

Workload	Small	Medium	Large
Customer emails per day	30	150	500
Invoices per month	100	500	2,000
Close packs per month	1	5	20

One inbox model call handles 20 emails, matching the benchmark task. That produces 33 monthly inbox calls for Small, 165 for Medium and 550 for Large.

The monthly range combines the lowest and highest measured Good model for each task. It does not assume one model handles the whole business.

Workload	Monthly model inference
Small	A$15.16 to A$17.09
Medium	A$75.82 to A$85.43
Large	A$301.71 to A$334.05

The low end uses GPT-5.6 Terra for the inbox, Sonnet for invoices and Gemini for close packs. The high end uses Opus for the inbox and close, with Sonnet still handling invoices.

Invoice entry accounts for most of the bill. It took many browser turns, while inbox triage and the close each completed in one model response.

Customer inbox costs

The inbox projection assumes one call for each group of 20 emails.

Good model	30 emails/day	150 emails/day	500 emails/day
GPT-5.6 Terra	A$0.47/month	A$2.36/month	A$7.88/month
Qwen3.7-Max	A$0.95	A$4.75	A$15.82
Qwen3.8-Max	A$1.30	A$6.51	A$21.69
GPT-5	A$1.43	A$7.14	A$23.79
Claude Opus 5	A$2.30	A$11.51	A$38.35

All five stayed above 98% in every inbox run. They did not make identical mistakes, and the original study is still too small for unattended deployment. This table answers the model-call cost once a configuration has earned further testing.

At 150 emails a day, the measured difference between the lowest and highest Good model was about A$9.15 a month.

Invoice-entry costs

Sonnet 5 was the only model to get all 18 invoice fields right in all six browser runs.

Good model	100 invoices	500 invoices	2,000 invoices
Claude Sonnet 5	A$14.68/month	A$73.41/month	A$293.62/month

The measured model cost was about 14.68 Australian cents per invoice.

That does not include the accounts system, document storage, purchase-order matching, approval rules or a person investigating an invoice that does not reconcile. It is the cost of the model operating the browser under the tested setup.

This task cost more because the model had to observe the page, choose an action, receive the new page state and repeat. Those turns kept sending page information back through the API.

Month-end close costs

Three models scored 100% in all three original close runs.

Good model	1 close/month	5 closes/month	20 closes/month
Gemini 3.7 Flash	A$0.01	A$0.05	A$0.20
Grok 4.6	A$0.03	A$0.15	A$0.59
Claude Opus 5	A$0.10	A$0.52	A$2.08

Even at 20 close packs a month, the measured model inference stayed below A$2.10.

A close still needs source-system connections, evidence, review and approval. The table gives the model-call component after the data has been prepared for the tested task.

What actually drives the token bill

A token price by itself tells you very little about the cost of finishing a job.

Four parts moved the bill in this benchmark:

• how much input the model received;
• how much it returned, including reported reasoning inside completion usage;
• the model's input and output rates;
• how many calls or browser turns the job needed.

Here are four measured examples. Token figures are mean usage per task run. Reported reasoning is part of completion usage, not extra on top.

Task and model	Input tokens	Completion tokens	Reported reasoning	Total tokens	Model cost
20-email inbox, GPT-5.6 Terra	1,726	605	0	2,331	A$0.0143
One invoice, Claude Sonnet 5	39,266	2,648	not reported	41,914	A$0.1468
One close, Gemini 3.7 Flash	1,682	3,554	2,786	5,236	A$0.0102
One close, Claude Opus 5	2,106	2,548	1,287	4,654	A$0.1038

Opus used fewer total tokens than Gemini on the close and cost about ten times as much. Their token rates were different.

Sonnet's invoice used about eight times Gemini's close tokens because browser operation repeated the page-and-action loop. The shape of the task changed the token count before model price entered the calculation.

This is why a blanket statement such as one million tokens costs X cannot tell a business what an automated process will cost. You need the model rate and the measured tokens required to finish that particular job.

A subscription is a different cost

A ChatGPT, Claude or other chat subscription is a user product. The provider sets seat prices, message limits and acceptable-use rules.

An automated business process normally calls a model through an API and pays for measured usage. Staff may still have chat subscriptions, but those subscriptions should not be used as the budget for an automated workflow.

The API calculation is separate from subscription pricing:

task runs × mean billed USD cost per task run × currency conversion

For invoice entry, the measured per-run cost already includes every browser-agent model turn.

Price sensitivity

I expect model prices to continue falling. That is my opinion, not a finding from this benchmark.

For conservative planning, the table below applies uniform 2×, 5× and 10× price increases to the measured Medium workload.

Price assumption	Medium monthly model inference
Measured prices	A$75.82 to A$85.43
2× prices	A$151.64 to A$170.86
5× prices	A$379.11 to A$427.15
10× prices	A$758.22 to A$854.31

This sensitivity test does not predict that every provider will change input and output rates by the same amount.

Put your own volume into the calculation

The arithmetic is straightforward:

Inbox monthly task runs = daily emails × 22 ÷ 20
Invoice monthly task runs = monthly invoice count
Close monthly task runs = monthly close-pack count
Monthly inference cost = task runs × mean billed USD cost per task run × 1.398

If you process emails individually rather than in groups of 20, measure that setup. If your invoice agent uses native document extraction instead of a browser loop, measure that too. Architecture changes the number of calls and tokens.