What Does an AI Task Cost? GPT-6.1 Sol, Claude and Gemini

Which AI model is cheapest for a support-ticket router? The rate card cannot answer until the team defines a successful ticket. Suppose each result must identify the product, assign urgency and cite the ticket words supporting both choices. Ambiguous cases go to a person. This article prices five model choices against that defined job. GPT-6 Sol and GPT-6.1 Sol share the same standard input and output rates, so the no-cache tables show one Sol price profile. Their cached-input rates differ. The article shows what published prices can and cannot decide.

Published API prices let a builder calculate the token charge for that workload under stated assumptions. The more useful comparison is the cost of an accepted ticket: attempts, paid tools, retries and review work needed to meet the rule. No vendor rate card supplies that figure on its own.

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.

OpenAI’s September 29 GPT-6.1 Sol release adds a current candidate to this price comparison. Standard API input and output are $2 and $10 per million tokens, with cached input at $0.10 per million. The standard input and output prices match GPT-6 Sol, so at the identical hypothetical token counts used below, GPT-6.1 Sol would have the same token-only charges: $3.60 for 1,000 short tickets and $9.00 for 100 longer jobs. That arithmetic does not predict its token use, ticket accuracy, retries or reviewer effort. OpenAI reports near-Astra results on selected evaluations at roughly one-fifth of Astra’s standard token prices; no ticket-router test or account-level access check is included here.

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.

View image detail

An announcement date, a model release date and a guide update are different evidence; none proves availability in a particular account.

Actual size

Choose Actual size to read the graphic closely.

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.

Historical price reductions answer a different question from this current ticket-cost comparison. OpenAI uses an earlier promotional baseline, Anthropic compares an earlier model’s base rates, and Google specifies a later rate for the same model. Keep the ticket workload constant and apply each candidate’s rate for the period and setup being tested. Claude Sonnet 5.5 is assessed against a coding workload in our Sonnet 5.5 coding-cost analysis; its result cannot be transferred to ticket routing. The companion essay, It’s a race to the bottom, explains why rate changes can reopen an old workflow decision.

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.

Before testing, the team must finish the acceptance rule from its own support policy. Specify permitted urgency labels, what counts as evidence of urgency, how to handle two products and whether a correct label with a false citation fails outright. Give every candidate the same ticket set, retry limit and review standard. Otherwise the exercise compares changing rules, not model routes.

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.

View image detail

This is a proposed support-ticket rubric. An invented citation fails; ambiguous cases need a defined handoff to a person.

Actual size

Choose Actual size to read the graphic closely.

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.

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.

For these 1,000 stipulated short tickets, the gap between the highest and lowest base-token totals is $7.02: $7.20 for Opus 5.5 minus $0.18 for Luna. That gap could be smaller than the labor of checking citations and handling escalations, although no labor figures were supplied. At higher volume, the token difference scales. The table measures the token component under these assumptions; a pilot must measure the review work and quality that determine business value.

View image detail

The $7.02 gap comes from the stipulated 1,000-ticket token calculation. Reviewer labor and tool charges were not supplied.

Actual size

Choose Actual size to read the graphic closely.

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.

Here is the mathematical shortcut and its limit: every rate pair in this base comparison prices output at five times input. With identical token counts across models, changing the input/output mix changes the bill but cannot change the rate order. Once models use different token counts, tools or numbers of attempts, that shortcut no longer ranks complete routes.

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.

View image detail

The short and long input paths are illustrative, not measured workloads. Either can produce a concise label.

Actual size

Choose Actual size to read the graphic closely.

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.

View image detail

Paid Standard cache reads are priced per million tokens. Storage is an additional per-hour charge, so estimate both token count and retention time.

Actual size

Choose Actual size to read the graphic closely.

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.

View image detail

These token-rate totals use the stipulated hypothetical usage. The published rates do not establish matching turnaround, eligibility or completed-task quality.

Actual size

Choose Actual size to read the graphic closely.

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.

View image detail

This documented threshold applies to GPT-6 Sol and Luna requests above 272,000 input tokens. At 300,000, the higher rate applies to the full request.

Actual size

Choose Actual size to read the graphic closely.

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.

An independent comparison gives one bounded benchmark example: Artificial Analysis measured GPT-6 Sol at $1.06 per Intelligence Index task at max effort versus $1.99 for GPT-5.6 Sol, and GPT-6 Luna at $0.07 versus $0.18. The same evaluation reported a mix of gains and regressions. Those figures belong to its benchmark and harness, not the support-ticket task defined here. Use them to decide what to test, then measure your own acceptance rate and full cost.

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.

View image detail

The denominator is accepted tickets. Keep retries, tool charges and any explicitly valued reviewer time in the numerator; these are proposed measures, not observed results.

Actual size

Choose Actual size to read the graphic closely.

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.

View image detail

The proposed four-route pilot holds the ticket and pass rule fixed, then logs settings, retries, review and outcome for each route.

Actual size

Choose Actual size to read the graphic closely.

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.

Before pricing a model, decide whether the underlying task should be automated at all. Our five-part Work Worth Doing test helps distinguish work to remove, simplify, automate with review, or keep human.

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.