DEV Community: Taswar Bhatti

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

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.

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. 🙂

Resources

Kimi K2.7 Code is Now Available in Microsoft Foundry

Taswar Bhatti — Fri, 31 Jul 2026 09:26:32 +0000

There are a lot of AI model announcements these days. But every now and then one lands that feels immediately practical for real engineering work.

Kimi K2.7 Code from Moonshot AI showing up in Microsoft Foundry feels like one of those releases.

Microsoft and Moonshot AI have made Kimi K2.7 Code available in the Foundry model catalog starting July 1, 2026. It is designed for the kind of software engineering that does not happen in a single prompt — multi-file refactors, feature work spanning multiple services, debugging sessions that need to hold context across many steps.

That is a different problem space from "generate a todo app in one shot." And honestly, that is where most development teams are today.

What Is Kimi K2.7 Code?

Kimi K2.7 Code is a coding-focused model from Moonshot AI. It builds on the K2.6 series with three focused improvements:

Long-horizon task execution — carries work across multiple files, tools, and steps
Stronger end-to-end task completion — designed to finish tasks, not just generate fragments
~30% fewer thinking tokens vs K2.6 — faster responses, lower cost, more work per context window

The 256K context window is the other number worth noting. Large codebases, long refactoring sessions, multiple files in context at once — that is the use case this model is optimized for.

Benchmark Numbers — The Honest Read

Here is how K2.7 Code stacks up against K2.6 and two frontier models:

Benchmark	Kimi K2.6	Kimi K2.7 Code	GPT-5.5	Claude Opus 4.8
Kimi Code Bench v2	50.9	62.0	69.0	67.4
Program Bench	48.3	53.6	69.1	63.8
MLS Bench Lite	26.7	35.1	35.5	42.8
MCP Atlas	69.4	76.0	79.4	81.3
MCP Mark Verified	72.8	81.1	92.9	76.4

A few things worth flagging:

The Kimi Code Bench numbers are Moonshot AI's own benchmark — take those as directional. MCP Mark Verified is human-verified and more credible for independent comparison. On that benchmark, K2.7 Code at 81.1 actually beats Claude Opus 4.8 at 76.4. That is the benchmark most relevant to agentic coding workflows with tool use.

On pure coding tasks (Program Bench, MLS Bench Lite), it sits between GPT-5.5 and Claude Opus 4.8. That is a reasonable position for a model priced at $0.95 input / $4.00 output per million tokens.

Pricing

	Input / 1M tokens	Output / 1M tokens	Cached Input
Kimi K2.7 Code	$0.95	$4.00	$0.19

At $0.95 input, this sits below GPT-4o-class pricing. For long-running coding tasks that consume a lot of output tokens, $4.00/M output is the number to watch. Cached input at $0.19 helps when you are repeatedly loading the same large codebase context.

Top Use Cases

If you are evaluating this model, here is where it fits:

Software engineering agents — multi-step planning, tool use, execution across a full development workflow
Repository-scale code understanding — analyze, modernize, or refactor large codebases while keeping context across many files
Complex feature implementation — changes that span multiple services, components, and repositories
Debugging and root cause analysis — deeper code understanding over multi-step investigation workflows

That is a pretty specific profile. This is not a general-purpose chatbot. It is a model built for developer tooling and autonomous coding agents.

Enough Theory. Let's Actually Call It from CSharp

Here is a working .NET console app that calls Kimi K2.7 Code through Azure AI Foundry. I am using the Azure AI Inference SDK and DefaultAzureCredential — no API key hardcoded.

Code also located at (Github|https://github.com/taswar/KimiFoundryDemo)

Prerequisites

dotnet new console -n KimiFoundryDemo
cd KimiFoundryDemo
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://YOURRESOURCE.services.ai.azure.com/models"
az login
$env:AZURE_AI_MODEL = "kimi-k2-7-code"

Program.cs


using Azure.Identity;
using Azure;
using Azure.AI.Inference;
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") ?? "Kimi-K2.7-Code";

// 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.2f,
    MaxTokens = 2000
};

options.Messages.Add(new ChatRequestSystemMessage(
    """
    You are a senior .NET architect.
    Your job is to review code and identify issues clearly and concisely.
    Be direct. Prioritize correctness over style.
    Return findings as a numbered list with severity: critical, warning, or info.
    """));

options.Messages.Add(new ChatRequestUserMessage(
    """
    Review the following C# method and identify any issues:

    public async Task GetUserAsync(int userId)
    {
        var user = await _dbContext.Users
            .Where(u => u.Id == userId)
            .FirstOrDefault();

        return user;
    }
    """));

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

Response<ChatCompletions> response = client.Complete(options);
System.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

Something like:


Calling model: kimi-k2-7-code
---
1. **Critical — `Task` return type does not match returned value**  
   The method returns `user`, but the signature returns non-generic `Task`. Change it to `Task<User?>` (or `Task<User>` if nullability is disabled).

2. **Critical — Synchronous `FirstOrDefault` used in an async method**  
   `.FirstOrDefault()` executes the query synchronously and is not awaitable. Use `.FirstOrDefaultAsync()` (and pass a `CancellationToken`).

3. **Warning — Missing `CancellationToken`**  
   Async methods should accept `CancellationToken cancellationToken = default` and forward it to `FirstOrDefaultAsync(cancellationToken)`.

4. **Info — Consider `FindAsync` for primary-key lookups**  
   Since the query is by primary key, `_dbContext.Users.FindAsync(userId, cancellationToken)` is more idiomatic and can be faster due to EF change-tracker short-circuiting.

That is the kind of output you want from a code review tool — specific, actionable, severity-tagged.

Why Run It in Foundry vs Directly?

If you are already in Azure, Foundry gives you a few things you do not get with a direct Moonshot API key:

Enterprise security and compliance — governance, data protection, responsible AI tooling built in
Side-by-side evaluation — compare Kimi K2.7 Code against GPT-5.5, Claude Opus 4.8, or any other Foundry model using the same evaluation dataset
GitHub Copilot and VS Code integration — native compatibility with the developer tools your team already uses
No separate infrastructure — model is already deployed, monitored, and scaled for you

That last point matters more than it sounds. The jump from "I tried this in a notebook" to "this is running in our CI pipeline" is usually infrastructure, not capability. Foundry removes that friction.

Final Thoughts

Kimi K2.7 Code in Microsoft Foundry is interesting for developers because it is not just a benchmark improvement. It is a model positioned for the kind of work that is genuinely hard to automate well: long-running, multi-step, multi-file engineering tasks.

The MCP Mark Verified score beating Claude Opus 4.8 is the number I would keep an eye on as agentic coding workflows mature. If your team is building AI-assisted developer tooling or coding agents, this is one worth evaluating.

If you are already on Azure AI Foundry, the model is in the catalog now. Start with the C# code above, swap in your own endpoint, and run it against a real method from your codebase. That will tell you more than any benchmark.

Resources

MAI-Image-2.5 Pro for .NET Developers — Microsoft's Own Image Model Lands in Foundry

Taswar Bhatti — Wed, 29 Jul 2026 08:00:00 +0000

Every time a new image model ships, my first question isn't "how pretty are the demo images." It's "can I actually put this in a pipeline and get consistent, controllable output." Most image models are great at one beautiful hero shot and terrible at the boring part — generating twelve consistent product variants, or fixing one object in an image without regenerating the whole thing.

Microsoft AI just shipped MAI-Image-2.5 Pro, now available in public preview in Microsoft Foundry as an Azure Direct Model. It's Microsoft's own image generation and image-editing model — not a third-party model hosted in the catalog, but one built in-house by Microsoft AI.

That is worth pausing on. Alongside it, MAI-Voice-2 Flash also shipped for real-time voice through Azure Speech. This post is about the image model (I will cover MAI-Voice-2 Flash in another post), because that is the one .NET developers building content pipelines, e-commerce catalogs, or design tools will actually reach for first.

What MAI-Image-2.5 Pro Actually Does

It's a diffusion-based text-to-image and image-to-image model. Two capabilities matter more than the others:

Generation — natural language prompt in, high-fidelity image out
Precise editing — targeted object edits, layout changes, text updates, and cleanup of artifacts like motion blur, all while preserving visual consistency across iterations

That second bullet is the interesting one. "Precise, surgical edits with consistency" is the phrase Microsoft uses, and it's the right framing. A lot of image models will happily regenerate an entire scene when you ask for one small change — swap the color of a shirt and the model quietly redraws the face too. MAI-Image-2.5 Pro is positioned specifically to avoid that.

Why It Matters

Professional creative quality — stronger object consistency, more accurate text rendering (a famously hard problem for diffusion models), closer alignment to what you actually asked for, and better visual/world reasoning
More model choice in Foundry — you can now pick a purpose-built Microsoft model for creative workflows alongside the rest of the Foundry catalog, the same way you'd pick Kimi K2.7 Code for coding tasks or Cohere Command A+ for enterprise agents
Enterprise-ready foundations — backed by Microsoft's safety and Responsible AI practices, running on Azure infrastructure for reliability, scale, and governance

Honestly, that last point is the one enterprises actually care about. A lot of image models are impressive right up until legal asks about content provenance and data handling.

Where This Fits — Real Use Cases

Microsoft calls out two buckets, and both map to real backlog items I've seen teams carry for months:

Campaigns and product content. Consistent hero assets, social media variants, retail signage, digital ads, product photography, e-commerce catalogs. The "consistency across iterations" capability is exactly what you need when you're generating fifteen size/color variants of the same product shot and they all need to look like the same product line.

Storyboarding and regulated-industry visuals. Consistent scenes, characters, and concepts with stronger real-world accuracy — relevant for creative production, but also healthcare, financial services, and manufacturing, where "close enough" visual accuracy isn't good enough.

If your team maintains a product catalog, a marketing asset pipeline, or anything that currently involves a human manually generating fifty variants of one image in Photoshop — this is worth a pilot.

Let's Actually Call It from CSharp

MAI-Image-2.5 Pro is available through the Foundry Model Catalog as an Azure Direct Model. Image generation models on Foundry are exposed through an OpenAI-compatible images endpoint, so the calling pattern will look familiar if you've used ImageClient from the Azure OpenAI SDK before.

Prerequisites

dotnet new console -n Mai-Image-2.5Pro-Demo
cd Mai-Image-2.5Pro-Demo
dotnet add package Azure.Core
dotnet add package Azure.Identity

Set your environment variables:

# On Windows (PowerShell)
$env:AZURE_AI_FOUNDRY_ENDPOINT = "https://YOUR-RESOURCE.services.ai.azure.com"
$env:AZURE_AI_IMAGE_MODEL = "MAI-Image-2.5-Pro"

Program.cs — Generate a Product Image

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

var endpoint = Environment.GetEnvironmentVariable("AZURE_AI_FOUNDRY_ENDPOINT")
    ?? throw new InvalidOperationException("Set AZURE_AI_FOUNDRY_ENDPOINT.");

var model = Environment.GetEnvironmentVariable("AZURE_AI_IMAGE_MODEL") ?? "MAI-Image-2.5-Pro";

var prompt = """
    A minimalist product photo of a stainless steel water bottle on a plain
    white background, studio lighting, soft shadow beneath the bottle,
    e-commerce catalog style, no text on the label.
    """;

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

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

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

using var content = new StringContent(
    JsonSerializer.Serialize(mai_payload),
    Encoding.UTF8,
    "application/json");

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

if (!response.IsSuccessStatusCode)
{
    Console.WriteLine($"Image generation failed: {(int)response.StatusCode} {response.ReasonPhrase}");
    Console.WriteLine(responseBody);
    throw new InvalidOperationException($"{model} image generation request failed.");
}

using JsonDocument json = JsonDocument.Parse(responseBody);
string? b64 = json.RootElement
    .GetProperty("data")[0]
    .GetProperty("b64_json")
    .GetString();

if (string.IsNullOrWhiteSpace(b64))
{
    throw new InvalidOperationException("Response did not contain data[0].b64_json.");
}

byte[] imageBytes = Convert.FromBase64String(b64);
string outputPath = Path.Combine(Environment.CurrentDirectory, "product-bottle.png");
await File.WriteAllBytesAsync(outputPath, imageBytes);
Console.WriteLine($"Image saved to: {outputPath}");

Editing an Existing Image — Targeted, Not a Full Regeneration

This is the part that matters more than pure generation. Here's how you make one precise change to an existing product shot — swap the bottle color without touching the background, lighting, or shadow:

var editPrompt = """
    Change the bottle color from stainless steel to matte black.
    Keep the background, lighting, shadow, and camera angle exactly the same.
    """;

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

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

byte[] sourceImageBytes = await File.ReadAllBytesAsync(outputPath);
var imagePart = new ByteArrayContent(sourceImageBytes);
imagePart.Headers.ContentType = new MediaTypeHeaderValue("image/png");
editContent.Add(imagePart, "image", "product-bottle.png");

Console.WriteLine("Editing image...");

using HttpResponseMessage editResponse = await http.PostAsync(editUrl, editContent);
string editResponseBody = await editResponse.Content.ReadAsStringAsync();

if (!editResponse.IsSuccessStatusCode)
{
    Console.WriteLine($"Image edit failed: {(int)editResponse.StatusCode} {editResponse.ReasonPhrase}");
    Console.WriteLine(editResponseBody);
    throw new InvalidOperationException($"{model} image edit request failed.");
}

using JsonDocument editJson = JsonDocument.Parse(editResponseBody);
string? editB64 = editJson.RootElement
    .GetProperty("data")[0]
    .GetProperty("b64_json")
    .GetString();

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

byte[] editedImageBytes = Convert.FromBase64String(editB64);
string editedOutputPath = Path.Combine(Environment.CurrentDirectory, "product-bottle-black.png");
await File.WriteAllBytesAsync(editedOutputPath, editedImageBytes);
Console.WriteLine($"Image saved to: {editedOutputPath}");

Expected Output

Generating image with MAI-Image-2.5-Pro...
Saved: product-bottle.png
Editing image...
Saved: product-bottle-black.png

Two files. Same lighting, same shadow, same camera angle. One bottle color changed. That is the workflow you'd wire into a service that generates every SKU variant overnight instead of a designer doing it by hand.

📝 Note: The exact SDK surface for Foundry image models is still settling as this model is in public preview — check the Foundry Model Catalog page for the current API reference before you wire this into production. The calling pattern above follows the standard Http Client image generation shape; MAI-Image models aren't compatible with the Azure.AI.OpenAI SDK's ImageClient — they require the raw REST call. Do confirmed against the latest docs, since things change very fast.

Why Run It Through Microsoft Foundry

Same reasoning as every other model I've covered in this series — Kimi K2.7 Code, Cohere Command A+ — but with one extra point specific to this model:

It's a first-party Microsoft model. Support, roadmap, and Responsible AI documentation come from the same team building the platform you're deploying on.
Entra ID auth — no separate API key management for yet another vendor.
Governance and safety tooling built into the platform, which matters more for image generation than most other model types — content policy and provenance questions come up fast in creative workflows.
Side-by-side evaluation against other Foundry models if you're also experimenting with other image generation options.

Final Thoughts

MAI-Image-2.5 Pro is Microsoft betting on its own first-party model for a category — image generation — that has mostly been third-party territory in Foundry until now. The pitch isn't "prettiest demo image." It's "precise edits with consistency," which is the actual bottleneck for anyone trying to move image generation from a design toy into a production content pipeline.

If your team maintains product catalogs, marketing assets, or storyboards and you're currently paying a human to manually generate every size and color variant — this is worth a pilot. Start with the generate-then-edit pattern above, point it at a real product shot, and see how many variants you can produce in a loop before lunch.

Resources

MAI-Voice-2 Flash for .NET Developers — Real-Time Voice on Azure Speech

Taswar Bhatti — Tue, 28 Jul 2026 09:00:00 +0000

MAI-Voice-2 Flash for .NET Developers — Real-Time Voice on Azure Speech

Every voice application I've ever built or reviewed has the same problem: latency. The model can sound as natural as you want, but if there's a full second of dead air between the user finishing a sentence and the assistant responding, the whole thing feels broken. Users notice a pause before they notice voice quality.

Microsoft AI just shipped MAI-Voice-2 Flash, a text-to-speech model built specifically to fix that. It's the low-latency sibling of MAI-Voice-2, now available through Azure Speech — not a separate SDK, not a new service to learn, just a new voice option inside the Speech service you may already be using.

Same day, Microsoft also shipped MAI-Image-2.5 Pro for high-fidelity image generation (I covered that one in a separate post if you're building creative/image pipelines). This post is about the voice model, because if you're building call center agents, IVR systems, or conversational assistants in .NET, this is the one that actually changes your architecture.

What MAI-Voice-2 Flash Actually Does

It's a text-to-speech model, tuned for one specific tradeoff: speed over voice customization.

2x faster than MAI-Voice-2, same natural voice quality
32% more cost-efficient
15+ languages supported — English (US/AU), Italian, Spanish (Mexico/Spain), Hindi, French, German, Portuguese (Brazil/Portugal), Korean, Chinese (Simplified), Turkish, Russian, Thai, Dutch, Romanian, Hungarian
Voice cloning from 5–60 second audio prompts — natural, conversational delivery with moderate energy gives the best results
SSML support for voice selection and pacing — see the SSML section below for what actually works today

MAI-Voice-2 Flash vs. MAI-Voice-2 — Which One Do You Actually Want?

Microsoft's own guidance on this is refreshingly direct: it comes down to voice identity vs. responsiveness.

Choose MAI-Voice-2 Flash when:

Low latency is the primary requirement
You're building conversational assistants, IVR systems, or call center experiences
Users expect an immediate spoken response as part of a live interaction
Cost efficiency matters as much as responsiveness

Choose MAI-Voice-2 instead when voice identity and higher-fidelity output matter more than raw speed — think narration, media production, or anything not happening in a live back-and-forth.

If your use case involves a human waiting on the other end of a phone call or a chat window, you want Flash.

Where This Fits — Real Use Cases

Microsoft calls out three scenarios, and all three map to things I've seen teams either build badly or avoid building entirely because of latency:

Call center agents. Spoken responses generated in real time, minimizing the delay between conversation turns. This is the difference between an AI agent that sounds like it's thinking and one that sounds like it's stalling.

Conversational voice assistants. Copilots and intelligent applications that respond nearly instantly — the fluid, interactive feel instead of the stilted turn-based one.

Modern IVR systems. Dynamic, context-aware phone experiences that respond to what the caller actually says instead of routing through a rigid menu tree.

If you're maintaining a legacy IVR system held together with pre-recorded prompts and DTMF menus, or a support bot that has a noticeable pause before every response — this is worth a pilot.

Pricing

MAI-Voice-2 Flash pricing starts at $15 per 1M characters. For comparison, MAI-Image-2.5 Pro (the image model announced alongside it) starts at $5 per 1M input tokens and $106 per 1M output tokens — a completely different pricing shape, since one generates images and the other generates audio from text.

For a call center handling, say, 200-character average responses across 10,000 calls a day, that's roughly 2M characters/day — a genuinely calculable cost before you commit to an architecture.

Setting Up Azure Speech — Full Instructions

Since MAI-Voice-2 Flash ships through Azure Speech rather than a standalone endpoint, you set it up exactly like any other Speech resource. Here's the complete path from zero to a working API key.

Step 1: Create a Speech Resource in Azure

Go to the Azure Portal
Click Create a resource
Search for Speech service (or Azure AI Foundry if you want the unified Foundry resource — both work for this)
Click Create
Fill in:
- Subscription — your Azure subscription
- Resource group — create new or use existing
- Region — pick a region that supports MAI-Voice-2 Flash (check the model catalog page for current regional availability — this is in public preview and region support is still expanding)
- Name — something like my-speech-resource
- Pricing tier — Standard (S0) for production use
Click Review + Create, then Create

Step 2: Get Your Key and Region

Once deployed, go to your Speech resource
Click Keys and Endpoint in the left sidebar
Copy KEY 1 and note your Region (e.g., eastus)

Step 3: Store Secrets Properly

Don't hardcode the key. Use user-secrets for local development:

dotnet new console -n MaiVoiceFlashDemo
cd MaiVoiceFlashDemo
dotnet user-secrets init
dotnet user-secrets set "Speech:Key" "YOUR_SPEECH_KEY"
dotnet user-secrets set "Speech:Region" "eastus"

Step 4: Install the Speech SDK

dotnet add package Microsoft.CognitiveServices.Speech
dotnet add package Microsoft.Extensions.Configuration.UserSecrets

Let's Actually Call It from CSharp

Here's a working console app that synthesizes speech using the Azure Speech SDK, configured for low-latency real-time output — the pattern you'd actually use for a conversational assistant.

Program.cs — Basic Synthesis

using Microsoft.CognitiveServices.Speech;
using Microsoft.CognitiveServices.Speech.Audio;
using Microsoft.Extensions.Configuration;

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

var speechKey = config["Speech:Key"]
    ?? throw new InvalidOperationException("Set Speech:Key via user-secrets.");
var speechRegion = config["Speech:Region"]
    ?? throw new InvalidOperationException("Set Speech:Region via user-secrets.");

var speechConfig = SpeechConfig.FromSubscription(speechKey, speechRegion);

// Voice name follows Azure Speech naming conventions — check the Foundry model
// catalog / Speech Studio voice gallery for the exact MAI-Voice-2 Flash voice
// identifier available in your region during public preview.
speechConfig.SpeechSynthesisVoiceName = "en-US-Olivia:MAI-Voice-2-Flash";

// Output directly to the default speaker. Swap AudioConfig for a file or
// in-memory stream if you're serving this from a web API instead of a console app.
using var audioConfig = AudioConfig.FromDefaultSpeakerOutput();
using var synthesizer = new SpeechSynthesizer(speechConfig, audioConfig);

var text = "Thanks for calling. I can help you check your order status, " +
           "process a return, or connect you with a specialist. What do you need today?";

Console.WriteLine("Synthesizing...");

using var result = await synthesizer.SpeakTextAsync(text);

if (result.Reason == ResultReason.SynthesizingAudioCompleted)
{
    Console.WriteLine("Done. Audio played through default speaker.");
}
else if (result.Reason == ResultReason.Canceled)
{
    var cancellation = SpeechSynthesisCancellationDetails.FromResult(result);
    Console.WriteLine($"Canceled: {cancellation.Reason}");

    if (cancellation.Reason == CancellationReason.Error)
    {
        Console.WriteLine($"Error code: {cancellation.ErrorCode}");
        Console.WriteLine($"Error details: {cancellation.ErrorDetails}");
    }
}

Expected Output

Synthesizing...
Done. Audio played through default speaker.

You should hear the response with noticeably less delay than a standard-tier voice model — that's the "2x faster" claim showing up as an actual user experience difference, not just a benchmark number.

Streaming to a Web API Response (Real-Time Use Case)

For an actual call center or assistant integration, you're not playing audio through a speaker — you're streaming bytes back to a caller or a browser. Here's the pattern for an ASP.NET Core minimal API endpoint that returns synthesized speech as a stream:

using Microsoft.CognitiveServices.Speech;
using Microsoft.CognitiveServices.Speech.Audio;

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapPost("/speak", async (SpeakRequest request, IConfiguration config) =>
{
    var speechConfig = SpeechConfig.FromSubscription(
        config["Speech:Key"], config["Speech:Region"]);

    speechConfig.SpeechSynthesisVoiceName = "en-US-Olivia:MAI-Voice-2-Flash";
    speechConfig.SetSpeechSynthesisOutputFormat(
        SpeechSynthesisOutputFormat.Audio24Khz96KBitRateMonoMp3);

    // No audio config = in-memory result instead of playing to a device
    using var synthesizer = new SpeechSynthesizer(speechConfig, null);
    using var result = await synthesizer.SpeakTextAsync(request.Text);

    if (result.Reason != ResultReason.SynthesizingAudioCompleted)
    {
        var cancellation = SpeechSynthesisCancellationDetails.FromResult(result);
        return Results.Problem($"Synthesis failed: {cancellation.ErrorDetails}");
    }

    return Results.File(result.AudioData, "audio/mpeg");
});

app.Run();

record SpeakRequest(string Text);

Call it with:

curl -X POST https://localhost:5001/speak \
  -H "Content-Type: application/json" \
  -d '{"text":"Your order has shipped and will arrive Thursday."}' \
  --output response.mp3

That is the shape of the endpoint sitting behind a real call center agent or IVR system — take text, return audio, keep the round trip fast.

Using SSML for Turn-Level Control — What Actually Works
Microsoft’s own materials describe MAI-Voice-2 Flash as supporting “turn-level control over tone, delivery, and emotion.” The obvious first move for anyone who’s used Azure Speech before is to reach for the classic mstts:express-as element — the same one you’d use with a standard Neural voice to say “make this line sound cheerful” or “empathetic.”

I tried it. It doesn’t work.

Here’s the SSML I first attempted, styled the same way you’d write it for any legacy Neural voice:


// ⚠️ THIS DOES NOT WORK ON MAI-VOICE-2-FLASH — kept here so you don't waste
// the 20 minutes I did trying to debug a namespace typo that wasn't the problem.
var ssmlBroken = """
    <speak version="1.0" xmlns="http://www.w3.org/2001/10/synthesis" xml:lang="en-US">
        <voice name="en-US-Ava:MAIVoice2FlashNeural">
            <mstts:express-as style="empathetic" xmlns:mstts="https://www.w3.org/2001/mstts">
                I'm sorry to hear your order arrived damaged.
            </mstts:express-as>
        </voice>
    </speak>
    """;

using var ssmlResult = await synthesizer.SpeakSsmlAsync(ssmlBroken);
// result.Reason == ResultReason.Canceled
// cancellation.ErrorCode == invalid_request

So what does “turn-level control over tone, delivery, and emotion” actually mean today? As of this public preview, it’s unclear. It may be a plain-text delivery cue baked into the prompt, or an MAI-specific SSML extension that isn’t documented yet. I could not find a combination that worked, and I’d treat that marketing line as aspirational until Microsoft publishes the actual mechanism.

Using SSML for Voice, Pacing, and Pauses

Strip out express-as entirely and SSML still earns its place — you get voice selection, break for natural pauses, and prosody control, all of which the service accepts without complaint:

var ssml = """
    <speak version="1.0" xmlns="http://www.w3.org/2001/10/synthesis" xml:lang="en-US">
        <voice name="en-US-Olivia:MAI-Voice-2-Flash">
            I'm sorry to hear your order arrived damaged.
            <break time="300ms"/>
            Let's get that sorted out right away.
        </voice>
    </speak>
    """;

using var ssmlResult = await synthesizer.SpeakSsmlAsync(ssml);

No emotion tags, no style attribute — just the voice name and a deliberate pause between the apology and the resolution. That pause alone does more for how “human” the response feels than most developers expect. It’s a smaller toolkit than advertised, but it’s a toolkit that actually ships a ResultReason.SynthesizingAudioCompleted instead of a canceled request.

Same Pattern in Turkish

MAI-Voice-2 Flash's multilingual support means the same SSML structure carries across languages — change xml:lang, the voice name, and the text:

var ssmlTurkish = """
    <speak version="1.0" xmlns="http://www.w3.org/2001/10/synthesis" xml:lang="tr-TR">
        <voice name="tr-TR-Elif:MAI-Voice-2-Flash">
            Siparişinizin hasarlı ulaştığını duyduğuma üzüldüm. Hemen bir iade işlemi başlatıyorum, birkaç saniye sürecek.
        </voice>
    </speak>
    """;

using var ssmlResultTr = await synthesizer.SpeakSsmlAsync(ssmlTurkish);

Translation for reference: "I'm sorry to hear your order arrived damaged. I'm starting a return right away — it will just take a few seconds."

This is the actual payoff of a multilingual low-latency voice model for a call center: one codebase, one SpeakSsmlAsync call, and the only thing that changes per market is the xml:lang, the voice name, and the translated text. You're not maintaining a separate TTS integration per region.

📝 Note: Voice names for MAI-Voice-2 Flash are still being finalized during public preview. Check the Foundry model catalog or Speech Studio's voice gallery for the exact identifiers available in your region — including Turkish — before shipping this to production.

Why Run It Through Azure Speech (Not a Separate Vendor)

If you're already using Azure Speech for any part of your stack, this is close to a zero-integration-cost upgrade:

Same SDK, same auth pattern — no new NuGet package beyond what you likely already have
Enterprise reliability and scale — the infrastructure Azure Speech already runs on
Same Responsible AI and governance guardrails as the rest of Foundry
Regional deployment options to keep voice data processing where compliance requires it

For teams already invested in Azure Speech for STT or existing TTS voices, swapping in MAI-Voice-2 Flash for your latency-sensitive scenarios is a configuration change, not a rewrite.

Final Thoughts

MAI-Voice-2 Flash is a narrow, well-aimed release. It's not trying to be the most expressive or highest-fidelity voice model Microsoft ships — that's what MAI-Voice-2 is for. It's optimized for the one metric that actually breaks real-time voice experiences: the gap between "user stops talking" and "assistant starts responding."

If you're building or maintaining call center agents, IVR systems, or conversational assistants, and users have ever complained about the pause before the response — this is worth a pilot. Point it at your existing Azure Speech integration, swap the voice name, and measure the round-trip time yourself.

If your team already runs on Azure Speech and just wants faster responses without switching vendors, this is one worth wiring in this week. 🙂

Resources

Prompt Engineering for .NET Developers: A Free, No-Python Guide to Building Real AI Features in C#

Taswar Bhatti — Mon, 27 Jul 2026 07:02:49 +0000

Most prompt engineering content out there assumes you're writing Python. Jupyter notebooks, pip install, Conda environments — none of it maps to how most of us actually ship software.

If you're a .NET developer who wants to build real AI-powered features — not toy demos — into your applications, I wrote a free ebook for exactly that: Prompt Engineering for .NET Developers.

Why I wrote this

Every prompt engineering tutorial I found was Python-first. Meanwhile, Microsoft.Extensions.AI gives .NET developers a clean, unified abstraction over LLM providers — LM Studio, OpenAI, Azure AI Foundry — using the exact same IChatClient interface. There was no practical, runnable guide to prompt engineering that met C# developers where they already live.

So I built one.

What's inside

Seven focused chapters, each ending in a runnable C# project:

The .NET Developer's AI Landscape — the cost spectrum and Microsoft's AI stack
Setting Up Your AI Dev Environment — LM Studio, OpenAI, Azure AI Foundry, all via the same interface
How LLMs Work — just enough theory to write better prompts, no transformer lecture
Anatomy of a Great Prompt — you'll build a fluent PromptBuilder class
Core Prompting Techniques — zero-shot, few-shot, chain-of-thought, and how to handle sycophancy (the silent failure mode where the model just tells you what you want to hear)
Structured Outputs and Advanced Patterns — defensive JSON parsing, streaming, resilience
Prompt Patterns for Real Developer Workflows — you'll carry PromptBuilder into DevToolkit, a console app that does AI-powered code review, test generation, commit messages, and docs

No Jupyter. No Python. Just dotnet new console and code that runs.

Try it in 5 minutes

git clone https://github.com/taswar/PromptEngineeringForDotNetDevelopers
cd PromptEngineeringForDotNetDevelopers/chapter-04/src/PromptBuilder
dotnet run

That's the PromptBuilder fluent class from Chapter 4, running against a local model — zero API cost.

Get it
📥 Download free on Leanpub (pay-what-you-want, including $0)
⭐ Star it on GitHub if it's useful — it's the best free way to help other .NET devs find it
🐛 Found a typo or have a suggestion? Open an issue
👉 Subscribe Newsletter for tips and trick

If you've been putting off learning prompt engineering because every guide assumes Python, this is for you. Would love to hear what you build with it — drop a comment or open a GitHub discussion.