OpenAI launches GPT-6 Sol and Luna: prices, benchmarks and access

OpenAI has launched GPT-6 Sol and Luna for coding and agent workflows.

For teams operating coding assistants, the useful question is how much a completed, acceptable task costs. A cheaper token can fund more iterations, but retries, cache writes and review time still determine whether a migration pays off. This article separates the published specifications from our practical assessment.

Where can you use them?

Plus, Pro, Business, Enterprise and Edu users get both in Work/Codex; Free/Go get Luna through desktop. Standard Chat is not included yet, and rollout is gradual. See the availability notice.

The API identifiers are gpt-6-sol and gpt-6-luna. The Sol and Luna documentation gives both a 1,050,000-token context, up to 922,000 input tokens and 128,000 output tokens. They accept text and images and generate text.

API pricing: reads, writes and output

Standard rates below are US dollars per million tokens, taken from the two model pages.

Token category	GPT-6 Sol	GPT-6 Luna
Uncached input	$2.00	$0.10
Cached input read	$0.20	$0.01
Cache write	$2.50	$0.125
Output	$10.00	$0.50

The previous GPT-5.6 Sol tariff was $4 input/$20 output; GPT-5.6 Luna was $0.20/$1.20. Sol’s two rates halve. Luna’s input halves, while its output falls 58.3%, calculated from $1.20 to $0.50. A single percentage does not describe every billing category.

Our equal-token example is 100,000 uncached input tokens plus 20,000 total billed output tokens, with no cache writes or tool charges:

Model	Calculated token cost
GPT-6 Sol	$0.40
GPT-5.6 Sol	$0.80
GPT-6 Luna	$0.02
GPT-5.6 Luna	$0.044

This is arithmetic, not a workload benchmark. It assumes identical token counts, without assuming identical answer quality. Reasoning tokens also count toward output billing, even when they do not appear in the visible answer.

Two pricing boundaries deserve attention. For more than 272K input tokens, both model pages specify 2× input/cache rates and 1.5× output rates for the whole request. Batch/Flex are half Standard pricing; Fast is twice the applicable rate. Regional processing has a 10% premium where supported, and EU residency requires Standard processing. Check the linked model tariff for your deployment rather than applying the small-request table to every job.

What the launch benchmarks measure

Selected figures from OpenAI’s launch report; these are not canberk.me measurements.

Evaluation	Model / effort	Reported result
AutomationBench 1.0.6	Sol / xhigh	33.2%; $0.27/task
Agents’ Last Exam V1	Sol / max	56.4%
DeepSWE 1.1	Sol / max	68.8%
DeepSWE 1.1	Luna / max	66.6%
OSWorld 2.0 offline, partial	Sol / xhigh	60.5%

These percentages answer different questions:

• AutomationBench checks whether an agent leaves a simulated business in the correct final state across multiple applications. Its main score requires all the relevant assertions to pass; partial progress is a separate diagnostic.
• FrontierCode asks whether a maintainer would accept the resulting change, including its tests, scope and code style. Version 1.1 also penalizes consultation of solution-bearing internet sources. That makes it useful context for teams whose bottleneck is reviewing patches rather than merely generating them.
• DeepSWE uses original engineering tasks with hand-written behavioral checks. OSWorld distinguishes full/offline task sets and partial/binary reward. A partial-reward percentage must not be presented as the share of workflows completely solved.

Our reading is that a deployment trial should preserve these distinctions. Keep model, effort, agent tools, evaluation version and acceptance criteria fixed when comparing runs. Otherwise a change in the surrounding agent can look like a model improvement.

The launch’s competitor references include Opus 5 and Fable versions; this is not a direct comparison with the newly released Opus 5.5.

Official reliability and behavior charts

The factuality set uses conversations selected because earlier models made mistakes. It is a stress test, not a measurement of the average error rate across everyday requests. Read the axes and the test population together.

The system card also reports regressions on HealthBench and HealthBench Hard alongside shorter answers. This is another reason to check the task you care about rather than infer universal improvement from a generation number.

Caching: make reusable context measurable

The caching guide distinguishes automatic breakpoint placement from developer-selected prefixes. A cache write costs 1.25× ordinary input processing; a later read costs 0.1×. Repeated reuse matters more than the presence of a cache feature.

For a runbook that is sent with every incident, our implementation choice would be to separate the stable runbook from changing logs and incident details. An explicit breakpoint after the runbook lets the reusable part be identified without treating every new log line as stable context. Keep the conversation append-only when practical, and measure whether this actually improves hit rates.

OpenAI’s diagnostics can compare a current response with an earlier response ID using prompt_cache_options.comparison_response_id. Inspect prompt_cache_diagnostics to investigate misses; use usage.input_tokens_details.cached_tokens for actual reuse. Requesting diagnostics does not itself load previous context or force a cache hit.

For an operations dashboard, we would track fresh input, cache reads, cache writes, total output and accepted-task counts together. A high hit rate alone does not show whether the agent produced a useful result.

Before changing an existing integration

The model documentation recommends the Responses API for tools. On Chat Completions, function calling requires reasoning_effort: "none". Both models offer effort levels from none through max, with medium as the default. This makes an API compatibility check part of migration, not just a model-ID replacement.

Our first trial would use a small, repeatable set of repository fixes and incident-analysis tasks. Define acceptance checks before running either model, record retries and latency, and keep consequential production actions behind the existing approval boundary. Start Luna on bounded tasks; evaluate Sol where multi-step reasoning and review quality matter. Escalate based on failures you can observe rather than using the most expensive model automatically.

Keep the incumbent results for comparison. If a cheaper run produces a patch that takes another engineer longer to repair, that extra work belongs in the cost calculation.

Checked against public primary sources on 22 September 2026. The four images are original OpenAI assets with attribution; the benchmark table is a transcription of selected numerical results. No independent model benchmark was run for this article.