What does an AI task really cost? Comparing GPT-6 Sol, Luna, Opus 5.5 and Gemini 3.8 Flash

Suppose a support team wants an AI service to route incoming tickets. Each result must identify the product, assign an urgency level and cite the ticket language supporting both choices. Ambiguous tickets must go to a person. Which model should the team try first?

Published API prices answer part of that question. They let a builder calculate a token charge for a specified workload under stated pricing conditions. They do not reveal which model will meet the ticket rule, how often it will need another attempt or how much work a reviewer will do before accepting a result. The relevant purchasing unit is an accepted ticket, not an isolated response.

This comparison uses official vendor terms checked on September 25, 2026, and explicitly hypothetical workloads. No four-model ticket test, invoice or account-level access check was supplied. The calculations can help plan a pilot. They cannot identify the cheapest successful model.

Put the published rates on the same unit

Input tokens include material sent to a model, such as instructions, ticket text and earlier messages. Output charges can include billed reasoning or thinking tokens, even when those tokens are not part of the visible answer. Every price below is in US dollars per one million text tokens. The table shows listed paid Standard or base rates; it excludes paid tools, retries, review labor and conditional pricing that applies to a particular request.

• GPT-6 Sol, checked September 25, 2026: Input per million tokens: $2.00; Output per million tokens: $10.00; Source: OpenAI Sol model reference
• GPT-6 Luna, checked September 25, 2026: Input per million tokens: $0.10; Output per million tokens: $0.50; Source: OpenAI Luna model reference
• Claude Opus 5.5, checked September 25, 2026: Input per million tokens: $4.00; Output per million tokens: $20.00; Source: Anthropic model reference
• Gemini 3.8 Flash, paid Standard introductory rate through December 31, 2026: Input per million tokens: $0.75; Output per million tokens: $3.75; Source: Google API pricing
• Gemini 3.8 Flash, stated paid Standard rate from January 1, 2027: Input per million tokens: $1.50; Output per million tokens: $7.50; Source: Google API pricing

The two Gemini rows describe successive periods. Google says its introductory paid rates run through December 31, 2026, and its standard paid rates begin January 1, 2027. Its pricing page also lists a free tier, which is outside the paid-workload calculations here. The Gemini 3.8 Flash guide names Google AI Studio and Gemini Enterprise Agent Platform in its introductory pricing discussion. Confirm the terms for the actual surface, region and account before building a budget around them.

The captured OpenAI release page does not display a publication date in its visible article text. An OpenAI release note dated September 22, 2026 separately records the introduction of Sol and Luna in ChatGPT Work and Codex. Anthropic’s Opus 5.5 model page lists September 22, 2026, as that model’s release date. Neither date proves when a particular account gained access or when every regional price took effect. Google’s guide says it was last updated September 23, 2026; that update date is not a stated launch date.

Read each price reduction against its stated baseline

OpenAI compares GPT-6 Sol at $2 per million input tokens and $10 per million output tokens with GPT-5.6 Sol promotional rates of $4 and $20. Both new rates are half that named baseline. The comparison does not show what every customer previously paid. It also does not show whether Sol would finish a given task for half as many dollars, because total tokens, attempts and tools may differ.

The Luna row requires separate input and output arithmetic. 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 $0.70 from a $1.20 baseline, or about 58.3%. The release describes the family as 50% cheaper but does not explain that mismatch. A builder should use the explicit rates, particularly for a workload that generates much more text than it receives.

Anthropic lists Opus 5.5 at $4 for input and $20 for output. Its Opus 5 overview lists the earlier model at $5 and $25. That is a 20% reduction in each listed base rate. It is not a measured reduction in completed-task cost. A change in reasoning behavior, response length or retries could change the amount billed for the same requested work.

These baselines explain why an old estimate may deserve another look. They should not be mixed into a four-model ranking: OpenAI’s comparison uses earlier promotional rates, Anthropic’s uses an earlier model’s base rates, and Google’s table includes a scheduled change to one model’s rate. For a prospective decision, define one workload and apply each candidate’s relevant current or forecast rate to it. The companion essay, It's a race to the bottom, explains why those rate changes can reopen an old workflow decision.

Define an accepted ticket before calculating a bill

Imagine a service handling tickets about several products. It must return a name from an approved product list, an urgency label and an exact phrase from the ticket supporting each choice. When the product is missing, evidence conflicts or urgency cannot be justified, the service must send the case for human review. A fabricated citation fails even if the product label happens to be right.

A real team would need to finish that rule before testing models. Which urgency labels exist? What language qualifies as urgent? Does a ticket about two products count as ambiguous? Is a correct label paired with a false citation a total failure or a repairable result? The team should answer those questions using its actual support policy. Otherwise reviewers may apply different standards to different candidates and call the resulting numbers a model comparison.

The ticket rule also identifies costs that a rate card cannot show. A reviewer might need seconds to check a clearly cited phrase, or minutes to reread the entire ticket after spotting an invented one. An escalation may be the correct outcome for one ticket and an unnecessary handoff for another. Counting only whether the model returned valid JSON would miss both distinctions.

For the first calculation, assume one request per ticket, fresh input, the listed base text rates, no paid tools, no retries and identical billed input and output token counts across all candidates. Those assumptions isolate token prices. They do not predict model behavior. In an actual pilot, reasoning settings, output lengths and tool paths can change consumption.

The formula is token charge = (fresh input tokens ÷ 1,000,000 × input rate) + (billable output tokens ÷ 1,000,000 × output rate). Keep the two terms separate. An input-heavy service and an output-heavy service can have very different bills even when both use the same total number of tokens. The result of this formula is a charge for stipulated tokens, not a cost per accepted ticket.

Hypothetical workload one: 1,000 short tickets

Assume 1,000 tickets. Each request sends 800 fresh input tokens and produces 200 billable output tokens. The full workload therefore sends 800,000 input tokens and generates 200,000 output tokens, or 0.8 million and 0.2 million tokens. Under the base-rate assumptions above, the calculation is straightforward.

• GPT-6 Sol: Input charge: 0.8 × $2 = $1.60; Output charge: 0.2 × $10 = $2.00; Hypothetical base token total: $3.60
• GPT-6 Luna: Input charge: 0.8 × $0.10 = $0.08; Output charge: 0.2 × $0.50 = $0.10; Hypothetical base token total: $0.18
• Claude Opus 5.5: Input charge: 0.8 × $4 = $3.20; Output charge: 0.2 × $20 = $4.00; Hypothetical base token total: $7.20
• Gemini 3.8 Flash, introductory: Input charge: 0.8 × $0.75 = $0.60; Output charge: 0.2 × $3.75 = $0.75; Hypothetical base token total: $1.35
• Gemini 3.8 Flash, stated 2027 standard: Input charge: 0.8 × $1.50 = $1.20; Output charge: 0.2 × $7.50 = $1.50; Hypothetical base token total: $2.70

Luna has the lowest listed base-token charge under these assumptions. Nothing in that result establishes that Luna will follow the ticket rule, pass on its first attempt or need the least review. A team choosing its first pilot candidate on a tight token budget could include Luna. It could not yet declare Luna its lowest-cost successful route.

The two Gemini calculations show why the date belongs in a forecast. The stipulated workload costs $1.35 at Google’s introductory rates and $2.70 at the standard rates it says begin January 1, 2027. A team expecting usage on both sides of that date should allocate requests to the applicable periods. Applying the introductory rate to every future ticket would understate the scheduled base-rate change.

These charges also need a sense of scale. If the workload truly contains only 1,000 short requests, a few dollars of model charges may be small compared with the work of checking citations, handling escalations and maintaining the integration. At a much larger volume, a difference of fractions of a cent per response could become meaningful. The table gives the token component of that decision. It does not supply the team’s volume, reviewer effort or required quality.

Hypothetical workload two: longer records and answers

Now assume 100 jobs. Each sends 20,000 fresh input tokens and generates 5,000 billable output tokens. A job might contain a longer customer history and require a written explanation. The stipulated workload contains 2 million input tokens and 0.5 million output tokens. Each request remains below the 272,000-input-token threshold documented for Sol and Luna. Keep one attempt, identical usage across models and no tools or cache.

The base token totals are $9.00 for Sol, calculated as 2 × $2 plus 0.5 × $10; $0.45 for Luna, from 2 × $0.10 plus 0.5 × $0.50; and $18.00 for Opus 5.5, from 2 × $4 plus 0.5 × $20. Gemini 3.8 Flash comes to $3.375 at its introductory rates, from 2 × $0.75 plus 0.5 × $3.75. At Google’s stated 2027 standard rates, the same stipulated usage comes to $6.75, from 2 × $1.50 plus 0.5 × $7.50. The $3.375 value is left unrounded to show the arithmetic; an actual invoice may apply its own rounding rules.

The base-price order has not changed. Each published rate pair in this comparison has the same 1:5 input-to-output price ratio. If every model uses identical token counts and only these base rates apply, changing the input-to-output mix cannot reverse the order. That is a mathematical property of the listed prices. It is not evidence that the models will consume identical tokens or produce equally useful answers.

The longer workload still changes the planning question. A service that reads extensive histories but returns short labels should examine input volume and cache eligibility. A service that produces detailed explanations should examine output volume. A longer source packet may also affect latency, citation checking and whether a context pricing threshold applies. Those factors are part of a complete route, even though they are outside this base-rate exercise.

Cache discounts require actual cache usage

A ticket service may resend the same product list, classification rules and output schema. Some of that repeated material may qualify for prompt caching. Reusing words in an application does not prove they were billed as cache reads. The useful record comes from the intended API route: how much input was fresh, how much was read from cache, what was charged for writes or storage and whether changes to a prompt prevented reuse.

The GPT-6 Luna reference lists $0.10 per million fresh input tokens, $0.01 for cached input reads, $0.125 for cache writes and $0.50 for output. Consider a separate hypothetical Luna usage record containing 0.2 million fresh input tokens, 0.6 million cached-read tokens, 0.1 million cache-write tokens and 0.2 million output tokens. The respective charges are $0.02, $0.006, $0.0125 and $0.10. The sum is $0.1385, before any other applicable charges.

Those four quantities are invented for the example. They were not observed in the 1,000-ticket workload, and the $0.1385 total should not replace that workload’s $0.18 figure as though a cache hit had been measured. A real team would need to identify stable prompt prefixes, record the actual cache categories and check how often product-rule updates invalidate reuse. Cheap cached reads help only when the implementation receives them; cache writes belong in the bill too.

Sol’s model reference lists $0.20 per million cached input reads and $2.50 for cache writes, alongside its $2 fresh input and $10 output rates. Anthropic’s Opus 5.5 documentation lists $0.20 for cache reads, $5 for five-minute cache writes and $8 for one-hour cache writes. A comparison using a read rate must include the write rate and retention choice that made those reads possible.

Google’s Gemini 3.8 Flash pricing page lists paid Standard context-cache reads at $0.075 per million tokens through December 31, 2026, and $0.15 from January 1, 2027. It also lists storage at $0.50 and then $1.00 per million tokens per hour across those periods. A cached-workload estimate needs the relevant storage duration as well as the number of cached tokens. These providers’ cache categories and qualifying behavior should be checked in the implementation rather than assumed equivalent.

Batch, tools and long context change the terms

Processing mode affects the listed rate. The Sol and Luna references say Batch and Flex are priced at 50% of Standard rates, while Fast mode is twice the applicable rates. If the hypothetical 1,000-ticket workload qualified for Batch and every other assumption held, its base-token charge would be $1.80 for Sol or $0.09 for Luna. These are conditional arithmetic results. A ticket router that must answer while a customer is waiting may have a timing requirement that makes an asynchronous option unsuitable.

Anthropic lists Opus 5.5 Batch rates of $2 per million input tokens and $10 per million output tokens. Applied to the stipulated 0.8 million input and 0.2 million output tokens, its Batch base-token charge would be $3.60, compared with $7.20 at its listed base rates.

Google lists Gemini 3.8 Flash paid Batch rates of $0.375 input and $1.875 output per million tokens through December 31, 2026. For the same hypothetical usage, those rates produce $0.675. Its stated Batch rates from January 1, 2027, are $0.75 input and $3.75 output, producing $1.35. The prices make a four-model Batch token calculation possible. They do not establish identical turnaround, eligibility or completed-task quality across the four services.

Tool calls introduce another cost and another source of variation. A model classifying a supplied ticket is doing different work from an agent that searches a customer database, retrieves policies and asks a second tool to verify an answer. OpenAI’s model references say tool-specific fees may apply. Google’s pricing page separately prices some grounding requests. A budget that needs those features should record the actual calls, region and processing mode. Adding a guessed tool allowance to every row would create a tidy table with little decision value.

Long context must be checked per request, not by looking only at a monthly token total. The Sol and Luna model pages say prompts with more than 272,000 input tokens receive twice the input and cache rates and 1.5 times the output rate for the full request. A 300,000-input-token request does not pay the higher rate only on its final 28,000 input tokens.

For an explicitly hypothetical Luna request with 300,000 fresh input tokens and 20,000 output tokens, and no cache, tools or other charges, ordinary base-rate arithmetic would be 0.3 × $0.10 plus 0.02 × $0.50, or $0.04. Because this request crosses Luna’s documented threshold, the applicable calculation is 0.3 × $0.20 plus 0.02 × $0.75, or $0.075. Under Sol’s corresponding published terms, the same stipulated tokens would cost $1.50, calculated as 0.3 × $4 plus 0.02 × $15. These examples illustrate published terms, not charges observed in the proposed ticket service.

A builder might shorten a source packet or split it across requests to avoid that threshold. Either change could add calls or deprive the classifier of information it needs. The right comparison is between complete routes that meet the same acceptance rule. The checked pages do not establish an equivalent long-context surcharge for every provider, so OpenAI’s threshold should not be assigned to Opus or Gemini by analogy.

Measure the cost of accepted work

A response that mislabels a ticket, cites words that are absent or mishandles ambiguity has not completed the task. A retry uses another attempt. A reviewer may have to find and repair the mistake. A useful cost measure is total model and tool charges, plus any explicitly valued review and repair time, divided by accepted tickets. Report escalated and unresolved tickets beside that figure so failures do not quietly disappear from the denominator.

Here is an unassigned hypothetical sensitivity example. No route is mapped to a named model. Route A charges $0.01 per attempt. Of 100 tickets, 80 pass first and 20 pass after one retry. Its 120 attempts cost $1.20. Assume all review associated with these tickets, including the retried ones, totals 400 minutes. At an assumed internal labor value of $30 per hour, that review costs $200. The modeled total is $201.20, or $2.012 per accepted ticket.

Route B charges $0.02 per attempt. In this imagined case, 95 tickets pass first and five pass after one retry. Its 105 attempts cost $2.10. Assume the review associated with all tickets totals 100 minutes at the same $30 hourly value. That is $50 of modeled review cost. The total is $52.10, or $0.521 per accepted ticket. Both imagined routes finish all 100 tickets within the allowed retry. Route B has the higher attempt charge and the lower modeled accepted-ticket cost because this example assigns it less review work.

The attempt prices, pass counts, review minutes and labor value are invented sensitivity inputs, not observed outcomes. They do not show that a higher-priced model is better. They show why a rate-card winner could lose once the team measures complete work. A real team may also set a minimum standard for citation accuracy or escalation behavior that cannot be traded for a lower cost.

Record failure types alongside averages. A missing optional explanation may be easy to repair. An invented citation may force a reviewer to reread the source. A repeated tool loop may run up charges without yielding an acceptable answer. Knowing which failure happened can point to a clearer source packet, a validator, a better escalation rule or a different route. A single average cost cannot tell the team which repair to make.

Run a pilot that can answer the ticket question

Start with representative tickets and the written rubric. Include routine examples, missing product details, conflicting urgency signals and ambiguous language if those cases occur in the intended work. Preserve the approved ticket text and required output fields across candidates. Set the retry limit before reading results and apply it consistently. If one candidate receives more context or more repair opportunities, record that difference rather than presenting the outcomes as directly comparable.

For every attempt, record the API model identifier, intended account surface, reasoning or thinking setting, processing mode and enabled tools. Providers do not expose identical controls, so matching a setting name across products does not guarantee the same amount of internal work. Capture reported fresh input, cache reads and writes or storage where available, billable output, tool charges, elapsed time and the reason for any retry. Reviewers should mark each ticket accepted unchanged, accepted after repair, correctly escalated, incorrectly escalated or rejected. Record the minutes spent reaching that decision.

Check access before scheduling the trial. OpenAI’s release names gpt-6-sol and gpt-6-luna for its API. It separately describes ChatGPT Work and Codex access for Plus, Pro, Business, Enterprise and Edu users, Luna desktop-app access for Free and Go users, a gradual rollout and no Chat access at the time described. Its September 22 release note says available models and reasoning options depend on plan and workspace settings. Anthropic’s documentation names claude-opus-5-5 for Claude API customers. Google’s guide names gemini-3.8-flash and calls it generally available. These are vendor statements, not an account-level check for the team running the pilot.

OpenAI reports benchmark scores and costs per task for Sol and Luna at specified effort levels. Those are OpenAI-reported results. Its named Claude comparisons involve Opus 5 or other specified models, rather than a controlled Opus 5.5 run on this four-model ticket workload. They may help a builder decide what to investigate. They cannot supply the ticket pilot’s acceptance rates, retries or reviewer minutes.

The team could also test a split route, with one candidate handling straightforward tickets and a person or another model handling ambiguity. That design may be useful, but it adds routing rules, possible routing mistakes and maintenance. Evaluate the complete split route against the same accepted-ticket standard as a single-model route. No benefit from such a split has been measured here.

Choose a shortlist, then choose a route

The checked base rates support a conditional shortlist. With identical token usage, paid Standard or base text pricing, no cache, no tools and one attempt, Luna has the lowest hypothetical token charge in both worked workloads. Gemini 3.8 Flash follows at its introductory rate, which Google says doubles on January 1, 2027. Sol and Opus 5.5 have higher base charges under those same assumptions. This ranks stipulated token bills. It does not rank quality, reviewer effort or cost per successful task.

Use the ticket rule to decide what must pass. Estimate input and output separately, confirm the rate period and intended account access, and add only the cache, processing, long-context, regional and tool conditions that actually apply. Then run representative cases, retain failed attempts in the record and measure the work needed to accept each result. Select a route when it meets the required standard at an acceptable total cost for this workload.

The cheapest successful ticket-routing route among GPT-6 Sol, GPT-6 Luna, Claude Opus 5.5 and Gemini 3.8 Flash remains unknown. The rate cards can tell a builder which candidates are affordable to test. The ticket results must determine which one is worth using.