Start with GPT-6 Sol for demanding coding or agent workflows. GPT-6 Luna has lower token prices and is designed for focused tasks at high volume.
Choose based on whether each model can complete your task accurately and how much the full workflow costs.
Copy link to headingWhat is the difference between GPT-6 Sol and Luna?
Sol and Luna belong to the GPT-6 family and share support for image input, function calling, and structured output. Their intended workloads differ in how much investigation a request needs and how often the application repeats it.
These starting points do not restrict either model to a particular job. Include both in a comparison when your workflow combines repeated operations with occasional investigation, such as a support assistant that answers routine questions and follows up on conflicting account records.
Copy link to headingWhen should you choose Sol?
Sol is designed for sustained coding and complex professional workflows. In these tasks, each result can change what the model needs to do next. Finding an unexpected call in a checkout handler might shift an investigation from the page code to the payment integration.
Consider a coding agent asked to fix a checkout failure that originates in the payment integration. It must follow the problem across files and verify that its proposed change addresses the reported behavior. Then, finally, assess the patch against a reproduction of the failure and the relevant tests, including checks that previously working checkout paths still succeed.
Sol's higher token price can be worthwhile if it avoids repeated attempts or substantial reviewer work. You can reserve it for the investigation and assess Luna separately for a summary of the completed change. Those steps have different demands even when they belong to the same product.
Copy link to headingWhen should you choose Luna?
Luna is worth testing when a task repeats across many inputs and the required answer is well defined. Invoice extraction, for example, asks for the same fields on each request. You can check a returned date and total against the supplied invoice, including cases where a field is missing or the document contains several totals.
Ticket routing is another candidate because the output comes from a defined set of destinations. Give each team a clear description and include a review outcome for ambiguous requests. The evaluation should include overlapping responsibilities and messages that raise more than one issue, so you can see where automatic assignment needs a review step.
Copy link to headingWhich capabilities do the models share?
The Sol and Luna specifications match on these capabilities:
Input, reasoning, and the visible response share the context window. The output limit includes reasoning tokens, which means a request can reach that limit before producing 128,000 tokens of visible text. Budget for both reasoning and the answer when assembling a long input.
Equal context capacity does not establish equal accuracy on long documents. For a report that contains evidence in several sections, compare whether each model connects the relevant passages and cites them correctly.
Copy link to headingHow much do GPT-6 Sol and Luna cost?
These OpenAI API prices are in USD per one million tokens for Standard processing with up to 272,000 input tokens:
Luna's input and output rates are each one twentieth of Sol's. For a request billed at the uncached input rate with 10,000 input tokens and 1,000 output tokens, the token charge is $0.03 with Sol and $0.0015 with Luna. These calculated amounts exclude tools and other charges. Actual requests may consume different numbers of tokens on each model, particularly when reasoning or retries are involved.
Requests above 272,000 input tokens use higher rates for the full request, with input and cache rates doubled and output rates multiplied by 1.5. Crossing the threshold therefore changes more than the cost of the extra tokens. Processing mode and regional processing can also affect the bill, so use the conditions that match your deployment when estimating spending.
Copy link to headingHow does prompt caching change the cost comparison?
Repeated requests often contain shared instructions or reference material. Prompt caching can reuse processing for the unchanged beginning of a prompt, called a prefix. Reuse requires an eligible cache entry that matches the complete prefix as represented by the API, including relevant instructions and tool definitions.
For a support application, place stable policy instructions before the changing ticket text. Check the API's reported cache usage to see how much of that prefix is being reused. Changes to a policy or tool definition can prevent later requests from matching an existing entry.
Include cache writes as well as reads in the estimate. Writing an eligible 10,000-token prefix at the rates above costs $0.025 with Sol or $0.00125 with Luna. Reading that prefix on a later request costs $0.002 or $0.0001, respectively. The write rate replaces the ordinary input rate for those tokens. New input and generated output are billed separately.
Compare both models using their observed cache usage. Assuming every repeated passage receives the read discount would hide the cost of writes and misses.
Copy link to headingHow should you compare reasoning settings?
Both Sol and Luna support reasoning effort values of none, low, medium, high, xhigh, and max, with medium as the default. Lower effort can reduce token use and response time. Higher effort gives the model more room to work through a difficult task.
Begin with the same effort setting for both models so your initial comparison changes only the model. You can then test other settings on each workload and record the model and effort together. The same named setting does not promise identical token consumption.
Reasoning tokens are billed as output tokens even though they do not appear in the visible answer. Use the API's usage data to capture that cost. Counting only the displayed response would miss the tokens spent working through the problem.
Include examples with different reasoning demands, such as a localized code edit and a bug whose cause spans several files. If higher effort improves only the investigation, you can reserve it for that category and keep the lower setting for routine edits. Check the time required as well as correctness, since the extra reasoning may be unsuitable for an interactive step.
Copy link to headingHow do you turn evaluation results into a model choice?
Compare both models through evaluation runs on a fixed set of representative examples. Decide what counts as an acceptable result before comparing prices. Ticket classification needs expected categories established by reviewers; code changes need checks for the reported behavior and unintended changes. Apply the same acceptance criteria to both models.
Record results by task category so routine successes do not conceal failures on less common requests. Inspect plausible but incorrect answers alongside obvious errors. Those failures matter when deciding which results your application can accept automatically.
Calculate cost per accepted result by dividing all model and tool spending, including failed attempts, by the number of tasks that meet your acceptance criteria. Spending $10 to obtain 80 accepted results gives a cost of $0.125 per accepted result. Track reviewer time separately unless you have an agreed way to price it; a workflow that requires more corrections may still be expensive to operate despite lower API charges.
Define any routing rule using information available when the application must choose a model. Document metadata might show that two policies cover the same region and have overlapping effective periods. That could trigger a Sol investigation, but a rule based on contradictions inside the text first needs a way to detect them. Include any detection call in the combined workflow's cost and accuracy assessment.
Copy link to headingWhere does Jev fit in model selection?
If part of your workflow only selects a category or assesses a defined rubric, Jev is another model to evaluate for that step. It returns typed decisions with native probabilities. Your application can use the selected option's probability to decide whether to accept a result or send it for review, with thresholds tested against labeled examples from your task.
Sol and Luna can also classify inputs through structured output. Test whether Jev's decision interface improves the way you handle uncertain assignments before adding it to the workflow. Generation and investigation still need their own model calls after routing. Include the decision call and any handoff errors when comparing the complete workflow with your existing implementation.
Copy link to headingWhat should you check before switching models?
Use the model identifier for your integration:
Test the replacement with the prompts, response formats, and tools your application uses. Shared feature support does not establish that both models will choose the same function arguments or produce equally useful values in a schema. Include error handling and retries when measuring completion time under expected traffic, so the results reflect what users will experience.
Copy link to headingFrequently asked questions
Copy link to headingDoes Sol have a larger context window than Luna?
No. Sol and Luna each support a 1,050,000-token context window and up to 128,000 output tokens, including reasoning. The input must leave enough room for reasoning and the visible answer within that context window. Compare accuracy separately on the long documents your application uses.
Copy link to headingIs Luna twenty times cheaper than Sol?
Luna's Standard short-context input and output token rates are one twentieth of Sol's. The cost of completing a task also depends on token consumption and any additional charges, so the ratio does not guarantee equivalent savings per task.
Copy link to headingWhich model should I test first for coding?
Start with Sol for coding work that involves dependent steps or extended investigation. Include Luna when testing bounded coding tasks where lower token cost is a priority, and compare the resulting code against the same checks.
Copy link to headingCan I turn reasoning off for Sol and Luna?
Yes. Set the reasoning effort to none for either model. The parameter is reasoning.effort in the Responses API and reasoning_effort in Chat Completions.