Calling GPT-6 Astra From .NET: Chat, Responses and Reasoning Effort

OpenAI announced GPT-6 Astra on September 3, 2026, positioning it as a step up for computer use, web browsing, programming and agent work that runs for a long time. Access arrives in stages. A limited group of companies in the Daybreak cybersecurity program comes first. After that the model reaches ChatGPT Plus, Pro, Business and Enterprise, the OpenAI API, Microsoft Foundry on Azure, and AWS Bedrock.

A launch post says little about what breaks once a .NET project points at a new model name. The useful check is to compare the model's published API contract with the live documentation, then install the real OpenAI NuGet package, version 2.13.0 at the time of testing, and read what it actually exposes instead of copying a sample from a blog. The distance between those two sources turns out to be the interesting part. Docs describe intent; a compiled assembly shows what a developer can really type, which attributes block compilation, and which enum members exist.

Three runnable samples live in a companion repository, one per client style: chat, meai and responses. All three send the same prompt. Because the meai mode sets reasoning effort through a higher-level abstraction covered further down, its results can't be lined up exactly against the other two modes. The repository README spells out what each mode runs.

The model's published numbers

• Model ID: gpt-6-astra
• Context window: 1,050,000 tokens, with up to 128,000 tokens of output
• Input room: roughly 922,000 tokens, though that figure comes from simple subtraction and isn't something OpenAI states
• Input types: text and images; output is text only
• Knowledge cutoff: April 30, 2026
• Endpoints: Chat Completions, Responses and Batch, all supporting streaming, structured outputs, image input and prompt caching
• Reasoning effort: five values, low, medium, high, xhigh and max

Pricing quirks

Once a request goes past 272K input tokens, the whole request is billed at twice the input and cache rate and 1.5 times the output rate, not just the overflow. Batch and Flex processing both cost half the standard rates. A Fast mode also exists at double the applicable rates, which matters for latency-sensitive paths but needs a budget conversation first. In practice the long-context surcharge deserves attention before a repository-sized prompt gets sent, since crossing the line reprices everything in that call. The documentation commits to that price without promising a particular speedup, so no speedup figure gets invented here either.

Two clients in one package

Running dotnet add package OpenAI installs 2.13.0 today. That version reaches the model through two different clients, and only one of them can be used without opting into an experimental API.

The stable chat client

OpenAI.Chat.ChatClient carries no experimental attribute. It has been the production path for some time, and the new model works through it like any other chat model.

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);

The Microsoft.Extensions.AI bridge, shipped in the separate Microsoft.Extensions.AI.OpenAI package, is equally uneventful. That suits teams already standardized on 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);

The AsIChatClient extension for ChatClient has no Experimental attribute either. This is the shape to use while Astra is only answering questions and not invoking tools.

A packaging snag appears when both packages are added. Microsoft.Extensions.AI.OpenAI 10.9.0 depends on OpenAI at 2.12.0 or above but below 2.13.0, while a plain add of OpenAI resolves to 2.13.0, one patch outside that window. The naive approach therefore produces an NU1608 warning about a version outside the constraint. Restore and build still succeed, but pinning the OpenAI version explicitly keeps the restore log clean.

Tool calling lives on the experimental client

The no-tools caveat is more significant than it sounds. OpenAI's release notes for Astra say plainly that tool calling needs the Responses API, and a migration guide exists for anyone currently calling tools through Chat Completions on another model. For this model, every agent-style capability sits on the client that is still gated behind the OPENAI001 diagnostic: function calls, web and file search, the code interpreter, computer use and MCP. The stable client answers questions; the experimental one is where agentic behavior happens. Anyone planning an agent on this model should budget for living with the OPENAI001 suppression, and for API surface that may be renamed between SDK releases.

OpenAI.Responses.ResponsesClient is marked Experimental("OPENAI001") on the whole class. That isn't a stray warning on a single method, so the whole type is off limits until the diagnostic is suppressed, whether in a pragma, a project setting or an editorconfig rule. Trying to construct it stops the compiler until the diagnostic is suppressed.

#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());

Past the convenience overload that takes three strings, which covers tools, reasoning options and structured output, a CreateResponseOptions object is needed. The type name is CreateResponseOptions, not ResponseCreationOptions, which is what the documentation's own prose would suggest.

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,
    },
});

The same Microsoft.Extensions.AI.OpenAI package also ships an AsIChatClient overload for ResponsesClient, and that one carries the same OPENAI001 marker, consistently.

Reasoning effort and the missing enum members

The documented reasoning.effort values for Astra are low, medium, high, xhigh and max. It explicitly does not accept none. That detail has some irony, because both convenience types in the .NET SDK, ChatReasoningEffortLevel for Chat Completions and ResponseReasoningEffortLevel for Responses, expose exactly five static members in 2.13.0: None, Minimal, Low, Medium and High. The value most people reach for out of habit is the one this model refuses.

Neither xhigh nor max has a named member on either type. That doesn't stop the SDK from sending them, only from naming them. Both types are extensible string wrappers rather than true C# enums, and each has a public constructor taking a string. There's direct evidence that this is the intended use. The OpenAI integration inside Microsoft.Extensions.AI does it internally. The Abstractions package, 10.9.0, defines a ReasoningEffort setting with None, Low, Medium, High and ExtraHigh on ChatOptions.Reasoning. The mapping inside the OpenAI integration sends ExtraHigh as a ChatReasoningEffortLevel built from the string xhigh. That literal string was confirmed to be embedded in the shipped 10.9.0 DLL itself, not merely in a newer sample on a main branch. At the IChatClient layer, then, no raw string is needed.

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 } });

The abstraction stops at ExtraHigh, with no equivalent for max. Reaching max, or using xhigh or max against the raw SDK types, means building the string by hand.

ReasoningEffortLevel = new ChatReasoningEffortLevel("max"),

One caveat applies. That call hasn't been fired at a live Astra endpoint to confirm the API answers with a 200 rather than a validation error. Showing that the SDK is willing to send an arbitrary string doesn't show the service will accept it, and only the first claim has been checked.

What's verified and what isn't

Checked against live documentation and the SDK's compiled surface: the model specifications, the pricing card, the class names, the Experimental attribute, and the xhigh string inside the shipped Microsoft.Extensions.AI.OpenAI DLL. Not checked yet: whether the API accepts max with a 200, and whether a real .NET task run at high versus xhigh through the experimental Responses client justifies the doubled token cost. That comparison is the planned follow-up, once the model leaves phased rollout and can be reached without a Daybreak invitation.