API de GPT-6 Astra: primera petición y migración desde GPT-5.6 Sol

Para un primer smoke test en BetterToken, cambia el Model ID a gpt-6-astra y envía una petición breve al endpoint Chat Completions compatible con OpenAI. Migrar una aplicación requiere algo más: GPT-6 Astra no admite reasoning effort none, hay que retirar varios parámetros de sampling y logprobs, y el tool calling debe usar Responses API.

El proceso empieza con una petición de texto y aplica después el mínimo cambio controlado desde gpt-5.6-sol. Es una ruta documentada; no hicimos una llamada de pago con una API Key real al preparar el artículo.

Requisitos y primera petición

A 6 de septiembre de 2026, el catálogo público de BetterToken incluye gpt-5.6-sol y gpt-6-astra en el grupo GPT. Necesitas tu propia cuenta, una Key creada para el grupo actual, Base URL https://www.bettertoken.ai/v1 y un cliente HTTP con Bearer token y JSON.

Crea una cuenta BetterToken y una API Key para GPT-6 Astra

Comprueba el Model ID en el catálogo y en Setup. No publiques la Key en código, issues, screenshots ni soporte. Expórtala localmente:

export BETTERTOKEN_API_KEY="YOUR_API_KEY"

Usa la referencia pública de BetterToken:

curl "https://www.bettertoken.ai/v1/chat/completions" \
  -H "Authorization: Bearer $BETTERTOKEN_API_KEY" \
  -H "Content-Type: application/json" \
  --data '{
    "model": "gpt-6-astra",
    "messages": [
      {
        "role": "user",
        "content": "Reply with exactly: ASTRA_OK"
      }
    ]
  }'

La respuesta correcta contiene texto en choices[0].message.content; este fixture espera ASTRA_OK. Comprueba que no aparece 401, 403 ni model not found, que el texto no está vacío y que Dashboard registra gpt-6-astra, el estado y los tokens input/output/cache. Esto confirma Key, endpoint, Model ID y formato básico, pero no tools, streaming del SDK, calidad de producción ni equivalencia con Sol.

Diff mínimo desde GPT-5.6 Sol

 {
-  "model": "gpt-5.6-sol",
+  "model": "gpt-6-astra",
   "messages": [
     {"role": "user", "content": "Summarize this incident report."}
   ]
 }

Si la petición anterior usaba reasoning effort none o minimal, comienza Astra con low. En Chat Completions el campo es reasoning_effort:

{
  "model": "gpt-6-astra",
  "reasoning_effort": "low",
  "messages": [
    {
      "role": "user",
      "content": "Summarize this incident report. Preserve dates and owners."
    }
  ]
}

Si Sol ya usaba otro nivel efectivo, OpenAI recomienda conservarlo para la primera comparación. Subir effort en todos los requests también cambia latencia y consumo.

Retira los parámetros no admitidos:

 {
   "model": "gpt-6-astra",
   "reasoning_effort": "low",
-  "temperature": 0.2,
-  "top_p": 0.95,
-  "top_logprobs": 5,
-  "logprobs": true,
   "messages": [
     {"role": "user", "content": "Summarize this incident report."}
   ]
 }

OpenAI enumera temperature, top_p y top_logprobs; en Chat Completions elimina además logprobs. Revisa el JSON serializado si el SDK añade valores por defecto.

Chat Completions para texto, Responses para tools

GPT-6 Astra admite ambos endpoints, pero OpenAI exige Responses para tool calling. La referencia general pública de BetterToken documenta Chat Completions; Responses aparece por separado en la configuración de Codex.

Objetivo	Ruta
Verificar Key, Model ID y texto	POST https://www.bettertoken.ai/v1/chat/completions
Usar tools en Codex	custom provider con wire_api = "responses" según la guía Codex
Llamar raw Responses desde tu app	Confirma antes el contrato actual de tu canal; no está publicado en la referencia general

No traslades el schema de tools cambiando solo la URL: input items, llamadas, continuidad de estado y extracción de texto difieren. Compatibilidad de transporte tampoco implica el mismo estilo o elección de herramientas.

Migración controlada y rollback

Crea fixtures reales: una respuesta exacta, un structured output validado por JSON Schema, un prompt largo, un workflow con tools y una petición inválida. Registra para Sol Model ID, endpoint, reasoning efectivo, body serializado y acceptance check; ejecuta lo mismo en Astra con el diff mínimo.

Cambia tráfico solo si todos los fixtures pasan, el monitoring distingue gpt-5.6-sol de gpt-6-astra y el rollback restaura modelo y parámetros sin un release. Empieza con un flujo interno o una proporción pequeña determinada por tu riesgo; no hay un porcentaje universal. Conserva la configuración Sol durante la observación.

Diagnóstico rápido

• 401 Unauthorized: revisa Authorization: Bearer ..., el environment del proceso y espacios copiados; no registres la Key completa.
• 403 o model not found: confirma el grupo y copia exactamente gpt-6-astra.
• 400: elimina temperature, top_p, top_logprobs y logprobs; cambia none o minimal por low.
• Texto funciona, tools no: revisa endpoint. El smoke test no prueba Responses. Mantén wire_api = "responses" en Codex.
• Respuesta correcta, UI vacía: guarda raw response sin secretos y revisa choices[0].message.content, status, finish reason y el adapter.

La migración termina cuando Astra supera los fixtures, se observa por separado y puede revertirse por configuración. El primer 200 confirma conectividad, no toda la migración.