AI prices fell this week. The cost of finished work is harder to measure.

The price of a new AI model can fall while the bill for running it stays roughly where it was. That is what Artificial Analysis found when it put Claude Opus 5.5 through its Intelligence Index at maximum effort, with Anthropic’s default fallback routing enabled: the system produced substantially more output tokens than its predecessor, offsetting cheaper pricing. It also earned the evaluator’s highest overall score. The money was buying a stronger performance on those tests, rather than a smaller invoice.[1]

OpenAI’s GPT-6 Sol and Luna, released September 22, took a different route. In the same evaluator’s September 22 assessment, their overall Intelligence Index scores were broadly level with their predecessors while measured costs fell sharply. Some individual capabilities improved; others slipped. Their lower rates create room to save, but the bargain depends on the work.[2]

Those distinctions matter as an AI request grows from a question into a job: read a set of files, find the relevant records, change something, check the result and try again if it fails. A low price for generating text helps. So do fewer unnecessary steps, successful reuse of information already processed, and an answer that survives inspection. None is a substitute for the others.

Anthropic introduced Opus 5.5 on September 22, claiming 40 percent lower costs for typical workloads at default settings. Ordinary input and output rates fell 20 percent; cache reads fell 60 percent. The advertised workload saving also depends on task mix and token use.[3]

OpenAI released Sol and Luna through its APIs on the same day. These are services priced by usage, which makes their economics visible in a way that a monthly chatbot subscription often is not. Their arrival gives software builders a fresh reason to revisit which work needs their most expensive model.[4]

What the price list actually buys

A token is a unit of text processed by a model; it need not correspond to a whole word. Providers charge separately for information sent into a model and tokens it generates. Because models can divide the same text differently, identical token counts are a billing illustration, not proof that two systems have performed identical work. Artificial Analysis distinguishes models’ native tokens from the common token measure it uses for some performance comparisons.[5]

The published standard rates make the scale of the new options clear:

• Claude Opus 5.5: $4 per million input tokens and $20 per million output tokens. Illustrative charge: $0.60.
• GPT-6 Sol: $2 per million input tokens and $10 per million output tokens. Illustrative charge: $0.30.
• GPT-6 Luna: $0.10 per million input tokens and $0.50 per million output tokens. Illustrative charge: $0.015.

Standard API rates checked September 26, 2026. Each illustrative charge assumes 100,000 ordinary input tokens and 10,000 billed output tokens. These are The Daybreak’s calculations, not benchmarks. The calculation excludes caching, tools, regional premiums and other processing tiers; the OpenAI examples are below the 272,000-input-token threshold. Output means all billed output, including reasoning where applicable.[6][7][8]

The small numbers become consequential when an application repeats a task thousands of times. But those prices say nothing about which model will identify the right account in a crowded database, produce a correct calculation or recognize that a request lacks essential information. A comparison that fixes the token count deliberately removes much of the behavior that determines the actual bill.

The size of a request can also change its price. Sol’s documentation specifies higher rates for a request above 272,000 input tokens: twice the input and cache rates and one-and-a-half times the output rate, applied to the full request. Its large context window therefore provides capacity without guaranteeing the short-context tariff.[7]

There are other choices besides model size. Luna’s documentation lists Batch and Flex processing at half the standard rates and Fast mode at twice the applicable rates. The economic choice includes when a result is needed, not just how much intelligence a vendor promises. An overnight job and an interactive assistant need not be bought on the same terms.[8]

The API prices also should not be read as new monthly subscription prices. OpenAI’s separate product notice places Sol and Luna in ChatGPT Work and Codex, with availability and effort choices dependent on plans and workspace settings; it explicitly distinguishes those models from the ones available in Chat.[9]

The same distinction is reaching office software. Microsoft’s September 25 Copilot announcement places delegated work in Cowork, Code and Autopilot on usage-based billing, alongside subscription access for everyday chat and Office tasks. The company also described spending controls and usage visibility. Home and Code are due to start rolling out through its Frontier program in the coming weeks; Autopilot’s expanded private preview is planned for month’s end. The pricing model makes the cost of a long assignment more visible, but says nothing by itself about whether the result will be right.[20]

The material an agent reads again

Consider an illustrative assistant examining a long set of project instructions before updating several records. Much of the background stays the same as the work proceeds. Reprocessing every unchanged passage at the ordinary input price would make a lengthy session more expensive than one that can reuse earlier computation.

Prompt caching provides that reuse. Anthropic’s documentation requires an exact match for the cached part of the prompt, including text and images. New material can follow a stable beginning, but changes inside that beginning can prevent a match. The cached item is processed context, not a stock answer: the system still generates a new response. Its default cache lifetime is five minutes, with a longer option available.[10]

That makes a cache discount conditional on the shape of the application. A developer who changes an early timestamp or rewrites shared instructions can lose reuse even when a human would regard the background as practically identical. The administrative details of how a conversation is assembled can matter to its cost.

OpenAI’s current documentation makes the tradeoff explicit for GPT-5.6 and later models: a cache write costs more than ordinary input processing, while subsequent reads cost much less. It calculates that one write followed by one full reuse costs 1.35 times the ordinary input cost, against twice that cost for two uncached reads. Caching something that will not be reused can therefore add expense.[11]

There is another source of billable work behind a short answer. OpenAI counts nonvisible reasoning tokens as output. Its documentation warns that a generation limit can be reached before the model produces any visible answer, leaving a charge for input and reasoning without the requested response. A concise paragraph on the screen is not a reliable measure of how much computation the model used to produce it.[12]

A useful account of an agent’s costs consequently follows the whole session: new input, reused input, reasoning, responses and tools. OpenAI, for example, lists a separate web-search charge plus model charges for search-content tokens. The cost of retrieving evidence is part of the work even when none of that evidence is quoted in the final answer.[13]

Cheaper attempts, different results

Independent evaluations put some behavior back into the comparison. Artificial Analysis measures cost using the tokens its workloads actually consume, combining input, cached-input and output prices with the weights assigned to its benchmark suite. Its cost-per-task figure is not a promise about the cost of successfully completing a particular customer’s job. The mix of tasks and their scores remains essential context.[5]

In its Opus assessment, maximum-effort Opus 5.5 used about 119,000 output tokens per Intelligence Index task, against roughly 73,000 for maximum-effort Opus 5. The evaluator reported similar cost per task despite the lower rates. It also found several lower effort settings offered strong combinations of cost and performance. Those results do not disprove Anthropic’s default-setting claim: they describe a different setting and workload. They do establish why the qualification belongs beside the saving.[1]

For maximum-effort Sol, Artificial Analysis reported an Intelligence Index cost of $1.06 per task, down from $1.99 for GPT-5.6 Sol. Luna fell from $0.18 to $0.07. Its coding assessment found improvement for Sol and a regression for Luna. Both also lost ground on a professional-work benchmark, with the evaluators pointing to omitted requirements and weaker presentation. A cheaper deliverable can still require more attention from the person receiving it.[2]

That is a practical distinction for a business adopting these tools. A report that omits a required section may be inexpensive to generate and expensive to repair. An extraction task whose answers can be checked automatically may tolerate a different approach. Neither case establishes that one model is universally better; they place different values on failure, verification and time.

Zapier’s AutomationBench examines another kind of work: an agent must carry out a task across simulated business applications, and the test checks the resulting records rather than the fluency of its closing message. The underlying research is designed around discovering the right interfaces, following policies and coordinating actions across systems. These are controlled simulations, not an audit of a deployed company’s productivity.[14]

On the leaderboard checked September 26, version 1.0.6, Opus 5.5 at maximum effort with default fallbacks scored 42.47 percent at $1.44 per task. Sol at xhigh effort scored 33.2 percent at $0.27. The Opus entry includes routing refused steps to Anthropic’s fallback model; it is a system result, not an isolated model working unaided. The scores measure strict completion, while the prices are per task, not per successful completion.[15]

The difference presents a real choice without resolving it. Lower spending per attempt can be valuable where unsuccessful work is detected and safely retried. A higher completion rate can matter more where failure leaves a difficult cleanup. A retry also cannot be assumed to fix a systematic misunderstanding. Multiplying the same unsuccessful approach simply spends the discount.

Why the test conditions belong in the story

On September 22, the UK AI Security Institute and the EvalEval coalition announced more structured publication of evaluation results, including configuration information and context. The release covers earlier models, not this week’s launches. Its relevance is methodological: it makes the setup behind a score easier to inspect.[16]

The associated research, first posted in June and revised in July, tested how additional tokens, repeated attempts, shorter representations of accumulated context and correctness feedback affected performance. The benefits varied by benchmark. A model permitted to keep trying with feedback was not undergoing the same test as one given a single constrained attempt.[17]

For a purchaser, the missing question behind an impressive score is often what resources produced it. Were tools available? How much reasoning was allowed? Did another model take over a blocked step? How were errors detected? A score paired with those answers is more informative than another decimal place on a ranking.

A different bill for local models

The week also brought a development for people who run models themselves. Hugging Face announced packed GGUF inference support in Transformers on September 22, allowing compressed model weights familiar from llama.cpp to work within the Python and PyTorch environment many researchers already use. The initial path requires Apple silicon, compatible kernels and Transformers’ main development branch; it is not yet the ordinary stable-release experience.[18]

The technical detail matters to memory use. The packed loader currently covers Qwen3.5 dense and mixture-of-experts architectures. Hugging Face’s documentation says weights remain packed when the compatible quantization kernel is available. Without it, loading expands the weights, using more memory. A compact download therefore does not by itself establish that a model will run comfortably, quickly or accurately on a particular machine.[19]

This is local inference, with the computation running on the user’s machine; an interface compatible with a cloud provider’s API does not turn it into that provider’s service. Hugging Face uses llama.cpp as its local-performance reference. The new integration chiefly widens the choices for people who need to inspect, evaluate or adapt models within Transformers.[18]

Local operation changes the accounting rather than eliminating it. Hardware, memory, electricity and the time needed to configure and check a model replace a simple per-token invoice. A machine that fits the weights has passed one test. Acceptable response time and a result good enough for the job are separate tests.

Across both local and hosted systems, this week’s developments give buyers more room to experiment. The most valuable savings will be the ones that remain after the work is checked: the records are right, the required sections are present, and the person who delegated the job does not have to do it again.