GPT-6 Astra for .NET: What Changes in the API, and Where the SDK Hasn't Caught Up

OpenAI released GPT-6 Astra on September 3, 2026 — described as a "new capability level" for computer use, browsing, coding, and long-running agentic work. It's rolling out in phases: first to a limited set of companies in OpenAI's Daybreak cybersecurity program, then to ChatGPT Plus/Pro/Business/Enterprise, the OpenAI API, Microsoft Foundry (Azure), and AWS Bedrock.

Announcement posts don't tell you what actually breaks when you point your .NET code at a new model ID. So I did what I did for Claude Fable 5 a few weeks back: checked the model's real API contract against OpenAI's live docs, then installed the actual OpenAI NuGet package (version 2.13.0, whatever dotnet add package OpenAI gives you today) and inspected what it actually exposes, rather than trusting a blog post's code sample. The gap between the two turned out to be the most useful part of this post.

Code

The three examples below are runnable end to end in a companion repo: gpt-6-astra-dotnet — one mode per client shape (chat, meai, responses), same prompt in all three. meai also sets reasoning effort through the higher-level abstraction covered later in this post, so it isn't a strict like-for-like comparison with the other two; the repo's README says exactly what each mode runs.

What's actually in the model

The model ID is gpt-6-astra. Context window is 1,050,000 tokens, max output is 128,000 — leaving roughly 922,000 for input, though that's my subtraction, not a number OpenAI states outright. Input takes text and images; output is text only. Knowledge cutoff is April 30, 2026. It's reachable through Chat Completions, Responses, and Batch, with streaming, structured outputs, image input, and prompt caching all supported everywhere. Reasoning effort takes five values: low, medium, high, xhigh, max.

Pricing, per the live pricing page

Requests over 272K input tokens are billed at 2x the input/cache rate and 1.5x the output rate for the whole request — not just the overflow. Batch and Flex both run at 50% of standard rates. There's also a Fast mode, priced at 2x the applicable rates — the docs commit to the price, not to a specific speedup, so I'm not going to invent one either.

Calling it from .NET: two paths, one of them experimental

dotnet add package OpenAI currently installs 2.13.0. It exposes GPT-6 Astra through two different clients, and only one of them is available without opting into an experimental API.

The stable path: Chat Completions

OpenAI.Chat.ChatClient carries no experimental attribute — it's been the production path for a while, and GPT-6 Astra 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);

And through Microsoft.Extensions.AI (a separate package, Microsoft.Extensions.AI.OpenAI), the bridge is just as unremarkable, which is the point if you're already standardized on IChatClient the way I described in my Microsoft.Extensions.AI post:

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

OpenAIClientExtensions.AsIChatClient(this ChatClient) has no [Experimental] attribute on it either. This is the shape to reach for as long as Astra is just answering questions, not calling any tools.

One packaging gotcha worth knowing before you add both: Microsoft.Extensions.AI.OpenAI 10.9.0 declares a dependency on OpenAI >= 2.12.0 && < 2.13.0. dotnet add package OpenAI on its own resolves to 2.13.0, one patch outside that range — add both packages the naive way and you'll get an NU1608 warning about a version outside the dependency constraint. It still restores and builds, but it's worth pinning the OpenAI version explicitly if you want a clean restore log.

That caveat about not calling tools isn't a small one. OpenAI's own release notes for Astra say it plainly: tool calling requires the Responses API, and if you're already calling tools through Chat Completions against another model, there's a dedicated migration guide for moving that to Responses. For Astra specifically, function calling, web search, file search, code interpreter, computer use, and MCP all live on the client that's still gated behind OPENAI001 — the stable client answers questions, the experimental one is where the agentic behavior actually lives.

The experimental path: Responses API

OpenAI.Responses.ResponsesClient, the whole class, is marked [Experimental("OPENAI001")]. That's not a stray warning on one method; try to construct it and the compiler stops you cold until you suppress the diagnostic:

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

For anything beyond the three-string convenience overload (tools, reasoning options, structured output), you build a CreateResponseOptions (not ResponseCreationOptions, which is what I'd have guessed from the docs' own prose before checking):

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 AsIChatClient(this ResponsesClient, string) — and that one is [Experimental("OPENAI001")] too, consistently.

The gap: named reasoning levels stop at High

This is the part worth knowing before you plan around it. GPT-6 Astra's documented reasoning.effort values are low, medium, high, xhigh, max — and, worth calling out on its own, Astra explicitly does not accept none. That's a small irony given what's coming next: both convenience enums in the .NET SDK (ChatReasoningEffortLevel for Chat Completions, ResponseReasoningEffortLevel for Responses) expose exactly five static members each in 2.13.0: None, Minimal, Low, Medium, High. The one named value that's fastest to reach for by habit is the one value this model will reject.

Neither xhigh nor max exists as a named member on either type — but that doesn't mean the .NET SDK can't send them, only that it hasn't given them a name yet. Both types are extensible string wrappers rather than real C# enums, each with a public string constructor, and I found direct proof the wrapper is meant to carry exactly this: Microsoft.Extensions.AI's own OpenAI integration already does it internally. Microsoft.Extensions.AI.Abstractions 10.9.0 defines ReasoningEffort as None, Low, Medium, High, ExtraHigh on ChatOptions.Reasoning, and the mapping inside Microsoft.Extensions.AI.OpenAI 10.9.0 sends ExtraHigh as new ChatReasoningEffortLevel("xhigh") — I confirmed the literal UTF-16 string "xhigh" is embedded in the actual 10.9.0 DLL I've got pinned in the companion repo, not just in a newer sample on GitHub's main branch. So this works at the IChatClient layer without writing the raw string yourself:

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

ReasoningEffort stops at ExtraHigh, though — there's no abstraction-level equivalent for max. To reach that one, or to use xhigh/max against the raw SDK types directly, you're back to constructing the string yourself:

ReasoningEffortLevel = new ChatReasoningEffortLevel("max"),

What I haven't done is fire that against a live GPT-6 Astra endpoint to confirm the API accepts max back with a 200 rather than a validation error. Confirming the SDK is willing to send an arbitrary string and confirming Astra is willing to accept it are two different claims, and only the first one is checked here. If you try it before I follow up, I'd genuinely like to know.

What's still open

Everything above (the model's specs, the pricing card, the class names, the [Experimental] attribute, the "xhigh" string embedded in the shipped Microsoft.Extensions.AI.OpenAI DLL) is checked against the live docs and the SDK's actual compiled surface, not the announcement post or someone else's blog snippet. What isn't checked yet: whether GPT-6 Astra's API actually accepts max back with a 200, and a real task run through high versus xhigh through the experimental Responses client to see whether the extra effort is worth the 2x token cost on an actual .NET workload — the same follow-up I still owe from the Fable 5 post. That comparison is next, once GPT-6 Astra is out of phased rollout and reachable without a Daybreak invite.