GPT-6 Sol and Luna Image Bug Fixed: Re-run Your Image Evals

On September 25, 2026, OpenAI’s API changelog recorded a fix for a bug in image encoding that had degraded how GPT-6 Sol and GPT-6 Luna understood images. Both models had launched three days earlier. OpenAI says the fix improves results on visual tasks in the API and in Codex, computer use included, and it recommends that anyone with image inputs re-run their evaluations and retry the workflows the bug touched.

That advice is short, and it matters most to the teams that moved fastest. If you tested GPT-6 on screenshots, scanned documents, charts or a computer-use agent in its first days, some of what you concluded may have come from a broken input path rather than from the model.

The OpenAI API changelog files the entry as a fix under both model names. It places the fault in image encoding, the step that turns a picture into input the model can read, and OpenAI shipped the correction without a new model identifier. Both models take text and images as input and return text; neither generates images, so the bug affected reading images, not making them.

The GPT-6 Sol model page lists a single identifier, gpt-6-sol, with no dated snapshot to pin, and the Luna page is the same. So the fix reached every caller without a code change. That is convenient now, and it also means there is no old snapshot to reproduce the broken behaviour if you want to measure how much it cost you.

OpenAI has not said when the bug began. The models went live in the API on September 22 and the fix is dated September 25, so the work to check is any image task run on either model before the fix. Four kinds of output deserve a second look:

The second box is the one teams forget. A comparison run in launch week becomes a routing rule, and a routing rule is rarely retested. If your router sends vision work away from GPT-6 because of a test from that window, the rule may rest on a fault that no longer exists. Our guide to telling a real regression from a broken evaluation covers the same trap from the other direction.

The token cost of a re-run is small at these prices. OpenAI lists GPT-6 Sol at $2 per million input tokens and $10 per million output tokens, and Luna at $0.10 and $0.50, with Batch processing at half the standard rate. The expensive part is the human review that follows a changed result, so narrow the re-run before you start:

• Filter your logs for requests to gpt-6-sol or gpt-6-luna that carried an image, dated before the fix.
• Re-run the evaluation set, not production traffic. A fixed test set gives a before-and-after comparison; production requests do not repeat.
• Use Batch for the bulk. An evaluation re-run has no deadline, which is what the half-price tier is for.
• Record which runs predate the fix so a future comparison does not mix the two populations.

If you do not have a fixed image test set, this is a reason to build one. Our walkthrough on building an evaluation harness to qualify new models shows the minimum version.

None of this is unusual for a changelog, which exists to record changes rather than explain them. It does mean the only reliable measure of the fix is the one you run on your own images. When OpenAI recommends “rerunning your evaluations,” it is telling you, in effect, that it cannot give you the answer for your workload.

A fix shipped without a new model identifier is easy to apply and easy to forget, and the decisions made before it do not update themselves. The illustrative cases below each carry a launch-week conclusion past September 25. They are patterns the exposure section describes, not teams we have worked with.

The routing rule that outlived the bug: a launch-week comparison put GPT-6 behind a rival on screenshots, the router was set to send vision work elsewhere, and nobody retested after the fix. The rule now encodes an encoding fault that no longer exists, which is the exposure section’s second box. The production re-run: a team re-runs its production traffic from launch week to measure the fix. Production requests do not repeat; only a fixed evaluation set gives a before-and-after comparison, which is why the re-run section says to re-run the set, not the traffic. The mixed populations: results from before and after the fix are kept in one table without a date label, and the next quarterly comparison averages across the fault. Recording which runs predate the fix is the step that was skipped. The launch score as confirmed: a vision-heavy figure from OpenAI’s launch coverage is quoted as the model’s capability. The changelog does not say whether published launch scores were produced with the bug, so the figure is unconfirmed until OpenAI says otherwise.

The common thread is that the fix changed the model under decisions that still cite the old one. The record in the next section is how a team finds those decisions and dates them.

The re-run section lists four steps, and the record is those steps with their results. The log filter: requests to gpt-6-sol or gpt-6-luna that carried an image, dated before the fix, with the count. The fixed test set: its identifier and the date it was last changed, so the before and after runs are known to be the same inputs. The batch job: the re-run on the half-price tier with its date, since an evaluation re-run has no deadline. The two result sets, labelled by date, with the differences that matter listed rather than a single aggregate. The decisions revisited: each routing rule, comparison or rejection made in the launch window, with whether the retest changed it. The shipped extractions: the slice sampled by hand and whether the sample found errors, which decides whether the review widens. And what remains unknown: the bug’s start date and magnitude, and whether any launch benchmark was affected, left as unknown rather than estimated.

An illustrative record for a document-extraction team reads: filter, a stated number of image requests to gpt-6-sol between September 22 and 25; test set, the invoice-and-receipt set last changed before launch; batch, re-run on the stated date; results, two labelled sets with the fields where accuracy moved listed; decisions, one routing rule set on September 24 retested and reversed, one vendor comparison retested and unchanged; extractions, a sample of delivered fields reviewed by hand with the error count recorded and the review not widened; unknown, the fault’s onset and size, and the launch figures.

The record also settles the gaps section’s point. The only reliable measure of the fix is the one you run on your own images, and the record is where that measure lives, dated, beside the decisions it changed.

Pull the launch-week image requests today and run the fixed set on Batch, then go through the decisions list before the retest results are filed. The rule set in launch week is the one that will cost the most if it is still there in a year.