Llamar a GPT-6 Astra desde .NET: Chat, Responses y esfuerzo de razonamiento

OpenAI anunció GPT-6 Astra el 3 de septiembre de 2026 y lo presenta como un salto en uso del ordenador, navegación web, programación y trabajo de agentes que se prolonga durante mucho tiempo. El acceso llega por fases. Primero lo recibe un grupo limitado de empresas del programa de ciberseguridad Daybreak. Después el modelo llega a ChatGPT Plus, Pro, Business y Enterprise, a la API de OpenAI, a Microsoft Foundry en Azure y a AWS Bedrock.

Un anuncio de lanzamiento cuenta poco sobre lo que se rompe cuando un proyecto .NET apunta a un nombre de modelo nuevo. La comprobación útil es comparar el contrato de API publicado del modelo con la documentación vigente, instalar después el paquete real de OpenAI en NuGet (la versión 2.13.0 en el momento de la prueba) y leer lo que expone de verdad en lugar de copiar un ejemplo de un blog. Lo interesante resulta ser precisamente la distancia entre ambas fuentes. La documentación describe intenciones; un ensamblado compilado muestra lo que un desarrollador puede escribir de verdad, qué atributos bloquean la compilación y qué miembros de enumeración existen.

En un repositorio complementario hay tres ejemplos ejecutables, uno por estilo de cliente: chat, meai y responses. Los tres envían el mismo prompt. Como el modo meai fija el esfuerzo de razonamiento mediante una abstracción de más alto nivel que se explica más abajo, sus resultados no pueden compararse exactamente con los de los otros dos modos. El README del repositorio detalla qué ejecuta cada modo.

Las cifras publicadas del modelo

• ID del modelo: gpt-6-astra
• Ventana de contexto: 1.050.000 tokens, con hasta 128.000 tokens de salida
• Espacio para la entrada: unos 922.000 tokens, aunque esa cifra sale de una simple resta y no la indica OpenAI
• Tipos de entrada: texto e imágenes; la salida es solo texto
• Fecha de corte del conocimiento: 30 de abril de 2026
• Endpoints: Chat Completions, Responses y Batch, todos con streaming, salidas estructuradas, entrada de imágenes y caché de prompts
• Esfuerzo de razonamiento: cinco valores, low, medium, high, xhigh y max

Peculiaridades de los precios

En cuanto una petición supera los 272K tokens de entrada, se factura la petición entera al doble de la tarifa de entrada y de caché y a 1,5 veces la de salida, no solo el exceso. El procesamiento Batch y el Flex cuestan la mitad de las tarifas estándar. También existe un modo Fast al doble de las tarifas aplicables, que importa en rutas sensibles a la latencia pero exige antes una conversación sobre presupuesto. En la práctica conviene tener en cuenta el recargo por contexto largo antes de enviar un prompt del tamaño de un repositorio, porque cruzar el umbral cambia el precio de todo lo que va en esa llamada. La documentación se compromete con ese precio sin prometer una aceleración concreta, así que aquí tampoco se inventa ninguna cifra de velocidad.

Dos clientes en un mismo paquete

Ejecutar dotnet add package OpenAI instala hoy la 2.13.0. Esa versión llega al modelo mediante dos clientes distintos, y solo uno de ellos puede usarse sin aceptar una API experimental.

El cliente de chat estable

OpenAI.Chat.ChatClient no lleva atributo Experimental. Es desde hace tiempo la vía de producción, y el nuevo modelo funciona con él como cualquier otro modelo de chat.

using OpenAI.Chat;

ChatClient client = new("gpt-6-astra", Environment.GetEnvironmentVariable("OPENAI_API_KEY"));
ChatCompletion completion = await client.CompleteChatAsync(
    [new UserChatMessage("Refactor the DbContext lifetime across every endpoint in this project.")],
    new ChatCompletionOptions
    {
        ReasoningEffortLevel = ChatReasoningEffortLevel.High,
    });
Console.WriteLine(completion.Content[0].Text);

El puente de Microsoft.Extensions.AI, que se distribuye en el paquete aparte Microsoft.Extensions.AI.OpenAI, tampoco da sorpresas. Eso encaja con los equipos que ya se han estandarizado en IChatClient.

using OpenAI.Chat;
using Microsoft.Extensions.AI;

IChatClient client = new ChatClient("gpt-6-astra", Environment.GetEnvironmentVariable("OPENAI_API_KEY"))
    .AsIChatClient();
var response = await client.GetResponseAsync(
    "Refactor the DbContext lifetime across every endpoint in this project.");
Console.WriteLine(response);

La extensión AsIChatClient para ChatClient tampoco tiene atributo Experimental. Es la forma que conviene usar mientras Astra solo responda preguntas y no invoque herramientas.

Al añadir ambos paquetes aparece un problema de versiones. Microsoft.Extensions.AI.OpenAI 10.9.0 depende de OpenAI 2.12.0 o superior pero inferior a 2.13.0, mientras que añadir OpenAI sin más resuelve a la 2.13.0, un parche fuera de ese margen. Por eso el enfoque ingenuo produce un aviso NU1608 por una versión fuera de la restricción. El restore y la compilación siguen funcionando, pero fijar explícitamente la versión de OpenAI mantiene limpio el log del restore.

Las llamadas a herramientas viven en el cliente experimental

La salvedad de las herramientas pesa más de lo que parece. Las notas de versión de OpenAI para Astra dicen claramente que las llamadas a herramientas requieren la API Responses, y hay una guía de migración para quien ahora llama a herramientas mediante Chat Completions con otro modelo. En este modelo, todas las capacidades de tipo agente están en el cliente que sigue bloqueado tras el diagnóstico OPENAI001: llamadas a funciones, búsqueda web y de archivos, el intérprete de código, el uso del ordenador y MCP. El cliente estable responde preguntas; el experimental es donde ocurre el comportamiento agéntico. Quien planee un agente sobre este modelo debería asumir que convivirá con la supresión de OPENAI001 y con una superficie de API que puede cambiar de nombre entre versiones del SDK.

OpenAI.Responses.ResponsesClient está marcado como Experimental("OPENAI001") en la clase entera. No es un aviso suelto en un único método: todo el tipo queda vetado hasta que se suprima el diagnóstico, ya sea con un pragma, una opción del proyecto o una regla de editorconfig. Intentar construirlo detiene el compilador mientras el diagnóstico no esté suprimido.

#pragma warning disable OPENAI001
using OpenAI.Responses;

ResponsesClient client = new(Environment.GetEnvironmentVariable("OPENAI_API_KEY"));
ResponseResult result = await client.CreateResponseAsync(
    "gpt-6-astra",
    "Refactor the DbContext lifetime across every endpoint in this project.",
    previousResponseId: null);
Console.WriteLine(result.GetOutputText());

Más allá de la sobrecarga cómoda que recibe tres cadenas, es decir, para herramientas, opciones de razonamiento y salida estructurada, hace falta un objeto CreateResponseOptions. El tipo se llama CreateResponseOptions, no ResponseCreationOptions, que es lo que daría a entender el propio texto de la documentación.

ResponseResult result = await client.CreateResponseAsync(new CreateResponseOptions
{
    Model = "gpt-6-astra",
    InputItems = { ResponseItem.CreateUserMessageItem("Refactor the DbContext lifetime across every endpoint in this project.") },
    ReasoningOptions = new ResponseReasoningOptions
    {
        ReasoningEffortLevel = ResponseReasoningEffortLevel.High,
    },
});

El mismo paquete Microsoft.Extensions.AI.OpenAI incluye también una sobrecarga de AsIChatClient para ResponsesClient, que, de forma coherente, lleva la misma marca OPENAI001.

El esfuerzo de razonamiento y los miembros que faltan

Los valores documentados de reasoning.effort para Astra son low, medium, high, xhigh y max. El modelo no acepta none de forma explícita. El detalle tiene su ironía, porque los dos tipos de conveniencia del SDK de .NET, ChatReasoningEffortLevel para Chat Completions y ResponseReasoningEffortLevel para Responses, exponen en la 2.13.0 exactamente cinco miembros estáticos: None, Minimal, Low, Medium y High. El valor al que casi todos recurren por costumbre es justo el que este modelo rechaza.

Ni xhigh ni max tienen un miembro con nombre en ninguno de los dos tipos. Eso no impide que el SDK los envíe, solo que los nombre. Ambos tipos son envoltorios extensibles de cadenas y no enums de C# auténticos, y cada uno tiene un constructor público que recibe una cadena. Hay pruebas directas de que ese es el uso previsto. La integración de OpenAI dentro de Microsoft.Extensions.AI lo hace internamente. El paquete Abstractions, 10.9.0, define un ajuste ReasoningEffort con None, Low, Medium, High y ExtraHigh en ChatOptions.Reasoning. El mapeo dentro de la integración de OpenAI envía ExtraHigh como un ChatReasoningEffortLevel construido a partir de la cadena xhigh. Se confirmó que esa cadena literal está incrustada en la propia DLL 10.9.0 publicada, no solo en un ejemplo más reciente de una rama main. Así que en la capa de IChatClient no hace falta ninguna cadena en bruto.

IChatClient client = new ChatClient("gpt-6-astra", Environment.GetEnvironmentVariable("OPENAI_API_KEY"))
    .AsIChatClient();

var response = await client.GetResponseAsync(
    "Refactor the DbContext lifetime across every endpoint in this project.",
    new ChatOptions { Reasoning = new ReasoningOptions { Effort = ReasoningEffort.ExtraHigh } });

La abstracción llega hasta ExtraHigh y no tiene equivalente para max. Para llegar a max, o para usar xhigh o max con los tipos en bruto del SDK, hay que construir la cadena a mano.

ReasoningEffortLevel = new ChatReasoningEffortLevel("max"),

Hay una salvedad. Esa llamada no se ha lanzado contra un endpoint real de Astra para confirmar que la API responde con un 200 y no con un error de validación. Demostrar que el SDK está dispuesto a enviar una cadena arbitraria no demuestra que el servicio la vaya a aceptar, y solo se ha comprobado lo primero.

Qué está verificado y qué no

Comprobado frente a la documentación vigente y la superficie compilada del SDK: las especificaciones del modelo, la tabla de precios, los nombres de las clases, el atributo Experimental y la cadena xhigh dentro de la DLL publicada de Microsoft.Extensions.AI.OpenAI. Aún sin comprobar: si la API acepta max con un 200 y si una tarea real de .NET ejecutada en high frente a xhigh mediante el cliente Responses experimental justifica el doble de coste en tokens. Esa comparación es la continuación prevista, cuando el modelo salga del despliegue por fases y se pueda usar sin invitación de Daybreak.