It's a race to the bottom

The API rate cards for several prominent AI models give builders a reason to revisit decisions made under older prices. As checked on September 25, 2026, OpenAI lists GPT-6 Sol and Luna at $2/$10 and $0.10/$0.50 per million input/output tokens, respectively. Anthropic lists Claude Opus 5.5 at $4/$20. Google lists Gemini 3.8 Flash at an introductory $0.75/$3.75 through December 31, 2026. In each pair, the first price is for tokens sent to the model and the second is for tokens it generates.

I read these offers as a race to the bottom in listed API prices. That is Rise’s interpretation of the market, not an admission of competitive motive by OpenAI, Anthropic or Google. OpenAI attributes its lower prices to improvements in caching and inference. The published pages do not establish whether any company changed a rate in response to another.

For an agency owner or application builder, the opportunity is more specific than a cheaper chatbot. A workflow dismissed as too expensive may deserve another estimate. An application that sends every step to one model may deserve a routing review. A team planning next year’s usage needs to account for a promotional rate that expires. None of those decisions can be settled by a price per million tokens alone. The question is which existing job is worth testing again, and what would count as a better way to finish it.

Read each price against its own baseline

OpenAI lists GPT-6 Sol at $2 per million input tokens and $10 per million output tokens. Its release table compares those figures with GPT-5.6 Sol promotional rates of $4 and $20. Both new rates are half that named baseline. The word promotional matters: the table does not establish a 50% reduction against every price a customer previously paid. Nor does a 50% reduction in two token rates imply that an agent completes a job for half its previous cost.

The Luna row needs even closer reading. OpenAI lists GPT-5.6 Luna promotional rates of $0.20 for input and $1.20 for output, followed by GPT-6 Luna at $0.10 and $0.50. Input falls 50%; output falls about 58.3%. The release describes the family as 50% cheaper, but its precise Luna output figures show a larger reduction against that promotional output baseline. The release does not explain the difference. Keeping the figures separate matters for a workflow that reads a short prompt and produces a long draft, because output accounts for more of that bill.

Anthropic’s Opus 5.5 documentation lists $4 per million input tokens and $20 per million output tokens. Its Opus 5 overview lists the earlier model at $5 and $25. Comparing those published base rates gives a 20% reduction for each token type. That arithmetic does not tell us whether Opus 5.5 would consume the same number of tokens, need the same number of attempts or finish a particular job more cheaply than Opus 5.

Google’s Gemini 3.8 Flash guide, marked last updated September 23, 2026, calls its $0.75 input and $3.75 output rates introductory. Its paid Standard rate card says they apply through December 31, 2026, and that rates of $1.50 and $7.50 begin January 1, 2027. The guide names Google AI Studio and Gemini Enterprise Agent Platform in its introductory pricing section. A team budgeting across that date should confirm the terms for its intended surface and include the later rate in its forecast.

• GPT-6 Sol, checked September 25, 2026: Input per million tokens: $2; Output per million tokens: $10; Baseline or condition: GPT-5.6 Sol promotional rates: $4/$20
• GPT-6 Luna, checked September 25, 2026: Input per million tokens: $0.10; Output per million tokens: $0.50; Baseline or condition: GPT-5.6 Luna promotional rates: $0.20/$1.20
• Claude Opus 5.5, checked September 25, 2026: Input per million tokens: $4; Output per million tokens: $20; Baseline or condition: Earlier Opus 5 base rates: $5/$25
• Gemini 3.8 Flash, introductory through December 31, 2026: Input per million tokens: $0.75; Output per million tokens: $3.75; Baseline or condition: Google’s paid Standard introductory rates
• Gemini 3.8 Flash, standard from January 1, 2027: Input per million tokens: $1.50; Output per million tokens: $7.50; Baseline or condition: Google’s stated paid Standard rates after the introductory period

These are vendor-published base token rates on the same per-million-token basis. The historical baselines differ, and the rows do not represent one coordinated price cut. OpenAI’s API changelog dates the Sol and Luna API release to September 22, 2026. Its ChatGPT release notes date their introduction in Work and Codex to the same day. Anthropic dates the Opus 5.5 release to September 22. Those dates establish the named releases; they do not prove that every customer gained access at the same hour, or that the companies acted for the same reason. Google’s guide states that Gemini 3.8 Flash is generally available and shows a September 23 update date, which should not be mistaken for a verified launch date.

A lower rate changes which ideas deserve an estimate

Imagine an agency that prepares a briefing from approved client documents every Monday. Its team once estimated that repeated model calls would cost too much for the value of a draft, so it kept the process manual. A new rate card gives the team a reason to redo the estimate. The source documents, staff review and quality standard would still determine whether an AI step is useful. Nothing in the published prices proves this hypothetical agency would save money or time.

That distinction matters because a lower unit price can change a decision even before it changes a production bill. It can reduce the cost of finding out whether a candidate route works. A builder could run a controlled pilot on a repeatable job, inspect the failures and decide whether the model belongs in the workflow. Without a clear pass rule, however, cheaper attempts may merely produce more outputs to sort through. The price of experimentation may fall while the work of deciding remains.

Lower rates also make routing worth revisiting. Some applications send every step to one default model because one route is easier to operate. Yet extracting fields from a fixed form, resolving an ambiguous exception and drafting a client-facing explanation demand different kinds of judgment. A builder might test a lower-priced model for the extraction step and retain another route for the consequential explanation. The rate card provides a reason to investigate that design. It cannot tell the builder which model will pass either step.

This is a useful moment to question how a team defines an AI task. If an application labels an entire client report as one job, its costs may be difficult to diagnose. Separating document intake, field extraction, exception handling and final drafting makes the bill easier to understand. It also lets the team ask where a cheaper model could help without forcing a change to every step. That decomposition has an operating cost: more routes, more evaluation and more maintenance. A small possible token saving may not justify a complicated system for a low-volume process.

The market signal therefore creates options, not a universal instruction to switch. For a high-volume step with stable inputs, a small difference in unit price could become material over many accepted tasks. For an infrequent, consequential decision, the team may care more about review effort and error consequences. Both teams can take the rate changes seriously while making different choices.

Start with a job you can recognize and check

Consider a hypothetical operations team preparing a weekly exception report. Approved records arrive in a consistent format. The report must identify records that violate stated rules, cite the source field behind each exception and leave ambiguous cases for a person. The team already has a process, even if parts of it are manual. That provides a baseline and a result a proposed pilot can compare.

Before choosing candidate models, the team can specify what a reviewer will check. Which fields must appear? What should happen when a required source value is missing? Does an invented citation fail the report even if the rest reads well? Which errors can be repaired with another attempt, and which make the output unusable? Does every report need a person’s sign-off, or only those with exceptions? These decisions turn “make a good report” into an acceptance rule.

They also expose work a token bill can hide. If an agent omits a required field and a reviewer fills it in, the report may be finished while the model’s attempt has failed. If the reviewer must reread every source record because the citations cannot be trusted, the visible model charge is only one part of completing the job. Recording these outcomes does not require inventing a dollar value for someone’s time. It requires keeping that time visible.

The job description shows which part of the rate card deserves attention. A report that reads a large packet and returns a short exception list may be sensitive to input pricing and cache eligibility. A report that writes detailed explanations may be more sensitive to output pricing. If it searches external systems, paid tool calls and unsuccessful loops belong in the estimate. If it must be ready before a meeting, elapsed time matters even when the token charge is small. The shape of the task determines which advertised number helps.

A pilot on this report would not settle every workflow in the business. A model that passes a structured exception report may still be unsuitable for a sensitive client letter. A model that struggles with the report might work for a simpler stage. Choosing one repeatable job helps a team reach a decision it can act on without treating a narrow result as a verdict on an entire model family.

The listed token price is one part of the bill

An API request contains input and produces output. Input can include instructions, source material, tool results and earlier conversation turns. Models given the same job need not consume identical quantities of either token type, especially when their thinking settings and tool behavior differ. A builder needs reported usage from the actual route being considered.

That distinction grows in an agent workflow. Suppose the hypothetical exception report requires the agent to inspect several records, call a tool for missing details and revise a draft after validation fails. Each turn can add input and output. Source material may be sent again; some of it may qualify for a cache read. A retry may repeat tool work. Pricing one tidy prompt and one tidy response would understate the bill for the complete attempt. The operational record should attach each turn and charge to the report it was meant to finish.

Conditional rates can change an estimate substantially. OpenAI’s GPT-6 Luna model page lists $0.10 per million fresh input tokens, $0.01 for cached input reads, $0.125 for cache writes and $0.50 for output. Its GPT-6 Sol model page lists $2, $0.20, $2.50 and $10 for those same categories. Both pages say prompts with more than 272,000 input tokens are charged at twice the input and cache rates and 1.5 times the output rate for the full request. Both list Batch and Flex at half the Standard rates, Fast at twice the applicable rates and a 10% regional processing premium where available. Tool-specific fees may apply. These are published model terms, not charges observed in a completed job.

Anthropic publishes different Opus 5.5 conditions: $5 per million tokens for a five-minute cache write, $8 for a one-hour write and $0.20 for a cache read. Its listed batch input and output rates are $2 and $10 per million, half its base rates. Google’s Gemini 3.8 Flash paid rate card lists introductory Standard context caching at $0.075 per million tokens, plus $0.50 per million cached tokens per hour in storage. The card says those rates become $0.15 and $1.00 on January 1, 2027. It lists introductory Batch input/output at $0.375/$1.875, with $0.75/$3.75 scheduled from January 1. Google states that its output price includes thinking tokens. Those conditions can matter as much as the headline rates when a workflow reuses context or runs asynchronously.

A useful estimate separates fresh input, cached reads, cache writes or storage where billed, generated output, paid tools and processing mode. It also records any long-context or regional condition that applies. This breakdown tells the builder which cost a lower base rate could affect. If an agent spends much of its budget on repeated tools or on reviewing failed work, comparing input rates alone answers only a small part of the business question.

The cheapest response may not finish the job

A first response is not always a finished report. For the hypothetical exception workflow, an answer that looks tidy but omits a required source field fails the agreed rule. Someone must correct it or ask the system to try again. The charge for the first response still belongs to the cost of completing that report, along with the next attempt and the reviewer’s time finding the omission.

Consider two possible outcomes, with no named model assigned to either. In one, a low-charge response leaves out a qualification. The reviewer spots it, requests a revision and checks the revised report. In the other, a response with a higher model charge passes the same check on the first attempt. Either route could ultimately cost less, depending on how often those outcomes occur and how much review each needs. These are hypothetical paths, not results from a Rise test.

The reverse is possible too. A lower-rate model may pass a tightly defined classification task often enough that a higher-priced option adds no useful value. That is particularly worth testing when inputs are stable, outputs are constrained and uncertain items already have a safe path to a person. Published prices make a candidate attractive. Observed pass rates and review work determine whether it is economical for that task.

Human review remains visible even when it is required for every option. If every client-facing report needs sign-off, a polished answer does not remove that obligation. One route might reduce the minutes needed to reach sign-off; another might increase them. Record those minutes before converting them to an internal cost, and state the hourly assumption if one is used. For consequential work, quality may be a firm requirement rather than a variable to trade for a lower token bill.

OpenAI’s release page reports benchmark scores and costs per task for Sol and Luna at specified reasoning efforts. Those are vendor-reported results. Its cited Claude Opus comparisons concern Opus 5 or other named models, rather than a controlled Opus 5.5 test of this hypothetical report. OpenAI says its own evaluations ran in a research environment or through its API and that competitor results came from public reports. The claims can help a builder choose what to investigate, provided their task, settings and attribution stay attached. They do not establish the cheapest successful route for another job.

Give a pilot a decision rule before seeing its outputs

For one selected job, preserve approved inputs and document the current process as the baseline. Define what a pass requires before reviewing candidate outputs, then apply that rule to each route. Record the model identifier, reasoning or thinking setting, processing mode and enabled tools for every run. Providers do not expose identical controls, so matching a setting name across products is no substitute for recording the configuration actually used.

For each attempted task, capture fresh input tokens, cached reads and writes where reported, output tokens, tool charges, retries and elapsed time. Keep failed attempts in the record even when a later attempt passes. Record whether a person accepted, repaired or rejected the result, along with review minutes and the reason. This makes it possible to compare the cost of accepted reports rather than the price of isolated responses. For a four-model token estimate with those limits stated, see the companion comparison of what an AI task really costs.

Include work that reflects the real decision. If the weekly report sometimes contains missing records, conflicting values or unusual exceptions, a pilot made entirely of clean examples will miss the cases most likely to consume review time. Label those cases and apply the same acceptance criteria. If one candidate receives a different source packet or a different review standard, the result will reflect those changes too. Consistent inputs and a consistent pass rule give the comparison a better chance of answering the question that justified it.

The decision can remain narrow: use a candidate for this report if it meets the required standard at an acceptable total cost for the workload. Keep the current route or send difficult cases to a person when that condition is not met. Findings might also suggest a better source packet, clearer instructions or a validation step. Those are possible outcomes of a proposed pilot, not observations already made.

No shared four-model run, retry record or human-review measurement was supplied for this article. The checked rate cards therefore cannot establish that GPT-6 Sol, GPT-6 Luna, Claude Opus 5.5 or Gemini 3.8 Flash is the cheapest model for a successful task. They can help a team select candidates and set a budget for finding out.

Confirm access before changing a workflow

An API price does not mean a model is selectable in every application from the same company. OpenAI’s September 22 API changelog records Sol and Luna under the identifiers gpt-6-sol and gpt-6-luna. Its release page separately describes ChatGPT Work and Codex access for Plus, Pro, Business, Enterprise and Edu users, Luna access in the desktop app for Free and Go users, and a gradual rollout. The page says the models were not yet available in Chat at the time described. The September 22 ChatGPT release notes say Work and Codex model options depend on plan and workspace settings. These are OpenAI’s published access conditions, not an account-level check.

Anthropic says Opus 5.5 is available to all Claude API customers under claude-opus-5-5 and lists other platforms. Google describes Gemini 3.8 Flash as generally available under gemini-3.8-flash. A builder still needs to confirm the intended account, region, quota, model identifier and product surface before promising an implementation. A dated announcement establishes what the vendor said it released; it does not substitute for checking a particular workspace.

This check belongs early in a price-led plan. A team might have API access but lack the model in the interface its staff use. It might discover that a processing mode assumed in its estimate is unavailable for its setup. Confirming the route turns an attractive spreadsheet option into a candidate the team can actually test.

What the race changes now

The checked offers give builders a reason to revisit decisions made under older prices. OpenAI lists Sol and Luna below the GPT-5.6 promotional baselines it names. Anthropic lists Opus 5.5 below Opus 5 on base input and output rates. Google gives Gemini 3.8 Flash an introductory rate with a stated increase on January 1, 2027. Together, those offers look like stronger competition on listed API prices. That is Rise’s market reading. The sources do not prove a common motive, a permanent downward path or savings for every workflow.

Select one repeatable job, record its current route and write its pass rule. Check access and the price conditions that apply. Then compare complete attempts, accepted outputs and review work. Change the route if a candidate meets the standard at an acceptable total cost. Otherwise, the exercise can still show whether the expense sits in tokens, tools, retries or the work a person must do to finish. The rate card opens the decision; the measured job closes it.