Temperature en la API de GPT-6 Luna: por qué devuelve 400 y qué enviar

Si intentas fijar temperature en la API de GPT-6 Luna, lo habitual es recibir un HTTP 400, no una respuesta más conservadora. La guía de migración a GPT-6 de OpenAI indica que hay que eliminar temperature, top_p y top_logprobs siempre que el reasoning effort sea distinto de none, y quitar también logprobs en Chat Completions^[1]. GPT-6 Luna usa medium como effort por defecto^[2], así que una request que añade temperature: 0.2 y no toca el effort cae en el lado equivocado de esa regla.

Este artículo explica qué dice la regla, los mensajes de error exactos que han publicado desarrolladores desde clientes de Amazon Bedrock, Azure y OpenAI, el ID de modelo correcto y una request de antes y después para el endpoint de Chat Completions de reAPI. Las mismas reglas valen para GPT-6 Sol.

TL;DR

• Elimina temperature y top_p. La guía de OpenAI dice que hay que quitarlos, junto con top_logprobs, cuando el reasoning effort no es none^[1]. El effort por defecto de Luna es medium^[2].
• En reAPI la regla es más sencilla: temperature, top_p, frequency_penalty y presence_penalty devuelven 400 tanto en gpt-6-luna como en gpt-6-sol. No los incluyas en ninguna request^[3][4].
• Incluso temperature: 1 puede fallar. Un bug report de Langflow comprobó que la Converse API de Amazon Bedrock rechaza el campo con cualquier valor, incluido 1^[5].
• El control que sí tienes es reasoning_effort: none, low, medium, high, xhigh o max^[2]. No existe un valor auto.
• El ID de modelo es gpt-6-luna (y gpt-6-sol), escrito exactamente así^[2][3].
• El primer resultado de Microsoft Q&A trata de otro bug. Habla de que Azure AI Foundry rechaza reasoning.effort, no de temperature^[6].

Por qué GPT-6 Luna rechaza temperature

GPT-6 Luna es un modelo de razonamiento. La página del modelo en OpenAI indica "Reasoning token support" y seis niveles de effort, con medium por defecto^[2]. La checklist "Update API and model parameters" de la guía de GPT-6 de OpenAI dedica un apartado propio a los parámetros de muestreo^[1]:

Fíjate bien en la condición. La guía vincula la eliminación al reasoning effort, no al nombre del modelo. La misma guía señala que GPT-6 Sol y GPT-6 Luna admiten none, mientras que GPT-6 Astra y GPT-6.1 Sol no^[1]. En la práctica, la mayoría de las requests se ejecutan con el medium por defecto, así que la mayoría de las que llevan temperature fallan.

reAPI documenta un resultado más estricto. Su tabla de parámetros para gpt-6-luna, medida en el endpoint el 2026-09-24, describe temperature, top_p, frequency_penalty y presence_penalty como "Not supported by this model — sending any of them returns 400. Leave them out of the request."^[3] La página de gpt-6-sol incluye la misma fila^[4]. La documentación no describe ninguna excepción para el effort none, así que no construyas sobre esa idea: elimina los campos.

Los errores 400 que de verdad están recibiendo los desarrolladores

Los resultados de búsqueda sobre este problema mezclan varios errores distintos. Estos son los mensajes que se han publicado, de dónde salió cada uno y qué lo soluciona.

Dos de estos reportes muestran que el campo llega sin que nadie lo haya elegido. El playground de AWS de Phoenix arranca cada ejecución con temperature: 1 desde una configuración por defecto, y su slider no se puede vaciar^[7]. El componente de Bedrock de Langflow envía por defecto Temperature 0.7 y Top P 0.9^[5]. Así que, si tu propio código nunca menciona temperature y aun así recibes el error, revisa los valores por defecto del framework.

Fijar temperature en la API de GPT-6 Luna con reAPI: antes y después

reAPI sirve GPT-6 Luna a través de POST https://reapi.ai/api/v1/chat/completions, con tu clave de reAPI como bearer token^[3]. Esta request arrastra costumbres de modelos de chat anteriores y será rechazada:

# Rejected: temperature and top_p return 400 on gpt-6-luna
curl https://reapi.ai/api/v1/chat/completions \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-6-luna",
    "messages": [
      { "role": "user", "content": "Classify this ticket as billing, bug or account access: I was charged twice." }
    ],
    "temperature": 0.2,
    "top_p": 0.9
  }'

La versión corregida quita ambos campos y fija los controles que el modelo sí respeta. reasoning_effort acepta los seis niveles en reAPI, y max_completion_tokens se aplica hasta 128,000^[3]:

# Accepted: no sampling fields, explicit effort and output cap
curl https://reapi.ai/api/v1/chat/completions \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-6-luna",
    "messages": [
      { "role": "user", "content": "Classify this ticket as billing, bug or account access: I was charged twice." }
    ],
    "reasoning_effort": "low",
    "max_completion_tokens": 1000
  }'

Los reasoning tokens cuentan para max_completion_tokens y se facturan como salida, así que un límite calculado solo para la respuesta visible puede truncar un prompt más difícil^[3]. Las tarifas actuales por token están en la página del modelo GPT-6 Luna.

El resto de la superficie de parámetros en reAPI, tal como está documentada para ambos modelos GPT-6^[3][4]:

La fila de tools difiere de la propia regla de OpenAI para Chat Completions, que solo permite function calling con reasoning_effort: "none"^[2]. En el endpoint de reAPI, tools devolvió tool_calls con medium en la medición del 2026-09-24^[3].

Qué usar en lugar de temperature

Temperature controlaba la aleatoriedad del muestreo. GPT-6 Luna no ofrece un sustituto directo, así que elige el control que corresponda a aquello para lo que querías temperature.

Querías una salida consistente y fácil de parsear. Usa response_format con un JSON schema y strict: true. reAPI lo aplica en ambos modelos GPT-6^[3], y un schema estricto fija la forma de la respuesta, que es lo que muchas configuraciones con temperature: 0 intentaban conseguir.

Querías respuestas más rápidas o más baratas. Baja el reasoning_effort. La guía de razonamiento de OpenAI describe none para trabajo donde la latencia es crítica, como clasificación y recuperación rápida, y low para uso de herramientas, flujos de soporte y redacción de borradores^[11]. Menos reasoning tokens también significa menos tokens de salida facturados^[3].

Querías respuestas variadas. Ni seed ni n sirven aquí en reAPI. seed se acepta sin efecto y n está limitado a 1^[3]. Envía requests separadas o pide varias alternativas en un mismo prompt.

Querías otro estilo. Dilo en el mensaje de system o developer. Los ajustes de muestreo siempre fueron una herramienta tosca para el tono, y las instrucciones son la única palanca que queda.

Eliminar los campos en Python

Si un helper compartido o una configuración inyecta valores de muestreo por defecto, quítalos antes de la llamada en lugar de editar cada punto de llamada. Esto usa el SDK oficial de OpenAI apuntando a reAPI, como en el ejemplo de Python de reAPI^[3]:

from openai import OpenAI

client = OpenAI(api_key="YOUR_API_KEY", base_url="https://reapi.ai/api/v1")

REJECTED = {"temperature", "top_p", "frequency_penalty", "presence_penalty"}

def gpt6_params(params: dict) -> dict:
    """Drop fields that gpt-6-luna and gpt-6-sol answer with 400."""
    return {k: v for k, v in params.items() if k not in REJECTED}

params = {"temperature": 0.2, "top_p": 0.9, "max_completion_tokens": 1000}

resp = client.chat.completions.create(
    model="gpt-6-luna",
    messages=[{"role": "user", "content": "Summarize this refund policy in two sentences."}],
    reasoning_effort="low",
    **gpt6_params(params),
)
print(resp.choices[0].message.content)

Cuando no ves de dónde sale un campo, registra durante las pruebas las claves del body final serializado de la request. Los reportes de Phoenix y Langflow citados arriba son, ambos, casos de un valor por defecto que quien hacía la llamada nunca escribió^[5][7].

FAQ

Configurar temperature en la API de GPT-6 Luna: GitHub

Los issues de GitHub sobre este tema son, sobre todo, bugs de herramientas que envían temperature por defecto. El componente de Bedrock de Langflow envía 0.7 y 0.9 para temperature y top_p^[5], y el playground de AWS de Phoenix envía temperature: 1 en cada ejecución^[7]. Ambos reportes dicen que la request funciona una vez eliminados los campos. La solución en tu propio código es la misma: no envíes temperature ni top_p a GPT-6 Luna.

Configurar temperature en la API de GPT-6 Luna con Python

No se puede. Deja temperature y top_p fuera de client.chat.completions.create(...) y pasa reasoning_effort en su lugar. En reAPI ambos campos devuelven 400^[3]. El helper de Python de arriba los filtra si llegan desde una configuración compartida.

Ejemplo de temperature en la API de GPT-6 Luna

El ejemplo es la request cURL corregida de arriba: model con valor gpt-6-luna, el array messages, reasoning_effort: "low" y max_completion_tokens: 1000, sin temperature ni top_p. Sigue las reglas de campos de la documentación de GPT-6 Luna en reAPI^[3].

Nombre de GPT-6 Luna en la API

El ID de modelo en la API es gpt-6-luna. OpenAI lo lista a la vez como ID de modelo y como único snapshot, con la indicación "Use gpt-6-luna in your API requests."^[2] reAPI usa la misma cadena y lo trata como un modelo distinto de gpt-5.6-luna y gpt-6-sol^[3]. Los mensajes de error de Azure mencionan además una versión del modelo, gpt-6-luna-2026-09-22^[10].

Reasoning auto en la API de GPT-6 Luna

No existe un reasoning effort auto. OpenAI lista none, low, medium, high, xhigh y max para GPT-6 Luna, con medium por defecto^[2]. Para obtener el valor por defecto del modelo, omite reasoning_effort por completo. La guía de razonamiento de OpenAI sí usa auto, pero para otros ajustes: los resúmenes de razonamiento y el campo reasoning.context^[11].

GPT-6 Luna en Azure

El problema de Azure más citado no tiene que ver con temperature. Una publicación de Microsoft Q&A del 29 de septiembre de 2026 reporta agentes de Foundry que fallan con "Unsupported parameter: 'reasoning.effort' is not supported with this model"^[6]. Un issue de GitHub lo reproduce en el project endpoint de Foundry, donde las llamadas simples devuelven 500 y con effort devuelven 400, mientras que el resource endpoint funciona con reasoning effort. La solución temporal de quien lo reportó es llamar al resource endpoint, y el issue seguía abierto cuando lo comprobamos el 7 de octubre de 2026^[8].

Qué effort usar con GPT-6 Sol

GPT-6 Sol admite los mismos seis valores que Luna, con medium por defecto^[4][12]. La recomendación general de OpenAI es none para trabajo donde la latencia es crítica, low para uso de herramientas y redacción de borradores, medium para la mayoría de las cargas de trabajo, high para depuración y planificación difíciles, y xhigh solo cuando los evals justifiquen la latencia y el coste adicionales^[11]. En reAPI, Sol rechaza temperature y top_p igual que Luna^[4].

Requests a GPT-6 Luna que pasan a la primera

Una request limpia a GPT-6 Luna tiene model con valor gpt-6-luna, un array messages, un reasoning_effort elegido a propósito y un límite de salida con margen para el razonamiento. No lleva temperature, top_p ni campos de penalización. Si llegaste aquí para fijar temperature en la API de GPT-6 Luna, la respuesta es dejar de fijarla: controla el coste y la latencia con el effort, controla la forma con un JSON schema estricto y revisa qué añade tu framework por defecto. La misma forma de request funciona con GPT-6 Sol. Los parámetros están en la documentación de GPT-6 Luna y la documentación de GPT-6 Sol, y las tarifas actuales en las páginas de los modelos GPT-6 Luna y GPT-6 Sol.

References

1. OpenAI. Using GPT-6. Consultado en octubre de 2026 en developers.openai.com/api/docs/guides/latest-model
2. OpenAI. GPT-6 Luna model page. Consultado en octubre de 2026 en developers.openai.com/api/docs/models/gpt-6-luna
3. reAPI. gpt-6-luna API documentation. Consultado en octubre de 2026 en reapi.ai/docs/gpt-6-luna
4. reAPI. gpt-6-sol API documentation. Consultado en octubre de 2026 en reapi.ai/docs/gpt-6-sol
5. Langflow on GitHub. Amazon Bedrock Converse: OpenAI GPT-6 Sol/Luna/Astra calls fail with 400 because Temperature and Top P are sent by default (#15349). Consultado en octubre de 2026 en github.com/langflow-ai/langflow/issues/15349
6. Microsoft Q&A. GPT-6-Luna agents fail with Unsupported parameter: 'reasoning.effort' error. Consultado en octubre de 2026 en learn.microsoft.com/en-us/answers/questions/6018360
7. Arize Phoenix on GitHub. Playground can't run OpenAI GPT-6 Sol/Luna/Astra on AWS Bedrock: default temperature=1 is always sent and rejected with 400 (#16430). Consultado en octubre de 2026 en github.com/Arize-ai/phoenix/issues/16430
8. Azure SDK for Python on GitHub. azure-ai-projects: gpt-6-luna returns 500 on project endpoint, works on resource endpoint (#49169). Consultado en octubre de 2026 en github.com/Azure/azure-sdk-for-python/issues/49169
9. redmine_ai_helper on GitHub. Chat fails with gpt-6 models (gpt-6-luna, gpt-6-sol): "Function tools with reasoning_effort are not supported" (#480). Consultado en octubre de 2026 en github.com/haru/redmine_ai_helper/issues/480
10. Microsoft Agent Framework on GitHub. Invalid parameter: 'text.format' of type 'json_schema' is not supported with model version gpt-6-luna-2026-09-22 (#8718). Consultado en octubre de 2026 en github.com/microsoft/agent-framework/issues/8718
11. OpenAI. Reasoning models. Consultado en octubre de 2026 en developers.openai.com/api/docs/guides/reasoning
12. OpenAI. GPT-6 Sol model page. Consultado en octubre de 2026 en developers.openai.com/api/docs/models/gpt-6-sol

Lecturas recomendadas

• reAPI. GPT-6 Sol vs GPT-6 Luna. reapi.ai/blog/gpt-6-sol-vs-luna
• reAPI. GPT-6 Luna API pricing. reapi.ai/blog/gpt-6-luna-api-pricing