LM-Kit.NET · Coming from Azure OpenAI

From Azure OpenAI, into your process.

If your .NET code talks to Azure OpenAI through Microsoft.Extensions.AI or Semantic Kernel, the abstractions you chose for portability can now pay out: swap the client, and inference runs inside your application.

IChatClient stays IChatClient Prompts and data stay in process Free to build and evaluate

The migration is one client.

Both Microsoft bridges are official LM-Kit integrations. Everything written against the abstraction keeps working.

The IChatClient your services consume gets a local implementation.

Program.cs

using LMKit.Integrations.ExtensionsAI.ChatClient;
using LMKit.Model;

// Before: chat client from the Azure OpenAI SDK.
// IChatClient client = azureClient.GetChatClient("gpt-4o").AsIChatClient();

// After: the same abstraction, served by a local model.
var model = LM.LoadFromModelID("qwen3.5:9b");
IChatClient client = new LMKitChatClient(model);

// Every consumer of IChatClient is untouched.
var reply = await client.GetResponseAsync("Summarize this contract clause.");

Kernel plugins, prompts, and planners stay; the connector changes.

Program.cs

using LMKit.Integrations.SemanticKernel;
using LMKit.Model;

var builder = Kernel.CreateBuilder();

// Before: builder.AddAzureOpenAIChatCompletion("gpt-4o", endpoint, key);
var model = LM.LoadFromModelID("qwen3.5:9b");
builder.AddLMKitChatCompletion(model);

var kernel = builder.Build();

Prefer a server to a library? Point the OpenAI-compatible client at LM-Kit One instead.

Program.cs

// The same engine, served over HTTP for every app on the team.
var client = new OpenAIClient(
    new ApiKeyCredential("your-server-token"),
    new OpenAIClientOptions { Endpoint = new Uri("http://your-server:5189/v1") });

var chat = client.GetChatClient("qwen3.5:9b");

The server path is its own guide: coming from OpenAI to LM-Kit One.

What survives the move unchanged.

The abstractions did their job: everything written against them keeps compiling and keeps running.

Contracts

The interfaces hold

IChatClient, IEmbeddingGenerator, and Semantic Kernel's connector contracts are served by official LM-Kit implementations.

Behavior

Streaming and tools

Streaming responses, function calling, and structured output ride the same abstractions your code already exercises.

Plugins

Kernel assets carry over

Semantic Kernel plugins, prompt templates, and planner logic run against the local connector without edits.

Then the runtime starts giving back.

Leaving the metered endpoint is the start. The point is what the embedded runtime adds around the model.

Private

Nothing leaves the process

Prompts, documents, and outputs stay in your application's memory space. Air-gapped deployments work once models are present.

Cost

No meter on iteration

Batch document runs, agent loops, and regression suites stop accruing per-token charges; capacity is your hardware.

Beyond chat

The rest of the runtime

Document intelligence, extraction with confidence, RAG with citations, governed agents, and speech ship in the same package as the client you just swapped in.

What actually changes.

Two differences worth planning for, before anyone discovers them in production.

Models

Open weights, your hardware

GPT-class hosted models stay in Azure. Locally you choose from a curated open-weight catalog sized to your machines; evaluate quality per task on your real workload.

Capacity

Sizing replaces quotas

Throughput comes from CPU, GPU, and model choice rather than provisioned throughput units. Test with production-shaped load before the cutover.

LM-Kit.NET

Swap the client this afternoon.

Download LM-Kit.NET See the Extensions.AI bridge