By Scott Sumner | AI at Work | Published September 23, 2026

Editorial illustration of a small purple price tag beside a long receipt and stopwatch: the model bill is only part of the cost of finished AI work.

Cheaper AI models can reduce your software bill without reducing the cost of getting work finished. OpenAI’s September 22 release of GPT-6 Sol and Luna makes this a good time to review what your business actually pays for a usable result.

Answer: Measure AI cost per finished job by adding model usage, paid tools, human review and rework, then dividing by accepted outputs. Lower token prices help, but they do not establish whether a workflow is cheaper overall.

The useful question is not whether the new model costs less to call. It is whether your team can finish the same work, to the same standard, with less total effort.

Jump ahead

What OpenAI actually changed

In its GPT-6 Sol and Luna announcement, OpenAI says API prices are 50% lower than the GPT-5.6 Sol and Luna promotional pricing. It attributes the reduction to improvements in caching and inference. TechCrunch reported the release on September 22, 2026.

That is a specific API pricing comparison. It does not mean every ChatGPT subscription is half price, or that your agency’s AI-powered software vendor has cut its bill in half.

OpenAI also reports better performance on business-workflow, factuality and coding evaluations. These are vendor-reported results under stated test conditions, not measurements of your customer service desk or marketing department. The announcement itself notes that research and API evaluations can differ from production ChatGPT.

My take: lower prices are good news. They give businesses more room to experiment and can make previously expensive uses practical. But a pricing announcement is a reason to revisit your assumptions, not a completed business case.

Define the finished job before comparing models

A model call is not a business outcome. Neither is a paragraph, a draft or a spreadsheet sitting in a downloads folder.

For a service company, a finished job might be a proposal section that accurately reflects the agreed scope and is ready for approval. For marketing, it might be a product page checked against the actual offer. For operations, it might be a request classified correctly and recorded in the right queue.

Choose one of those. Write down the acceptance rules before comparing tools. Otherwise a faster model can appear to win simply because it produces work that is less complete.

For a proposal section, I would specify that every promised service must appear in the source brief, all exclusions must survive, and no invented deadline or price can be introduced. A fluent draft that fails those checks does not count as a finished job.

This is an operating definition, not an industry-standard metric. Your team should decide what accepted means for its own work.

A cheaper model can still produce a more expensive job

Here is a deliberately fictional example. These are not OpenAI prices, measured model results or client outcomes.

Suppose two workflows each produce 100 accepted drafts. Both use a reviewer whose internal time cost is $60 per hour. We exclude setup and other software costs only to keep the arithmetic visible.

Cost for the same 100 accepted drafts Workflow A Workflow B
Model usage, including retries $20 $10
Review and correction per accepted draft 2 minutes 4 minutes
Total review and correction cost $200 $400
Total measured cost $220 $410
Cost per accepted draft $2.20 $4.10

Workflow B halves the model bill. It still costs more overall because the example assumes more human correction. Nothing here says the newly released models require more correction. The point is to measure whether they do.

The reverse matters too. A lower-priced model that also reduces editing time could save much more than the token comparison suggests. Do not assume cheap means poor, or expensive means dependable. Compare the actual work.

Test one workflow before switching everything

Start with a small evaluation set of 20 representative past tasks, using approved data and the same source material for each candidate. Twenty is a practical starting point, not enough to prove safety or reliability for every situation. Include awkward briefs and missing information, not only the clean examples that make a demo easy.

Keep the acceptance rules fixed. Let the reviewer judge outputs without the model name when feasible. Record the result and actual review time, including the drafts you reject.

  • Usage: include retries and all billable model or tool activity, not only the final successful response.
  • Human effort: include reading, fact-checking, correction and escalation.
  • Accepted work: count only outputs that meet the written standard.
  • Failure type: distinguish an awkward sentence from an invented promise. Some errors should disqualify a workflow rather than be averaged into its cost.
  • Elapsed time: record waiting time separately. A low-cost job that misses a customer deadline is not an operational win.

Use this calculation for a measured batch:

Cost per accepted output = (model and tool charges + review and rework labor) / accepted outputs.

Keep initial implementation costs separate, then decide how to spread them across realistic usage. If you already pay a flat subscription, distinguish the allocated cost from the extra cash cost of this particular test. Do not quietly count the same labor twice.

For rare but serious mistakes, a small sample cannot establish an acceptable failure rate. Retain the safeguards the work requires. A better average does not justify removing review of consequential customer commitments.

Ask your provider what the price change actually reaches

If you buy a packaged AI service rather than API access, the underlying model price is only one supplier cost. Hosting, support, integration and the vendor’s margin can all sit between the model rate and your invoice.

Ask whether your workflow uses the affected model, whether the supplier intends to change pricing, and whether any change also affects usage limits or service levels. A falling ingredient cost does not automatically change the price on the menu.

There is no need to turn every model release into a procurement project. Revisit workflows where usage is substantial, where work previously cost too much, or where the vendor claims a meaningful improvement. Leave a dependable low-volume workflow alone if a switch would cost more than it saves.

What this means for AI-assisted website work

Cheap generation makes it easier to produce service pages, compare offers and draft useful explanations. Publishing more pages is not the finished job.

The finished job is a page a buyer can use: the offer is accurate, the evidence is real, the next step works, and the business can maintain it. Those requirements connect practical AI use to AI Findability. A business needs to be understandable and trustworthy, not merely prolific.

When evaluating an AI website workflow, include the time spent checking claims, publishing, reviewing the rendered page and fixing errors. If you are repairing existing content, the content refresh process should improve the answer rather than manufacture a newer date.

If you need help identifying where your website loses clarity or trust, the Findability OS Audit is the relevant starting point. It is a website diagnostic, not a promise to benchmark every model in your business.

One next move: choose one recurring AI-assisted task and record the time it takes to reach an accepted result. Compare that with the model bill before deciding what to change.

Sources and scope

The cost framework, sample acceptance rules and worked example are my recommendations and illustrations. They are not findings from those sources. I have not presented this as a hands-on test of the new models.