[Bug] gpt-5.6-luna intermittently returns HTTP 500 for image-only function outputs

API Bugs
, , ,
1

I am seeing a reproducible issue with gpt-5.6-luna on the Responses API.

We use the computer tool alongside a custom function. After the model calls the function, we continue with the same previous_response_id and return only a locally generated image:

{
  "type": "function_call_output",
  "call_id": "call_...",
  "output": [
    {
      "type": "input_image",
      "image_url": "data:image/png;base64,..."
    }
  ]
}

The custom function name is omitted here, but the structure above matches the actual request. The call_id and previous_response_id are correct, and the tool definitions remain registered.

I ran six identical multi-turn trials with Luna. In each trial, the model was expected to alternate between the custom image-returning function and the computer tool for at least four turns.

None of the six trials completed:

  • In three trials, Luna returned HTTP 500 immediately after receiving the image-only function_call_output.

  • In the other three trials, Luna accepted the image output but returned HTTP 500 on the next valid computer_call_output.

Control tests:

  • Luna completed 12/12 computer-only trials without the custom image-returning function.

  • Simple custom function calls with Luna also work.

  • Changing only the model to gpt-5.6-terra allowed the same sequence to complete successfully in 8/8 trials.

  • Terra completed 40/40 API turns and processed 17 image-only function outputs with no HTTP 500 errors.

Because the same request sequence works reliably with Terra, this appears specific to Luna’s handling of image-only custom function results interleaved with computer use.

Has anyone else encountered this? Is it a known Luna issue?

I can provide failed request IDs, exact timestamps, and a sanitized reproduction privately to OpenAI Support.

Observed: July 12, 2026 at 11:32 UTC

2

Update: I created a minimal single-file reproduction:

https://gist.github.com/idoco/bf19dd35d44add74d97ee466ba07b4f1

The script embeds a static Base64 screenshot, disables SDK retries, and runs the identical request chain once with Luna and once with Terra.

I repeated it six times per model:

  • Luna completed 4/6 runs.
  • Terra completed 6/6 runs.
  • Both Luna failures occurred on the following computer_call_output request, after the image-only function_call_output had been accepted successfully.
  • A tiny 1×1 PNG completed 6/6 with both models, suggesting image size or complexity may help trigger the issue.
3

Luna has been seen creating corrupted JSON with garbage.

It is possible that status 500 is reported on similar bad model output - that the api backend that parses out function calls from AI-written tool shape cannot handle similar generation faults not matching the schema.

Large image returns could be part of the problem and model confusion. You might try wrapping an image return with text content parts to put the AI back in “text writing” mode. There, you can also report on the metadata, success of the tool call parameters in creating the image, what turn might be expected in succession or other post-prompt.

If you could get a dump of generated token ID integers instead of a 500 error, it would be far more diagnostic, but OpenAI wants to keep internals (such as special tokens and function-call sequences) secret.

4

Are you still encountering this issue? It is no longer happening for me today.

5

I expect the pattern of actual computer screenshot use in a longer agentic setting is needed. Then use of OpenAI’s smallest and cheapest in a family has never given good results.

I got a luna model symptom of empty assistant message upon return without and with text unless exact and non-optional text instruction was included in return. Producing nothing is likely what they want on ChatGPT image generator without needing to prompt for silence.

The positioning of text vs image cannot be controlled in OpenAI’s chat playground like you can do when actually creating multipart messages, where you can interleave identifiers and metadata with images and then ensure the guidance is last. OpenAI jams in system messages after tool calls on their own internal tools, which also can’t be demonstrated on OpenAI’s playground with functions even with a developer message. Cannot be submitted or cast to a different role:

Untitled-1
Untitled-1442×118 8 KB

Unclear placement, where “get code” reveals the opposite of this order:

Untitled
Untitled773×322 32.8 KB

6

Thanks for the pointers.

@ido provided a script for the minimal repro but using this I got the expected results.

7

Hi, thanks for the detailed report and minimal repro and for sharing further insight on this. We tracked this down and rolled out a fix for the intermittent HTTP 500 in this image-only function_call_output → computer-tool flow. I have verified the supplied gist completes end-to-end in production after the rollout.

@ido, could you retry your original workload and let us know whether you’re still seeing the issue? If you encounter any remaining 500s - or any other unexpected behavior - do feel free to share details

8

Thanks @Pansul_Bhatt for the quick fix! I’ve already run several tests and it’s working great so far. I’ll continue testing it more thoroughly, but this looks resolved.