Startseite / Artikel / GPT-6 Astra aus .NET aufrufen: Chat, Responses und Reasoning Effort

GPT-6 Astra aus .NET aufrufen: Chat, Responses und Reasoning Effort

Was das OpenAI-NuGet-SDK 2.13.0 für GPT-6 Astra bereitstellt: stabiler Chat-Client, experimenteller Responses-Client, Preis-Eigenheiten und Reasoning Effort xhigh oder max.

1435 Wörter

OpenAI hat GPT-6 Astra am 3. September 2026 angekündigt und positioniert das Modell als Fortschritt bei Computer-Use, Web-Browsing, Programmierung und lang laufender Agentenarbeit. Der Zugang kommt in Etappen. Zuerst ist eine begrenzte Gruppe von Unternehmen aus dem Cybersecurity-Programm Daybreak dran. Danach erreicht das Modell ChatGPT Plus, Pro, Business und Enterprise, die OpenAI-API, Microsoft Foundry auf Azure und AWS Bedrock.

Ein Launch-Post verrät wenig darüber, was kaputtgeht, sobald ein .NET-Projekt auf einen neuen Modellnamen zeigt. Sinnvoll ist es, den veröffentlichten API-Vertrag des Modells mit der aktuellen Dokumentation abzugleichen, dann das echte OpenAI-NuGet-Paket zu installieren (zum Testzeitpunkt Version 2.13.0) und nachzulesen, was es tatsächlich bereitstellt, statt ein Beispiel aus einem Blog abzuschreiben. Spannend ist genau der Abstand zwischen diesen beiden Quellen. Die Doku beschreibt Absichten; eine kompilierte Assembly zeigt, was ein Entwickler wirklich tippen kann, welche Attribute die Kompilierung blockieren und welche Enum-Member existieren.

In einem begleitenden Repository liegen drei lauffähige Beispiele, eines pro Client-Stil: chat, meai und responses. Alle drei schicken denselben Prompt. Weil der meai-Modus den Reasoning Effort über eine höhere Abstraktion setzt (dazu weiter unten), lassen sich seine Ergebnisse nicht exakt neben die der anderen beiden Modi legen. Das README des Repositorys beschreibt, was jeder Modus ausführt.

Die veröffentlichten Eckdaten des Modells

  • Modell-ID: gpt-6-astra
  • Kontextfenster: 1.050.000 Tokens, davon bis zu 128.000 Tokens Ausgabe
  • Platz für Eingaben: rund 922.000 Tokens, wobei diese Zahl aus einer einfachen Subtraktion stammt und nicht von OpenAI angegeben wird
  • Eingabetypen: Text und Bilder; die Ausgabe ist reiner Text
  • Wissensstand: 30. April 2026
  • Endpunkte: Chat Completions, Responses und Batch, alle mit Streaming, Structured Outputs, Bildeingabe und Prompt-Caching
  • Reasoning Effort: fünf Werte, low, medium, high, xhigh und max

Eigenheiten bei den Preisen

Überschreitet eine Anfrage 272K Eingabe-Tokens, wird die gesamte Anfrage zum doppelten Eingabe- und Cache-Preis und zum 1,5-fachen Ausgabepreis abgerechnet, nicht nur der Überhang. Batch- und Flex-Verarbeitung kosten jeweils die Hälfte der Standardpreise. Außerdem gibt es einen Fast-Modus zum doppelten Preis, der für latenzkritische Pfade relevant ist, aber vorher ein Gespräch übers Budget braucht. In der Praxis sollte man den Langkontext-Aufschlag im Blick haben, bevor ein Prompt in Repository-Größe rausgeht, denn das Überschreiten der Grenze verteuert alles in diesem Aufruf. Die Dokumentation legt sich auf diesen Preis fest, verspricht aber keine bestimmte Beschleunigung, deshalb wird hier auch keine Zahl dazu erfunden.

Zwei Clients in einem Paket

dotnet add package OpenAI installiert heute 2.13.0. Diese Version erreicht das Modell über zwei verschiedene Clients, und nur einer davon lässt sich nutzen, ohne sich auf eine experimentelle API einzulassen.

Der stabile Chat-Client

OpenAI.Chat.ChatClient trägt kein Experimental-Attribut. Er ist seit einiger Zeit der Weg für den Produktivbetrieb, und das neue Modell funktioniert darüber wie jedes andere Chat-Modell.

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

Die Brücke zu Microsoft.Extensions.AI, ausgeliefert im separaten Paket Microsoft.Extensions.AI.OpenAI, ist ebenso unspektakulär. Das passt zu Teams, die bereits auf IChatClient standardisiert haben.

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

Auch die Erweiterung AsIChatClient für ChatClient hat kein Experimental-Attribut. Das ist die Variante der Wahl, solange Astra nur Fragen beantwortet und keine Tools aufruft.

Fügt man beide Pakete hinzu, hakt es bei den Versionen. Microsoft.Extensions.AI.OpenAI 10.9.0 verlangt OpenAI ab 2.12.0, aber unter 2.13.0, während ein schlichtes Hinzufügen von OpenAI auf 2.13.0 auflöst, also einen Patch außerhalb dieses Fensters. Der naive Weg erzeugt deshalb eine NU1608-Warnung wegen einer Version außerhalb der Einschränkung. Restore und Build gelingen trotzdem, aber wer die OpenAI-Version explizit festlegt, hält das Restore-Log sauber.

Tool-Calling steckt im experimentellen Client

Der Hinweis auf fehlende Tools wiegt schwerer, als er klingt. In den Release Notes zu Astra schreibt OpenAI unmissverständlich, dass Tool-Calling die Responses-API braucht, und es gibt eine Migrationsanleitung für alle, die Tools bisher über Chat Completions mit einem anderen Modell aufrufen. Bei diesem Modell liegen sämtliche agentischen Fähigkeiten auf dem Client, der weiterhin hinter der Diagnose OPENAI001 steckt: Funktionsaufrufe, Web- und Dateisuche, der Code Interpreter, Computer-Use und MCP. Der stabile Client beantwortet Fragen, das agentische Verhalten findet im experimentellen statt. Wer einen Agenten auf diesem Modell plant, sollte einkalkulieren, mit der Unterdrückung von OPENAI001 zu leben und mit einer API-Oberfläche, die zwischen SDK-Releases umbenannt werden kann.

OpenAI.Responses.ResponsesClient ist als ganze Klasse mit Experimental("OPENAI001") markiert. Das ist keine verirrte Warnung an einer einzelnen Methode: Der gesamte Typ ist tabu, bis die Diagnose unterdrückt wird, sei es per Pragma, Projekteinstellung oder editorconfig-Regel. Der Versuch, ihn zu instanziieren, stoppt den Compiler, solange die Diagnose nicht unterdrückt ist.

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

Jenseits der bequemen Überladung mit drei Strings, also für Tools, Reasoning-Optionen und strukturierte Ausgaben, braucht man ein CreateResponseOptions-Objekt. Der Typ heißt CreateResponseOptions und nicht ResponseCreationOptions, wie es der Fließtext der Dokumentation nahelegen würde.

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

Dasselbe Paket Microsoft.Extensions.AI.OpenAI liefert auch eine AsIChatClient-Überladung für ResponsesClient, und die trägt konsequenterweise dieselbe OPENAI001-Markierung.

Reasoning Effort und die fehlenden Enum-Member

Die dokumentierten reasoning.effort-Werte für Astra sind low, medium, high, xhigh und max. none akzeptiert das Modell ausdrücklich nicht. Das hat eine gewisse Ironie, denn beide Komforttypen im .NET-SDK, ChatReasoningEffortLevel für Chat Completions und ResponseReasoningEffortLevel für Responses, bieten in 2.13.0 genau fünf statische Member: None, Minimal, Low, Medium und High. Ausgerechnet der Wert, zu dem die meisten aus Gewohnheit greifen, wird von diesem Modell abgelehnt.

Weder xhigh noch max hat in einem der beiden Typen einen benannten Member. Das hindert das SDK nicht daran, sie zu senden, nur daran, sie zu benennen. Beide Typen sind erweiterbare String-Wrapper statt echter C#-Enums, und jeder hat einen öffentlichen Konstruktor, der einen String annimmt. Es gibt einen direkten Beleg, dass genau das so gedacht ist. Die OpenAI-Integration in Microsoft.Extensions.AI macht es intern so. Das Abstractions-Paket 10.9.0 definiert eine ReasoningEffort-Einstellung mit None, Low, Medium, High und ExtraHigh in ChatOptions.Reasoning. Das Mapping in der OpenAI-Integration sendet ExtraHigh als ChatReasoningEffortLevel, das aus dem String xhigh gebaut wird. Bestätigt wurde, dass dieser literale String in der ausgelieferten DLL 10.9.0 selbst steckt und nicht nur in einem neueren Beispiel auf einem Main-Branch. Auf der IChatClient-Ebene braucht man also keinen rohen String.

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

Die Abstraktion endet bei ExtraHigh, für max gibt es keine Entsprechung. Wer max erreichen oder xhigh bzw. max mit den rohen SDK-Typen nutzen will, muss den String von Hand bauen.

ReasoningEffortLevel = new ChatReasoningEffortLevel("max"),

Eine Einschränkung gilt. Dieser Aufruf wurde noch nicht gegen einen echten Astra-Endpunkt abgefeuert, um zu bestätigen, dass die API mit 200 statt mit einem Validierungsfehler antwortet. Dass das SDK bereit ist, einen beliebigen String zu senden, heißt nicht, dass der Dienst ihn annimmt, und geprüft wurde nur Ersteres.

Was geprüft ist und was nicht

Gegen die aktuelle Dokumentation und die kompilierte Oberfläche des SDK geprüft: die Modellspezifikationen, die Preisübersicht, die Klassennamen, das Experimental-Attribut und der xhigh-String in der ausgelieferten DLL von Microsoft.Extensions.AI.OpenAI. Noch nicht geprüft: ob die API max mit 200 akzeptiert und ob eine echte .NET-Aufgabe mit high gegenüber xhigh über den experimentellen Responses-Client die doppelten Token-Kosten rechtfertigt. Dieser Vergleich ist als Fortsetzung geplant, sobald das Modell den gestaffelten Rollout verlässt und ohne Daybreak-Einladung erreichbar ist.