A documented fix for a specific problem
On September 25, OpenAI's API changelog reported a fix for an image-encoding bug that weakened image understanding in GPT-6 Sol and GPT-6 Luna. It identifies visual tasks in the API and Codex, including computer use, and recommends repeating affected workflows and evaluations.
The scope matters: this entry names Sol and Luna. It does not establish an Astra regression or explain every disappointing ChatGPT response. It also supplies no universal improvement percentage. A report about a visual processing fault should be connected to tasks that actually used images.
Which past results deserve another look?
For readers who tried the new models immediately after launch, our recommendation is to revisit failures whose answers depended on visual evidence. Useful candidates include interpreting a chart, reading a screenshot, or finding a control in an application. These are suggested test cases, not a list of failures independently confirmed by VSike.
- Preserve the original image, prompt, model name, and failed response.
- Write down what the correct result should contain before running it again.
- Keep reasoning settings and tool access comparable, and record the new run's date.
- Separate an incorrect visual interpretation from a failed click, missing file, or permission error.
Compare the same evidence
Changing the screenshot crop, wording, model, and reasoning level together can produce a better answer while leaving the reason unclear. Begin with the same input. If the old screenshot is no longer available, state that limitation rather than presenting the result as a controlled comparison.
A repeated run can show that the current workflow succeeds. Proving exactly which internal change caused the improvement is harder, especially when the earlier service configuration cannot be reproduced. Keep that distinction in any public before-and-after report.
What this adds to the quality debate
Our reading of this news is practical: a perceived loss of quality can have a specific, documented implementation cause. That makes release notes useful evidence alongside saved examples. It does not justify treating every error as temporary or assuming that a named fix solves unrelated reasoning problems.
For a structured investigation, see our quality-drop diagnosis guide and the reproducible comparison method. For background on the two models, read the Sol and Luna launch briefing.