DEV Community: Taswar Bhatti

Cohere Rerank v5 Pro and Fast for C# Developers

Taswar Bhatti — Fri, 30 Oct 2026 06:23:52 +0000

Most retrieval-augmented apps follow the same path. A vector search returns 30 or 50 passages, and the chat model reads all of them. Some of those passages are close but wrong. Some are right but buried. The model spends tokens on the noise and sometimes answers from the wrong paragraph.

A reranker sits between the search and the chat model. It reads the query and the candidate passages together, scores each one, and returns them in order of relevance. Your code decides how many to keep and where to cut.

Cohere Rerank v5 is now in Microsoft Foundry in two versions, Pro and Fast, and both add a feature called Context Focus. This post covers when each one fits, a table of the trade-offs, and a C# console app that calls both.

If you missed it, I covered the Cohere family in Foundry earlier in Cohere Command A+ Lands in Microsoft Foundry. Command A+ is the chat model that pairs well with a reranker like this one.

Sources for the model details below: the Foundry announcement (October 21, 2026), the Cohere Rerank 5 post, and the Cohere Rerank v5 changelog. I've used only one figure from Cohere's evaluations, the calibration error, because it changes how you set thresholds. Your own queries and documents will tell you more.

What you get

Three things from the Rerank 5 release matter for .NET apps:

Two tiers. Pro is tuned for ranking quality, especially reasoning-heavy queries and long or specialized documents. Fast is tuned for low latency and high throughput.
Calibrated scores. The relevance_score is meant to behave the same way across queries and domains. Cohere suggests a cut-off of 0.50 for Pro and 0.45 for Fast, so one number can filter results before they reach the model.
Context Focus. An optional setting that returns the most relevant character spans inside each document, so you can pass a few sentences to the chat model instead of whole pages. It is off by default.

The Foundry model cards list both models as text classification, in preview, for over 100 languages, with text and image input.

The numbers that matter for design

	Rerank v5 Pro	Rerank v5 Fast
Foundry model name	`Cohere-rerank-v5-pro`	`Cohere-rerank-v5-fast`
API model ID	`rerank-v5.0-pro`	`rerank-v5.0-fast`
Languages	Over 100	Over 100
Score cut-off suggested by Cohere	0.50	0.45
Expected Calibration Error (lower is better)	~0.06 (Rerank 4 Pro: ~0.38)	~0.06
Cohere API price	$0.05 per 1M tokens	$0.02 per 1M tokens
Status on Foundry	Preview	Preview

Calibration is what makes one cut-off work across queries. Expected Calibration Error (ECE) measures how far a score sits from the real chance that a passage is useful. Cohere reports about 0.06 for both Rerank 5 models, against 0.38 for Rerank 4 Pro on human judgments (0.31 on NIST judgments). In practice, a Rerank 5 score of 0.7 is much closer to a real 70% chance of being useful, so a fixed threshold filters the same way on every query. These are Cohere's own figures from the Rerank 5 post.

⚠️ Uncertain: Foundry price. Cohere's own price is listed above. The Foundry model cards link to a pricing page, which is in-correct; thus rather than showing a rate, confirm the Foundry rate before you try out the samples.

Where each one fits

These are the situations where reranking earns its place. Each one has a clear reason to rerank.

1. Grounding a RAG answer

Your vector search returns 40 passages. Rerank them, keep the top 3 that clear the threshold, and send only those to the chat model. The answer is grounded in fewer, better passages, and the prompt stays small.

Use Pro here. A wrong passage in the final three is expensive, because the chat model will quote it confidently.

2. Agents that search many times per task

An agent might run 5 to 10 searches before it answers. Each search returns a candidate list that needs ordering. The latency adds up across those calls.

Use Fast here. The quality gap matters less than the time per call, and the agent can run more searches inside the same budget.

3. Help-desk article matching

A customer writes "I was charged twice this month". Your help center has a few hundred articles. Vector search finds the likely ones, and the reranker decides which article to show first.

Use Fast for high volume, and check a sample of matches with Pro during setup.

4. Multilingual support content

Support articles are often written in one language and asked about in another. Both models cover over 100 languages, so the same reranker can order English, Spanish, German, and Japanese passages against one query.

Test both on your own languages. Cohere's language claims are general, and your articles may behave differently.

5. Semi-structured records

Product catalogs, incident logs, and CRM entries are often JSON or tables. Cohere's guidance is to pass each record as a YAML string so the field names stay with the values. That gives the reranker more to match on. Plain JSON may also work, so test both formats on your own records before you settle on one.

Use Pro when records are long or specialized, such as contracts or clinical notes.

6. Answer or abstain

This is the use case I'd build first. When no candidate clears the threshold, the app says "I do not know" and does not call the chat model at all. The calibrated score makes that cut-off possible without guessing.

Either model works. Set the threshold, then test it against queries you know have no answer in your data.

Pros and cons

Model	Good for	Pros	Cons	Pick it when
Pro	RAG grounding, long or specialized documents, reasoning-heavy queries	Ranks complex queries better, stronger on long documents	Slower and more expensive per call than Fast	The top few results must be right, and a wrong pick costs more than the extra latency
Fast	Agents with many searches, high-volume help-desk matching	Low latency, high throughput, lower price	Less accurate on hard or long documents	Volume and speed matter more than the last few points of quality
Neither	Tiny candidate lists you can scan in code	No extra call, no extra cost	Does not scale to large lists or fuzzy queries	You have fewer than about five candidates

Two things a reranker does not do:

It does not search. You pass it the candidates. Keep your vector or keyword search for finding them.
It does not write. Summaries, rewrites, and answers still belong to the chat model. The reranker decides what the chat model reads.

Calling Rerank v5 from C

The complete project is on GitHub at taswar/Cohere-Rerank-V5-Pro-Fast-Csharp-Sample. Clone it if you want to run the code without copying it from this post.

The sample reads an endpoint for Pro and one for Fast. When both models are deployed in the same Foundry resource, the two endpoints are the same URL. Each one takes an API key if you set one. If you leave the key out, the app signs in with Entra ID through DefaultAzureCredential, so run az login first. The sample sends the same query to both and prints each result with a keep or drop decision based on that model's cut-off.

The request goes to {endpoint}/providers/cohere/v2/rerank, the Foundry route for Cohere models, with a bearer token in the Authorization header. The token is your API key if you set one, or an Entra ID token if you don't. The model field takes the Foundry model name, Cohere-rerank-v5-pro or Cohere-rerank-v5-fast. If your deployment expects a different header or path, the code is the only part to change.

Create the project on .NET 10 and add the configuration packages:

dotnet new console -n Cohere-Rerank-v5-CSharp-Sample
cd Cohere-Rerank-v5-CSharp-Sample
dotnet add package Azure.Identity
dotnet add package Microsoft.Extensions.Configuration.UserSecrets
dotnet add package Microsoft.Extensions.Configuration.EnvironmentVariables
dotnet user-secrets init

Store the endpoints with user secrets. Use the base URL of your Foundry resource, with no path. The two API key lines are optional, so leave them out to use Entra ID:

dotnet user-secrets set "COHERE_RERANK_PRO_ENDPOINT" "https://YOUR-RESOURCE.services.ai.azure.com"
dotnet user-secrets set "COHERE_RERANK_PRO_API_KEY" "your-pro-key"
dotnet user-secrets set "COHERE_RERANK_FAST_ENDPOINT" "https://YOUR-RESOURCE.services.ai.azure.com"
dotnet user-secrets set "COHERE_RERANK_FAST_API_KEY" "your-fast-key"

To check what the app will read, run:

dotnet user-secrets list

The project file is Cohere-Rerank-v5-CSharp-Sample.csproj. The UserSecretsId is the one dotnet user-secrets init writes:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net10.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <UserSecretsId>b9934625-9fc9-4364-ae1e-0107ce65b680</UserSecretsId>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Azure.Identity" Version="1.21.0" />
    <PackageReference Include="Microsoft.Extensions.Configuration.EnvironmentVariables" Version="10.0.12" />
    <PackageReference Include="Microsoft.Extensions.Configuration.UserSecrets" Version="10.0.12" />
  </ItemGroup>

</Project>

Then Program.cs:

using System.Diagnostics;
using System.Net.Http.Headers;
using System.Text;
using System.Text.Json;
using System.Text.Json.Nodes;
using Azure.Core;
using Azure.Identity;
using Microsoft.Extensions.Configuration;

var config = new ConfigurationBuilder()
    .AddUserSecrets<Program>()
    .AddEnvironmentVariables()
    .Build();

var credential = new DefaultAzureCredential();

var pro = ReadModel(config, "Pro", "Cohere-rerank-v5-pro", 0.50);
var fast = ReadModel(config, "Fast", "Cohere-rerank-v5-fast", 0.45);

var query = "What is the refund window for annual plans?";
var documents = new[]
{
    "Monthly plans can be cancelled at any time. The change takes effect at the end of the billing period.",
    "Annual plans can be refunded in full within 30 days of purchase. After 30 days, the remaining months are prorated.",
    "Refund requests are submitted from the billing page under Invoices.",
    "Our offices are closed on public holidays in Ottawa and Toronto.",
    "Enterprise contracts follow the terms in the signed order form, not this page.",
    "Gift cards cannot be refunded but can be transferred to another account."
};

using var http = new HttpClient { Timeout = TimeSpan.FromSeconds(60) };

foreach (var model in new[] { pro, fast })
{
    var stopwatch = Stopwatch.StartNew();
    var results = await RerankAsync(http, credential, model, query, documents, topN: 3);
    stopwatch.Stop();

    Console.WriteLine($"{model.Name} ({stopwatch.ElapsedMilliseconds} ms, threshold {model.Threshold:0.00})");
    foreach (var result in results)
    {
        var decision = result.Score >= model.Threshold ? "keep" : "drop";
        Console.WriteLine($"  {result.Score:0.00}  {decision}  {documents[result.Index]}");
    }

    var kept = results.Count(r => r.Score >= model.Threshold);
    Console.WriteLine(kept == 0
        ? "  No passage cleared the threshold. Answer 'I do not know' instead of guessing."
        : $"  {kept} passage(s) passed to the chat model.");
    Console.WriteLine();
}

static RerankModel ReadModel(IConfiguration config, string name, string modelId, double threshold)
{
    var key = name.ToUpperInvariant();
    var endpoint = config[$"COHERE_RERANK_{key}_ENDPOINT"]
        ?? throw new InvalidOperationException($"Set COHERE_RERANK_{key}_ENDPOINT with dotnet user-secrets.");
    // The API key is optional. Without one, the app signs in with Entra ID through az login.
    var apiKey = config[$"COHERE_RERANK_{key}_API_KEY"];

    return new RerankModel(name, modelId, endpoint.TrimEnd('/'), apiKey, threshold);
}

static async Task<List<RerankResult>> RerankAsync(
    HttpClient http, TokenCredential credential, RerankModel model, string query,
    IReadOnlyList<string> documents, int topN)
{
    var body = new JsonObject
    {
        ["model"] = model.ModelId,
        ["query"] = query,
        ["top_n"] = topN,
        ["documents"] = new JsonArray(documents.Select(d => (JsonNode)d).ToArray())
    };

    using var request = new HttpRequestMessage(HttpMethod.Post, $"{model.Endpoint}/providers/cohere/v2/rerank");
    if (!string.IsNullOrWhiteSpace(model.ApiKey))
    {
        request.Headers.Authorization = new AuthenticationHeaderValue("Bearer", model.ApiKey);
    }
    else
    {
        var token = await credential.GetTokenAsync(
            new TokenRequestContext(["https://cognitiveservices.azure.com/.default"]),
            CancellationToken.None);
        request.Headers.Authorization = new AuthenticationHeaderValue("Bearer", token.Token);
    }

    // StringContent sets a fixed Content-Length; JsonContent uses chunked encoding.
    request.Content = new StringContent(body.ToJsonString(), Encoding.UTF8, "application/json");

    using var response = await http.SendAsync(request);
    var text = await response.Content.ReadAsStringAsync();
    if (!response.IsSuccessStatusCode)
    {
        throw new InvalidOperationException($"{model.Name} returned {(int)response.StatusCode}: {text}");
    }

    using var doc = JsonDocument.Parse(text);
    var results = new List<RerankResult>();
    foreach (var item in doc.RootElement.GetProperty("results").EnumerateArray())
    {
        results.Add(new RerankResult(
            item.GetProperty("index").GetInt32(),
            item.GetProperty("relevance_score").GetDouble()));
    }

    return results;
}

record RerankModel(string Name, string ModelId, string Endpoint, string? ApiKey, double Threshold);

record RerankResult(int Index, double Score);

Run it:

dotnet run

Run it on your own query and documents before you copy the thresholds. The output shows each passage with its score, the keep or drop decision, and the time per call. Your timings and scores will differ from anyone else's, so record them alongside your data.

Output

Pro (2512 ms, threshold 0.50)
  0.81  keep  Annual plans can be refunded in full within 30 days of purchase. After 30 days, the remaining months are prorated.
  0.13  drop  Refund requests are submitted from the billing page under Invoices.
  0.06  drop  Monthly plans can be cancelled at any time. The change takes effect at the end of the billing period.
  1 passage(s) passed to the chat model.

Fast (2138 ms, threshold 0.45)
  0.81  keep  Annual plans can be refunded in full within 30 days of purchase. After 30 days, the remaining months are prorated.
  0.06  drop  Refund requests are submitted from the billing page under Invoices.
  0.05  drop  Monthly plans can be cancelled at any time. The change takes effect at the end of the billing period.
  1 passage(s) passed to the chat model.

The sample doesn't use Context Focus yet. To try it, add a relevant_spans object to the request body, with mode set to enabled and a threshold and max_spans. Cohere's changelog shows the shape, and the spans come back in each result.

Final thoughts

The reranker is the cheapest quality step in a RAG pipeline. It doesn't write anything, and it doesn't need your whole index. You pass it the candidates your search already found, and it tells you which ones matter.

Start with Fast if you run many searches, and Pro for answers where the top passage has to be right. Whichever you pick, set the threshold on your own data, and build the "I do not know" path before you tune anything else. 🙂

Resources

Decisions API in Azure OpenAI: A C# Walkthrough

Taswar Bhatti — Sun, 25 Oct 2026 19:02:17 +0000

Decisions API in Azure OpenAI: A C# Walkthrough

Recently I wrote about Microsoft-Decision-1, a model that scores a fixed set of options instead of writing text. That post used a Microsoft provider route. This week the Azure OpenAI Decisions API went generally available in Microsoft Foundry, and it solves the same problem through the Azure OpenAI resource you may already have.

Every agent makes small judgments: which team owns this ticket, does the customer want a refund, how severe is this issue, should the workflow continue or stop. Those steps still get sent to a chat model, which means you ask for JSON, parse text that almost looks like JSON, and trust a confidence number the model never really returned.

The Decisions API is built for those judgments. It evaluates text or images and returns a typed answer: a probability, a choice from your list, or a score against your rubric.

Sources for the numbers and endpoint details below: the Foundry announcement (October 22, 2026) and the Decisions API how-to. The official examples are in Python, JavaScript, and REST. This post gives you the same REST call in C#.

What the API returns

The announcement describes three outcomes, one per question type:

Probability: whether a condition is true, with a value from 0 to 1
Choice: one value from a list you define
Score: a position on an ordered rubric

You send one shared input and a questions array. Each question has a unique name, so you can match each answer back to its question. You get back an answers array in the same order, plus token usage.

The endpoint is:

POST https://YOUR-RESOURCE-NAME.openai.azure.com/openai/v1/decisions

The model field takes your deployment name. The docs use gpt-6-luna, which is currently the only supported model. It works with either an API key in the api-key header or a Microsoft Entra ID bearer token.

Two things to remember from the docs:

A refusal is a separate answer type. It is not a low probability, so handle it as its own case.
Each request supports up to 400 questions. Questions in one request all see the same input.

How this differs from Microsoft-Decision-1

	Microsoft-Decision-1 (previous post)	Azure OpenAI Decisions API (this post)
Endpoint	`{resource}/providers/microsoft/v1/systemone`	`{resource}.openai.azure.com/openai/v1/decisions`
Model field	Your Decision-1 deployment	Your `gpt-6-luna` deployment
Question types	`noul`, `choice`, `score`	`predicate`, `choice`, `score`
Auth	Entra ID	API key or Entra ID
SDK examples	None in the quickstart, C# calls `HttpClient`	Python, JavaScript, REST

Both return typed answers. The sample in this post uses the Azure OpenAI route, so the code and the JSON match the official docs.

Calling it from C

The official docs don't show a C# SDK for this endpoint, so the sample calls it with HttpClient. It uses the same pattern as the Decision-1 demo: Azure.Identity for Entra ID, with an API key as a shortcut when one is set.

The complete project is on GitHub at taswar/OpenAI-DecisionApi-CSharp-Sample. Clone it if you want to run the code without copying it from this post.

Create the project on .NET 10, then add the packages. The packages let the app read settings from user secrets, so the endpoint and key stay out of your shell and out of the code:

dotnet new console -n OpenAI-DecisionApi-CSharp-Sample
cd OpenAI-DecisionApi-CSharp-Sample
dotnet add package Azure.Identity
dotnet add package Microsoft.Extensions.Configuration.UserSecrets
dotnet add package Microsoft.Extensions.Configuration.EnvironmentVariables
dotnet user-secrets init

dotnet user-secrets init adds a UserSecretsId to the project file. Keep it as it is.

Store your settings with user secrets from the project folder. Use the base URL only, with no path:

dotnet user-secrets set "AZURE_OPENAI_ENDPOINT" "https://YOUR-RESOURCE-NAME.openai.azure.com"
dotnet user-secrets set "AZURE_OPENAI_DEPLOYMENT" "gpt-6-luna"
dotnet user-secrets set "AZURE_OPENAI_API_KEY" "your-key-here"

The deployment name is optional, and the app defaults to gpt-6-luna. If you leave out AZURE_OPENAI_API_KEY, the app uses DefaultAzureCredential instead, so az login works.

To check what the app will read, run:

dotnet user-secrets list

The project file is OpenAI-DecisionApi-CSharp-Sample.csproj. The UserSecretsId value is the one dotnet user-secrets init writes in your copy:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net10.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <UserSecretsId>91102972-0612-452c-90b4-a2dfa5578168</UserSecretsId>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Azure.Identity" Version="1.21.0" />
    <PackageReference Include="Microsoft.Extensions.Configuration.EnvironmentVariables" Version="10.0.12" />
    <PackageReference Include="Microsoft.Extensions.Configuration.UserSecrets" Version="10.0.12" />
  </ItemGroup>

</Project>

Then Program.cs. The ticket and the three questions are the same ones the official Python example uses, so the output can be compared directly:

using System.Net.Http.Headers;
using System.Text;
using System.Text.Json;
using System.Text.Json.Nodes;
using Azure.Core;
using Azure.Identity;
using Microsoft.Extensions.Configuration;

var config = new ConfigurationBuilder()
    .AddUserSecrets<Program>()
    .AddEnvironmentVariables()
    .Build();

var endpoint = (config["AZURE_OPENAI_ENDPOINT"]
    ?? throw new InvalidOperationException(
        "Set AZURE_OPENAI_ENDPOINT with dotnet user-secrets, for example https://YOUR-RESOURCE-NAME.openai.azure.com"))
    .TrimEnd('/');
var deployment = config["AZURE_OPENAI_DEPLOYMENT"] ?? "gpt-6-luna";
var apiKey = config["AZURE_OPENAI_API_KEY"];

var ticket = "I was charged twice for my order. Please return the extra charge.";

var body = new JsonObject
{
    ["model"] = deployment,
    ["input"] = ticket,
    ["questions"] = new JsonArray
    {
        new JsonObject
        {
            ["type"] = "predicate",
            ["name"] = "refund_requested",
            ["instructions"] = "Does the customer ask for a refund?"
        },
        new JsonObject
        {
            ["type"] = "choice",
            ["name"] = "department",
            ["instructions"] = "Which department should handle this complaint?",
            ["choices"] = new JsonArray
            {
                new JsonObject { ["value"] = "billing", ["description"] = "Payments and refunds." },
                new JsonObject { ["value"] = "technical", ["description"] = "Product problems." },
                new JsonObject { ["value"] = "shipping", ["description"] = "Delivery and tracking." },
                new JsonObject { ["value"] = "other", ["description"] = "All other requests." }
            }
        },
        new JsonObject
        {
            ["type"] = "score",
            ["name"] = "severity",
            ["instructions"] = "How severe is this issue?",
            ["levels"] = new JsonArray
            {
                new JsonObject { ["label"] = "Cosmetic", ["description"] = "No lost functionality." },
                new JsonObject { ["label"] = "Workaround available", ["description"] = "A task fails, but another way works." },
                new JsonObject { ["label"] = "Fully blocked", ["description"] = "A task fails with no workaround." }
            }
        }
    }
};

using var decision = await PostDecisionAsync(endpoint, apiKey, body);

foreach (var answer in decision.RootElement.GetProperty("answers").EnumerateArray())
{
    PrintAnswer(answer);
}

static async Task<JsonDocument> PostDecisionAsync(string endpoint, string? apiKey, JsonObject body)
{
    using var http = new HttpClient { Timeout = TimeSpan.FromSeconds(60) };
    using var request = new HttpRequestMessage(HttpMethod.Post, $"{endpoint}/openai/v1/decisions");

    if (!string.IsNullOrWhiteSpace(apiKey))
    {
        request.Headers.Add("api-key", apiKey);
    }
    else
    {
        var credential = new DefaultAzureCredential();
        var token = await credential.GetTokenAsync(
            new TokenRequestContext(["https://cognitiveservices.azure.com/.default"]),
            CancellationToken.None);
        request.Headers.Authorization = new AuthenticationHeaderValue("Bearer", token.Token);
    }

    // StringContent sets a fixed Content-Length; JsonContent uses chunked encoding.
    request.Content = new StringContent(body.ToJsonString(), Encoding.UTF8, "application/json");

    using var response = await http.SendAsync(request);
    var text = await response.Content.ReadAsStringAsync();
    if (!response.IsSuccessStatusCode)
    {
        throw new InvalidOperationException(
            $"Decisions API returned {(int)response.StatusCode}: {text}");
    }

    return JsonDocument.Parse(text);
}

static void PrintAnswer(JsonElement answer)
{
    var type = answer.GetProperty("type").GetString();
    var name = answer.TryGetProperty("name", out var nameValue) ? nameValue.GetString() : null;

    switch (type)
    {
        case "predicate":
            var probability = answer.GetProperty("probability").GetDouble();
            Console.WriteLine($"{name}: {probability:P0} true");
            break;

        case "choice":
            var choice = answer.GetProperty("choice").GetString();
            var choiceConfidence = answer.GetProperty("confidence").GetDouble();
            Console.WriteLine($"{name}: {choice} (confidence {choiceConfidence:P0})");
            break;

        case "score":
            var score = answer.GetProperty("score").GetDouble();
            var scoreConfidence = answer.GetProperty("confidence").GetDouble();
            Console.WriteLine($"{name}: {score:0.00} (confidence {scoreConfidence:P0})");
            break;

        case "refusal":
            // A refusal is not a low probability. Send this one to a person.
            Console.WriteLine($"{name ?? "(unnamed)"}: refused, send to a person");
            break;

        default:
            Console.WriteLine($"Unexpected answer: {answer.GetRawText()}");
            break;
    }
}

Run it:

dotnet run

The output should look like this. Your numbers will differ:

refund_requested: 100% true
department: billing (confidence 100%)
severity: 0.98 (confidence 13%)

What changed in the code

The first thing to notice is that all three questions go out in one request. The ticket is evaluated once, and the answers come back together. That matters when a workflow makes many small decisions.

The score answer is a weighted average of the level positions. A score of 0.98 sits close to "Workaround available" (position 1), but the confidence is only 13%. That low confidence is the signal to act on. Send this ticket to a person rather than trust the score. Use the score for thresholds and ordering, not as an exact label.

The refusal branch is there on purpose. The docs are clear that a refusal is different from a predicate answer with a low probability, so the code gives it its own case.

I kept the code as one file so it reads top to bottom. In a real service you would move the request into its own class and add a retry policy.

Where it fits

Use it when the next step is a closed choice:

Route a support ticket before a person or a bigger model sees it
Decide whether an agent should continue, retry, or hand off
Check a draft against a rubric before it goes out
Gate a tool call, such as one that touches production data

Keep a chat model for anything that needs words, such as summaries, rewrites, or explanations. The decision model decides, and the chat model writes.

Set your own thresholds with a labeled set of tickets from your application. The announcement and the docs both describe these probabilities as estimates, so do not treat 0.95 as a guarantee.

Final thoughts

The Decisions API is the same idea as Microsoft-Decision-1, but it sits on the Azure OpenAI resource with gpt-6-luna and the three question types from the docs. If your team already has an Azure OpenAI resource, this is the easier starting point.

Try it against your own tickets before you change any routing. If your team already has a classifier, put this next to it and compare the answers on the same data. 🙂

Resources

Building AI features in C#? I write about practical, no-hype prompt engineering and Azure AI patterns for .NET developers. Check out Prompt Engineering for .NET Developers — free, no Python required. Also subscribe to my mailing list for the latest blogs, tips and tricks I share.

Using Grok 4.7 with C#

Taswar Bhatti — Mon, 19 Oct 2026 19:37:39 +0000

xAI just announced that Grok 4.7 so I wanted to try their model with C#. This isn't another incremental update—it's a model specifically architected for advanced reasoning, long-horizon problem solving, software engineering, and agentic workflows. For .NET developers building enterprise applications with AI capabilities, here's what actually matters and how to put it to work.

What Grok 4.7 Actually Is

Grok 4.7 is xAI's latest model release, built from the ground up for scenarios where you need an AI that can think through multi-step problems, use tools effectively, and maintain context across extended tasks. The key differentiators:

Deep reasoning capabilities. Trained extensively on complex problem-solving tasks requiring planning, analysis, and synthesis—not just pattern matching or next-token prediction.
Up to 500K tokens of context, according to the current Grok deployment guide. Input and output share that budget; actual use still depends on deployment limits and cost.
Software engineering focus. Benchmarked at 71.0% on DeepSWEv1.1—a rigorous evaluation across 113 original, long-horizon software engineering tasks spanning 91 active repositories and five languages. That's not a toy benchmark; it's real engineering work.
Enterprise-grade deployment. Available through Global Standard and US Data Zone Standard in Foundry, with familiar Chat Completions and Responses APIs, tool calling support, streaming, Microsoft Entra ID authentication, and API keys.

The model was also evaluated on CADGenBench (generating executable CAD geometry from design requirements), reflecting xAI's broader engineering focus beyond just code generation. But for .NET developers, the software engineering and knowledge work capabilities are what matter most right now.

Set up a .NET console app

Deploy grok-4.7 in a supported Microsoft Foundry region. Copy the resource endpoint (https://<resource>.services.ai.azure.com) and the deployment name (which may differ from grok-4.7) from the Foundry portal. You need permission to deploy the model and a role that allows calling the deployed endpoint. The examples below use the official OpenAI .NET SDK pointed at the documented /openai/v1 Foundry endpoint, authenticating with Microsoft Entra ID so no API keys live in source.

With the .NET 10 SDK installed, create a project, add the SDK packages, and store the endpoint and deployment name in user secrets:

dotnet new console -n Grok-4.7-Demo-Csharp -f net10.0
cd Grok-4.7-Demo-Csharp
dotnet add package OpenAI
dotnet add package Azure.Identity
dotnet add package Microsoft.Extensions.Configuration.UserSecrets
dotnet user-secrets init
dotnet user-secrets set "Foundry:Endpoint" "https://YOUR-RESOURCE.services.ai.azure.com"
dotnet user-secrets set "Foundry:Deployment" "YOUR-DEPLOYMENT-NAME"

Authentication goes through Microsoft Entra ID via DefaultAzureCredential, so there are no keys to store or leak. For local development, sign in once with az login (Visual Studio and VS Code sign-ins also work); when the app runs in Azure, the same credential resolves managed identity automatically. Your identity needs a role that grants inference access—for example, Cognitive Services User—on the Foundry resource, and the Entra token scope for this API is https://ai.azure.com/.default. User secrets here hold only non-secret configuration (endpoint and deployment name) and remain a local-development convenience, not a production config store. See the Grok authentication guide for more detail.

Create FoundryChat.cs next to Program.cs. This shared factory builds a configured ChatClient the whole program reuses:

#pragma warning disable OPENAI001 // The Entra ID authenticationPolicy constructor is an evaluation API.
using System.ClientModel.Primitives;
using Azure.Identity;
using Microsoft.Extensions.Configuration;
using OpenAI;
using OpenAI.Chat;

public static class FoundryChat
{
    public static ChatClient CreateClient()
    {
        var config = new ConfigurationBuilder()
            .AddUserSecrets(typeof(FoundryChat).Assembly)
            .Build();

        var endpoint = config["Foundry:Endpoint"]
            ?? throw new InvalidOperationException("Set Foundry:Endpoint with dotnet user-secrets.");
        var deployment = config["Foundry:Deployment"]
            ?? throw new InvalidOperationException("Set Foundry:Deployment with dotnet user-secrets.");

        // DefaultAzureCredential resolves az login, Visual Studio, or managed identity.
        var tokenPolicy = new BearerTokenPolicy(new DefaultAzureCredential(), "https://ai.azure.com/.default");
        var options = new OpenAIClientOptions { Endpoint = new Uri($"{endpoint.TrimEnd('/')}/openai/v1") };

        return new ChatClient(model: deployment, authenticationPolicy: tokenPolicy, options: options);
    }
}

The OPENAI001 pragma is required because the OpenAI SDK marks its custom-authenticationPolicy constructor as an evaluation API—it is the supported way to attach an Entra bearer token to a non-OpenAI endpoint. Setting Endpoint to .../openai/v1 lets the SDK append chat/completions itself; this v1 surface needs no api-version query parameter.

The five examples below form a single Program.cs, not five standalone files. Replace the generated Program.cs with the shared setup block that follows, then append each use-case function (Use Cases 1–5) to the same file; keep FoundryChat.cs unchanged. The program picks a case from the command line—dotnet run -- 2 runs Use Case 2 and dotnet run -- all runs them in sequence, defaulting to Use Case 1 when you pass no argument.

using System.Diagnostics;
using System.Text.Json;
using OpenAI.Chat;

var selectedCase = args.FirstOrDefault()?.ToLowerInvariant() ?? "1";
if (selectedCase is not ("1" or "2" or "3" or "4" or "5" or "all"))
{
    Console.WriteLine("Usage: dotnet run -- [1|2|3|4|5|all]");
    return;
}

var chat = FoundryChat.CreateClient();

// A shared deadline for the whole run; Ctrl+C cancels in-flight requests too.
using var cancellation = new CancellationTokenSource(TimeSpan.FromMinutes(10));
Console.CancelKeyPress += (_, e) =>
{
    e.Cancel = true;
    cancellation.Cancel();
};

string[] cases = selectedCase == "all" ? ["1", "2", "3", "4", "5"] : [selectedCase];
foreach (var useCase in cases)
{
    Console.WriteLine($"\n--- Use case {useCase} ---");
    try
    {
        switch (useCase)
        {
            case "1": await RunSpecDraftAsync(); break;
            case "2": await RunRefactoringReviewAsync(); break;
            case "3": await RunToolCallingAsync(); break;
            case "4": await RunImpactAssessmentAsync(); break;
            case "5": await RunCompileFixLoopAsync(); break;
        }
    }
    catch (OperationCanceledException)
    {
        Console.Error.WriteLine("Cancelled, or the demo's ten-minute limit was reached.");
        Environment.ExitCode = 1;
        break;
    }
    catch (Exception ex)
    {
        // Demo boundary: report the failure but let 'all' continue to the next case.
        Console.Error.WriteLine($"Use case {useCase} failed: {ex.Message}");
        Environment.ExitCode = 1;
    }
}

Run from the Grok-4.7-Demo-Csharp directory with dotnet run -- <case>. These examples send paid requests to your deployed model. If you see 401/403, check your Entra sign-in (az login) and role assignment; for 404, verify the resource endpoint and deployment name (not the model catalog ID); for 429, reduce traffic or retry with backoff. Each use-case block below is a function appended to this same file; the two helpers at the end of Use Case 5 go last.

Use Case 1: Drafting a technical specification

Use a constrained prompt and review the resulting document with your team rather than treating generated architecture as an approved design.

async Task RunSpecDraftAsync()
{
    var requirements = """
        Multi-location inventory system: 10K concurrent users, updates visible within
        two seconds, SQL Server migration, SAP REST integration, audit trail and a
        six-month delivery timeline. The team has limited NoSQL experience.
        """;

    ChatCompletion completion = await chat.CompleteChatAsync(
    [
        new SystemChatMessage("Draft a technical specification with assumptions, architecture trade-offs, data model, APIs, reliability, security, rollout phases and open questions. Do not invent verified benchmarks."),
        new UserChatMessage(requirements)
    ], cancellationToken: cancellation.Token);

    await File.WriteAllTextAsync("inventory-system-spec.md", completion.Content[0].Text);
    Console.WriteLine("Review inventory-system-spec.md with the engineering team.");
}

Output Case 1

--- Use case 1 ---
Review inventory-system-spec.md with the engineering team.

Use Case 2: Two-stage refactoring review

The first completion analyzes code; the second uses that analysis to propose changes. The embedded code is deliberately input data, not a compilable payment implementation.

async Task RunRefactoringReviewAsync()
{
    var existingCode = """
        // InventoryService.cs (excerpt)
        var current = await GetStockLevel(sku);
        if (current >= quantity) await UpdateStockLevel(sku, current - quantity);

        // OrderManager.cs (excerpt)
        order.Status = "Cancelled";
        await SaveOrder(order);
        await SendCancellationEmail(order);
        """;

    ChatCompletion analysis = await chat.CompleteChatAsync(
    [
        new SystemChatMessage("Review the supplied C# excerpts. Identify concurrency, consistency and validation issues; distinguish facts from assumptions."),
        new UserChatMessage(existingCode)
    ], cancellationToken: cancellation.Token);

    var findings = analysis.Content[0].Text;
    Console.WriteLine(findings);

    ChatCompletion plan = await chat.CompleteChatAsync(
    [
        new SystemChatMessage("Propose a reviewable refactoring plan, test cases and a migration strategy. Ask for missing domain details instead of inventing them."),
        new UserChatMessage($"Excerpts:\n{existingCode}\n\nReview:\n{findings}")
    ], cancellationToken: cancellation.Token);

    Console.WriteLine("\nRefactoring proposal:\n" + plan.Content[0].Text);
}

I have omitted the output of case 2 since it was pretty long, so you should try it yourself.
This is a planning aid, not an automatic repository refactor. A human must inspect proposed patches and run tests.

Use Case 3: Structured tool calling (local research notes)

The SDK surfaces tool requests as completion.ToolCalls with a ToolCalls finish reason; never parse assistant prose for a string like tool_use. This small example looks up local, hard-coded notes, not live web search. Replace the allowlisted lookup with a real, trusted data source before claiming current research results. Keep the tool result tied to its tool_call_id and bound the number of rounds.

async Task RunToolCallingAsync()
{
    var messages = new List<ChatMessage>
    {
        new SystemChatMessage("Use lookup_note for supplied local notes. Say explicitly when information is unavailable; do not claim live web access."),
        new UserChatMessage("What should I consider when adding distributed tracing to a .NET service?")
    };

    var options = new ChatCompletionOptions
    {
        Tools =
        {
            ChatTool.CreateFunctionTool(
                functionName: "lookup_note",
                functionDescription: "Look up a local note about tracing or sampling",
                functionParameters: BinaryData.FromString("""
                    {
                      "type": "object",
                      "properties": { "topic": { "type": "string", "description": "tracing or sampling" } },
                      "required": ["topic"]
                    }
                    """))
        }
    };

    for (var round = 0; round < 4; round++)
    {
        ChatCompletion completion = await chat.CompleteChatAsync(messages, options, cancellation.Token);
        if (completion.FinishReason != ChatFinishReason.ToolCalls)
        {
            Console.WriteLine(completion.Content[0].Text);
            return;
        }

        messages.Add(new AssistantChatMessage(completion)); // Preserve assistant tool calls and their IDs.
        foreach (var call in completion.ToolCalls)
        {
            var result = "Unknown tool or topic";
            if (call.FunctionName == "lookup_note")
            {
                using var arguments = JsonDocument.Parse(call.FunctionArguments);
                var topic = arguments.RootElement.GetProperty("topic").GetString();
                result = topic switch
                {
                    "tracing" => "Local note: use OpenTelemetry spans and propagate trace context across HTTP calls.",
                    "sampling" => "Local note: measure cost and choose a sampling strategy before production rollout.",
                    _ => "No local note exists for this topic."
                };
            }

            messages.Add(new ToolChatMessage(call.Id, result));
        }
    }

    Console.WriteLine("Stopped after four tool rounds; inspect the conversation before retrying.");
}

Output Case 3

--- Use case 3 ---
Use OpenTelemetry spans and propagate trace context across HTTP calls.

Local notes do not cover further .NET-specific setup (exporters, sampling, instrumentation packages, or collector config). In practice, also consider:

- **Instrumentation:** ASP.NET Core, HttpClient, and other outbound clients so incoming and outgoing calls create spans automatically.
- **Context propagation:** W3C `traceparent` / `tracestate` (or your platform’s equivalent) on every hop so traces stay connected.
- **Sampling and volume:** Head- or tail-based sampling so high-traffic services do not overwhelm storage.
- **Export path:** An OTLP exporter to a collector or backend, plus resource attributes (service name, version, environment).
- **Operational impact:** Span cardinality, sensitive data in attributes, and the cost of always-on tracing in hot paths.

Remember to treat tool arguments as untrusted input. Do not let a model execute arbitrary shell commands or read arbitrary paths; apply authorization, timeouts and size limits in a real agent.

Use Case 4: Bounded codebase impact assessment

A large context window is a ceiling, not a reason to upload every file. This example uses the local console project's Program.cs so it runs without a separate repository; point it at your own reviewed files when using it for a real change.

async Task RunImpactAssessmentAsync()
{
    var path = "Program.cs";
    var code = await File.ReadAllTextAsync(path, cancellation.Token);
    if (code.Length > 40_000)
        throw new InvalidOperationException("Select a smaller, relevant excerpt before sending it.");

    var proposedChange = "Add structured logging for each external API request.";
    ChatCompletion completion = await chat.CompleteChatAsync(
    [
        new SystemChatMessage("Assess the impact of a proposed C# change. List directly affected code, likely dependencies, test cases and unknowns. Do not claim to have read files not supplied."),
        new UserChatMessage($"Change: {proposedChange}\nFile: {path}\n```
{% endraw %}
csharp\n{code}\n
{% raw %}
```")
    ], cancellationToken: cancellation.Token);

    await File.WriteAllTextAsync("impact-assessment.md", completion.Content[0].Text);
    Console.WriteLine("Review impact-assessment.md; only the supplied file was analyzed.");
}

Output Case 4


--- Use case 4 ---
Review impact-assessment.md; only the supplied file was analyzed.

For an actual repository-wide assessment, explicitly select relevant files, exclude credentials and generated artifacts, and stay within your deployment's token and rate limits. The Grok guide documents a 500,000-token context window; both input and output consume it.

Use Case 5: A bounded generate → compile → fix loop

This is the honest version of "agentic self-correction." The model generates code, your harness compiles it and feeds any errors back, and the loop repeats until the build is clean or a round limit is hit. The compiler is the verifier—Grok 4.7 does the reasoning and the patching, but the loop, the build step, and the stopping rule are code you own, not something the model does on its own. The generated code is compiled, never executed, in a throwaway class library.

async Task RunCompileFixLoopAsync()
{
    // Isolated scratch class library. Generated code is built, never run.
    var workDir = Path.Combine(Path.GetTempPath(), "grok-codegen-" + Guid.NewGuid().ToString("N")[..8]);
    Directory.CreateDirectory(workDir);
    await RunDotnetAsync(workDir, "new classlib --output . --framework net10.0");
    var generatedPath = Path.Combine(workDir, "Generated.cs");

    var task = """
        Write a single C# file with a public static class `Temperature` exposing
        `CelsiusToFahrenheit(double c)` and `FahrenheitToCelsius(double f)`, both returning double.
        Return only the file contents.
        """;

    var messages = new List<ChatMessage>
    {
        new SystemChatMessage("You write C# that compiles on .NET 10. When given compiler errors, return the complete corrected file, not a diff. Output only C# source."),
        new UserChatMessage(task)
    };

    for (var round = 1; round <= 4; round++)
    {
        ChatCompletion completion = await chat.CompleteChatAsync(messages, cancellationToken: cancellation.Token);
        var source = StripFences(completion.Content[0].Text);
        await File.WriteAllTextAsync(generatedPath, source, cancellation.Token);

        var (compiled, output) = await RunDotnetAsync(workDir, "build --nologo -clp:ErrorsOnly");
        if (compiled)
        {
            Console.WriteLine($"Compiled on round {round}. Review {generatedPath} and add tests before use.");
            return;
        }

        Console.WriteLine($"Round {round} did not compile; sending errors back.");
        messages.Add(new AssistantChatMessage(source));
        messages.Add(new UserChatMessage($"That file did not compile. Fix it and return the complete file.\n\nCompiler output:\n{output}"));
    }

    Console.WriteLine("Stopped after four rounds without a clean build; inspect the last attempt manually.");
}

static string StripFences(string text)
{
    var trimmed = text.Trim();
    if (!trimmed.StartsWith("```
{% endraw %}
")) return trimmed;
    var firstNewline = trimmed.IndexOf('\n');
    var body = firstNewline < 0 ? trimmed : trimmed[(firstNewline + 1)..];
    var closingFence = body.LastIndexOf("
{% raw %}
```", StringComparison.Ordinal);
    return (closingFence < 0 ? body : body[..closingFence]).Trim();
}

static async Task<(bool compiled, string output)> RunDotnetAsync(string workDir, string arguments)
{
    using var process = Process.Start(new ProcessStartInfo("dotnet", arguments)
    {
        WorkingDirectory = workDir,
        RedirectStandardOutput = true,
        RedirectStandardError = true
    })!;
    var stdout = await process.StandardOutput.ReadToEndAsync();
    var stderr = await process.StandardError.ReadToEndAsync();
    await process.WaitForExitAsync();
    return (process.ExitCode == 0, stdout + stderr);
}

Output - Case 5

--- Use case 5 ---
Compiled on round 1. Review /tmp/grok-codegen-8208d923/Generated.cs and add tests before use.


public static class Temperature
{
    public static double CelsiusToFahrenheit(double c) => c * 9.0 / 5.0 + 32.0;

    public static double FahrenheitToCelsius(double f) => (f - 32.0) * 5.0 / 9.0;
}

Building untrusted source is not a full sandbox—MSBuild can run build logic such as source generators and build targets—so run this in a disposable or sandboxed environment, cap the rounds (as above), and add a per-call timeout for anything beyond a demo. The loop stops on the first clean build; a human still reviews and tests the result before it goes anywhere near production.

That is the last block. Your single Program.cs now holds the setup-and-dispatch code, all five use-case functions, and the two local helpers—run any case with dotnet run -- <case>, or dotnet run -- all for the full sequence.

Practical considerations

Use larger reasoning models where they add value; check current pricing before sending large repositories or repeated multi-step calls. Model outputs are suggestions, not verified specifications, current documentation, or executable patches. Review security and architecture decisions and test generated code before production use. Foundry supports both Global Standard and US Data Zone Standard deployments; verify current region availability and data-residency requirements for your organization.

The bottom line

Grok 4.7 on Microsoft Foundry can assist with technical writing, architecture reviews, tool-assisted workflows and change-impact analysis. The workable .NET pattern is simple: deploy the model, point the OpenAI SDK at the Foundry resource's /openai/v1 endpoint with your deployment name, authenticate with Microsoft Entra ID, and verify every output against your own codebase and requirements.

Resources

GPT-6.1 Sol for C# Developers: The Model I'd Test on Every Pull Request

Taswar Bhatti — Mon, 12 Oct 2026 09:42:04 +0000

When I wrote about GPT-6 Astra, the interesting question was: Can an agent take a messy problem, investigate it, and hand back something worth reviewing? The examples were deliberately substantial: bug investigations, BI recommendations, template-based reports, approval-gated record updates, and long-document synthesis.

Now there is a different question: Can you afford to do that every time the work shows up? Microsoft's GPT-6.1 Sol announcement says GPT-6.1 Sol is generally available in Microsoft Foundry. It upgrades GPT-6 Sol, not Astra, and improves agentic coding, computer use, and professional work. Microsoft says it approaches Astra on its cited evaluations while offering a better capability-to-cost balance for agents that run all day. That is a positioning and evaluation claim, not a promise that Sol wins every task or that any particular deployment will be cheaper.

For a .NET team, I would not start with another one-off chatbot. I would start with the work that repeats: each PR, each support request, and each weekly review. No Python required; the patterns below use C# and Microsoft.Extensions.AI, and every sample prints the token usage you need to measure cost.

What changed since Astra?

A quick note on naming, because there are three models in play. GPT-6 Astra is the flagship I covered last time. GPT-6 Sol is the earlier Sol model. GPT-6.1 Sol is the upgrade to GPT-6 Sol. In the table, the Astra column summarizes how I used Astra; the GPT-6.1 Sol column describes what Microsoft says improved compared with GPT-6 Sol, not compared with Astra.

Question	GPT-6 Astra	GPT-6.1 Sol (changes vs. GPT-6 Sol)
Best starting point	The most demanding reasoning and high-stakes reviews	A candidate default for recurring production agents and complex workflows
Agentic coding	Investigate bugs and propose changes for review	Improved planning, editing, testing, and iteration across multi-tool workflows
Computer use	Navigate approved interfaces with oversight	Improved reliability across multi-step interface workflows
Professional work	Synthesize, analyze, and produce review-ready work	Stronger recurring analysis, drafting, and factual accuracy
Context and modalities	Large text/image inputs	Text and image inputs, text output, up to a 1M-token total context window; not a claim of more context than Astra

The comparison matters: 6.1 Sol is an upgrade to Sol; Astra remains Microsoft's starting point for the hardest reasoning. Microsoft's model reference lists a 1,050,000-token context window for both Astra and 6.1 Sol (maximum input 922,000; maximum output 128,000). A million tokens is capacity, not a suggestion to ship your whole repository on every request. Long prompts have real latency and cost consequences. Check the current catalog for your region and deployment options before building around any limit.

Foundry's announcement lists Standard deployments across Global and US, EU, and APAC Data Zones; at launch it lists Provisioned Throughput in Global and US Data Zone. Serving location, capacity, and pricing are separate design choices. Check current availability and the Azure OpenAI pricing page for your own deployment rather than treating a launch-day price table as a quote.

Already running GPT-6 Sol?

In code, moving to 6.1 Sol is a configuration change: create a new deployment and point your deployment name at it. With Microsoft.Extensions.AI nothing else in your C# changes. Treat it as a model change anyway. Run your existing prompts and evaluation set against both deployments side by side, compare outcomes and token usage, and only then switch traffic. A model that reasons differently can spend a different number of tokens on the same prompt.

The .NET setup

Deploy gpt-6.1-sol from the Foundry model catalog and note two values from the deployment's details page:

Endpoint: the resource endpoint, https://your-resource.services.ai.azure.com, not a Foundry project endpoint ending in /api/projects/....
Deployment name: the name you gave the deployment, which may differ from the model name.

Then give your identity access. The sample uses Microsoft Entra ID through DefaultAzureCredential, not API keys:

Assign the Cognitive Services OpenAI User role on the resource to whoever runs the code: your own account for local development, a managed identity in production.
Locally, sign in with az login (or Visual Studio / VS Code Azure sign-in). DefaultAzureCredential picks that up.
Role assignments can take a few minutes to apply. A 401 or 403 right after assigning the role usually means "wait", not "wrong code".

Create the project. I compiled every sample in this post against the package versions below on .NET 10; pinning them keeps the code from drifting as Microsoft.Extensions.AI evolves. Any .NET 8+ SDK works.

dotnet new console -n Gpt-6.1-Sol-CSharp-Demo
cd Gpt-6.1-Sol-CSharp-Demo
dotnet add package Azure.AI.OpenAI --version 2.1.0
dotnet add package Azure.Identity --version 1.21.0
dotnet add package Microsoft.Extensions.AI --version 10.10.0
dotnet add package Microsoft.Extensions.AI.OpenAI --version 10.10.1
dotnet add package Microsoft.Extensions.Configuration.UserSecrets --version 10.0.12
dotnet user-secrets init
dotnet user-secrets set "AZURE_AI_ENDPOINT" "https://your-resource.services.ai.azure.com"
dotnet user-secrets set "AZURE_OPENAI_DEPLOYMENT" "gpt-6.1-sol"

The endpoint and deployment name live in .NET user secrets, which are stored in your user profile outside the project folder, so they never end up in source control.

using System.ComponentModel;
using System.Diagnostics;
using Azure.AI.OpenAI;
using Azure.Identity;
using Microsoft.Extensions.AI;
using Microsoft.Extensions.Configuration;

var config = new ConfigurationBuilder()
    .AddUserSecrets<Program>()
    .Build();

var endpoint = config["AZURE_AI_ENDPOINT"]
    ?? throw new InvalidOperationException(
        "AZURE_AI_ENDPOINT is not set. Run: dotnet user-secrets set \"AZURE_AI_ENDPOINT\" \"<your-endpoint>\"");
var deployment = config["AZURE_OPENAI_DEPLOYMENT"]
    ?? throw new InvalidOperationException(
        "AZURE_OPENAI_DEPLOYMENT is not set. Run: dotnet user-secrets set \"AZURE_OPENAI_DEPLOYMENT\" \"<your-deployment>\"");

var clientOptions = new AzureOpenAIClientOptions
{
    NetworkTimeout = TimeSpan.FromMinutes(3)
};

IChatClient chat = new AzureOpenAIClient(
        new Uri(endpoint), new DefaultAzureCredential(), clientOptions)
    .GetChatClient(deployment)
    .AsIChatClient()
    .AsBuilder()
    .UseFunctionInvocation()
    .UseOpenTelemetry(sourceName: "GptSixOneSolDemo")
    .Build();

using var cts = new CancellationTokenSource(TimeSpan.FromMinutes(5));

static void Report(string label, ChatResponse response, Stopwatch timer) =>
    Console.WriteLine(
        $"[{label}] input={response.Usage?.InputTokenCount} " +
        $"cached={response.Usage?.CachedInputTokenCount} " +
        $"output={response.Usage?.OutputTokenCount} " +
        $"reasoning={response.Usage?.ReasoningTokenCount} " +
        $"elapsed={timer.Elapsed.TotalSeconds:F1}s");

A few choices in that setup are deliberate:

Timeouts and retries. Reasoning models can take a while on hard prompts, so the network timeout is raised and every call gets a cancellation token with an overall budget. The Azure client already retries transient failures (such as 429 and 503) with backoff, so you don't need to wrap calls in your own retry loop. Do count those retries when you measure cost and latency.
UseFunctionInvocation() lets the model call the C# tools you register. It's harmless for samples without tools, which simply never trigger it.
UseOpenTelemetry() emits a trace span per model call, including token counts, following the OpenTelemetry GenAI conventions. Nothing is exported until you add the OpenTelemetry SDK and an exporter (Azure Monitor, OTLP, or console); then the same data lands next to Foundry's tracing.
Report prints input, cached-input, output, and reasoning tokens plus wall-clock time for each call. Those are the numbers you'll need for the cost comparison later in the post.

The snippets below are alternatives to append after that setup, not three workloads to fire at once. Tool bodies and inputs are illustrative, not a live GitHub, browser, or CRM integration. Tool calling through UseFunctionInvocation() can invoke your C# methods: give those methods narrowly scoped permissions and validate inputs server-side. For a new deployment, also verify the supported API surface in the model documentation.

Use case 1: PR triage on every pull request

The Astra bug demo asked the model to correlate logs with a commit. Sol's production pitch is to run a similar loop on every PR: inspect CI, flag likely breakages, propose a focused test, and let a human decide whether to merge. The interesting part is not generating a paragraph of review comments; it is knowing when evidence is insufficient.

The program reads CI output from a file when you pass one, and falls back to a sample otherwise:

var ci = args.Length > 0
    ? File.ReadAllText(args[0])
    : "PR #418: change to PromoCodeResolver; CI failed: " +
      "DiscountTests.SinglePromo_WhenExpired expected rejection, got success. " +
      "Other 203 tests passed.";

var reviewTimer = Stopwatch.StartNew();
var review = await chat.GetResponseAsync(
    [
        new(ChatRole.System, "You are a C# PR reviewer. Use only the supplied CI " +
            "evidence. Separate observed facts from hypotheses. Suggest one " +
            "reproducible next test. Do not approve or merge the PR."),
        new(ChatRole.User, ci)
    ], cancellationToken: cts.Token);

Console.WriteLine(review.Text);
Report("pr-triage", review, reviewTimer);

Output - Case 1

###################### Case 1 ################################
**Blocking CI failure:** `DiscountTests.SinglePromo_WhenExpired` expected rejection but got success. The other 203 tests passed.

**Possible cause, not established by the CI evidence:** the `PromoCodeResolver` change may allow an expired promo through the single-promo path. The failure alone does not identify where that happens.

**Next test:** Run `dotnet test --filter "FullyQualifiedName~DiscountTests.SinglePromo_WhenExpired"` to check whether the failure reproduces in isolation. I would not approve or merge while this failure remains unresolved.
[pr-triage] input=77 cached=0 output=266 reasoning=149 elapsed=5.4s
##############################################################

Illustrative result: “Observed: the expired single-promo test failed; 203 others passed. Hypothesis: the resolver now accepts an expired code in one path. Next: reproduce that test locally and inspect expiry validation in the changed method. Do not merge until the failure is resolved.” No invented diff, no claim to have run tests.

Wiring it into CI

To run it on every pull request, put the program in its own project (say tools/PrTriage) and call it from your pipeline. Here is a minimal GitHub Actions workflow. It runs the tests, asks the model for triage only when they fail (that's where it helps, and it keeps cost down), and writes the result to the job summary:

name: pr-triage
on: pull_request

permissions:
  contents: read
  id-token: write

jobs:
  test-and-triage:
    # Forked PRs get no OIDC token or secrets, so skip them.
    if: github.event.pull_request.head.repo.full_name == github.repository
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '10.0.x'

      - name: Test
        id: tests
        continue-on-error: true
        shell: bash
        run: dotnet test 2>&1 | tee test-output.txt

      - uses: azure/login@v2
        if: steps.tests.outcome == 'failure'
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

      - name: AI triage
        if: steps.tests.outcome == 'failure'
        run: |
          dotnet user-secrets set --project tools/PrTriage "AZURE_AI_ENDPOINT" "${{ vars.AZURE_AI_ENDPOINT }}"
          dotnet user-secrets set --project tools/PrTriage "AZURE_OPENAI_DEPLOYMENT" "${{ vars.AZURE_OPENAI_DEPLOYMENT }}"
          tail -n 200 test-output.txt > ci-summary.txt
          dotnet run --project tools/PrTriage -- ci-summary.txt >> "$GITHUB_STEP_SUMMARY"

      - name: Fail the job if tests failed
        if: steps.tests.outcome == 'failure'
        run: exit 1

The triage step writes the endpoint and deployment name from repository variables into the runner's user secrets, so the same Program.cs runs unchanged locally and in CI. azure/login with OIDC means no API key is stored in GitHub; the workflow's federated identity needs the same Cognitive Services OpenAI User role as before. Notice what the model can't do: it gets read-only test output, it writes only to the job summary, and merge rights stay with your branch protection rules. Treat PR content as untrusted input (a test name or log line can contain prompt-injection text), which is one more reason to keep the model's output advisory. Passing the last 200 lines of output instead of the whole log keeps input tokens predictable.

Use case 2: Back-office changes with a real approval boundary

Astra illustrated “look up a record, then propose an update.” Sol makes the pattern worth testing for frequent billing-email changes or account reconciliation. This is function calling, not a demonstration of computer-use/browser automation. If you do add browser-based computer use later, isolate the browser, scope credentials, and require human confirmation before sensitive writes.

This time the model doesn't return prose. GetResponseAsync<T> asks for structured output matching a C# record, so your code receives a typed proposal it can route into an approval queue:

var options = new ChatOptions
{
    Tools = [AIFunctionFactory.Create(LookUpAccount)]
};

var changeTimer = Stopwatch.StartNew();
var result = await chat.GetResponseAsync<ProposedChange>(
    [
        new(ChatRole.System, "You assist a support agent. Look up the account, " +
            "then return a proposed billing-email change for human review. " +
            "You have no tool that can update the account."),
        new(ChatRole.User, "Account ACC-4471 requests changing its billing email " +
            "to finance@northwind-retail.com.")
    ], options, cancellationToken: cts.Token);

if (result.TryGetResult(out var proposal))
{
    // Hand the proposal to your approval workflow; nothing is written here.
    Console.WriteLine($"{proposal.AccountId} {proposal.Field}: " +
        $"{proposal.CurrentValue} -> {proposal.ProposedValue} (pending approval)");
}
Report("account-change", result, changeTimer);

[Description("Read-only lookup of an account by ID.")]
static string LookUpAccount([Description("Account ID")] string accountId) =>
    accountId == "ACC-4471"
        ? "Northwind Retail; billing email: billing-old@northwind-retail.com"
        : "Account not found";

record ProposedChange(
    string AccountId,
    string Field,
    string CurrentValue,
    string ProposedValue,
    bool RequiresRequesterVerification);

The record must come after all top-level statements, so keep it at the bottom of Program.cs.

Illustrative result: ACC-4471 billingEmail: billing-old@northwind-retail.com -> finance@northwind-retail.com (pending approval). This is the real approval boundary: the model has only a read-only tool, and its output is data, a ProposedChange your service validates (is it a well-formed email? does the account exist?) and puts in front of an authenticated human. TryGetResult returning false is a normal outcome you should handle, not an exception. Read-only tools and authenticated human-operated write paths are a stronger boundary than asking a model to be careful.

Output - Case 2

###################### Case 2 ################################
ACC-4471 billingEmail: billing-old@northwind-retail.com -> finance@northwind-retail.com (pending approval)
[account-change] input=408 cached=0 output=116 reasoning=30 elapsed=5.9s
##############################################################

Use case 3: Weekly document review without fake citations

Astra's report and filing examples showed what long context can do. For recurring professional work, try Sol on a smaller, source-labeled set of documents: a vendor SLA and an internal incident note. Ask for an evidence table rather than a sweeping “everything looks fine.”

var documents = """
    [SLA §4] Credits require a claim within 30 days of the incident.
    [Incident INC-204] Availability dropped below the SLA target on 2026-09-16.
    [Incident INC-204] The incident note does not record whether a claim was filed.
    """;

var vendorTimer = Stopwatch.StartNew();
var summary = await chat.GetResponseAsync(
    [
        new(ChatRole.System, "Review only the supplied sources. For each finding, " +
            "quote its source label. Distinguish a missing fact from a negative fact. " +
            "Suggest a human follow-up; do not make a legal determination."),
        new(ChatRole.User, documents + "\nWhat should the weekly vendor review flag?")
    ], cancellationToken: cts.Token);

Console.WriteLine(summary.Text);
Report("vendor-review", summary, vendorTimer);

Illustrative result: “The SLA requires a claim within 30 days [SLA §4]. An availability incident is recorded on September 16 [Incident INC-204]. Unknown: whether a claim was submitted; the incident note does not say [Incident INC-204]. Follow up with the contract owner before the relevant deadline.” Before sending such a summary to anyone, verify each cited claim against the source and confirm the deadline calculation and time zone with the contract owner. Large-context access does not guarantee grounded answers.

Output - Case 3

###################### Case 3 ################################
The weekly vendor review should flag:

- **SLA availability issue:** Availability fell below the target on 2026-09-16 (“[Incident INC-204]”).
- **Time-sensitive credit question:** Credits require a claim within 30 days of the incident (“[SLA §4]”).
- **Missing fact, not a confirmed failure to file:** The note does not say whether a claim was filed (“[Incident INC-204]”).

**Human follow-up:** Ask the vendor owner to confirm whether and when a claim was submitted, obtain the submission record, and check the applicable deadline.
[vendor-review] input=113 cached=0 output=272 reasoning=143 elapsed=7.5s
##############################################################

For a weekly job, the cached count in the report is worth watching. If the system prompt and long reference documents stay identical between runs and come first in the prompt, repeated input can be served from the prompt cache, which is typically billed at a lower rate.

Choosing Astra, Sol, or Luna with evidence

Microsoft positions three models for different jobs: Astra for the hardest reasoning, GPT-6.1 Sol for production agents and complex recurring workflows, and Luna for high-volume preparatory and data tasks: think classification, extraction, and cleanup that feed a larger workflow. Treat that as a shortlist, not a routing rule baked into your product.

I would put a representative set of your own PRs, support requests, and document reviews through all three and record: correct outcomes, unsupported claims, tool calls, retries, human escalations, end-to-end latency, and total cost per successfully completed task. Include failed and repeated attempts in the cost.

Reasoning effort is the other dial. Microsoft.Extensions.AI exposes it as a provider-neutral option, so comparing settings is a loop:

foreach (var effort in new[] { ReasoningEffort.Low, ReasoningEffort.Medium, ReasoningEffort.High })
{
    var effortTimer = Stopwatch.StartNew();
    var attempt = await chat.GetResponseAsync(
        [new(ChatRole.User, ci)],
        new ChatOptions { Reasoning = new() { Effort = effort } },
        cts.Token);
    Report($"pr-triage-{effort}", attempt, effortTimer);
}

Output - Reasoning effort

###################### Reasoning Effort ################################
[pr-triage-Low] input=37 cached=0 output=117 reasoning=29 elapsed=2.6s
[pr-triage-Medium] input=37 cached=0 output=217 reasoning=101 elapsed=4.0s
[pr-triage-High] input=37 cached=0 output=341 reasoning=210 elapsed=4.7s
##############################################################
</pre>

Check which effort levels your deployment accepts before relying on one; an unsupported value can be rejected by the service. Watch the reasoning count in the output: the reasoning documentation notes that reasoning tokens are billed as output tokens, so a short answer can still be expensive. If High doesn't produce measurably better triage on your PRs, you're paying for tokens nobody reads.

This post uses the Chat Completions API because that's what GetChatClient targets. Azure OpenAI also offers the Responses API, which is built for multi-turn agent work with server-side conversation state. Microsoft.Extensions.AI can sit on top of either, so your IChatClient code stays the same, but options and behavior don't always map one-to-one between them. Pick one for your evaluation and keep it fixed while comparing models.

Keep approval checkpoints, least-privilege tool identities, audit logs, and prompt-injection defenses in place regardless of which model wins. Foundry offers evaluation, tracing, monitoring, and safety controls, but they do not remove the need to test your tools and enforce authorization in C#.

Beyond a console app

The console app keeps the samples short. In ASP.NET Core, register the same pipeline once with dependency injection and inject IChatClient wherever you need it. Run dotnet user-secrets init and the same two set commands in the web project; ASP.NET Core loads user secrets automatically in the Development environment:

builder.Services
    .AddChatClient(_ => new AzureOpenAIClient(
            new Uri(builder.Configuration["AZURE_AI_ENDPOINT"]!),
            new DefaultAzureCredential())
        .GetChatClient(builder.Configuration["AZURE_OPENAI_DEPLOYMENT"]!)
        .AsIChatClient())
    .UseFunctionInvocation()
    .UseOpenTelemetry();

For anything a person watches in real time, such as a support agent waiting on a draft, stream the response instead of waiting for the whole thing:

await foreach (var update in chat.GetStreamingResponseAsync(
    [new(ChatRole.User, ci)], cancellationToken: cts.Token))
{
    Console.Write(update.Text);
}

Background jobs like PR triage and the weekly review don't need streaming; the non-streaming call is simpler and gives you the usage numbers in one place.

Wrapping up

Astra was my “can this do the difficult work?” model. GPT-6.1 Sol is the model I would test first for work that happens constantly: PR triage, back-office review, and routine document analysis. Its announcement is about capability per task at production frequency, not about a bigger context window or magic autonomy. Keep the human approval button, log the token counts, measure your actual outcomes, and then choose the deployment that earns its place in your .NET stack.

Resources

Using Opus 5.5 Claude Code with Microsoft Foundry in VS Code

Taswar Bhatti — Mon, 05 Oct 2026 12:17:07 +0000

In my Claude Opus 5.5 for C# developers post I called Opus 5.5 from my own code: the Anthropic.Foundry SDK, Entra ID, and the effort parameter. This time the code calling Opus 5.5 isn't mine. It's Claude Code, running in my terminal and in VS Code, pointed at my Foundry resource.

Microsoft already has a good step-by-step setup guide for Claude Code on Microsoft Foundry in VS Code, so I'm not going to repeat it. If you've never connected Claude Code to Microsoft Foundry, start there. This post is about what happens after it connects, when the model on the other end is Opus 5.5: how to make sure you're actually talking to it, which dial to turn, and where the tokens go when you're not looking.

Why Opus 5.5 Changes the Claude Code Setup

A quick recap of what shipped, and what each change means inside Claude Code:

It's 40% cheaper than Opus 5. $4/M input, $20/M output, and $0.20/M cache reads. Claude Code sessions are mostly re-read context, so the cache price matters more than the headline price.
Medium effort is the default. Claude Code respects that: Opus 5.5 starts at medium, while most other models start at high. You can raise it per session.
Thinking is always on. There's no thinking toggle to hunt for. Effort is the only dial, and MAX_THINKING_TOKENS does nothing on Opus 5.5.
Output is 30%+ faster. You'll feel this in the VS Code panel on long diffs.
More refusals. The expanded safety classifiers apply in Claude Code too. If your repo is security tooling, expect some declines.

The catch: none of this matters if Claude Code isn't using Opus 5.5. And by default, on Foundry, it isn't.

The Short Setup (and the Line Most Guides Miss)

Install Claude Code CLI

Deploy Claude Opus 5.5 from the Foundry Model Catalog to your Foundry resource, same as any other model. Give yourself the Azure AI User or Cognitive Services User role on that resource (either one is enough to call the model), and run az login. No API key: Claude Code falls back to the Azure credential chain when no key is set, so your az login session is the credential. If you plan to use the API Key then you will need to set your env key or the json file to have the ANTHROPIC_FOUNDRY_API_KEY rather.

Remember to install the Extension in VSCode

VSCode Claude

Now the part I care about. Instead of setx-ing environment variables or pasting them into every shell, put them in ~/.claude/settings.json. Both the CLI and the VS Code extension read that file, so you configure Foundry once:

{
  "env": {
    "CLAUDE_CODE_USE_FOUNDRY": "1",
    "ANTHROPIC_FOUNDRY_RESOURCE": "your-foundry-resource-name",
    "ANTHROPIC_MODEL": "claude-opus-5-5",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "claude-opus-5-5"
  }
}

The two model lines do different jobs, and you want both:

ANTHROPIC_MODEL makes Opus 5.5 the model for the session. This is the line most guides miss. On Foundry, Claude Code's default model is Sonnet 4.5, not Opus. Setting only ANTHROPIC_DEFAULT_OPUS_MODEL remaps the opus alias, but you keep chatting with Sonnet until you switch.
ANTHROPIC_DEFAULT_OPUS_MODEL makes the opus alias (in /model, subagent definitions, and so on) resolve to your Opus 5.5 deployment instead of an older Opus you may not have deployed.

Use your actual deployment name if it isn't claude-opus-5-5. ANTHROPIC_FOUNDRY_RESOURCE takes the resource name only, not a URL. If you need a private endpoint or custom domain, use ANTHROPIC_FOUNDRY_BASE_URL instead. Don't set both.

In VS Code, install the Claude Code extension and add one line to your VS Code settings.json so it doesn't push you toward an Anthropic login:

{
  "claudeCode.disableLoginPrompt": true
}

Then check it, in the terminal or the VS Code panel: /status

You're looking for the API provider set to Microsoft Foundry, your resource name, and your Opus 5.5 deployment as the model. If the model line says Sonnet, the ANTHROPIC_MODEL line isn't being picked up.

Dev takeaway: "Deployed in Foundry" and "used by Claude Code" are two different things. /status is the five-second check that tells you which one you've got.

Effort: The Dial You'll Actually Touch

In the SDK post, effort was a property on the request. In Claude Code it's a session setting, and there are three ways to set it:

/effort sets it for the current session: /effort high, /effort low, or /effort auto to go back to the model default.
The /model picker has an effort slider (left/right arrows). Whatever you pick there is remembered per model, so Opus 5.5 can keep its own setting.
CLAUDE_CODE_EFFORT_LEVEL in the environment or the env block wins over everything else, including /effort.

That last point is easy to trip over: put CLAUDE_CODE_EFFORT_LEVEL in your settings while testing, forget about it, and later /effort high appears to do nothing. For interactive work, leave the env var out and use /effort or the /model slider. Save the env var for scripted or CI runs where you want one fixed level. (The top-level effortLevel user setting also won't apply to Opus 5.5, which is one more reason to use the per-model slider.)

Here's how I map the levels to Claude Code work:

Effort	What I use it for in Claude Code
`low`	"Explain this file", rename a symbol, write a commit message
`medium` (default)	Everyday feature work, bug fixes, writing tests
`high` / `xhigh`	Multi-file refactors, framework migrations, tricky concurrency bugs
`max`	Rarely, and only for the session: `/effort max` when `xhigh` clearly isn't getting there

Thinking tokens are billed as output, at $20/M. Raising effort for the whole day costs you; raising it for one hard problem and dropping back is cheap.

Where the Opus Bill Hides

Pinning everything to Opus 5.5 is easy. The surprise is how much else then runs on Opus 5.5 too.

Background tasks. Claude Code does small jobs behind the scenes, such as generating session titles. On the Anthropic API those go to Haiku. On Foundry they run on your primary model, which is now Opus 5.5, unless you deploy a Haiku model and point ANTHROPIC_DEFAULT_HAIKU_MODEL at it.

Subagents. When Claude Code fans work out to subagents (the Explore agent searching your repo, for example), each one uses the main conversation's model unless something says otherwise. That's Opus 5.5 for every file search. If you deploy a cheaper model, route subagents to it:

{
  "env": {
    "CLAUDE_CODE_USE_FOUNDRY": "1",
    "ANTHROPIC_FOUNDRY_RESOURCE": "your-foundry-resource-name",
    "ANTHROPIC_MODEL": "claude-opus-5-5",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "claude-opus-5-5",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "claude-sonnet-4-6",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "claude-haiku-4-5",
    "CLAUDE_CODE_SUBAGENT_MODEL": "claude-sonnet-4-6"
  }
}

Again, those are deployment names, so use yours. Opus 5.5 does the planning and the edits in the main conversation; a cheaper model does the searching and reading.

Only reference models you actually deployed. Foundry has no startup model check, so Claude Code won't warn you about a typo or a missing deployment when it launches. You find out mid-session. While drafting this post, a subagent in my own session died with:

The model claude-sonnet-4-5 is not available on your foundry deployment.

It had tried a model my resource didn't have. Everything else kept working, which is exactly why it's easy to miss. If you only deployed Opus 5.5, leave the Sonnet and Haiku lines out and accept that everything runs on Opus.

Dev takeaway: with one deployment, every token is an Opus token. That can be fine, since Opus 5.5 is cheaper than Opus 5, but make it a decision rather than a surprise.

Make the $0.20 Cache Reads Count

Cache reads at $0.20/M are the best part of the Opus 5.5 price sheet, and Claude Code is a cache-heavy workload: every turn re-sends your instructions, CLAUDE.md, and the conversation so far. Caching is on automatically. Three things decide whether you actually get those cheap reads:

The default cache lifetime on Foundry is 5 minutes. Step away for coffee, come back, and the next turn re-writes the whole context at full price. For long sessions with gaps, set ENABLE_PROMPT_CACHING_1H to 1 in the env block. One-hour cache writes are billed at a higher rate than 5-minute writes, so this pays off for long, stop-and-start sessions, not quick ones. (Recent Claude Code versions also have CLAUDE_CODE_PROMPT_CACHE_TTL=1h, which applies only to the main conversation.)
Pick your model at the start and stay on it. Switching from Opus 5.5 to Sonnet and back mid-session throws away the cache each time.
Set up MCP servers before you start. Some Azure-hosted deployments reject Claude Code's tool search, so it loads all MCP tools up front. Then connecting or removing an MCP server mid-session resets the cache.

Refusals Show Up in Your Editor Now

In the SDK post I made refusal handling a required pattern, because a refusal is a successful HTTP response with no answer in it. In Claude Code you don't write that handler, but you'll still see the result: Opus 5.5 declines more requests than Opus 5 in the biology, cybersecurity, and reasoning-extraction categories.

If you work on security tooling (scanners, fuzzers, detection rules), you'll occasionally hit a decline on a request that looks reasonable to you. Rephrase the request with the defensive context, or do that piece by hand. Don't try to engineer around the classifier; on a work resource, that's a conversation for your security team, not a prompt trick.

Checking What You Actually Spent

Inside Claude Code, run /usage (/cost is an alias). On Foundry you get the session's token counts, a prompt cache line, and an estimated dollar cost at list price. That estimate is great for "did turning effort up just double my session?", and the cache line tells you whether the 5-minute or 1-hour setting is actually working.

It is not your bill. The real numbers live in Azure Cost Management for the Foundry resource, at whatever price your agreement gives you. Anthropic's usage dashboards don't see Foundry traffic at all. For per-developer numbers across a team, Claude Code can export usage through OpenTelemetry. Tagging the Foundry resource (team=..., env=dev) makes chargeback easier.

When Something's Off

These are the Opus 5.5-specific problems I'd check first:

Symptom	Likely cause	Fix
`/status` shows Sonnet, not Opus 5.5	Only `ANTHROPIC_DEFAULT_OPUS_MODEL` is set	Add `ANTHROPIC_MODEL` with your Opus 5.5 deployment name
`model ... is not available on your foundry deployment`	An alias or subagent points at a model you didn't deploy	Deploy it, or remove that line from `env`
`/effort` seems to do nothing	`CLAUDE_CODE_EFFORT_LEVEL` is set and overrides it	Remove the env var for interactive use
Bill higher than `/usage` suggests per session	Background tasks and subagents running on Opus 5.5	Deploy Haiku/Sonnet and set the Haiku and subagent model lines
Every turn after a break is expensive	5-minute cache lifetime expired	`ENABLE_PROMPT_CACHING_1H=1` for long sessions
VS Code panel asks you to sign in to Anthropic	Login prompt not disabled	`"claudeCode.disableLoginPrompt": true`
`401` / `403`	Missing role, or `az login` in the wrong tenant	Azure AI User or Cognitive Services User on the resource; `az login --tenant <id>`

One more: there's no /logout on Foundry. To switch accounts or tenants, change your az login.

Bottom Line

Opus 5.5 is the first Opus worth testing as your all-day default in Claude Code. It's cheaper, faster, and medium effort is enough for most work. But "default" has to be deliberate on Foundry. Set ANTHROPIC_MODEL, confirm it with /status, decide whether background tasks and subagents should really run on Opus, and turn effort up only for the problem that needs it.

Configure it once in ~/.claude/settings.json, and the CLI and VS Code both pick it up. Then keep an eye on /usage for a week before you roll it out to the team.

GPT-image-2.5 Flare & Sunburst Land for C# Developers

Taswar Bhatti — Sat, 26 Sep 2026 11:24:37 +0000

Picture a home design app. A customer types, "Show me a modern kitchen with dark cabinets and a large center island." An image appears in seconds. They follow up: "Make it brighter, and add natural wood accen
ts." The app updates the image without redrawing the whole scene, without losing the layout that was already right. That's the interaction GPT-image-2.5 — split into two models, Flare and Sunburst
— is built for: fast, iterative image generation and editing that actually holds up across a real revision loop, not just a single lucky prompt.

Both models are now Generally Available in Microsoft Foundry. As always: no Python, no notebooks. Just Azure.AI.OpenAI's ImageClient, Microsoft.Extensions.Configuration, and dotnet run.

What Actually Shipped

Two models, one job split by speed vs. precision. Flare is the smaller, faster model for most production workloads — higher-quality images than GPT-image-2 at 50% lower latency, which is what keeps a user inside a live iteration loop instead of waiting on every change. Sunburst is for creative workflows that need greater precision and control — high-fidelity campaign assets and polished visuals where quality outranks speed.
More accurate editing. Update targeted elements while preserving the rest of the image — not a full re-roll every time you ask for a small change.
Stronger multi-turn editing. Refine through successive instructions without the image drifting or degrading as edits accumulate. This is the thing that actually breaks in a lot of image models: edit thr ee quietly changes something edit one got right.
Better instruction following. More accurate interpretation of complex visual instructions, layouts, and stylistic direction.
Transparent background generation. Generate logos, product cutouts, UI assets, icons, and stickers directly with a transparent background — set background="transparent" and output_format="png" (PNG o r WebP required; JPEG doesn't support transparency).
Both GA, both production-ready. Unlike some of the other models in this catalog, there's no preview caveat here — Flare and Sunburst are both fully supported for production workloads today.

Why This Matters for .NET Developers Specifically

The use cases Microsoft is calling out map directly onto real .NET workloads:

Marketing and campaign production — generate and resize campaign assets from an approved creative direction, with legible headline text rendered directly in the image
Retail and e-commerce catalogs — produce and maintain large volumes of consistent product imagery at scale
Virtual try-on and personalization — let a shopper preview an item, then adjust color, style, or setting through successive edits without the result drifting
Education and training content — generate diagrams and illustrations that evolve as a lesson or explanation develops
Travel, real estate, and discovery apps — turn a description into personalized imagery a user can react to and refine

Both models sit behind the exact same ImageClient you may already be using for GPT-image-2 or GPT-image-1 — swapping in Flare or Sunburst is a deployment-name change, not a rewrite.

Getting Started

dotnet new console -n GptImage2.5-flare-sunburst-demo
cd GptImage2.5-flare-sunburst-demo
dotnet add package Azure.AI.OpenAI
dotnet add package Azure.Identity
dotnet add package Microsoft.Extensions.Configuration.UserSecrets
dotnet add package Microsoft.Extensions.Configuration.EnvironmentVariables
dotnet user-secrets init
dotnet user-secrets set "AZURE_AI_ENDPOINT" "https://your-resource.services.ai.azure.com"'
dotnet user-secrets set "AZURE_AI_API_KEY" "<your-resource-api-key>"
dotnet user-secrets set "AZURE_AI_IMAGE_EDIT_API_VERSION" "2025-04-01-preview"

Deploy gpt-image-2.5-flare and gpt-image-2.5-sunburst from the Foundry Model Catalog to your project — same process as any other model. Grab your endpoint, and you're ready to go.

Here's the shared client setup every example below builds on:

using Azure.AI.OpenAI;
using System.ClientModel;
using Microsoft.Extensions.Configuration;
using OpenAI.Images;
using System.Net.Http.Headers;
using System.Text.Json;

var config = new ConfigurationBuilder()
    .AddUserSecrets<Program>()
    .AddEnvironmentVariables()
    .Build();

var endpoint = new Uri(config["AZURE_AI_ENDPOINT"]
    ?? throw new InvalidOperationException(
        "AZURE_AI_ENDPOINT is not set. Run: dotnet user-secrets set \\"AZURE_AI_ENDPOINT\\" \\"<your-endpoint>\\""));

// After reading endpoint from configuration:
var apiKey = config["AZURE_AI_API_KEY"]
    ?? throw new InvalidOperationException("AZURE_AI_API_KEY is not set.");

var imageEditApiVersion = config["AZURE_AI_IMAGE_EDIT_API_VERSION"] ?? "2025-04-01-preview";
const string flareDeployment = "gpt-image-2.5-flare";
const string sunburstDeployment = "gpt-image-2.5-sunburst";

var azureClient = new AzureOpenAIClient(endpoint, new ApiKeyCredential(apiKey));
var flareClient = azureClient.GetImageClient(flareDeployment);
var sunburstClient = azureClient.GetImageClient(sunburstDeployment);

using var httpClient = new HttpClient();
httpClient.DefaultRequestHeaders.Add("api-key", apiKey);

Uri CreateImageRequestUri(string deployment, string operation, string apiVersion) => new(
    $"{endpoint.ToString().TrimEnd('/')}/openai/deployments/{Uri.EscapeDataString(deployment)}/images/{operation}?api-version={Uri.EscapeDataString(apiVersion)}");

Now let's put both models to work on the scenarios Microsoft is targeting.

Use Case 1: Home Design — Iterative Generation That Holds Its Shape

The scenario from the announcement, minus the voice layer: a customer describes a kitchen, sees it rendered, and asks for a change — and the change should read as a revision, not a brand-new image that happe
ns to share a theme. Flare is the right choice here since this is a live iteration loop where responsiveness matters more than maximum fidelity.

async Task<byte[]> ReadImageResponseAsync(HttpResponseMessage response, Uri requestUri)
{
    var responseBody = await response.Content.ReadAsStringAsync();
    if (!response.IsSuccessStatusCode)
    {
        throw new HttpRequestException(
            $"Azure image request failed with HTTP {(int)response.StatusCode} ({response.ReasonPhrase}). " +
            $"Endpoint: {requestUri}\nResponse: {responseBody}");
    }

    using var json = JsonDocument.Parse(responseBody);
    var base64Image = json.RootElement
        .GetProperty("data")[0]
        .GetProperty("b64_json")
        .GetString();

    if (string.IsNullOrWhiteSpace(base64Image))
    {
        throw new InvalidOperationException("Azure image response did not contain data[0].b64_json.");
    }

    return Convert.FromBase64String(base64Image);
}

async Task<byte[]> GenerateKitchenDesignAsync(string description)
{
    GeneratedImage image = await flareClient.GenerateImageAsync(description, new ImageGenerationOptions
    {
        Size = new GeneratedImageSize(1536, 864)
    });
    return image.ImageBytes.ToArray();
}

async Task<byte[]> ReviseKitchenDesignAsync(byte[] currentImage, string revisionInstruction)
{
    var requestUri = CreateImageRequestUri(flareDeployment, "edits", imageEditApiVersion);
    using var form = new MultipartFormDataContent();
    using var imageContent = new ByteArrayContent(currentImage);
    imageContent.Headers.ContentType = new MediaTypeHeaderValue("image/png");
    form.Add(imageContent, "image[]", "kitchen-design.png");
    form.Add(new StringContent(revisionInstruction), "prompt");
    form.Add(new StringContent("1536x864"), "size");

    using var response = await httpClient.PostAsync(requestUri, form);
    return await ReadImageResponseAsync(response, requestUri);
}

Console.WriteLine("**************************** Case 1 ************************************");
Console.WriteLine("**** Home Design — Iterative Generation That Holds Its Shape ***********");

// First pass: the initial description.
byte[] kitchenV1 = await GenerateKitchenDesignAsync(
    "A modern kitchen with dark cabinets and a large center island, professional " +
    "interior photography style, natural daylight.");
await File.WriteAllBytesAsync("kitchen-v1.png", kitchenV1);
Console.WriteLine("Saved: kitchen-v1.png");

// Second pass: an edit against the same image, not a fresh prompt from scratch.
byte[] kitchenV2 = await ReviseKitchenDesignAsync(kitchenV1,
    "Make the lighting brighter and add natural wood accents to the cabinetry and " +
    "island. Keep the layout, camera angle, and overall composition the same.");
await File.WriteAllBytesAsync("kitchen-v2.png", kitchenV2);
Console.WriteLine("Saved: kitchen-v2.png");
Console.WriteLine("**************************** END Case 1 **********************************");

Expected Output

Saved: kitchen-v1.png
Saved: kitchen-v2.png

The important detail is which API call each step uses: the first pass is a plain generation, but the revision is an edit against the actual first image — not a second generation call with an updated prompt. That distinction is what keeps the island and the camera angle consistent between v1 and v2 instead of getting a completely different kitchen that happens to also have wood accents.

Use Case 2: Travel Planning — Exploration with Flare, Final Asset with Sunburst

Exploring destinations and itineraries generates a lot of throwaway previews for every one image a traveler actually keeps. This is the two-tier pattern the Flare/Sunburst split is built for: cheap, fast prev
iews during exploration, then a single higher-fidelity render once a direction is locked.

async Task<byte[]> PreviewDestinationAsync(string description)
{
    GeneratedImage preview = await flareClient.GenerateImageAsync(description, new ImageGenerationOptions
    {
        Size = GeneratedImageSize.W1024xH1024,
    });
    return preview.ImageBytes.ToArray();
}

async Task<byte[]> FinalizeItineraryImageAsync(string description)
{
    GeneratedImage final = await sunburstClient.GenerateImageAsync(description, new ImageGenerationOptions
    {
        Size =  new GeneratedImageSize(1536, 864)
    });
    return final.ImageBytes.ToArray();
}

Console.WriteLine("**************************** Case 2 ************************************");
Console.WriteLine("**** Travel Planning — Exploration with Flare, Final Asset with Sunburst *****");
// Exploration phase: quick, cheap previews as the traveler narrows down ideas.
string[] explorationPrompts =
[
    "A quiet coastal town in Portugal, whitewashed buildings, golden hour, travel photography style.",
    "Same coastal town, but with a small boat harbor visible and outdoor cafes along the water.",
];

foreach (var prompt in explorationPrompts)
{
    byte[] preview = await PreviewDestinationAsync(prompt);
    await File.WriteAllBytesAsync($"preview-{explorationPrompts.ToList().IndexOf(prompt)}.png", preview);
}



Console.WriteLine("Traveler picked the second preview - finalizing the itinerary card for day 3.");


byte[] finalCard = await FinalizeItineraryImageAsync(
    "A polished travel itinerary hero image: a coastal Portuguese town with a small boat harbor, " +
    "outdoor cafes, golden hour lighting, labeled 'Day 3: Coastal Harbor Town', clean readable text overlay.");
await File.WriteAllBytesAsync("itinerary-day3-final.png", finalCard);
Console.WriteLine("Saved: itinerary-day3-final.png");
Console.WriteLine("**************************** END Case 2 **********************************");

Expected Output

Traveler picked the second preview - finalizing the itinerary card for day 3.
Saved: itinerary-day3-final.png

Paying full Sunburst price for every exploratory preview doesn't make sense when most of them get discarded — this pattern only spends the higher-cost, higher-fidelity call once a customer has actually committ
ed to a direction.

Use Case 3: Education — Diagrams That Evolve With the Lesson

A student discusses a concept with an AI tutor and gets diagrams that evolve as the lesson progresses — not one static diagram handed over up front. Flare regenerates a diagram each time the topic shifts, whic
h only works if generation is fast enough to keep pace with a real conversation.

async Task<byte[]> GenerateLessonDiagramAsync(string concept)
{
    var prompt = $"""
        A clean, labeled educational diagram explaining: {concept}.
        Simple flat illustration style, high contrast, readable labels,
        suitable for a student-facing tutoring app.
        """;

    GeneratedImage diagram = await flareClient.GenerateImageAsync(prompt, new ImageGenerationOptions
    {
        Size = new GeneratedImageSize(1024, 1024)
    });
    return diagram.ImageBytes.ToArray();
}

// Simulated turns of a tutoring conversation - each turn shifts what the diagram needs to show.
var lessonTurns = new[]
{
    "how photosynthesis converts sunlight into energy in a plant cell",
    "how photosynthesis differs between C3 and C4 plants",
};

Console.WriteLine("**************************** Case 3 ************************************");
Console.WriteLine("**** Education — Diagrams That Evolve With the Lesson ******************");
foreach (var concept in lessonTurns)
{
    byte[] diagram = await GenerateLessonDiagramAsync(concept);
    string fileName = $"lesson-diagram-{lessonTurns.ToList().IndexOf(concept)}.png";
    await File.WriteAllBytesAsync(fileName, diagram);
    Console.WriteLine($"Saved: {fileName} (\\"{concept}\\")");
}

Console.WriteLine("**************************** END Case 3 **********************************");

Expected Output

Saved: lesson-diagram-0.png ("how photosynthesis converts sunlight into energy in a plant cell")
Saved: lesson-diagram-1.png ("how photosynthesis differs between C3 and C4 plants")

Wire this into a chat-driven tutoring UI and the diagram updates the moment a student asks a follow-up question — no separate "generate a diagram" button, no need for the student to describe what they want dra
wn in prompt-engineering terms.

Use Case 4: Retail Campaign Creative — Legible Text, Consistent Batches

Marketing and catalog work both come down to the same requirement: consistent output at volume, with headline text that's actually legible — historically the weak point of diffusion models. Here's a campaign b
anner from Sunburst (final quality matters) followed by a Flare batch of product catalog shots (volume matters more than maximum fidelity).

// Final campaign asset - precision and legible text matter more than speed here.
var campaignPrompt = """
    A wide-format e-commerce banner ad for a summer sale. Clean minimalist studio
    background in soft pastel blue. A pair of white running shoes floating at a
    slight angle, dramatic soft shadow beneath. Bold, perfectly legible headline
    text at the top reading "SUMMER SALE - 30% OFF" in a clean modern sans-serif
    font, white text with subtle drop shadow.
    """;

Console.WriteLine("**************************** Case 4 ************************************");
Console.WriteLine("**** Retail Campaign Creative — Legible Text, Consistent Batches *******");

GeneratedImage campaignAsset = await sunburstClient.GenerateImageAsync(campaignPrompt, new ImageGenerationOptions
{
    Size = new GeneratedImageSize(1536, 864)
});
await File.WriteAllBytesAsync("campaign-summer-sale-banner.png", campaignAsset.ImageBytes.ToArray());
Console.WriteLine("Saved: campaign-summer-sale-banner.png");

// Catalog batch - volume matters, Flare keeps cost and latency down across many SKUs.
var catalogItems = new[]
{
    new { Sku = "SKU-1001", Description = "a matte black ceramic coffee mug" },
    new { Sku = "SKU-1002", Description = "a glossy red ceramic coffee mug" },
    new { Sku = "SKU-1003", Description = "a sage green ceramic coffee mug" },
};

const string catalogStyleTemplate = """
    A studio product photo of {0} on a plain white seamless background, soft even
    lighting from the upper left, subtle reflection beneath, centered composition,
    e-commerce catalog style, no props, no text.
    """;

foreach (var item in catalogItems)
{
    var prompt = string.Format(catalogStyleTemplate, item.Description);
    GeneratedImage image = await flareClient.GenerateImageAsync(prompt, new ImageGenerationOptions
    {
        Size = new GeneratedImageSize(1024, 1024)
    });
    string outPath = $"catalog-{item.Sku}.png";
    await File.WriteAllBytesAsync(outPath, image.ImageBytes.ToArray());
    Console.WriteLine($"Saved: {outPath}");
}
Console.WriteLine("**************************** END Case 4 **********************************");

Expected Output

Saved: campaign-summer-sale-banner.png
Saved: catalog-SKU-1001.png
Saved: catalog-SKU-1002.png
Saved: catalog-SKU-1003.png

Open the campaign banner and check the headline text specifically — that's the failure mode this model generation is explicitly built to fix. And because the catalog template is fixed with only the description
swapped per SKU, lighting and framing stay consistent across the whole batch — swap the hardcoded array for a real product database and this loop becomes an overnight catalog-refresh job.

Use Case 5: Virtual Try-On — Multi-Turn Editing Without Drift

Virtual try-on lets a shopper preview an item and then adjust color, style, or setting — successive edits that need to stay consistent with each other, not drift with every change. This is Sunburst's precision
-editing strength: each edit builds on the last while the customer's pose, framing, and identity stay intact.

Console.WriteLine("**************************** Case 5 ************************************");
Console.WriteLine("******** Virtual Try-On — Multi-Turn Editing Without Drift *************");

async Task<byte[]> EditProductPhotoAsync(byte[] sourceImage, string editInstruction)
{
    var requestUri = CreateImageRequestUri(sunburstDeployment, "edits", imageEditApiVersion);
    using var form = new MultipartFormDataContent();
    using var imageContent = new ByteArrayContent(sourceImage);
    imageContent.Headers.ContentType = new MediaTypeHeaderValue("image/png");
    form.Add(imageContent, "image[]", "product-photo.png");
    form.Add(new StringContent(editInstruction), "prompt");
    form.Add(new StringContent("1024x1024"), "size");

    using var response = await httpClient.PostAsync(requestUri, form);
    return await ReadImageResponseAsync(response, requestUri);
}

byte[] originalPhoto = await File.ReadAllBytesAsync("customer-tryon-photo.png");

// Successive edits - each one builds on the last, and Sunburst is built to keep
// the customer's pose, framing, and identity consistent across all of them.
byte[] navyJacket = await EditProductPhotoAsync(originalPhoto,
    "Replace the jacket the person is wearing with a navy blue version of the same jacket style. " +
    "Keep the person's pose, face, and background exactly the same.");
await File.WriteAllBytesAsync("tryon-navy.png", navyJacket);

byte[] navyJacketOutdoors = await EditProductPhotoAsync(navyJacket,
    "Change the background to an outdoor city street setting. Keep the jacket color and the " +
    "person's pose and appearance exactly the same.");
await File.WriteAllBytesAsync("tryon-navy-outdoors.png", navyJacketOutdoors);

Console.WriteLine("Saved: tryon-navy.png, tryon-navy-outdoors.png");
Console.WriteLine("**************************** END Case 5 **********************************");

Expected Output

Saved: tryon-navy.png, tryon-navy-outdoors.png

Two edits deep, the customer's face, pose, and the jacket's shape are all still consistent — only the color and background changed, exactly as requested. That's "stronger multi-turn editing" in practice: the k
ind of drift where edit three quietly changes something from edit one is exactly what this release is built to avoid, and it's the difference between a try-on feature customers trust and one they give up on a
fter two tries.

Where This Fits (and Where It Doesn't)

Reach for Flare when:

You're iterating live with a user in the loop and latency matters more than maximum fidelity
You're generating at volume — catalogs, previews, personalization

Reach for Sunburst when:

The output is a final, ship-ready asset — a campaign hero image, a locked try-on result
Editing precision matters more than speed, especially across multiple successive edits

Don't reach for either when:

You need pixel-perfect brand-guideline compliance with zero human review — treat generated output as a strong first draft, not an approval-free final asset
Your workload depends on non-text modalities or file attachments the image APIs don't cover — check current capability docs before committing to a design

Wrapping Up

The pitch for GPT-image-2.5 isn't "one bigger image model" — it's a genuine two-tier portfolio: iterate fast with Flare, ship precise with Sunburst, and trust that a multi-turn edit chain won't quietly drift b
y the third revision. For .NET developers, both models sit behind the exact same ImageClient you already know from GPT-image-2 — the new surface area is picking which model fits which step of your workflow,
not learning a new SDK.

Resources

MAI Image 2.6 Lands in Foundry for C# Developers

Taswar Bhatti — Tue, 08 Sep 2026 07:54:23 +0000

Every time a new image model ships, I ask the same unglamorous question: can I actually put this in a pipeline, or is it just good at one pretty hero shot? Most image models nail the demo and fall apart the moment you need the fiftieth consistent variant of the same product, or a single surgical edit that doesn't quietly redraw everything else in the frame.

Microsoft AI just shipped two models that answer that question directly: MAI-Image-2.6 and MAI-Image-2.6-Flash, both now in public preview in Microsoft Foundry. They're not "one model, two names" — they're a genuine two-tier portfolio: one for maximum quality, one for maximum throughput, sharing the same capabilities underneath.

As always: no Python, no notebooks. Just C#, HttpClient, and a dotnet run.

What Actually Shipped

A few facts worth knowing before you touch any code:

MAI-Image-2.6 is independently verified as frontier-tier. No. 2 on the Arena text-to-image leaderboard at launch, ahead of Google's Nano Banana family and Meta's Muse Image. No. 3 on Arena's image-editing leaderboard, and No. 1 for image editing on Artificial Analysis. This isn't a marketing claim you have to take on faith — it's ranked against the models you're probably already comparing against.
Multi-reference editing. MAI-Image-2.6 accepts up to five reference images in a single request. Lock a product, a character, or a brand mark, and it stays consistent as you revise, resize, and reformat it. One approved concept travels across channel formats without drifting.
Web grounding. The model can pull real-world context from Bing Search instead of relying only on training data — meaningfully better accuracy for real places, objects, events, and subjects.
Explicit control over format and resolution. Adaptive aspect ratios, 1.5K output resolution, and levers over how much the model deliberates before generating — so the same model family serves both a fast iteration loop and a final production render.
MAI-Image-2.6-Flash is the throughput tier. More than 2x faster than GPT-Image-2-Medium and roughly 72–78% more efficient than GPT-Image-2, depending on the metric. Built for interactive apps, automated pipelines, and personalization at volume.
Pricing. MAI-Image-2.6 starts at $5/1M text input tokens, $8/1M image input tokens, $38/1M image output tokens. MAI-Image-2.6-Flash starts at $1.75/1M text input, $2.50/1M image input, $19/1M image output — genuinely cheap enough to generate per-user variants without flinching.
Enterprise-ready by default. Delivered as a Foundry Model sold directly by Azure — Entra ID auth, RBAC, key-based access, Azure data-handling commitments. Prompts and outputs are not used to train the models.

Choosing Between Them

This isn't "pick the cheap one or the good one." It's a real division of labor:

MAI-Image-2.6 — final campaign assets, complex multi-reference edits, high-fidelity text rendering, anything where precision is the point
MAI-Image-2.6-Flash — rapid iteration, interactive experiences, personalization, high-volume generation, anything where throughput is the point

The intended workflow: explore and iterate with Flash, then render the final asset with MAI-Image-2.6 once the direction is locked. You'll see exactly that pattern in the code below.

Prerequisites

dotnet new console -n MaiImage26FoundryDemo
cd MaiImage26FoundryDemo
dotnet add package Azure.Core
dotnet add package Azure.Identity
dotnet add package Microsoft.Extensions.Configuration.UserSecrets
dotnet add package Microsoft.Extensions.Configuration.EnvironmentVariables
dotnet user-secrets init
dotnet user-secrets set "AZURE_AI_FOUNDRY_ENDPOINT" "https://YOUR-RESOURCE.services.ai.azure.com"

Deploy both MAI-Image-2.6 and MAI-Image-2.6-Flash from the Foundry Model Catalog to your project — same process as any other model.

📝 Note: MAI-Image models aren't compatible with the Azure.AI.OpenAI SDK's ImageClient — they require the raw REST call against Foundry's images endpoint, same as MAI-Image-2.5. The exact API surface is still settling in public preview, so confirm request/response shapes against the Foundry Model Catalog before shipping anything to production.

Here's a small shared helper both examples below build on — auth token + a reusable POST helper:

using Azure.Core;
using Azure.Identity;
using Microsoft.Extensions.Configuration;
using System.Net.Http.Headers;
using System.Text;
using System.Text.Json;

var config = new ConfigurationBuilder()
    .AddUserSecrets<Program>()
    .AddEnvironmentVariables()
    .Build();

var endpoint = config["AZURE_AI_FOUNDRY_ENDPOINT"]
    ?? throw new InvalidOperationException(
        "AZURE_AI_FOUNDRY_ENDPOINT is not set. Run: dotnet user-secrets set \"AZURE_AI_FOUNDRY_ENDPOINT\" \"<your-endpoint>\"");

var credential = new DefaultAzureCredential();
AccessToken token = await credential.GetTokenAsync(
    new TokenRequestContext(new[] { "https://cognitiveservices.azure.com/.default" }));

using var http = new HttpClient();
http.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", token.Token);

async Task<byte[]> GenerateImageAsync(string model, string prompt, int width = 1024, int height = 1024)
{
    string url = $"{endpoint.TrimEnd('/')}/mai/v1/images/generations?api-version=preview";

    var payload = new
    {
        prompt,
        model,
        width,
        height,
        output_compression = 100,
        output_format = "png",
        n = 1
    };

    using var content = new StringContent(JsonSerializer.Serialize(payload), Encoding.UTF8, "application/json");
    using HttpResponseMessage response = await http.PostAsync(url, content);
    string body = await response.Content.ReadAsStringAsync();

    if (!response.IsSuccessStatusCode)
    {
        throw new InvalidOperationException($"{model} generation failed: {(int)response.StatusCode} {response.ReasonPhrase}\n{body}");
    }

    using JsonDocument json = JsonDocument.Parse(body);
    string b64 = json.RootElement.GetProperty("data")[0].GetProperty("b64_json").GetString()
        ?? throw new InvalidOperationException("Response missing data[0].b64_json.");

    return Convert.FromBase64String(b64);
}

Now let's put both models to work on the actual use cases Microsoft is targeting.

Use Case 1: Marketing & Campaign Production — Legible Text, First Try

Text rendering inside generated images has historically been the weak point of diffusion models — garbled letters, wrong spacing, headlines that look right at a glance and fall apart on inspection. MAI-Image-2.6's quality step-up specifically targets this.

var campaignPrompt = """
    A wide-format e-commerce banner ad for a summer sale. Clean minimalist studio
    background in soft pastel blue. A pair of white running shoes floating at a
    slight angle, dramatic soft shadow beneath. Bold, perfectly legible headline
    text at the top reading "SUMMER SALE — 30% OFF" in a clean modern sans-serif
    font, white text with subtle drop shadow. Small subtext below reading
    "Limited time only" in a lighter weight. Professional advertising photography
    style, high detail, 1.5K resolution.
    """;

byte[] campaignAsset = await GenerateImageAsync("MAI-Image-2.6", campaignPrompt, width: 1536, height: 864);
await File.WriteAllBytesAsync("campaign-summer-sale-banner.png", campaignAsset);
Console.WriteLine("Saved: campaign-summer-sale-banner.png");

Expected Output

Saved: campaign-summer-sale-banner.png

Open the file and check the headline text specifically — that's the thing to inspect closely, since it's the failure mode this model is explicitly built to fix. If your marketing team currently routes every hero banner through a designer for text placement and kerning, this is the workflow to pilot first: generate ten headline variants overnight, let the team pick the one that needs the least manual cleanup.

Use Case 2: Retail & E-Commerce Catalogs — Consistent Imagery at Volume

Catalogs live and die on consistency: same lighting, same framing, same background across hundreds of SKUs. Here's a batch pattern using Flash for the volume — this is exactly the "millionth personalized variant" scenario Flash is priced for.

var catalogItems = new[]
{
    new { Sku = "SKU-1001", Description = "a matte black ceramic coffee mug" },
    new { Sku = "SKU-1002", Description = "a glossy red ceramic coffee mug" },
    new { Sku = "SKU-1003", Description = "a sage green ceramic coffee mug" },
    new { Sku = "SKU-1004", Description = "a cream white ceramic coffee mug" },
};

const string catalogStyleTemplate = """
    A studio product photo of {0} on a plain white seamless background,
    soft even lighting from the upper left, subtle reflection beneath,
    centered composition, e-commerce catalog style, no props, no text.
    """;

foreach (var item in catalogItems)
{
    var prompt = string.Format(catalogStyleTemplate, item.Description);
    byte[] image = await GenerateImageAsync("MAI-Image-2.6-Flash", prompt);
    string outPath = $"catalog-{item.Sku}.png";
    await File.WriteAllBytesAsync(outPath, image);
    Console.WriteLine($"Saved: {outPath}");
}

Expected Output

Saved: catalog-SKU-1001.png
Saved: catalog-SKU-1002.png
Saved: catalog-SKU-1003.png
Saved: catalog-SKU-1004.png

Because the style template is fixed and only the product description changes, lighting and framing stay consistent across the whole batch. Swap this loop to read SKUs from your actual product database and you have an overnight catalog-refresh job instead of a photo studio booking.

Use Case 3: Brand & Creative Operations — Multi-Reference Editing

This is the capability that's genuinely new in 2.6: up to five reference images in a single request, so a locked brand asset — a mascot, a product shape, a logo mark — stays consistent as you reformat it for different channels. Here's a helper for a multi-reference edit call, followed by locking a product across three different channel formats.

async Task<byte[]> EditWithReferencesAsync(string model, string editPrompt, params string[] referenceImagePaths)
{
    if (referenceImagePaths.Length == 0 || referenceImagePaths.Length > 5)
    {
        throw new ArgumentException("Provide between 1 and 5 reference images.");
    }

    string url = $"{endpoint.TrimEnd('/')}/mai/v1/images/edits?api-version=preview";

    using var content = new MultipartFormDataContent
    {
        { new StringContent(editPrompt), "prompt" },
        { new StringContent(model), "model" }
    };

    foreach (var path in referenceImagePaths)
    {
        byte[] bytes = await File.ReadAllBytesAsync(path);
        var imagePart = new ByteArrayContent(bytes);
        imagePart.Headers.ContentType = new System.Net.Http.Headers.MediaTypeHeaderValue("image/png");
        content.Add(imagePart, "image", Path.GetFileName(path));
    }

    using HttpResponseMessage response = await http.PostAsync(url, content);
    string body = await response.Content.ReadAsStringAsync();

    if (!response.IsSuccessStatusCode)
    {
        throw new InvalidOperationException($"{model} multi-reference edit failed: {(int)response.StatusCode} {response.ReasonPhrase}\n{body}");
    }

    using JsonDocument json = JsonDocument.Parse(body);
    string b64 = json.RootElement.GetProperty("data")[0].GetProperty("b64_json").GetString()
        ?? throw new InvalidOperationException("Response missing data[0].b64_json.");

    return Convert.FromBase64String(b64);
}

// Lock a brand mascot + product shape as references, then reformat for three channels.
var channelFormats = new[]
{
    ("instagram-square.png", "Recompose for an Instagram square post (1:1), mascot on the right, product centered-left."),
    ("story-vertical.png", "Recompose for a 9:16 vertical story format, mascot at the bottom, product taking up the upper two-thirds."),
    ("banner-wide.png", "Recompose for a wide horizontal banner (16:9), mascot and product side by side with even spacing."),
};

foreach (var (fileName, formatPrompt) in channelFormats)
{
    byte[] reformatted = await EditWithReferencesAsync(
        "MAI-Image-2.6",
        formatPrompt + " Keep the mascot design, product shape, and brand colors identical to the references.",
        "brand-mascot-reference.png",
        "product-shape-reference.png");

    await File.WriteAllBytesAsync(fileName, reformatted);
    Console.WriteLine($"Saved: {fileName}");
}

Expected Output

Saved: instagram-square.png
Saved: story-vertical.png
Saved: banner-wide.png

Same mascot, same product, same brand colors — three different channel-native compositions, generated from two locked reference images instead of a designer manually recreating the layout three times. This is the actual "one approved concept travels across formats without drifting" pitch, and it's the reason multi-reference editing is the headline feature of this release.

Use Case 4: Personalization at Scale — Flash in an Interactive Loop

Flash's pricing and latency profile make per-user or per-segment generation viable inside a live request path, not just a batch job. Here's a minimal pattern for a personalized greeting card generator — the kind of feature you'd wire into an app, not run overnight.

async Task<byte[]> GeneratePersonalizedCardAsync(string recipientName, string occasion, string themeColor)
{
    var prompt = $"""
        A festive greeting card illustration for a {occasion} celebration.
        Hand-lettered style text reading "Happy {occasion}, {recipientName}!"
        centered at the top. Warm {themeColor} color palette, soft decorative
        flourishes around the border, friendly and celebratory illustration style,
        square format.
        """;

    return await GenerateImageAsync("MAI-Image-2.6-Flash", prompt, width: 1024, height: 1024);
}

// Simulates generating cards for a batch of users in an interactive path —
// fast enough per-call that this could sit behind a live API endpoint.
var requests = new[]
{
    ("Priya", "Birthday", "coral and gold"),
    ("Marcus", "Work Anniversary", "navy and silver"),
    ("Aiko", "Graduation", "sage green and cream"),
};

foreach (var (name, occasion, colors) in requests)
{
    var started = DateTime.UtcNow;
    byte[] card = await GeneratePersonalizedCardAsync(name, occasion, colors);
    var elapsed = DateTime.UtcNow - started;

    string fileName = $"card-{name.ToLowerInvariant()}.png";
    await File.WriteAllBytesAsync(fileName, card);
    Console.WriteLine($"Saved: {fileName} ({elapsed.TotalSeconds:F1}s)");
}

Expected Output

Saved: card-priya.png (2.1s)
Saved: card-marcus.png (1.9s)
Saved: card-aiko.png (2.0s)

(Timings above are illustrative — measure against your own Foundry deployment region and load. The point of the pattern is that Flash's latency profile makes this loop viable inside a request/response cycle, not that these exact numbers are guaranteed.)

Swap the hardcoded array for real user data from your app, and this same loop becomes a "generate a personalized asset on demand" endpoint behind an API controller.

Use Case 5: Image Cleanup & Surgical Editing

The other side of multi-reference editing is single-image precision editing — targeted object edits, replacements, inpainting, text updates, and artifact removal, without regenerating the whole scene. This is the same surgical-edit pattern from MAI-Image-2.5, still very much present in 2.6.

var cleanupPrompt = """
    Remove the motion blur from the product in this image and sharpen the focus.
    Replace the scuffed cardboard background with a clean plain white studio
    background. Keep the product's position, angle, and proportions exactly
    the same — do not regenerate or redesign the product itself.
    """;

byte[] cleanedUp = await EditWithReferencesAsync(
    "MAI-Image-2.6",
    cleanupPrompt,
    "warehouse-photo-raw.png");

await File.WriteAllBytesAsync("product-cleaned.png", cleanedUp);
Console.WriteLine("Saved: product-cleaned.png");

Expected Output

Saved: product-cleaned.png

This is the unglamorous, high-volume use case that actually pays for itself: a warehouse team's phone-camera product shots turned into catalog-ready images without a reshoot. The product itself is untouched — only the blur and background changed.

Where This Fits (and Where It Doesn't)

Reach for MAI-Image-2.6 when:

You need final, ship-ready campaign assets with legible, precise text rendering
You're locking a brand asset across multiple reference images and need it to survive reformatting
Editing precision matters more than generation speed

Reach for MAI-Image-2.6-Flash when:

You're generating at volume — catalogs, personalization, high-throughput pipelines
Latency matters because the call sits inside an interactive user-facing path
You're iterating on concepts before committing to a final MAI-Image-2.6 render

Don't reach for either when:

You need pixel-perfect brand-guideline compliance without any human review — treat generated output as a strong first draft, not a final approval-free asset
Your workload depends on an SDK-level ImageClient integration today — you're on raw REST calls for now, and the API surface is still settling in public preview

Wrapping Up

MAI-Image-2.6 and MAI-Image-2.6-Flash aren't "the same model, one slower." They're a genuine quality/throughput portfolio: iterate fast with Flash, ship precise with 2.6, and use multi-reference editing to keep one approved creative direction consistent across every format your marketing or product team actually needs. If your team is currently paying someone to manually generate the fiftieth catalog variant or resize one approved hero image into six channel formats by hand — this is worth a real pilot, not just a demo.

Resources

GPT-6 Astra Is Now Generally Available in Foundry — What It Means If You Write C#

Taswar Bhatti — Mon, 07 Sep 2026 07:49:00 +0000

The next era of enterprise AI isn't going to be defined by chat experiences. It's going to be defined by how well a model can actually work for you — not just talk at you. GPT-6 Astra, OpenAI's newest frontier model, is now generally available for all customers in Microsoft Foundry. Instead of optimizing for "answer this one prompt well," Astra is built to take an open-ended challenge, reason through it in multiple steps, create a plan, and hand you a finished result.

That's a meaningfully different design target, and it's the kind of thing that matters once you move past demos and start building agents that have to survive contact with real workloads — where the interesting part isn't the model call, it's everything Foundry brings around it: identity, networking, governance, data handling, evaluation, compliance.

As always: no Python required, no notebook required. Just Microsoft.Extensions.AI and dotnet run.

What GPT-6 Astra Actually Is

A few things worth knowing before you touch any code:

Deliberate planning and decision support. Astra breaks a challenge into steps, evaluates options, communicates its recommendation, and identifies next actions for review — rather than just returning a single best-effort answer.
Polished, purposeful output. It applies context, templates, and quality standards throughout a workflow, aiming to produce documents, spreadsheets, presentations, and analyses that are ready for expert review, not rough drafts.
Execution across applications. With advanced tool use and computer use, Astra can interact with software on a person's behalf, move between apps, and complete multi-step tasks with appropriate human oversight — including workflows that have no dedicated API.
Long-context understanding. Up to 1,050,000 total context tokens, so large repositories, filings, and multi-document knowledge bases can be reasoned about in one pass instead of chunked and reassembled.
Enterprise controls by default. Microsoft Entra identity and access management, encryption in transit and at rest, private networking, RBAC, content filtering, safety evaluations, and monitoring. Prompts and outputs are not used to train the models.
Generally available. Not preview — this is production-ready in Foundry today.

Why This Matters for .NET Developers Specifically

The enterprise scenarios Microsoft is calling out map directly onto real .NET workloads:

Software engineering — reproduce complex bugs, investigate likely causes, propose fixes, and prepare changes for developer testing and review
Business intelligence — build and refine dashboards in Power BI, compare data, identify trade-offs, and prepare insights to share
Professional work — produce documents, spreadsheets, and presentations that follow existing templates and business standards
Application workflows — update customer records, process forms, test websites, and work through approved interfaces where dedicated APIs are limited
Financial services — synthesize filings, market data, and internal research into an investment point of view, then draft client-ready materials in a firm's house style
Customer experience — resolve tickets rather than route them: research the issue, act in CRM and billing, close the loop

And because Astra is a native OpenAI model in Foundry — not a partner/MaaS model — it slots in through the exact same AzureOpenAIClient + IChatClient pattern you already use for GPT-4o or GPT-chat-latest. No special client, no bearer-token workaround. Swapping Astra into your evaluation pipeline is a deployment-name change, not a rewrite.

Getting Started

dotnet new console -n GptSixAstraDemo
cd GptSixAstraDemo
dotnet add package Azure.AI.OpenAI
dotnet add package Microsoft.Extensions.AI
dotnet add package Azure.Identity
dotnet add package Microsoft.Extensions.Configuration.UserSecrets
dotnet add package Microsoft.Extensions.Configuration.EnvironmentVariables
dotnet add package Microsoft.Extensions.AI.OpenAI
dotnet user-secrets init
dotnet user-secrets set "AZURE_AI_ENDPOINT" "https://your-resource.services.ai.azure.com"

Deploy gpt-6-astra from the Foundry Model Catalog to your project — same process as any other model. Grab your endpoint and deployment name, and you're ready to go.

Use Case 1: Software Engineering — Deliberate Bug Investigation and Fix Proposal

This is the headline scenario: Astra reproducing a complex bug, investigating likely causes, and proposing a fix for developer review — not guessing from a stack trace alone. Let's build a small agent that pulls recent error logs and the relevant code change history before it commits to a root cause, reasoning through both signals together instead of pattern-matching on the first plausible explanation.

#pragma warning disable OPENAI001 // Responses API is experimental in the OpenAI .NET SDK
using Azure.Identity;
using Microsoft.Extensions.AI;
using Microsoft.Extensions.Configuration;
using OpenAI.Responses;
using System.ClientModel.Primitives;
using System.ComponentModel;

var config = new ConfigurationBuilder()
    .AddUserSecrets<Program>()
    .AddEnvironmentVariables()
    .Build();

var deploymentName = config["AZURE_OPENAI_DEPLOYMENT"] ?? "gpt-6-astra";
var resourceEndpoint = config["AZURE_AI_ENDPOINT"]
    ?? throw new InvalidOperationException(
        "AZURE_AI_ENDPOINT is not set. Run: dotnet user-secrets set \"AZURE_AI_ENDPOINT\" \"<your-endpoint>\"");

// The Responses API is only reachable on the v1 surface, not the deployments/api-version surface.
var responsesEndpoint = new Uri($"{resourceEndpoint.TrimEnd('/')}/openai/v1");
var tokenPolicy = new BearerTokenPolicy(new DefaultAzureCredential(), "https://ai.azure.com/.default");

// gpt-6-astra doesn't allow tools + reasoning_effort on /chat/completions; use /responses instead.
IChatClient chatClient = new ResponsesClient(
        authenticationPolicy: tokenPolicy,
        options: new ResponsesClientOptions { Endpoint = responsesEndpoint })
    .AsIChatClient(deploymentName)
    .AsBuilder()
    .UseFunctionInvocation()
    .Build();

var chatOptions = new ChatOptions
{
    Tools =
    [
        AIFunctionFactory.Create(GetRecentErrorLogs),
        AIFunctionFactory.Create(GetRecentCommits)
    ],
    // Deep, multi-step decision support — worth paying for higher reasoning effort.
    AdditionalProperties = new AdditionalPropertiesDictionary
    {
        ["reasoning_effort"] = "high" // low | medium | high
    }
};

var messages = new List<ChatMessage>
{
    new(ChatRole.System,
        "You are a senior engineer investigating a production bug. Pull both recent error " +
        "logs and recent commit history before concluding a root cause. State your recommended " +
        "fix, your confidence level, and the next action a human reviewer should take."),
    new(ChatRole.User, "Users report 'checkout-api' intermittently returns HTTP 500 on order submission since this morning. What's going on and what should we do?")
};

var response = await chatClient.GetResponseAsync(messages, chatOptions);
Console.WriteLine(response.Text);

// --- Tool stand-ins for real observability/source-control APIs ---

[Description("Gets recent error log entries for a named service.")]
static string GetRecentErrorLogs(
    [Description("The service name, e.g. checkout-api")] string serviceName)
{
    return serviceName switch
    {
        "checkout-api" => "09:14 NullReferenceException at OrderTotalCalculator.Apply(discount). " +
                           "Occurs on ~8% of requests, only when a promo code is present.",
        _ => "No recent errors found."
    };
}

[Description("Gets a summary of recent commits merged to a named service's main branch.")]
static string GetRecentCommits(
    [Description("The service name, e.g. checkout-api")] string serviceName)
{
    return serviceName switch
    {
        "checkout-api" => "06:40 - 'Refactor discount pipeline to support stacked promo codes' " +
                           "(touches OrderTotalCalculator.cs, PromoCodeResolver.cs).",
        _ => "No recent commits found."
    };
}

Case 1 – Output

**Likely cause:** a regression in promo-code handling from the discount-pipeline refactor
merged at **06:40**.

Evidence:
- Recent logs show a **`NullReferenceException` at `OrderTotalCalculator.Apply(discount)`**
  at 09:14, affecting roughly **8% of requests**, only when a promo code is present.
- The refactor, "support stacked promo codes," changed both `OrderTotalCalculator.cs` and
  `PromoCodeResolver.cs`, directly overlapping the failing path.

This suggests the new pipeline permits a null value that the calculator does not handle.
The exact null reference — and whether that commit was deployed before failures began —
still needs confirmation.

**Recommended fix**
- **Mitigate:** if deployment timing confirms the correlation, roll back the refactor
  through the normal incident process, provided rollback is safe.
- **Patch:** inspect the resolver-to-calculator contract and explicitly handle absent or
  invalid discount results according to intended promo behavior. Don't simply swallow the
  exception or silently charge an undiscounted total.
- Add regression tests for invalid, expired, unresolved, and stacked promo codes, plus
  orders without promos.

**Confidence:** high that the failure is in promo discount handling; moderate that this
specific commit caused it until deployment history and the diff are verified.

**Next human action:** have the on-call reviewer confirm when the 06:40 commit reached
production and review the two changed files against the exception stack. If confirmed and
safe, approve rollback, then monitor checkout 500 rates and promo-order success. Before
retrying affected orders, verify whether failed requests created any orders or payments.

Notice Astra doesn't stop at "here's an exception" — it correlates the error with why it started happening (a specific recent change), proposes a concrete fix, states its confidence, and hands off a clear next action. That's the "planning and decision support" Microsoft is describing, applied to something every .NET team actually deals with.

Use Case 2: Business Intelligence — Power BI Insight Synthesis

The second headline scenario is business intelligence: comparing data, identifying trade-offs, and preparing insights someone can act on. Here's a pattern for feeding Astra a dataset summary — the kind of thing you'd pull from a Power BI dataset via the REST API — and getting back a structured, decision-ready recommendation instead of a paragraph you have to re-read three times.

using System.Text.Json.Serialization;

var chatOptionsBI = new ChatOptions
{
    ResponseFormat = ChatResponseFormat.ForJsonSchema<RegionalInsight>()
};

var biMessages = new List<ChatMessage>
{
    new(ChatRole.System,
        "You are a BI analyst. Given quarterly regional sales data, identify the clearest " +
        "trade-off, recommend one action, and flag anything that needs a human to verify " +
        "before it goes in a report."),
    new(ChatRole.User, """
        Q3 regional sales summary (vs. Q2):
        - West: revenue +18%, returns +22%, avg order value flat
        - East: revenue +4%, returns -3%, avg order value +11%
        - Central: revenue -6%, returns +2%, avg order value -9%
        What should we highlight to leadership, and what's the trade-off?
        """)
};

var biResponse = await chatClient.GetResponseAsync<RegionalInsight>(biMessages, chatOptionsBI);
var insight = biResponse.Result;

Console.WriteLine("Case 2: Business Intelligence — Power BI Insight Synthesis");
Console.WriteLine("****************************************************");
Console.WriteLine($"Headline: {insight.Headline}");
Console.WriteLine($"Trade-off: {insight.TradeOff}");
Console.WriteLine($"Recommended action: {insight.RecommendedAction}");
Console.WriteLine($"Needs human verification: {insight.NeedsVerification}");
Console.WriteLine("****************************************************");

record RegionalInsight(
    [property: JsonPropertyName("headline")] string Headline,
    [property: JsonPropertyName("trade_off")] string TradeOff,
    [property: JsonPropertyName("recommended_action")] string RecommendedAction,
    [property: JsonPropertyName("needs_verification")] string NeedsVerification);

Case 2 – Output

Headline: West leads revenue growth (+18%), but rising returns warrant scrutiny. East
shows more balanced improvement; Central is weakening across all three metrics.
Trade-off: West's strong revenue growth comes alongside a larger percentage increase in
returns (+22%), with average order value flat — potentially offsetting some growth
benefits. East grows more slowly (+4%) but combines fewer returns (-3%) with higher
average order value (+11%). Profitability cannot be determined from these figures alone.
Recommended action: Prioritize a review of West's return drivers by product and channel
before committing additional growth investment.
Needs human verification: Confirm whether returns means count, dollar value, or return
rate; whether revenue is gross or net of returns; and the underlying Q2/Q3 totals. A 22%
increase in returns versus 18% revenue growth does not by itself establish a higher
return rate or lower profit. Check return timing and seasonal effects before attributing
the changes to Q3 performance.

That last field is doing real work: Astra is explicit about where the data runs out and a human needs to step in, instead of confidently inventing a root cause it can't actually support. Wire the structured fields straight into a Power BI custom visual, a Teams card, or an email digest — no regex-parsing a paragraph to extract "what do I actually do with this."

Use Case 3: Professional Work — Template-Based Report Generation

The third scenario: producing documents that follow existing templates and business standards, polished enough for expert review rather than a rough draft. Here's Astra generating a weekly status report against a fixed template structure — the kind of thing that normally eats twenty minutes of a project lead's Friday afternoon.

var reportMessages = new List<ChatMessage>
{
    new(ChatRole.System, """
        You produce weekly status reports for a project template with exactly these
        sections, in this order: Summary, Progress This Week, Risks, Next Week.
        Keep tone professional and concise. Do not invent details not provided.
        """),
    new(ChatRole.User, """
        Project: Order Fulfillment Modernization
        Raw notes from the team:
        - Migrated inventory sync job to the new event bus, passed load testing
        - Warehouse API integration is 2 days behind schedule due to a vendor sandbox outage
        - Next week: finish warehouse API integration, start UAT with ops team
        - Risk: vendor sandbox reliability could delay UAT start if it recurs
        """)
};

var reportResponse = await chatClient.GetResponseAsync(reportMessages);
Console.WriteLine(reportResponse.Text);

Case 3 – Output

## Summary
Order Fulfillment Modernization progressed with the inventory sync migration completed
and load testing passed. Warehouse API integration is two days behind schedule.

## Progress This Week
- Migrated the inventory sync job to the new event bus and passed load testing.
- Warehouse API integration fell two days behind schedule due to a vendor sandbox outage.

## Risks
- Recurring vendor sandbox outages could delay the start of UAT.

## Next Week
- Finish warehouse API integration.
- Start UAT with the operations team.

This is deliberately unglamorous, and that's the point — Astra didn't editorialize, didn't invent a risk that wasn't in the notes, and stuck to the exact template structure. That's the difference between "ready for expert review" and "needs to be rewritten before anyone sees it."

Use Case 4: Application Workflows — Acting Through Approved Interfaces

The fourth scenario is the one without a clean API: updating customer records, processing forms, and working through approved interfaces where a dedicated API is limited or doesn't exist. Full computer-use automation is a Foundry-side capability with its own configuration, approvals, and monitoring — but the same tool-driven pattern applies at the code level. Here's Astra deciding what action to take and why, with the actual system interaction going through a scoped, human-approved tool rather than the model touching anything directly.

var workflowChatOptions = new ChatOptions
{
    Tools =
    [
        AIFunctionFactory.Create(LookUpCustomerRecord),
        AIFunctionFactory.Create(ProposeRecordUpdate)
    ]
};

var workflowMessages = new List<ChatMessage>
{
    new(ChatRole.System,
        "You process customer update requests submitted via a support form. Look up the " +
        "current record before proposing any change. Never apply an update directly — " +
        "only propose it for a human approver to confirm."),
    new(ChatRole.User, "Form submission: customer ACC-4471 says their billing email should now be finance@northwind-retail.com instead of the old one.")
};

var workflowResponse = await chatClient.GetResponseAsync(workflowMessages, workflowChatOptions);
Console.WriteLine(workflowResponse.Text);

// --- Scoped tool stand-ins — the model proposes, a human/approved system applies ---

[Description("Looks up a customer record by account ID.")]
static string LookUpCustomerRecord(
    [Description("The account ID, e.g. ACC-4471")] string accountId)
{
    return accountId switch
    {
        "ACC-4471" => "Account: Northwind Retail. Current billing email: billing-old@northwind-retail.com. Status: active.",
        _ => "Account not found."
    };
}

[Description("Proposes a record update for human approval. Does not apply the change.")]
static string ProposeRecordUpdate(
    [Description("The account ID")] string accountId,
    [Description("The field to change")] string field,
    [Description("The new value")] string newValue)
{
    return $"Proposed update queued for approval: {accountId} / {field} -> {newValue}. Awaiting reviewer confirmation.";
}

Case 4 – Output

Proposed billing email change for **Northwind Retail (ACC-4471)**:
- **Current:** billing-old@northwind-retail.com
- **Proposed:** finance@northwind-retail.com

The proposal is queued for human approval. No change has been applied.

That "propose, don't apply" boundary is the whole game here. The announcement is explicit about this: computer-use capability demands containment, with scoped credentials, approved resources, and human checkpoints for consequential actions. Your AIFunction tools are exactly where you enforce that boundary in code — a lookup tool that reads, and a propose tool that never writes without a human in the loop.

Use Case 5: Financial Services — Long-Context Synthesis Into an Investment Point of View

The fifth scenario leans on Astra's up-to-1M-token context: synthesizing filings, market data, and internal research into a point of view, then drafting client-ready materials in a firm's house style. You don't need a chunking/retrieval pipeline for a single filing plus a research note — just pass the whole thing in.

var filingExcerpt = await File.ReadAllTextAsync("northwind-q3-10q-excerpt.txt");
var researchNote = await File.ReadAllTextAsync("internal-analyst-note.txt");

var financeMessages = new List<ChatMessage>
{
    new(ChatRole.System,
        "You are a financial analyst assistant. Synthesize the filing excerpt and internal " +
        "note into a one-page investment point of view, in the firm's house style: " +
        "Thesis, Supporting Evidence, Risks, Recommendation. Cite which source each point " +
        "came from (filing or internal note)."),
    new(ChatRole.User, $"""
        FILING EXCERPT:
        {filingExcerpt}

        INTERNAL ANALYST NOTE:
        {researchNote}

        Draft the point of view.
        """)
};

var financeResponse = await chatClient.GetResponseAsync(financeMessages);
Console.WriteLine(financeResponse.Text);

Case 5 – Output

## Northwind | Q3 Investment Point of View

### Thesis
**Operational execution is improving, but the durability and cash returns of those
improvements remain unproven.** Sales growth, better inventory productivity, and lower
fulfillment costs support a constructive operating outlook. Internal checks corroborate
several efficiency gains, but heavier promotions, elevated shrink, and rising automation
spending temper confidence that recent margin improvement will persist. **[Filing;
Internal note]**

### Supporting Evidence
- **Growth is supported by both existing stores and digital demand.** Q3 net sales rose
  6.8% to $1.84 billion, including 3.1% comparable-store growth. E-commerce grew 14% to
  27% of revenue, while fulfillment cost per order fell 8%. Field checks independently
  corroborate lower last-mile costs and continued strong online order growth. **[Filing;
  Internal note]**
- **Efficiency gains extend across merchandise and operating expenses.** Gross margin
  increased 90 basis points to 35.7%, reflecting lower freight costs, fewer markdowns,
  and favorable mix. SG&A declined to 24.1% of sales from 24.8%. Internal observations
  support productivity benefits from labor scheduling and reduced manual handling
  through distribution-center automation. **[Filing; Internal note]**
- **Inventory and supplier execution are stronger.** Inventory rose just 2.4%, below
  sales growth, and turns improved to 4.6 from 4.2. On-time, in-full supplier deliveries
  increased to 93% from 88%. Store visits and supplier conversations corroborate better
  availability at high-volume locations and fewer expedited replenishment requests.
  **[Filing; Internal note]**
- **Cash generation improved, although investment demands are rising.** Operating cash
  flow increased to $198 million from $141 million. Separately, year-to-date capital
  expenditures rose to $126 million from $82 million, making investment discipline
  increasingly important to the cash-flow outlook. **[Filing]**

### Risks
- **Margin gains face emerging pressure.** Analysts observed heavier late-Q3 promotions
  in discretionary categories, challenging the sustainability of the filing's markdown
  benefit. Shrink increased to 1.8% of sales from 1.6%, with urban-market checks
  indicating continued losses despite additional prevention measures. Hourly wages rose
  4.5%, creating expense pressure if sales moderate. **[Filing; Internal note]**
- **Automation benefits lack a clear spending boundary.** Quarterly supply-chain
  automation capex reached $74 million versus $49 million a year earlier, its third
  consecutive quarterly increase. No capex ceiling is disclosed; internal analysts flag
  the timing of returns as increasingly important. Continued spending could constrain
  free cash flow if savings or working-capital benefits disappoint. **[Filing; Internal
  note]**
- **Expansion and seasonal inventory introduce execution risk.** Northwind opened 12
  stores and closed five, ending Q3 with 486 locations. Internal checks suggest healthy
  new-store traffic but corroborate below-mature-store productivity. Earlier holiday
  inventory arrivals reduce near-term stockout risk while increasing markdown exposure
  if demand falls short. **[Filing; Internal note]**
- **Digital cost savings are not yet a service differentiator.** Customer sentiment on
  delivery speed has not materially improved, and returns remain a meaningful
  fulfillment expense. These findings temper the investment case for continued digital
  efficiency gains. **[Internal note]**

### Recommendation
**Maintain a cautiously constructive operating view; require further evidence before
adopting a stronger investment stance.** Prioritize holiday comparable-store growth and
markdown performance, shrink stabilization, new-store productivity, and clearer
automation spending limits and payback milestones. These measures will help establish
whether current efficiencies translate into durable earnings and free cash flow.
**[Analyst assessment based on Filing; Internal note]**

A valuation-based buy or sell recommendation is not supported by the supplied materials,
which provide no share price, valuation multiples, or earnings outlook.

Every claim is tagged with its source — that per-claim citation discipline is exactly what you want before anything with "investment" in the name goes in front of a client, and it's a direct product of feeding Astra the full source material instead of a lossy summary of it.

Where This Fits (and Where It Doesn't)

Reach for GPT-6 Astra when:

You need deliberate, multi-step planning and decision support — not a one-shot answer
The output needs to be polished enough for expert review: documents, reports, structured recommendations
You're automating work through approved interfaces or systems without a clean API, with human checkpoints on consequential actions
Your scenario genuinely needs long-context reasoning across large documents, filings, or repositories

Don't reach for it when:

You need a lightweight, low-latency conversational bot — that's a better fit for a chat-tuned model like GPT-chat-latest
The task is narrow, single-shot classification or extraction with no planning component
You're not ready to build the governance layer (approvals, scoped credentials, monitoring) that responsible agentic/computer-use workflows require — Foundry gives you the tools, but you still have to configure and own that boundary

Wrapping Up

GPT-6 Astra's pitch isn't "smarter chat" — it's "does more of the actual work and hands you something finished." For .NET developers, that shows up as agents that investigate before they conclude, reports that follow your template without babysitting, and workflows that act through your systems with a human still holding the approval button. Pair it with Foundry Agent Service so that autonomy inherits identity, security, and lifecycle management rather than becoming its own liability — and it's worth deploying gpt-6-astra next to whatever you're running today and comparing the two side by side.

Grok 4.6 Is Now in Foundry — Here’s What It Means If You Write C#

Taswar Bhatti — Mon, 31 Aug 2026 12:52:32 +0000

Grok 4.6 — SpaceXAI's latest frontier model — just landed in public preview in Microsoft Foundry as an Azure Direct Model. The headline isn't "another big model dropped." It's that Grok 4.6 is built specifically for long-horizon, agentic work: planning across many steps, calling tools reliably, recovering when something goes wrong, and handing you a finished work product instead of a half-baked fragment you have to stitch together yourself.

That's a meaningfully different design target than "answer this one prompt well." And it's exactly the kind of thing that matters once you move past demos and start building agents that actually have to survive contact with real workloads.

As always: no Python required, no notebook required. Just Microsoft.Extensions.AI and dotnet run.

What Grok 4.6 Actually Is

A few things worth knowing before you touch any code:

Frontier reasoning at value pricing. Grok 4.6 is positioned as the value-tier frontier option — frontier-class reasoning at a materially lower cost per task than comparable models. That matters the moment "reasoning agent" stops being a one-off demo and becomes something running continuously in production.
Selectable reasoning effort. You choose reasoning depth per call — low, medium, high, or xhigh (default high) — instead of paying maximum-reasoning cost on every single request regardless of whether the task needs it.
Long-horizon agentic execution. It's designed to sustain complex, multi-step work — planning, tool calls, error recovery, and self-verification — with limited human babysitting.
Multimodal input. Text and images, so document-heavy, diagram-heavy, and screenshot-heavy workflows don't need a bolted-on separate vision pipeline.
200K token context window at launch. Solid for most agentic and document-analysis workloads — just set expectations up front if your scenario needs more.
Still preview. Validate against your own prompts, tools, and safety thresholds before anything production-sensitive touches it.

Why This Matters for .NET Developers Specifically

The use cases Microsoft is calling out map directly onto real .NET workloads:

Long-running agents — multi-tool orchestration with error recovery and planning, not a single tool call and done
Software engineering — multi-stage coding sessions, large refactors, and debugging across a real repository, not a single isolated function
Research and analysis — synthesizing dense source material into structured, decision-ready output
Enterprise knowledge work — drafting full documents, reports, and deliverables end to end, not just paragraph stubs

And it slots into Foundry the same way every other model does — same IChatClient abstraction, same deployment pattern. Swapping in Grok 4.6 next to GPT-4o or MAI-Thinking-1 in your evaluation pipeline is a config change, not a rewrite.

Getting Started

dotnet new console -n Grok46MSFoundryDemo
cd Grok46MSFoundryDemo
dotnet add package Azure.AI.OpenAI
dotnet add package Microsoft.Extensions.AI
dotnet add package Azure.Identity
dotnet add package Microsoft.Extensions.Configuration.UserSecrets
dotnet add package Microsoft.Extensions.Configuration.EnvironmentVariables
dotnet add package Microsoft.Extensions.AI.OpenAI
dotnet user-secrets init
dotnet user-secrets set "AZURE_AI_ENDPOINT" "https://your-resource.services.ai.azure.com"

Deploy grok-4.6 from the Foundry Model Catalog (currently Global Standard deployment only) to your Foundry project, same as any other model. Grab your endpoint and deployment name.

Use Case 1: Long-Horizon Agent with Tool Calling and Selectable Reasoning Effort

Let's build the thing Grok 4.6 is actually designed for: an agent that plans across multiple tool calls instead of answering from a single shot. Here's a small deployment-readiness agent that checks a service's health, checks its recent error rate, and only then decides whether it's safe to proceed with a deploy — reasoning through the combination rather than just checking one signal in isolation.

One important wrinkle: Grok is a partner (MaaS) model, not a native Azure OpenAI deployment, so it can't be reached through AzureOpenAIClient's /openai/deployments/... path. Instead we use the generic OpenAI ChatClient pointed at the Foundry model endpoint, with a bearer-token policy for Entra ID auth and a small pipeline policy to append the API version.

using Azure.Identity;
using Microsoft.Extensions.AI;
using Microsoft.Extensions.Configuration;
using OpenAI;
using System.ClientModel.Primitives;
using System.ComponentModel;
using OpenAIChatClient = OpenAI.Chat.ChatClient;

#pragma warning disable OPENAI001

var config = new ConfigurationBuilder()
    .AddUserSecrets<Program>()
    .AddEnvironmentVariables()
    .Build();

var deploymentName = config["AZURE_OPENAI_DEPLOYMENT"] ?? "grok-4.6";
var endpoint = config["AZURE_AI_ENDPOINT"]
    ?? throw new InvalidOperationException(
        "AZURE_AI_ENDPOINT is not set. Run: dotnet user-secrets set \"AZURE_AI_ENDPOINT\" \"<your-endpoint-e.g.-https://<resource>.services.ai.azure.com/models>\"");

// Grok is a partner (MaaS) model, not a native Azure OpenAI deployment, so it can't be
// reached through AzureOpenAIClient's /openai/deployments/... path. Use the generic
// OpenAI ChatClient against the Foundry model endpoint instead (mirrors Grok4.3 sample).
BearerTokenPolicy tokenPolicy = new(
    new DefaultAzureCredential(),
    "https://ai.azure.com/.default");

var clientOptions = new OpenAIClientOptions { Endpoint = new Uri(endpoint) };
clientOptions.AddPolicy(new ApiVersionPolicy("2024-05-01-preview"), PipelinePosition.PerCall);

OpenAIChatClient openAiChatClient = new(
    model: deploymentName,
    authenticationPolicy: tokenPolicy,
    options: clientOptions);

IChatClient chatClient = openAiChatClient
    .AsIChatClient()
    .AsBuilder()
    .UseFunctionInvocation()
    .Build();

var chatOptions = new ChatOptions
{
    Tools =
    [
        AIFunctionFactory.Create(GetServiceHealth),
        AIFunctionFactory.Create(GetRecentErrorRate)
    ],
    // Reasoning effort tuned for a multi-step decision — not maximum, not minimal.
    AdditionalProperties = new AdditionalPropertiesDictionary
    {
        ["reasoning_effort"] = "high" // low | medium | high | xhigh
    }
};

var messages = new List<ChatMessage>
{
    new(ChatRole.System,
        "You are a deployment safety agent. Before recommending a deploy, check both " +
        "service health and recent error rate. Reason about both signals together before " +
        "concluding — do not approve a deploy based on a single check alone."),
    new(ChatRole.User, "Is it safe to deploy service 'checkout-api' right now?")
};

var response = await chatClient.GetResponseAsync(messages, chatOptions);
Console.WriteLine(response.Text);

// --- Tool stand-ins for a real monitoring/ops API ---

[Description("Gets the current health status of a named service.")]
static string GetServiceHealth(
    [Description("The service name, e.g. checkout-api")] string serviceName)
{
    return serviceName switch
    {
        "checkout-api" => "Healthy. All instances passing readiness checks.",
        _ => "Unknown service."
    };
}

[Description("Gets the error rate for a named service over the last hour.")]
static string GetRecentErrorRate(
    [Description("The service name, e.g. checkout-api")] string serviceName)
{
    return serviceName switch
    {
        "checkout-api" => "Error rate: 4.2% over the last hour (baseline: 0.3%). Elevated.",
        _ => "No data available."
    };
}

/// <summary>Pipeline policy that appends api-version as a query parameter to every request.</summary>
class ApiVersionPolicy(string apiVersion) : PipelinePolicy
{
    public override void Process(PipelineMessage message, IReadOnlyList<PipelinePolicy> pipeline, int currentIndex)
    {
        AppendApiVersion(message);
        ProcessNext(message, pipeline, currentIndex);
    }

    public override async ValueTask ProcessAsync(PipelineMessage message, IReadOnlyList<PipelinePolicy> pipeline, int currentIndex)
    {
        AppendApiVersion(message);
        await ProcessNextAsync(message, pipeline, currentIndex);
    }

    private void AppendApiVersion(PipelineMessage message)
    {
        var url = message.Request.Uri!.ToString();
        var separator = url.Contains('?') ? "&" : "?";
        message.Request.Uri = new Uri($"{url}{separator}api-version={apiVersion}");
    }
}

Case 1 – Output

**No — do not deploy `checkout-api` right now.**

- **Health:** Healthy (all instances passing readiness checks).
- **Error rate:** Elevated at 4.2% over the last hour vs. 0.3% baseline.

The current health check looks fine, but the error rate is an order of magnitude above
baseline. Deploying while errors are already elevated risks amplifying an existing
problem. Wait until the error rate returns closer to baseline (and re-check both signals)
before proceeding.

Notice the agent has to combine two tool results before it can reason to an answer — a healthy service with a spiking error rate is exactly the kind of situation where a single-signal check would give you a false "all clear." That's the long-horizon, multi-step reasoning Grok 4.6 is built for, not a gimmick.

Use Case 2: Software Engineering — Multi-Stage Code Review Across a Repository

The second headline use case is software engineering: multi-stage coding sessions and debugging across complex repositories, not a single isolated snippet. Here's a pattern for feeding Grok 4.6 multiple related files and asking it to reason about the change as a whole, not file by file. This reuses the same chatClient built in Use Case 1.

var interfaceFile = """
    public interface IOrderRepository
    {
        Task<Order?> GetByIdAsync(Guid orderId);
        Task SaveAsync(Order order);
    }
    """;

var implementationFile = """
    public class OrderRepository : IOrderRepository
    {
        private readonly AppDbContext _db;
        public OrderRepository(AppDbContext db) => _db = db;

        public async Task<Order?> GetByIdAsync(Guid orderId)
            => await _db.Orders.FindAsync(orderId);

        public async Task SaveAsync(Order order)
        {
            _db.Orders.Update(order);
            await _db.SaveChangesAsync();
        }
    }
    """;

var callerFile = """
    public class OrderService
    {
        private readonly IOrderRepository _repo;
        public OrderService(IOrderRepository repo) => _repo = repo;

        public async Task CancelOrderAsync(Guid orderId)
        {
            var order = await _repo.GetByIdAsync(orderId);
            order.Status = OrderStatus.Cancelled; // no null check
            await _repo.SaveAsync(order);
        }
    }
    """;

var systemPrompt = """
    You are a senior .NET code reviewer. You'll be given multiple related files from
    the same change set. Review them together, not in isolation — flag issues that only
    become visible when you consider how the files interact (e.g. a nullable return type
    being used without a null check downstream). Be direct and specific about severity.
    """;

var messagesMulti = new List<ChatMessage>
{
    new(ChatRole.System, systemPrompt),
    new(ChatRole.User, $"""
        Review this change set:

        --- IOrderRepository.cs ---
        {interfaceFile}

        --- OrderRepository.cs ---
        {implementationFile}

        --- OrderService.cs ---
        {callerFile}
        """)
};

var responseMulti = await chatClient.GetResponseAsync(messagesMulti);
Console.WriteLine(responseMulti.Text);

Case 2 – Output

## Cross-file review

The real bug here is a **contract lie** between the three files. It is not visible in
any one of them in isolation.

### Critical: `GetByIdAsync` can return null, but nothing admits it

`DbSet<T>.FindAsync` returns `T?`. The repository still types the method as `Task<Order>`:

    public async Task<Order> GetByIdAsync(Guid orderId)
        => await _db.Orders.FindAsync(orderId);

The interface repeats that lie:

    Task<Order> GetByIdAsync(Guid orderId);

`OrderService` then trusts it:

    var order = await _repo.GetByIdAsync(orderId);
    order.Status = OrderStatus.Cancelled; // NRE if missing
    await _repo.SaveAsync(order);

Missing order → `NullReferenceException` at the assignment, or a worse failure inside
`Update`/`SaveChanges` if the NRE is somehow avoided. With NRTs on, this should not
compile without a warning at the repository; the warning is being swallowed by the
non-nullable signature, so the service never sees it.

**Fix the contract, then the callers.** Do not paper over it with a `!`.

    Task<Order?> GetByIdAsync(Guid orderId);

    public async Task CancelOrderAsync(Guid orderId)
    {
        var order = await _repo.GetByIdAsync(orderId)
            ?? throw new InvalidOperationException($"Order {orderId} was not found.");
        order.Status = OrderStatus.Cancelled;
        await _repo.SaveAsync(order);
    }

Prefer a domain-specific not-found exception (or `Results.NotFound()` at the API edge)
over a generic one. The point is: **absence is a first-class outcome**, not a crash.

If "must exist" is actually the invariant, keep `Task<Order>` but make the repository
throw (e.g. `FindAsync` + throw, or `SingleAsync`). Do not return null behind a
non-nullable type.

---

### High: `Update` on an already-tracked entity

`FindAsync` attaches the entity (unless you changed the default tracker). `SaveAsync`
then does:

    _db.Orders.Update(order);
    await _db.SaveChangesAsync();

`Update` marks **all** properties modified. That is the detached-entity API. On a
tracked instance it is redundant and harmful:

- Extra UPDATE columns you did not change
- Overwrites of concurrent edits to other fields
- Surprising behavior if anyone later passes a detached or new `Order`

After a tracked load, mutate and `SaveChangesAsync()`. If the repository must support
detached graphs, branch on `_db.Entry(order).State`.

Also: no concurrency token (`xmin` / `RowVersion`). Two `CancelOrderAsync` calls, or
cancel vs. another status change, last-write-wins with no conflict.

---

### Medium: cancel has no domain guard

`order.Status = OrderStatus.Cancelled` is a field poke, not a transition.

Together with the null hole, any id "cancels." You likely also want to reject
already-shipped / already-cancelled / unpaid-invalid states. That belongs on `Order`
(`order.Cancel()`), not in the service, so the repository cannot persist an illegal
status even if another caller appears.

---

### Low (still worth fixing in this changeset)

- No `CancellationToken` on any of the three async methods. Once this is on a request
  path, you cannot abort the EF round-trip.
- `GetByIdAsync` has no `AsNoTracking` decision. Fine if you always mutate; wrong if this
  repo is reused for reads.
- Interface + impl + service all assume a live `AppDbContext` scope. If `OrderService` is
  longer-lived than the context, this blows up at runtime — not shown here, but the
  `Update` pattern makes that failure mode worse.

---

### What I would require before merge

1. `Task<Order?>` **or** throw-on-miss in the repository — pick one, align interface,
   impl, and service.
2. Null/not-found handling in `CancelOrderAsync`.
3. Drop `Update` for this tracked path; `SaveChangesAsync` only.
4. Optional but strongly recommended: `order.Cancel()` with explicit illegal-transition
   errors, and a concurrency token.

The nullability mismatch is the merge-blocker. Everything else is how this will fail in
production after the NRE is fixed.

The interesting part isn't reviewing one file — any model can do that. It's reasoning across files: GetByIdAsync returns Order?, and the caller in OrderService uses it without a null check. That's a cross-file bug a naive single-file review would miss entirely.

Use Case 3: Research and Analysis — Structured, Decision-Ready Output

Grok 4.6 is also positioned for turning dense source material into structured output you can actually hand to someone. Here's a pattern using strongly-typed structured output instead of hoping the model formats things consistently. Still reusing the same chatClient.

var sourceMaterial = """
    Q3 vendor evaluation notes:
    Vendor A: $42/user/month, 99.95% uptime SLA, no SOC 2 report available yet,
    onboarding takes ~6 weeks, strong API docs.
    Vendor B: $58/user/month, 99.99% uptime SLA, SOC 2 Type II certified,
    onboarding takes ~2 weeks, API docs are sparse.
    """;

var messagesRA = new List<ChatMessage>
{
    new(ChatRole.System,
        "Synthesize the provided source material into a structured, decision-ready " +
        "recommendation. Output valid JSON matching the requested schema only."),
    new(ChatRole.User, $"Analyze this vendor comparison and recommend one:\n\n{sourceMaterial}")
};

var chatOptionsRA = new ChatOptions
{
    ResponseFormat = ChatResponseFormat.ForJsonSchema<VendorRecommendation>()
};

var responseRA = await chatClient.GetResponseAsync(messagesRA, chatOptionsRA);
var recommendation = JsonSerializer.Deserialize<VendorRecommendation>(responseRA.Text);

Console.WriteLine($"Recommended: {recommendation?.RecommendedVendor}");
Console.WriteLine($"Reasoning: {recommendation?.Reasoning}");
Console.WriteLine($"Key risk: {recommendation?.KeyRisk}");

record VendorRecommendation(
    [property: JsonPropertyName("recommended_vendor")] string RecommendedVendor,
    [property: JsonPropertyName("reasoning")] string Reasoning,
    [property: JsonPropertyName("key_risk")] string KeyRisk
);

Case 3 – Output

Recommended: Vendor B

Reasoning: Vendor B is the stronger overall choice for most enterprise deployments:
SOC 2 Type II certification addresses a common compliance gate that Vendor A currently
cannot, the 99.99% SLA and 2-week onboarding reduce operational and time-to-value risk,
and the $16/user premium is justified by those factors. Sparse API docs are a manageable
trade-off versus A's missing audit report and 6-week ramp.

Key risk: Sparse API documentation may increase integration effort, delay custom
development, and raise long-term maintenance cost.

This is the difference between "the model wrote something that sounds like a recommendation" and "the model produced a typed object your application can actually act on" — route it to an approval workflow, log it, feed it into a dashboard, whatever your enterprise-knowledge-work pipeline actually needs downstream.

Use Case 4: Multimodal Input — Reviewing a Diagram or Screenshot

Since Grok 4.6 accepts text and images, document- and diagram-heavy workflows skip the separate vision pipeline entirely.

using Microsoft.Extensions.AI;

var diagramBytes = await File.ReadAllBytesAsync("architecture-diagram.png");

var message = new ChatMessage(ChatRole.User,
[
    new TextContent("Review this architecture diagram. Flag any single points of failure."),
    new DataContent(diagramBytes, "image/png")
]);

var response = await chatClient.GetResponseAsync([message]);
Console.WriteLine(response.Text);

Case 4 – Output

**Single points of failure (and related HA gaps)**

The diagram is a single-region Azure architecture (the large "A" boundary) with a
typical ingress → compute → data path, Entra ID, Key Vault, monitoring, and a CI/CD
pipeline. Several components and the overall topology lack redundancy.

### Highest-impact SPOFs

- **Single Azure region.** Everything runtime lives in one region. A region-level
  outage (or even a prolonged zonal issue if services are not zone-redundant) takes the
  whole system down. There is no second region, no Azure Front Door / Traffic Manager
  failover pair, no geo-replicated data, and no active-active or active-passive pattern.
- **Azure SQL Database.** A single SQL instance is shown with no failover group,
  geo-replication, zone-redundant configuration, or Hyperscale mention. This is a
  classic data-plane SPOF. Azure Storage (the table icon) is more resilient by default
  (ZRS/GRS options exist) but is still regional and does not protect the relational data.
- **Ingress chain (Front Door / CDN → WAF → load balancer / Traffic Manager → API
  Management or equivalent).** These are drawn as a linear series of single icons.
  Front Door itself is globally distributed, but the backends, WAF policy, regional
  load balancer, and API Management instance are not shown as scaled-out,
  zone-redundant, or multi-region. A failure or misconfiguration in any hop can
  black-hole traffic.
- **Compute (API Management / AKS / App Service + chained Functions).** The three
  dashed compute boxes and the two sequential Functions imply a synchronous pipeline
  with no queue, Event Grid, or Service Bus decoupling. One Function or the hosting
  plan/cluster going down stops the flow. No multiple instances, Availability Zones, or
  Premium/Isolated SKUs with zone redundancy are indicated. A single AKS cluster or App
  Service plan is also a SPOF unless node pools / instances are spread across zones and
  (ideally) regions.

### Other notable single points / HA gaps

- **Azure Key Vault (shown in two places).** Regional service. Runtime secret/
  certificate retrieval without caching, retry, or a replica in another region can fail
  the app. Soft-delete + purge protection help with accidental deletion but not with
  regional unavailability.
- **No Availability Zones called out.** Even within the single region, most PaaS
  services (Functions, App Service, SQL, API Management, Firewall, etc.) can and should
  be zone-redundant. The diagram gives no indication this is configured, so a
  datacenter failure is a realistic outage.
- **Hybrid / on-premises dependency (building + connectivity icon on the right).** If
  any critical path (identity, data, or connectivity via ExpressRoute/VPN) depends on
  the on-premises side or a single circuit, that is an additional SPOF. Dual
  ExpressRoute circuits or VPN backup would be needed.
- **Azure Firewall (single instance shown).** Can be made zone-redundant, but a single
  firewall (or single policy) is a choke point for both north-south and any east-west
  traffic that transits it.
- **DNS.** Azure DNS itself is globally anycast and highly available. The risk is if
  records only point at the single-region endpoints with no Traffic Manager / Front
  Door health-probe failover, or if a custom DNS server is in the path.

### Components that are *not* SPOFs (or are relatively resilient)

- Microsoft Entra ID (global, highly available).
- Azure Monitor / Defender / management plane (shown on the right).
- The CI/CD pipeline (Azure DevOps / Pipelines / ACR-style icons at the bottom) is a
  deployment concern, not a runtime SPOF — unless the running application somehow
  depends on it remaining available.
- Serverless Functions and App Services *can* be made highly available, but the diagram
  does not show the required SKU, scaling, or zonal/multi-region setup.

### Recommendations (priority order)

1. Make the solution multi-region (active-passive with Front Door or Traffic Manager +
   SQL failover groups / Cosmos DB, or active-active). This addresses the biggest risk.
2. Enable zone redundancy on SQL, compute, API Management, Firewall, and Key Vault where
   the SKU supports it; add a second Key Vault + secret replication for DR.
3. Decouple the Function chain with queues/topics so a single Function failure does not
   halt everything; add retries, circuit breakers, and health endpoints.
4. Scale out and zone-redundant the ingress (multiple API Management units, Standard
   Load Balancer or Front Door backends in different zones/regions).
5. Confirm (or add) Availability Zones, GRS/ZRS storage, and managed identities to
   reduce Key Vault runtime dependency.
6. If hybrid connectivity is required, dual-circuit ExpressRoute + VPN failover.

The diagram is a reasonable starting point for a cloud-native app but currently has
several classic single-region + single-instance data and compute SPOFs. The largest
reliability gains come from multi-region + zone-redundant data and from breaking the
synchronous Function chain.

Same IChatClient, same message pattern as every text-only example above — you're just adding a DataContent alongside the TextContent.

Where This Fits (and Where It Doesn't)

Reach for Grok 4.6 when:

You're building agents that need to plan, call multiple tools, recover from errors, and run with limited human oversight
You're doing large, multi-file refactors or debugging that require reasoning across a whole change set, not one file at a time
You need frontier-class reasoning at high volume, where cost per task actually matters
Your workload benefits from tunable reasoning effort instead of paying maximum cost on every call

Don't reach for it when:

Your context needs meaningfully exceed 200K tokens — qualify that requirement up front
The task is a simple, low-latency single-shot response where low effort on a cheaper model is a better fit
You need a production SLA today — it's still preview, so validate against your own prompts, tools, and safety thresholds first

Wrapping Up

Grok 4.6 in Foundry isn't another "yet another model" announcement — it's a genuine value-tier option for the agentic, long-horizon work that's increasingly what "building with AI" actually means once you're past the demo stage. Selectable reasoning effort means you're not stuck overpaying for depth you don't need on every call, and the fact that it drops into the same IChatClient abstraction as everything else in Foundry means adding it to your evaluation lineup costs you an afternoon, not a rewrite.

Source code at: github.com/taswar/Grok46MSFoundryDemo

GPT-5.6 Sol Is Now in Foundry — What It Means If You Write C#

Taswar Bhatti — Tue, 25 Aug 2026 13:06:26 +0000

Microsoft has a habit of quietly upgrading the model behind a stable endpoint name instead of forcing everyone to migrate to a new one. That's exactly what just happened with GPT-chat-latest — it's now built on GPT-5.6 Sol, and if you're already pointing at GPT-chat-latest in Microsoft Foundry, you get the upgrade without touching a line of code.

If you're not already using it, this is a good moment to start. Here's what changed, why it matters, and — because I don't do AI posts without something you can actually run — a working C# sample.

What Actually Changed

A few things worth knowing before you touch any code:

Same endpoint, better model underneath. For gpt-5.6-sol, you don't select a new model name — you just get the improved behavior through the same integration path you already have.
More focused responses. Tighter formatting, more direct answers, and a clearer main recommendation instead of a wall of hedged possibilities.
Improved factual reliability. Fewer mistakes on the things that are easy to get subtly wrong — dates, numbers, sources, rules, and assumptions.
More consistent behavior. Whether the question is a one-liner or a genuinely deep multi-step task, the model handles both without feeling like two different personalities.
Multimodal by default. Text, image, and audio inputs with long-turn consistency — you're not stuck bolting on a separate vision model for basic multimodal chat.

None of that is exotic. It's the boring, unglamorous stuff that actually matters when you're shipping a chatbot people rely on — not a demo you show once and never touch again.

Why This Matters for .NET Developers Specifically

If you're building any of the following, this update is aimed at you:

Customer support and self-service bots — troubleshooting, product Q&A, multi-step processes grounded in your own knowledge base
Planning and knowledge-work assistants — breaking down objectives, reconciling constraints, producing briefs and recommendations
Multimodal conversational features — combining text and image context in a single chat flow
Retrieval-grounded assistants — multi-turn conversations that synthesize answers from documents you feed in, not just the model's training data

And because it's the exact same IChatClient interface you're already using for GPT-4o, MAI-Thinking-1, or anything else in Foundry — there's no new SDK, no new package, no new mental model. You point at the same deployment name and the improvements just show up.

Getting Started

dotnet new console -n GptChat-Sol-Demo
cd GptChat-Sol-Demo
dotnet add package Azure.AI.OpenAI
dotnet add package Microsoft.Extensions.AI
dotnet add package Azure.Identity
dotnet user-secrets init
dotnet user-secrets set "AZURE_AI_ENDPOINT" "https://your-resource.services.ai.azure.com"

Deploy gpt-5.6-sol from the Foundry Model Catalog to your project — same process as any other model. Grab your endpoint, and you're ready to go.

A Multi-Turn, Retrieval-Grounded Support Assistant

Reasoning quality is nice, but the real test for a chat model is whether it holds context sensibly across a back-and-forth conversation, and whether it sticks to the facts you actually gave it instead of making something up. Let's build a small support assistant that's grounded in a product knowledge snippet, and push it through a multi-turn conversation.

using Azure.AI.OpenAI;
using Azure.Identity;
using Microsoft.Extensions.AI;
using Microsoft.Extensions.Configuration;

var config = new ConfigurationBuilder()
    .AddUserSecrets<Program>()
    .AddEnvironmentVariables()
    .Build();

var deploymentName = config["AZURE_OPENAI_DEPLOYMENT"] ?? "gpt-5.6-sol";
var endpoint = new Uri(config["AZURE_AI_ENDPOINT"]
    ?? throw new InvalidOperationException(
        "AZURE_AI_ENDPOINT is not set. Run: dotnet user-secrets set \"AZURE_AI_ENDPOINT\" \"<your-endpoint>\""));

IChatClient chatClient = new AzureOpenAIClient(endpoint, new DefaultAzureCredential())
    .GetChatClient(deploymentName)
    .AsIChatClient();

// This stands in for content you'd normally pull from a retrieval/RAG pipeline —
// a vector search hit, a support doc, a knowledge base article, etc.
var retrievedContext = """
    Product: Contoso Sync Pro (desktop client, v4.2)
    Known issue: Sync fails silently if the local cache exceeds 2GB.
    Fix: Settings > Storage > "Clear Local Cache", then restart the app.
    Note: Clearing the cache does not delete any cloud-stored files.
    """;

var systemPrompt = """
    You are a Contoso Sync Pro support assistant. Answer only using the
    provided knowledge context below. If the context doesn't cover the
    question, say so plainly instead of guessing. Keep answers direct,
    with the main recommendation clearly stated first.

    KNOWLEDGE CONTEXT:
    """ + retrievedContext;

var messages = new List<ChatMessage>
{
    new(ChatRole.System, systemPrompt)
};

// Turn 1
messages.Add(new ChatMessage(ChatRole.User, "My sync keeps failing and I don't get any error. What's going on?"));
var response1 = await chatClient.GetResponseAsync(messages);
Console.WriteLine($"Assistant: {response1.Text}\n");
messages.Add(new ChatMessage(ChatRole.Assistant, response1.Text));

// Turn 2 — a natural follow-up that depends on remembering turn 1
messages.Add(new ChatMessage(ChatRole.User, "Will I lose any files if I do that?"));
var response2 = await chatClient.GetResponseAsync(messages);
Console.WriteLine($"Assistant: {response2.Text}\n");
messages.Add(new ChatMessage(ChatRole.Assistant, response2.Text));

// Turn 3 — asking something outside the provided knowledge, to check it doesn't hallucinate
messages.Add(new ChatMessage(ChatRole.User, "Does this also work on the mobile app?"));
var response3 = await chatClient.GetResponseAsync(messages);
Console.WriteLine($"Assistant: {response3.Text}");

Output

Assistant: Your local cache may have exceeded 2GB, which can cause sync to fail silently in
Contoso Sync Pro v4.2. Go to Settings > Storage > Clear Local Cache, then restart the app.
This will not delete any cloud-stored files.

Assistant: No. Clearing the local cache does not delete any cloud-stored files. After
clearing it, restart Contoso Sync Pro.

Assistant: The provided information only covers the Contoso Sync Pro desktop client v4.2.
It doesn't confirm whether this fix applies to the mobile app.

What I'm actually testing here: turn 2 depends on the model remembering what "that" refers to from turn 1 (clearing the cache), and turn 3 deliberately asks something the knowledge context doesn't cover — a model with improved factual reliability should say "I don't have that information" instead of confidently inventing a mobile-app answer. That's the difference between a chatbot people trust and one that quietly erodes trust one hallucinated answer at a time.

Multimodal Input: Text + Image in the Same Conversation

gpt-5.6-sol handles multimodal input natively, which matters for support scenarios where a user just wants to send you a screenshot instead of describing an error message character by character.

using Microsoft.Extensions.AI;

var imageBytes = await File.ReadAllBytesAsync("error-screenshot.png");

var multimodalMessage = new ChatMessage(ChatRole.User,
[
    new TextContent("Here's the error I'm seeing. What does this mean and how do I fix it?"),
    new DataContent(imageBytes, "image/png")
]);

var messages = new List<ChatMessage>
{
    new(ChatRole.System, systemPrompt),
    multimodalMessage
};

var response = await chatClient.GetResponseAsync(messages);
Console.WriteLine(response.Text);

Output

The message only indicates that the upload failed; the provided information doesn't
identify the exact cause.

If you're using Contoso Sync Pro desktop v4.2, try the known fix:
1. Go to Settings > Storage.
2. Select Clear Local Cache.
3. Restart the app and retry.

This resolves failures caused by a local cache exceeding 2 GB. Clearing it will not delete
cloud-stored files.

The screenshot appears to be from a mobile app, which isn't covered by the available
support information.

Same IChatClient, same message list pattern — you're just adding a DataContent alongside your TextContent in the same ChatMessage. No separate vision API, no separate client to wire up. Notice the model also flagged that the screenshot looked like it came from the mobile app — outside the scope of the desktop-only knowledge context it was given — instead of just applying the desktop fix blindly.

Where This Fits (and Where It Doesn't)

Reach for GPT-chat-latest when:

You're building conversational, multi-turn experiences — support bots, internal assistants, sales enablement tools
You need retrieval-grounded answers that stick to the facts you provide, not the model's general knowledge
You want multimodal input (text + image) without adding a separate model to your stack
You want model improvements over time without maintaining multiple endpoint names in your config

Don't reach for it when:

You need deep, extended multi-step reasoning as the primary workload — that's a better fit for a dedicated reasoning model
You're doing narrow, single-shot classification or extraction with no conversational component
Audio input is core to your scenario and you need to validate current format/latency support against your specific requirements before committing

Wrapping Up

The best kind of model update is the one where you don't have to do anything. GPT-chat-latest running on GPT-5.6 Sol is exactly that: same endpoint, same IChatClient code, better answers underneath. If you're building support bots, planning assistants, or anything that leans on multi-turn conversation grounded in your own data, it's worth pointing your existing integration at it and seeing the difference for yourself.

Source code at: github.com/taswar/GptChat-Sol-Demo

MAI-Thinking-1 Is Now in Foundry — Here's What It Means If You Write C#

Taswar Bhatti — Tue, 18 Aug 2026 12:15:47 +0000

Every time Microsoft ships a new model into Foundry, I ask myself the same boring-but-important question: does this change anything for the way I actually write code? Most of the time the answer is "cool demo, doesn't affect my day job." This time it's different.

MAI-Thinking-1 — Microsoft's first reasoning model — just went into public preview in Microsoft Foundry. It's not a chat model with a "think harder" flag bolted on. It's built from the ground up for multi-step reasoning: the kind of work where the model has to plan, reconsider, call tools, and stitch together a long chain of context before it gives you an answer worth trusting.

If you've read anything else I've written, you know where this is going: no Python required, no notebook gymnastics, just Microsoft.Extensions.AI and a dotnet run.

What MAI-Thinking-1 Actually Is

A few things worth knowing before you touch any code:

Mixture-of-Experts (MoE) architecture. Instead of activating the entire model for every request, it only activates the parts it needs. Translation for us: you get reasoning depth without paying full-model compute cost on every call.
Trained from scratch, no distillation. Microsoft trained it on clean data rather than distilling from a third-party model — worth knowing if procurement ever asks "where did this model come from."
Competitive on SWE-Bench Pro at a lower price point than other models in its weight class. Translation: it's genuinely usable for coding-adjacent agent workloads, not just benchmark bragging rights.
Pricing: $2 per 1M input tokens, $8 per 1M output tokens through the Foundry Model Catalog. Cheap enough that "always-on reasoning agent" stops being a scary line item.

None of that matters if you can't get it working in fifteen minutes, so let's do that.

Why This Matters for .NET Developers Specifically

Most "reasoning model" content is written for people gluing together Python scripts and LangChain. That's not how most of us ship software. If you're building:

Agents that call tools — CRM lookups, ERP queries, ticketing systems — and need to reason across the results before responding
Long-document analysis — contracts, filings, transcripts — where the model needs to hold context and reason step-by-step instead of pattern-matching a summary
Decision-support features — root-cause analysis, recommendation generation, anything where "just guess the most likely next token" isn't good enough

MAI-Thinking-1 is aimed squarely at you, and it slots into the same IChatClient interface you're already using for GPT-4o or any other Foundry model. Swapping models is a config change, not a rewrite.

Getting Started: The Boring Setup Part

dotnet new console -n MaiThinkingDemo
cd MaiThinkingDemo
dotnet add package Azure.AI.OpenAI
dotnet add package Microsoft.Extensions.AI
dotnet add package Azure.Identity
dotnet user-secrets init
dotnet user-secrets set "AZURE_AI_ENDPOINT" "https://your-resource.services.ai.azure.com"

Deploy MAI-Thinking-1 from the Foundry Model Catalog to your Foundry project, same as you would any other model. Grab your endpoint and deployment name.

A Multi-Step Reasoning Example

Here's the thing about reasoning models: the interesting part isn't a single prompt/response, it's giving the model something that actually requires reasoning across steps. Let's build a small "contract risk triage" service — the kind of long-document, multi-step reasoning task MAI-Thinking-1 is designed for.

using Azure.AI.OpenAI;
using Azure.Identity;
using Microsoft.Extensions.AI;
using Microsoft.Extensions.Configuration;

var config = new ConfigurationBuilder()
    .AddUserSecrets<Program>()
    .AddEnvironmentVariables()
    .Build();

var deploymentName = config["AZURE_OPENAI_DEPLOYMENT"] ?? "mai-thinking-1";
var endpoint = new Uri(config["AZURE_AI_ENDPOINT"]
    ?? throw new InvalidOperationException(
        "AZURE_AI_ENDPOINT is not set. Run: dotnet user-secrets set \"AZURE_AI_ENDPOINT\" \"<your-endpoint>\""));

IChatClient chatClient = new AzureOpenAIClient(endpoint, new DefaultAzureCredential())
    .GetChatClient(deploymentName)
    .AsIChatClient();

var systemPrompt = """
    You are a contract risk analyst. When given a contract excerpt, you must:
    1. Identify every clause that creates financial or legal risk.
    2. Reason step-by-step about *why* each clause is risky before concluding.
    3. Rank the risks by severity (High / Medium / Low).
    4. Output a final structured summary — do not skip the reasoning steps.
    """;

var contractExcerpt = """
    Section 9.2: Client may terminate this Agreement for convenience with 5 days'
    written notice. Vendor shall be entitled to fees for Services rendered through
    the termination date only, with no early-termination compensation.

    Section 11.4: Vendor's total liability under this Agreement shall not exceed
    the total fees paid in the preceding twelve (12) months, except in cases of
    gross negligence, in which liability is uncapped.
    """;

var messages = new List<ChatMessage>
{
    new(ChatRole.System, systemPrompt),
    new(ChatRole.User, $"Analyze this contract excerpt:\n\n{contractExcerpt}")
};

var response = await chatClient.GetResponseAsync(messages);
Console.WriteLine(response.Text);

Notice what's not here: no special "reasoning mode" flag, no separate SDK, no different message format. It's the exact same IChatClient call you'd make against any Foundry model. The reasoning happens because of how the model was built, not because of extra plumbing you have to write.

Sample output

# Contract Risk Analysis

Based off of the provided excerpt, I have identified the following clauses that pose financial or legal risk.

---

## RISK 1: Section 9.2 - Termination for Convenience

### Reasoning Step By Step:
1. **Short Notice Period** - The client only has to provide 5 days' written notice prior to terminating the agreement. This is an extremely short window for the vendor to adjust their operations.
2. **Unrecoverable Costs** - The clause only allows for fees for services rendered up to the termination date, with no early termination compensation. This means any upfront costs (i.e: staffing, software, third party vendors, onboarding, or materials) that were procured for the remainder of the work will not be reimbursed.
3. **Opportunity Cost** - With such a short notice period, the vendor may be unable to reallocate their resources to another client in time. This leads to lost revenue outside of what was already performed.
4. **Imbalance of Power** - This is a unilateral right for the client with no reciprocal protections for the vendor, opening up the door for abuse of this clause.

### Risk Severity: `HIGH`

---

## RISK 2: Section 11.4 - Liability Cap

### Reasoning Step By Step:
1. **Disproportionate Cap** - By limiting the vendor's total liability to only the fees paid in the preceding 12 months, the damages awarded could be massively disproportionate to the harm caused. For example, if a breach causes millions of dollars worth of damages, however only a small amount of fees were paid within the last 12 months, the vendor's exposure would be negligible compared to the loss.
2. **Uncertainty With The Exception** - The only exception to this cap is "gross negligence", which is a very high and fact specific legal standard to prove. This creates litigation uncertainty for both parties, as disputes may arise over whether the conduct met this threshold as opposed to ordinary negligence.
3. **Uncapped Exposure** - While the uncapped liability for gross negligence may seem reasonable on the surface, it creates uninsurable or unpredictable exposure for the vendor. Depending on the claim, this can be catastrophic from a financial standpoint.
4. **Jurisdictional Enforceability** - Depending on the governing law, liability caps are not always enforceable for certain claims (i.e: fraud, willful misconduct, statutory violations, or certain types of data breaches), which could render parts of this clause void, causing further unpredictability.

### Risk Severity: `HIGH`

---

## Final Summary

| Risk | Clause | Key Concern | Severity | Recommended Mitigation |
| :-- | :-- | :-- | :-- | :-- |
| Termination For Convenience | 9.2 | 5 day notice with no early termination fee, leading to unrecoverable costs and opportunity loss. | High | Negotiate a longer notice period (e.g: 15-30 days), a termination fee based off of work scheduled, or a wind down reimbursement for committed costs. |
| Liability Cap | 11.4 | Cap to 12 months of fees is disproportionate, with an ambiguous "gross negligence" exception that can lead to uncapped, unpredictable exposure. | High | Expand the cap carveouts carefully, define "gross negligence", consider a higher liability cap (or a mutually agreed upon amount), and confirm compatibility with insurance coverage. |

Tool-Augmented Reasoning (The Agentic Part)

The use case Microsoft calls out explicitly — connecting to CRM, ERP, and ticketing systems through native tool calling — is where reasoning models earn their keep. A non-reasoning model will happily call a tool with garbage arguments and move on. A reasoning model is far more likely to check its own work before it commits to a tool call.

Here's a minimal tool-calling setup using Microsoft.Extensions.AI's function tools, written as a .NET single-file app (#:package directives, no .csproj needed — just dotnet run app.cs):

#:package Azure.AI.OpenAI@2.9.0-beta.1
#:package Azure.Identity@1.21.0
#:package Microsoft.Extensions.AI@10.9.0
#:package Microsoft.Extensions.AI.OpenAI@10.3.0
#:package Microsoft.Extensions.Configuration@10.0.0
#:package Microsoft.Extensions.Configuration.EnvironmentVariables@10.0.0
#:package Microsoft.Extensions.Configuration.UserSecrets@10.0.0
#:property UserSecretsId=f8d4253e-5e0c-4aac-b93b-4e8e1d5d7b25

using Azure.AI.OpenAI;
using Azure.Identity;
using Microsoft.Extensions.Configuration;
using System.ComponentModel;
using Microsoft.Extensions.AI;

await FunctionSample.RunAsync();

public class FunctionSample
{
    public static async Task RunAsync()
    {
        var config = new ConfigurationBuilder()
            .AddUserSecrets<FunctionSample>()
            .AddEnvironmentVariables()
            .Build();

        var deploymentName = config["AZURE_OPENAI_DEPLOYMENT"] ?? "mai-thinking-1";
        var endpoint = new Uri(config["AZURE_AI_ENDPOINT"]
            ?? throw new InvalidOperationException(
                "AZURE_AI_ENDPOINT is not set. Run: dotnet user-secrets set \"AZURE_AI_ENDPOINT\" \"<your-endpoint>\""));

        IChatClient chatClient = new AzureOpenAIClient(endpoint, new DefaultAzureCredential())
            .GetChatClient(deploymentName)
            .AsIChatClient()
            .AsBuilder()
            .UseFunctionInvocation()
            .Build();

        var chatOptions = new ChatOptions
        {
            Tools = [AIFunctionFactory.Create(GetTicketStatus)]
        };

        var response = await chatClient.GetResponseAsync(
            "Ticket TCK-4471 has been open a while — what's going on and what should we do?",
            chatOptions);

        Console.WriteLine(response.Text);
    }

    // A stand-in for a real ticketing system lookup
    [Description("Looks up the current status and priority of a support ticket by ID.")]
    public static string GetTicketStatus(string ticketId)
    {
        return ticketId switch
        {
            "TCK-4471" => "Status: Escalated. Priority: Critical. Opened 6 days ago, SLA breached.",
            _ => "Ticket not found."
        };
    }
}

The model decides whether it needs to call GetTicketStatus based on its own reasoning about the request — not because you hardcoded "if the user mentions a ticket ID, call the tool." That's the actual value proposition here: less prompt-engineering gymnastics to force sensible tool use.

Output

## Ticket TCK-4471 — Current Status
- **Status:** Escalated
- **Priority:** Critical
- **Opened:** 6 days ago
- **SLA:** Breached

So: it's a critical issue, already escalated, and it's been open long enough that the committed response/resolve time has been missed.

## What's going on (interpretation)
- **Critical impact**: This is likely affecting production, revenue, security, or a major customer. Treat as high urgency.
- **Escalated**: Support has already bumped it up (likely to Tier 2/3, engineering, management, or a partner team). It's no longer being handled at the frontline only.
- **SLA breached (6 days open)**: The agreed SLA clock has expired. Expect pressure from stakeholders and potential contractual/experience impact.

## What you should do now
1. **Acknowledge & set comms**: Update the customer/stakeholder that it's escalated and you're actively driving it. Share next check-in time.
2. **Own the escalation**: Identify the escalation owner (engineer/lead) and a single point of contact. Confirm who is driving resolution.
3. **Find the blocker**: Check internal notes (linked incident, reproduction, affected env, logs, PRs). Is it waiting on engineering, a vendor, data fix, or release?
4. **Mitigate**: Is there a workaround (feature flag, rollback, hotfix, config change)? If yes, document and apply/communicate.
5. **Escalate to leadership if stalled**: If no movement today, loop in the escalation manager/incident commander; also consider incident post if prod is impacted.
6. **Track and document**: Log actions, update the ticket with ETA and next steps, and record SLA breach reason per process (for reporting/compliance).

## Quick questions to answer next
- Is there a linked incident (e.g., SEV-1/INC-…)? What's the customer impact (users affected, downtime)?
- Who is the current assignee and last update time? Any dependencies (third-party/vendor)?
- What's the target resolution path (rollback vs. fix vs. workaround)?

If you paste the latest internal note or assignee, I can suggest a tighter action plan (who to ping, what to ask, and a message template).

Where This Fits (and Where It Doesn't)

Be honest with yourself about when you need this:

Reach for MAI-Thinking-1 when:

The task genuinely requires multi-step reasoning — plan → check → revise → answer
You're processing long documents where a shallow summary isn't good enough
Your agent needs to reason about whether and how to call a tool, not just execute a fixed script

Don't reach for it when:

You need a fast autocomplete-style response (use a smaller/cheaper model — reasoning models trade latency for depth)
The task is simple classification or extraction with no ambiguity to reason through
You're cost-sensitive on high-volume, low-complexity calls — the MoE efficiency helps, but it's still priced above a lightweight model

Structured output, defensive parsing, and resilience patterns all still apply here exactly like they do with any other Foundry model — if you've read the earlier chapters on that, nothing changes; you're not throwing away any of the patterns you already have.

Wrapping Up

MAI-Thinking-1 is Microsoft's first real swing at a reasoning model, and the fact that it drops straight into the same IChatClient abstraction as every other Foundry model is, frankly, the best part. No new SDK to learn, no separate reasoning-specific message format — just a model that's better at the multi-step, tool-calling, long-context work that "just answer the prompt" models tend to fumble.

If you've been holding off on agentic workloads because the reasoning quality wasn't there yet, this is worth a real evaluation — not just a demo.

Source code can be found at: github.com/taswar/MaiThinkingDemo

Stop Stitching Models Together — Cohere Command A+ Lands in Microsoft Foundry

Taswar Bhatti — Mon, 03 Aug 2026 09:00:00 +0000

Enterprise AI teams have a familiar problem. You need multilingual support because your users are in Germany, Japan, and Brazil. You need document understanding because half your data lives in scanned PDFs and screenshots. You need tool calling because your agents have to actually do things, not just talk about them. And you need reasoning across long contexts because business decisions rarely fit in 4K tokens.

Historically, that meant stitching together three or four models. One for translation. One for OCR. One for reasoning. Something in the middle to orchestrate all of it. That is a lot of moving parts to keep in production.

Cohere Command A+ in Microsoft Foundry is designed to collapse that stack.

Announced as a Direct from Azure model, Command A+ is Cohere's latest open enterprise model — and their first mixture-of-experts (MoE) architecture. It brings together reasoning, long-context understanding, tool use, multilingual support, and multimodal input in a single model.

Honestly, this is the sort of release that matters more than the benchmark numbers suggest.

What Makes Command A+ Different

Three things are worth understanding before you evaluate this model.

It is a Mixture-of-Experts Model

218 billion total parameters. 25 billion active per token. That is roughly 11.5% activation.

If you have not worked with MoE architectures before, the short version: instead of every token going through every parameter, the model routes each token to a subset of "expert" sub-networks. You get the knowledge coverage of a large model at the inference cost of a much smaller one.

For enterprise workloads, this matters. Cohere lists hardware requirements of 1× B200 or 2× H100 at W4A4 quantization. That is a genuinely deployable footprint for a model with this level of capability.

It Speaks 48 Languages

Not "supports" — actually speaks. All official EU languages included. If you are building for a global enterprise, that is a compliance requirement in many places, not a nice-to-have.

It Handles Text and Images Together

Command A+ accepts text and image inputs. That opens up document processing scenarios where the useful information lives in charts, tables, screenshots, or scanned records — not just plain text.

The Full Spec Sheet

Field	Value
Architecture	Sparse Mixture-of-Experts
Total parameters	218B
Active parameters	25B
Context window	128K input, 64K output
Inputs	Text, image, tool calls
Outputs	Text, reasoning, tool calls
Languages	48 (all EU official languages included)
License	Apache 2.0 (also on Hugging Face)
Foundry pricing	$0.80 input / $3.20 output per 1M tokens

Where This Model Actually Fits

Cohere positions Command A+ for four workload types. Each one lines up with a real problem developers deal with in production.

1. Enterprise Agents

Agents that reason, plan, and call tools across multi-step workflows. Command A+ handles all four capabilities — reasoning, planning, tool use, and long context — in one model. If you are building agentic systems today with three different models glued together, this is worth evaluating as a consolidation play.

2. Knowledge Assistants and RAG

RAG applications over internal documents, policies, contracts, and knowledge bases. The 128K context window means you can fit a lot of retrieved chunks into a single call without aggressive truncation. Combined with multilingual support, this is well suited to global enterprises where the same knowledge base needs to answer questions in multiple languages.

3. Document Analysis Workflows

Summarising reports, extracting terms from contracts, comparing policies, analysing research papers. The multimodal input means it handles documents that mix text with charts, tables, and images — the kind of enterprise content where "just OCR it and pass to an LLM" produces bad results.

4. Multilingual Applications

Global customer support. Regional compliance reporting. Cross-market analytics. Command A+ was designed with 48-language coverage as a first-class feature, not a translation layer bolted on afterward.

That is a pretty focused positioning. This is not a general-purpose chatbot model — it is an enterprise agent and document processing model.

Enough Theory. Let's Actually Call It from CSharp

Here is a working .NET console app that calls Command A+ through Azure AI Foundry. I am using the Azure AI Inference SDK with DefaultAzureCredential for Entra ID auth — no API keys in code.

Sample code located at Github

Prerequisites

dotnet new console -n CohereCommandAPlusDemo
cd CohereCommandAPlusDemo
dotnet add package Azure.AI.Inference --prerelease
dotnet add package Azure.Identity

Set your environment variables:

# On Windows (PowerShell)
$env:AZURE_AI_CHAT_ENDPOINT = "https://YOUR-RESOURCE.services.ai.azure.com/models"
$env:AZURE_AI_MODEL = "cohere-command-a-plus"

Program.cs — Contract Analysis Example

Rather than a "tell me a joke" demo, let's do something that actually shows what Command A+ is good at. Here is a service that analyses a business contract and returns a structured summary — the kind of workflow you might drop into a document management pipeline.


using Azure.AI.Inference;
using Azure.Identity;
using Azure.Core;

var endpoint = Environment.GetEnvironmentVariable("AZURE_AI_CHAT_ENDPOINT")
    ?? throw new InvalidOperationException("Set AZURE_AI_CHAT_ENDPOINT environment variable.");

var model = Environment.GetEnvironmentVariable("AZURE_AI_MODEL") ?? "cohere-command-a-plus";

// DefaultAzureCredential handles Entra ID auth — no API key in code.
// Sign in first with: az login
var credential = new DefaultAzureCredential(new DefaultAzureCredentialOptions
{
    ExcludeManagedIdentityCredential = true
});

// Foundry (Cognitive Services) endpoints require a token whose audience is
// https://cognitiveservices.azure.com. Force that scope regardless of the
// scope the Azure.AI.Inference SDK requests by default.
var scopedCredential = new ScopeOverrideCredential(
    credential, "https://cognitiveservices.azure.com/.default");

var client = new ChatCompletionsClient(new Uri(endpoint), scopedCredential);

var options = new ChatCompletionsOptions
{
    Model = model,
    Temperature = 0.1f,
    MaxTokens = 2000
};

options.Messages.Add(new ChatRequestSystemMessage(
    """
    You are a senior contracts analyst reviewing enterprise agreements.

    Your job is to extract key terms and flag risks. Be precise and cite the exact
    contract language when identifying issues. If a required clause is missing,
    say so explicitly rather than guessing at its content.

    Return your analysis as structured JSON with these fields:
    -parties: array of parties to the agreement
    - effective_date: string or "not specified"
    - term_length: string or "not specified"
    - renewal_terms: string or "not specified"
    - key_obligations: array of strings
    - liability_cap: string or "not specified"
    - termination_clauses: array of strings
    - risks: array of { severity: "high"|"medium"|"low", description: string}
    """));

options.Messages.Add(new ChatRequestUserMessage(
    """
    Analyze the following service agreement excerpt:

    ---
    SOFTWARE LICENSING AGREEMENT

    This Agreement is entered into on 1 August 2026 between Zeytin Software Ltd
    ("Licensor") and GlobalCorp Industries GmbH ("Licensee").

    1.LICENSE GRANT.Licensor grants Licensee a non-exclusive, non-transferable
       license to use the Software during the Term.

    2. TERM. This Agreement shall commence on the Effective Date and continue
       for an initial period of three (3) years, automatically renewing for
       successive one (1) year periods unless either party provides ninety (90)
       days written notice of non-renewal.

    3. FEES. Licensee shall pay an annual license fee of EUR 250,000.

    4. LIABILITY. IN NO EVENT SHALL LICENSOR'S AGGREGATE LIABILITY EXCEED THE
       FEES PAID BY LICENSEE IN THE TWELVE (12) MONTHS PRECEDING THE CLAIM.

    5. TERMINATION. Either party may terminate this Agreement for material
       breach if such breach is not cured within thirty (30) days of written
       notice.
    ---
    """));

Console.WriteLine($"Calling model: {model}");
Console.WriteLine("---");

var response = await client.CompleteAsync(options);

Console.WriteLine(response.Value.Content);


// Wraps a TokenCredential and forces a fixed audience/scope, ignoring the
// scope the client pipeline asks for.
sealed class ScopeOverrideCredential : TokenCredential
{
    private readonly TokenCredential _inner;
    private readonly string[] _scopes;

    public ScopeOverrideCredential(TokenCredential inner, string scope)
    {
        _inner = inner;
        _scopes = new[] { scope };
    }

    public override AccessToken GetToken(TokenRequestContext requestContext, CancellationToken cancellationToken)
        => _inner.GetToken(new TokenRequestContext(_scopes), cancellationToken);

    public override ValueTask<AccessToken> GetTokenAsync(TokenRequestContext requestContext, CancellationToken cancellationToken)
        => _inner.GetTokenAsync(new TokenRequestContext(_scopes), cancellationToken);
}

Expected Output

{
  "parties": [
    "Zeytin Software Ltd (Licensor)",
    "GlobalCorp Industries GmbH (Licensee)"
  ],
  "effective_date": "1 August 2026",
  "term_length": "3 years (initial)",
  "renewal_terms": "Automatic renewal for successive one-year periods unless either party provides ninety (90) days written notice of non-renewal.",
  "key_obligations": [
    "Licensor grants Licensee a non-exclusive, non-transferable license to use the Software during the Term.",
    "Licensee shall pay an annual license fee of EUR 250,000."
  ],
  "liability_cap": "Licensor's aggregate liability is capped at the fees paid by Licensee in the twelve (12) months preceding the claim.",
  "termination_clauses": [
    "Either party may terminate for material breach if the breach is not cured within thirty (30) days after written notice.",
    "Non-renewal terminates the Agreement upon provision of ninety (90) days written notice."
  ],
  "risks": [
    {
      "severity": "high",
      "description": "Liability cap limited to fees paid in the prior 12 months may be insufficient to cover actual damages, exposing Licensee to significant risk if a major incident occurs."
    },
    {
      "severity": "high",
      "description": "Material breach clause lacks definition of what constitutes a material breach, creating uncertainty and potential disputes over termination rights."
    },
    {
      "severity": "high",
      "description": "No provision for warranties, indemnities, or remedies for software defects, leaving Licensee without recourse for faulty software."
    },
    {
      "severity": "medium",
      "description": "Governing law and dispute resolution mechanisms are absent, which may complicate enforcement and litigation."
    },
    {
      "severity": "medium",
      "description": "No confidentiality or data protection provisions, increasing risk of unauthorized disclosure or misuse of sensitive information."
    },
    {
      "severity": "medium",
      "description": "License is non-transferable, limiting Licensee's ability to assign or sublicense the software in future corporate restructurings."
    },
    {
      "severity": "low",
      "description": "Automatic renewal may lead to unintended continued licensing if the parties forget to provide the ninety‑day non‑renewal notice."
    }
  ]
}

That is structured, actionable output — the kind of thing you can pipe directly into a downstream review workflow or store as document metadata.

Multilingual Example — Same Prompt, Different Language

One of the more interesting things about Command A+ is that you can run the same structured prompt with content in any of 48 languages and get consistent output structure back. Here is the same analysis pattern with a German contract excerpt:


options.Messages.Clear();

Console.WriteLine($"Calling Multilingual: {model}");

options.Messages.Add(new ChatRequestSystemMessage(
    """
    You are a senior contracts analyst. Return your analysis in English JSON
    even if the source contract is in another language.
    """));

options.Messages.Add(new ChatRequestUserMessage(
    """
    Analysiere den folgenden Vertragsauszug:

    ---
    DIENSTLEISTUNGSVERTRAG


    Dieser Vertrag wird zwischen der Zeytin Software GmbH (&quot; Auftragnehmer & quot;)
    und der Berliner Handelsgesellschaft mbH (&quot; Auftraggeber & quot;) geschlossen.

    § 1 VERTRAGSGEGENSTAND.Der Auftragnehmer verpflichtet sich zur Bereitstellung
    von Softwareentwicklungsleistungen.

    § 2 LAUFZEIT. Der Vertrag beginnt am 15. September 2026 und läuft für eine
    Erstlaufzeit von zwei (2) Jahren.

    § 3 VERGÜTUNG. Der Auftraggeber zahlt einen monatlichen Betrag von EUR 18.500
    zzgl. gesetzlicher Umsatzsteuer.

    § 4 KÜNDIGUNG. Der Vertrag kann von beiden Seiten mit einer Frist von drei
    Monaten zum Ende eines Kalenderjahres gekündigt werden.
    ---
    """));

response = await client.CompleteAsync(options);
Console.WriteLine(response.Value.Content);

Sample output of Multilingual

json
{
  "contract_type": "Service Agreement",
  "parties": {
    "contractor": "Zeytin Software GmbH",
    "client": "Berliner Handelsgesellschaft mbH"
  },
  "subject_matter": "Contractor agrees to provide software development services.",
  "term": {
    "start_date": "2026-09-15",
    "initial_term": "2 years"
  },
  "compensation": {
    "amount_per_month": 18500,
    "currency": "EUR",
    "taxes": "plus statutory VAT"
  },
  "termination": {
    "notice_period": "3 months",
    "termination_date_alignment": "end of calendar year",
    "available_to": "both parties"
  },
  "key_provisions": [
    "Monthly payment of €18,500 plus VAT.",
    "Either party may terminate with 3 months' notice to the end of a calendar year."
  ],
  "risk_assessment": {
    "early_termination_risk": "Since the contract starts on 15 September 2026, the first possible termination date is 31 December 2026, requiring notice by 30 September 2026 – only 15 days after commencement.",
    "scope_ambiguity": "The contract does not define the scope of software development services, deliverables, milestones, or acceptance criteria.",
    "payment_structure": "Fixed monthly fee without performance-based adjustments; no provision for price revisions or inflation."
  },
  "recommendations": [
    "Define service scope, deliverables, milestones, and acceptance criteria in an annex or statement of work.",
    "Consider adding a price review clause (e.g., annual adjustment based on CPI).",
    "Clarify whether termination notices must be in writing and specify the exact method of delivery.",
    "Include governing law and dispute resolution provisions explicitly.",
    "Address intellectual property rights, confidentiality, and data protection obligations."
  ]
}

You get the same JSON structure back, with German-language terms parsed correctly and the analysis delivered in English. That is genuinely useful for global enterprises where legal teams work in local languages but reporting rolls up centrally.

Why Run It on Microsoft Foundry Instead of Cohere Direct?

Cohere offers Command A+ through their own API and on Hugging Face under Apache 2.0. So why bother with Foundry?

If you are already in Azure, Foundry gives you a few things you cannot easily replicate elsewhere:

Entra ID authentication — no API keys in source, no separate credential management
Enterprise governance — data residency, compliance, audit logging built into the platform
Side-by-side model evaluation — compare Command A+ against Kimi K2.7 Code, Claude Opus 4.8, or GPT-4o on the same dataset without setting up multiple SDKs
Unified billing — one Azure invoice covers all models, not one bill per vendor
Foundry Agent Service and RAG pipelines — plug Command A+ directly into Foundry's agentic infrastructure

For an enterprise team already invested in Azure, Foundry is the easier operational choice. For solo experimentation or non-Azure deployments, direct API or self-hosting on Hugging Face makes sense too.

Final Thoughts

Command A+ is not the flashiest model announcement of the year. It is not going to top general-purpose benchmarks. But it is genuinely positioned for a class of enterprise problems that have been underserved: multilingual agentic workflows over multimodal documents at reasonable cost.

If your team is building enterprise agents, RAG applications, or document analysis pipelines — especially with multilingual requirements — this is worth evaluating alongside your existing models. At $0.80 input / $3.20 output per million tokens, it is priced to compete for real production workloads.

The MoE architecture is also worth watching more broadly. Expect more of the frontier lab releases over the next 12 months to go this route. Command A+ is an early mainstream option to build intuition against.

If your team already builds RAG over internal documents, ships multilingual applications, or runs agentic workflows in production — this is one worth wiring into your evaluation harness. 🙂