Gpt-5.6-luna thread runs fail because parameters temperature and top_p are not supported and cannot be omitted

Question

Gpt-5.6-luna thread runs fail because parameters temperature and top_p are not supported and cannot be omitted

Birud Vora 1

We are using the Microsoft Foundry Agent Service (Assistants API, with assistants, threads and runs) on the project endpoint:

https://<project-name>.services.ai.azure.com/api/projects/<project-id>

with api-version=v1.

The model deployment in question is gpt-5.6-luna, model version 2026-07-09, deployed as GlobalStandard.

Run Request URL:

https://<project-name>.services.ai.azure.com/api/projects/<project-id>/threads/<thread-id>/runs?api-version=v1

Run Request Payload:

{
  "assistant_id": "<assistant-id>",
  "instructions": "[chatbot instructions omitted]",
  "stream": true,
  "model": "gpt-5.6-luna",
  "temperature": null,
  "top_p": null,
  "additional_messages": [
    {
      "role": "user",
      "content": "[user message and internal instructions omitted]"
    }
  ]
}

Run Response:

The service returns an event similar to:

event: thread.run.failed

{
  "id": "<run-id>",
  "object": "thread.run",
  "assistant_id": "<assistant-id>",
  "thread_id": "<thread-id>",
  "status": "failed",
  "last_error": {
    "code": "invalid_prompt",
    "message": "Unsupported parameter: 'top_p' is not supported with this model."
  },
  "model": "gpt-5.6-luna",
  "temperature": 1,
  "top_p": 1
}

Every thread run we create against this deployment fails. The run comes back with status "failed" and error code "invalid_prompt". The error message states either that top_p is not supported with this model, or that temperature is not supported with this model.

The core problem is that the run object returned by the service always contains numeric values for both temperature and top_p, no matter what we send in the request. We have not found any way to create a run where these two fields are absent, so the model rejects every run we are able to construct.

We have tested every combination of the two parameters:

When we omit both parameters completely from the request, the service itself populates temperature as 1 and top_p as 1 on the run, and the run then fails saying top_p is not supported.
When we send temperature as 0 and top_p as null, the run comes back with temperature as 0 and top_p as 1, and fails saying temperature is not supported.
When we send both parameters as null, we get the same values on the run and the same error.
When we send temperature as 0 and top_p as 0, the run keeps both of those values and still fails saying temperature is not supported.

In short, the run fails regardless of which values we use, and regardless of whether we send the parameters or leave them out entirely.

We would like clarification on two points:

Is gpt-5.6-luna supported for use with the Assistants API / Agent Service threads and runs execution path?
If it is supported, how can we create a run in which temperature and top_p are absent from the run object, given that omitting them, sending null, and sending explicit values have all been rejected?

We would appreciate any guidance on whether this is expected behavior for this model/deployment type, or whether there is a specific configuration or API parameter required to prevent the service from automatically populating temperature and top_p.

0 comments

2 answers

Your answer

Answer 1

Hello Birud Vora,

Thank you for the detailed information.

Based on the behaviour you described, the issue appears to be related to the interaction between the gpt-5.6-luna deployment and the Agent Service (Assistants API) run execution path. The error indicates that the model does not support the temperature and/or top_p parameters, while the service is automatically populating these values on the run object even when they are omitted from the request.

At this time, there is no documented mechanism in the Threads/Runs API to explicitly remove these fields from the generated run object. If the service continues to inject default values (temperature=1, top_p=1) and the model rejects them, this would suggest either:

A compatibility limitation between the current gpt-5.6-luna deployment and the Assistants/Agent Service execution path, or
An issue in the service handling of model-specific parameter restrictions when creating runs.

To help determine whether this is expected behaviour or a service-side issue, could you please confirm:

Whether the same assistant and workflow succeeds when using another supported model deployment (for example, a GPT-4.x or other GPT-5 family deployment).
The SDK and SDK version being used (if applicable), or whether the requests are being sent directly via REST.
A request ID / correlation ID from a failed run response, along with the approximate UTC timestamp of the failure.

Once we have that information, we can further investigate the model compatibility and backend behaviour.

Thank you, and we look forward to your update.

Answer 2

Hello Birud Vora

gpt-5.6-luna cannot be used on the classic Assistants-style threads/runs path at all, and no combination of temperature/top_p values will change that.

Here's the full picture:

The model catalog entry for gpt-5.6-luna lists its supported API surfaces as Chat Completions and Responses only. Like the rest of the GPT-5.x reasoning family, it rejects sampling parameters (temperature, top_p) outright the presence of the parameter is the error, regardless of its value. When Microsoft says GPT-5.6 is available in Foundry Agent Service, that means the new, Responses-API-based Agent Service (conversations + responses), not the classic Assistants-compatible execution path you're calling (/threads/<id>/runs with api-version=v1).

In the Assistants API contract, temperature and top_p are always-present fields on the run object with service-side defaults of 1, and null means use the default, not omit. The service materializes them on every run and forwards them to the model, which rejects them. The only place this could be fixed is server-side (the runs pipeline stripping sampling params for reasoning models), and that fix is very unlikely to come, because:

The Azure OpenAI Assistants API was retired on August 26, 2026 (retirement notice discussion).
The Foundry Agent Service classic the threads/runs surface on services.ai.azure.com/api/projects/... that you're using is built on the Assistants API, is deprecated, and retires March 31, 2027 (Q&A on the classic SDK's fate).

The way forward:

Migrate to the new Foundry Agent Service (Responses-based). The mapping is: assistants → agent versions, threads → conversations, runs → responses. Microsoft's migration tool at aka.ms/agent/migrate/tool gives you a starting point, though run-state orchestration logic needs rewriting against response states.
If you don't need agentic features (file search, code interpreter, managed threads), call the Responses API directly on the project endpoint (/openai/v1/responses) gpt-5.6-luna works there, and reasoning models on that surface simply don't accept sampling params, so the problem disappears.
Stopgap: if migration takes time, point the classic assistant at a non-reasoning deployment (gpt-4.1/gpt-4o family), which still accepts temperature/top_p, and hold gpt-5.6-luna until you're on the new surface.gpt-5.6-luna cannot be used on the classic Assistants-style threads/runs path at all, and no combination of temperature/top_p values will change that.