OpenAI Cuts GPT-6 Prices With Sol and Luna

Your agent roadmap now needs a price column beside capability, latency, and retention. OpenAI released GPT-6 Sol and GPT-6 Luna on September 22, offering models aimed at mid-tier agentic and coding workloads at half the price of their predecessors. Sol is listed at $2/$10. Luna is listed at $0.10/$0.50. The gap between them is the story.

That gap is large enough to change the shape of a product. A team can no longer sensibly treat its chosen model as a permanent backend, hidden behind one application-wide setting. A support agent that drafts an answer, a coding agent that revises a file, and a background agent that classifies thousands of records may all need different economic rules. OpenAI has made the cheaper answer explicit. Product managers now have to decide where intelligence is worth paying for.

The announcement makes the mechanics unusually easy to understand. Sol and Luna are available through the API, and both arrive with a 50% reduction against their predecessors. SiliconANGLE described the release as a simultaneous move with Anthropic’s Claude Opus 5.5, putting the new OpenAI models directly into an active price fight. The competitive context matters. The product consequence matters more.

The price becomes a router

Consider a simple agent workflow. It receives a request, decides whether a tool is needed, calls that tool, reads the result, and produces an answer. Some turns require judgment. Others amount to sorting, extracting, or checking whether a field is present. Under one model, those steps look like a single experience. Under two sharply different price points, they look like a routing problem.

Routing is the product decision. A manager might send routine classification to Luna, use Sol for a more involved coding task, and reserve a more expensive model for work that genuinely affects the customer’s outcome. That is not a claim about benchmark performance. The available evidence does not provide a comparison of Sol or Luna’s quality. It is a statement about the choice OpenAI is putting in front of teams: two cheaper GPT-6 options, with a substantial spread between them.

The familiar product instinct is to pick the strongest available model and optimise later. That worked when model choice was a relatively stable technical preference. It becomes expensive when agents repeat actions at volume. A single request may be cheap. A workflow that retries, calls tools, and runs in the background is a different object. Its cost is determined by the number of model decisions, not by the fact that one user pressed one button.

For a PM, the useful unit is therefore not the model. It is the decision inside the workflow. Which steps need interpretation? Which steps can tolerate a cheaper answer? Which steps are repeated often enough that a small per-call difference becomes a material operating cost? Sol and Luna force those questions into discovery and planning instead of leaving them to whoever owns the API key.


Design the tiers early

A sensible first pass is to map the workflow by consequence. A low-consequence step might label an incoming document or decide whether a known format is valid. A higher-consequence step might write code, resolve an ambiguous request, or produce the final response a customer sees. The example is deliberately ordinary. The point is that the tiers should follow the job, not the model’s marketing name.

That changes how teams write requirements. “Use GPT-6” is no longer a complete technical requirement. It says nothing about which calls use Sol, which use Luna, or what happens when a step fails or needs another attempt. A better product requirement names the class of work and its budget. The implementation can then select a model without turning every future price change into a roadmap event.

This also changes experimentation. Teams need to test a workflow with model assignments, not only a model in isolation. A cheaper model may be adequate for one narrow operation and unsuitable for the next. Conversely, a more expensive model may be wasteful when it is asked to repeat a mechanical task. The evidence does not tell us where Sol or Luna will draw those boundaries. It tells us that OpenAI has lowered the cost of trying to draw them.

The practical risk is averaging. If a dashboard reports one blended cost for an agent, it can hide the expensive path. A small number of difficult requests may account for a disproportionate share of spend. A large number of routine calls may make the cheaper tier the main economic lever. Product teams should see cost by workflow step and by model tier, even if the first version of that reporting is a spreadsheet rather than a new platform.

That visibility is not finance theatre. It determines which features can exist. A background agent that checks every item in a large queue has a different price ceiling from an assistant used a few times per day. Luna’s listed $0.10/$0.50 price point creates room for the former kind of product. Sol’s $2/$10 price point offers a different compromise. Whether either model delivers the required quality remains an open question, but the pricing makes separate product cases possible.

Cheap does not mean simple

The counterpoint is obvious. Lower API prices do not automatically lower total product cost. A cheaper model can require more retries, more review, or more complicated routing. The supplied reporting provides no benchmark or reliability data for Sol and Luna, so nobody outside the lab can conclude that the cheaper call is the cheaper workflow. The sticker price is an input, not the business case.

That uncertainty is precisely why segmentation should happen before launch, not after the first bill. Define the acceptable outcome for each step. Measure how often the step needs another attempt. Put a ceiling on spend for repeated work. Then test the assignment. If the cheap path needs so much repair that it erases its price advantage, the data will show it. If it handles routine work well enough, the product has gained a durable margin lever.


The release also narrows the distance between product architecture and pricing strategy. In a conventional software stack, a vendor’s price change can be a procurement concern. In an agent stack, price changes alter what the product is allowed to do repeatedly. A lower-cost model can make continuous background work plausible. A higher-cost model may need to be reserved for moments where the user can see its value. That is architecture expressed in dollars.

This week’s launch therefore creates a less glamorous planning task. Rewrite the agent map. Mark every model call. Separate the steps by consequence and volume. Assign a cost tier. Keep the assignments changeable. The teams that do this can treat Sol and Luna as options. The teams that do not will discover their segmentation after usage has already chosen it for them.

OpenAI’s half-price move is aggressive, but its most important effect is not that one API bill gets smaller. It is that “the model” stops being a singular product decision. There are now at least two price bands inside the same release, and every repeated decision has to earn its place in the expensive one.