GPT-6 image encoding bug fixed Sept 25: re-run frame reviews

OpenAI's changelog says that on September 25 it fixed an image encoding issue in GPT-6 Sol and GPT-6 Luna that had degraded image understanding, and that the update improves results on visual tasks including computer use. If you used either model between their September 22 release and that fix to review video frames, the verdicts you saved are worth re-running.

Both facts come from the OpenAI API changelog, read 2026-10-03: GPT-6 Sol and Luna released on Sep 22, the encoding fix on Sep 25. The page does not say how large the degradation was or which inputs it hit, so this post offers a re-check routine, not a quality claim.

Which saved results are at risk?

Anything where a GPT-6 Sol or Luna call looked at an image in that window and you stored the conclusion: a caption-legibility check, a product-in-frame check, a face-or-logo screen, a first-frame approval. Results that never relied on those models, or that predate September 22, are outside what the changelog describes. A model that misread an image tends to be wrongly confident, so the stored verdict is the thing to doubt, not the frame.

How do I pull the same frames again on Sume?

Sume's video frames endpoint extracts durable stills from one clip you already host on media.sume.com at times you name. You send video_url and exactly one of at[] or fps; optional format is jpeg (default) or png, and max_edge clamps the long edge between 16 and 2160. Submit always answers 202, and the finished job returns frames[{t,url,width,height}] as durable image artifacts. The source clip is untouched.

Because frames are stored artifacts, re-running a review does not require re-extraction: feed the same url values to the model again. Extract again only when you want a different time or size.

curl -X POST https://api.sume.com/v1/video-frames \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: recheck-frames-001" \
  -d '{"video_url":"https://media.sume.com/artifacts/artf_demo/talk.mp4",
       "at":[0,2.5,5],"format":"png","max_edge":1280}'

Is a still enough, or should I probe the clip?

For legibility and framing, a still at full size is the right input. For a clip-level question (duration, sampled stills and optional transcript) the video inspect endpoint probes one hosted clip and returns probe facts, stills and optional speech-to-text, and its page says it does not return typed scenes. Neither endpoint answers a semantic question; the model you point at the stills does.

What would a careful re-run look like?

Pick a sample of twenty saved verdicts, fifteen that passed and five that failed. Re-run them on the current model with the same stills and the same prompt, and compare. If the pass set stays stable and the failures stay failures, your older results held. If a few flip, widen the sample before trusting anything saved in that window. Store the model id next to each verdict from now on; the saved record then says which model looked.

Does this affect video generation itself?

Not as the changelog describes it. The entry concerns image understanding by the two reasoning models, which is the reading side of a video workflow. The pixels a video model produces are not a GPT-6 output, so a render you made in that window is not suspect because of this fix. What may be suspect is any decision made about a render by a model that looked at it.

That distinction keeps the re-check small. You do not need to regenerate clips; you need to re-ask the questions that were answered by looking.