This blog post was created with the help of AI tools. Yes, I used a bit of magic from language models to organize my thoughts and automate the boring parts, but the geeky fun and the in C# are 100% mine.

Hi!

If you are building local AI apps in C#, you quickly hit a practical gap:

• Foundry Local SDK is great for local/on-device inference.
• Microsoft.Extensions.AI and Microsoft Agent Framework expect an IChatClient.
• There is no first-party Foundry Local -> IChatClient bridge yet.

That is exactly why I created this library

• Nuget: https://www.nuget.org/packages/ElBruno.MAF.FoundryLocal.Adapter
• Repo: https://github.com/elbruno/ElBruno.MAF.FoundryLocal/
• Sample: ElBruno.MAF.FoundryLocal/src/ElBruno.MAF.FoundryLocal.Console at main · elbruno/ElBruno.MAF.FoundryLocal

Why I created this

I wanted a clean, non-REST, in-process integration where:

1. Foundry Local stays local and private.
2. My app code uses standard MEAI abstractions (IChatClient).
3. The same IChatClient can be reused by Microsoft Agent Framework.

So the library provides a thin adapter:

Foundry Local SDK -> FoundryLocalChatClientAdapter -> IChatClient

This lets you write provider-agnostic app code while still running local inference.

Minimal usage

Install:

dotnet add package ElBruno.MAF.FoundryLocal.Adapter
dotnet add package Microsoft.Extensions.Hosting
dotnet add package Microsoft.Agents.AI

Use the wrapper as IChatClient:

using ElBruno.MAF.FoundryLocal;
using Microsoft.Extensions.AI;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var builder = Host.CreateApplicationBuilder(args);

builder.Services.Configure<FoundryLocalOptions>(o =>
{
    o.ModelAlias = "qwen2.5-0.5b";
    o.DownloadIfMissing = true;
    o.UnloadOnExit = true;
});

builder.Services.Configure<ChatRuntimeOptions>(_ => { });
builder.Services.AddSingleton<FoundryLocalModelLifecycleService>();
builder.Services.AddSingleton<IChatClient, FoundryLocalChatClientAdapter>();

using var host = builder.Build();
var chatClient = host.Services.GetRequiredService<IChatClient>();

var response = await chatClient.GetResponseAsync(
[
    new(ChatRole.User, "Explain local-first AI in one paragraph.")
]);

Console.WriteLine(response.Text);

Reuse the same wrapper with Microsoft Agent Framework:

using Microsoft.Agents.AI;

var agent = new ChatClientAgent(
    chatClient: chatClient,
    instructions: "You are a concise local assistant.",
    name: "LocalFoundryAgent",
    description: "Foundry Local + IChatClient adapter",
    tools: null,
    loggerFactory: null,
    services: null);

var agentResponse = await agent.RunAsync(
    "Give me 3 bullet points about local AI in .NET.",
    session: null,
    options: null);

Console.WriteLine(agentResponse);

What this gives you

• Local inference through Foundry Local SDK
• No local REST server required
• Standard MEAI IChatClient programming model
• Easy path to Agent Framework agents

In short: local model runtime + standard .NET AI abstractions + minimal glue code.

This blog post was created with the help of AI tools. Yes, I used a bit of magic from language models to organize my thoughts and automate the boring parts, but the geeky fun and the in C# are 100% mine.

Hi!

For a long time, many of us used GitHub Copilot as if it were unlimited magic: autocomplete, chat, agent mode, code review, increasingly powerful models, massive context, and long-running sessions that sometimes felt like a pair-programming marathon.

And it worked. Well, mostly.

Now, with usage-based billing and AI Credits, many developers are seeing something that used to be mostly invisible: every AI interaction has a cost. And that cost is not only about “asking a question.” It depends on the model, the context, input tokens, output tokens, cached tokens, tools, files, logs, MCP servers, and how long we let an agent keep working.

GitHub explains this in the Copilot billing documentation: interactions consume input, output, and cached tokens; each model has its own pricing; and the total is converted into AI Credits. The same documentation also explains an important detail: code completions and Next Edit Suggestions are not charged as AI Credits in paid plans.

Source: https://docs.github.com/en/copilot/reference/copilot-billing/models-and-pricing

The natural reaction is to panic.

The useful reaction is to optimize.

Just like we optimize compute, storage, bandwidth, or GitHub Actions minutes, now we also need to optimize how we use tokens.

And yes, this applies to those of us using Copilot every day for .NET, AI, Azure, scripts, demos, documentation, refactors, and those beautiful moments when we tell the agent “just fix this test” and come back 20 minutes later to find a doctoral thesis in progress.

The real problem is not the prompt. It is the context

When we talk about tokens, we often think only about the text we type.

But in AI-assisted development tools, the expensive part is often everything that travels around the prompt:

• chat history
• open files
• files attached as context
• workspace search results
• diffs
• terminal output
• build errors
• long logs
• tool calls
• MCP server responses
• custom instructions
• agent memory
• content the model decides to inspect while completing the task

A one-line question can be cheap.

A one-line question inside a conversation with 80 messages, 12 files, 3 logs, 5 tools, and an MCP server connected to half the universe… not so much.

The first optimization is mental: more context does not always mean a better answer.

Sometimes more context only means more tokens, more noise, and more chances for the model to get distracted.

1. Use autocomplete and Next Edit Suggestions before opening chat

Not everything needs a conversation.

For small tasks, Copilot directly in the editor is often the most efficient option:

• completing a line
• finishing a simple function
• generating boilerplate
• suggesting the next obvious change
• completing a repeated pattern
• adjusting names
• writing a simple condition
• generating a property, DTO, or mapping

If you can solve it with Tab, do not open a chat.

This is not just convenience. It is strategy. According to GitHub documentation, code completions and Next Edit Suggestions are not billed as AI Credits in paid plans.

Source: https://docs.github.com/en/copilot/reference/copilot-billing/models-and-pricing

Simple rule:

• Use autocomplete for micro-tasks.
• Use inline edit for local changes.
• Use chat for questions that require reasoning.
• Use agent mode for well-scoped multi-file tasks.
• Use cloud agents when you really want to delegate a workflow, not when you only need to change three lines.

The most expensive model in the world should not be helping you write public string Name { get; set; }.

That is what Tab is for. And coffee.

2. Choose the right model for the task

Not every model has the same cost or the same purpose.

The VS Code documentation recommends using lighter models for quick edits, boilerplate, and direct questions, and reserving reasoning models for complex refactors, architecture decisions, and multi-step debugging.

Source: https://code.visualstudio.com/docs/copilot/guides/optimize-usage

A practical pattern:

GitHub also documents Auto Model Selection, which can choose a model based on task complexity, availability, and policies. The documentation also notes that Auto can improve efficiency by reserving more expensive models for tasks that actually need them.

Source: https://docs.github.com/en/copilot/concepts/auto-model-selection

My recommendation for most developers:

• use Auto as the default
• manually switch to a more powerful model only when you have a clear reason
• switch back to Auto or a cheaper model when the complex task is done

Do not drive a truck to buy bread.

And do not use the most expensive model to ask how to center a div. Although, to be fair, sometimes centering a div does deserve an architecture review.

3. Start new chats when you change tasks

This is one of the simplest and most ignored optimizations.

The VS Code documentation is clear: when a conversation grows, it accumulates context from previous messages, tool outputs, and file contents. If you switch to an unrelated task inside the same session, the model still processes irrelevant history.

Source: https://code.visualstudio.com/docs/copilot/guides/optimize-usage

Bad pattern:

Chat 1:
- Debug tests
- Then architecture
- Then generate README
- Then review Dockerfile
- Then explain an Azure error
- Then ask for a tweet

Better pattern:

Chat 1: Debug tests
Chat 2: Architecture design
Chat 3: README
Chat 4: Dockerfile
Chat 5: Azure deployment issue

New task, new chat.

Yes, it sounds simple.

Yes, it works.

And yes, it also helps your human brain, which sometimes has a smaller context window than the model.

4. Use /compact and /fork when it makes sense

When a conversation has useful context but starts getting too large, you do not always need to throw it away.

You can compact it or fork it.

VS Code documents new sessions, forking, and compaction as ways to manage context and reduce unnecessary tokens.

Source: https://code.visualstudio.com/docs/copilot/guides/optimize-usage

Good practices:

• use /compact when the conversation has useful information but too much history
• use /fork when you want to explore an alternative without polluting the main conversation
• start a new chat if the new task is unrelated
• summarize the current state before continuing a long task

Useful prompt:

Summarize the current state, decisions made, files changed, and next steps. Keep it short and actionable.

Then copy that summary into a new conversation and continue with clean context.

Less noise. Fewer tokens. Better focus.

5. Do not ask it to analyze the whole repo if you only need three files

This is the classic one.

Expensive prompt:

Analyze this entire repository and tell me what is wrong.

Better prompt:

Analyze only these files:
- src/MyApp.Api/Program.cs
- src/MyApp.Core/Services/OrderService.cs
- tests/MyApp.Tests/OrderServiceTests.cs
Goal: find why this test is failing.
Do not edit files yet. First explain the likely cause.

The difference is huge.

The first prompt invites the model to explore, read, search, open files, infer architecture, and consume context.

The second prompt defines:

• files
• goal
• limits
• working mode
• expected output

In AI coding, scope is part of the prompt.

Small scope, better result.

Infinite scope, surprise in the bill.

6. Separate planning, implementation, and validation

One of the most common mistakes with agent mode is asking for everything at once:

Analyze the issue, design the fix, implement it, run tests, fix errors, update docs, and create a summary.

That sounds productive.

But it can also trigger loops, tool calls, unnecessary changes, and high token consumption.

A better approach is to use phases.

Phase 1: plan

Create a short implementation plan. Do not modify files yet.
Focus only on the failing test and the minimal code path required to fix it.

Phase 2: scoped implementation

Implement step 1 only. Modify only the files listed in the plan.

Phase 3: validation

Run the relevant tests only. If they fail, explain the failure before changing code again.

Phase 4: cleanup

Now clean up the implementation without changing behavior. Keep the diff small.

The VS Code documentation also recommends planning before implementation to reduce rework and back-and-forth.

Source: https://code.visualstudio.com/docs/copilot/guides/optimize-usage

Sometimes the best prompt is not “do everything.”

It is “think first, touch little, validate quickly.”

7. Be careful with logs: do not paste a novel if you only need the error

Logs are one of the silent token killers.

Typical example:

Here is my build log

[paste 2,000 lines]

And the real error was in the last 20 lines.

Better:

Here are the last 40 lines of the failing build log. Focus on the first real error, not the cascading errors.

Or even:

This is the error:
CS0246: The type or namespace name 'X' could not be found.
Relevant files:
- Program.cs
- MyService.cs
What is the likely fix?

Good practices:

• paste only the first relevant error
• avoid full logs if errors are repeated
• remove timestamps if they do not add value
• remove duplicated stack traces
• summarize what you already tried
• include exact commands, not the whole terminal history

Copilot can help a lot with logs.

But it does not need to read your CI/CD diary.

8. Review your custom instructions

Custom instructions are fantastic.

They can also become a token backpack if nobody maintains them.

A good .github/copilot-instructions.md file is:

• short
• specific
• current
• based on real repository rules
• clear about build/test commands
• clear about important conventions

A bad one is:

• too long
• duplicated
• contradictory
• based on old architecture
• full of rules nobody follows
• full of generic instructions that apply to every repo on the planet

Example of useful instructions:

# Copilot instructions
- Use C# 13 and .NET 10 conventions.
- Keep changes minimal and focused.
- Do not introduce new dependencies without explaining why.
- Run `dotnet build -c Release` after code changes.
- Run relevant tests only unless asked for the full suite.
- Prefer Aspire service defaults when adding services.
- Do not modify generated files.

You do not need to write a national constitution for Copilot to understand your repo.

You need short rules that reduce repeated decisions.

9. Review the MCP servers and tools you have enabled

This is one of the areas where many developers may be consuming context without realizing it.

MCP is powerful because it lets agents connect to tools, resources, prompts, and external systems. But every server and every available tool can also affect context, tool selection, and the way the agent works.

The VS Code documentation explains that MCP servers can expose tools, resources, prompts, and apps. It also allows developers to enable, disable, install, configure, and manage MCP servers from VS Code.

Source: https://code.visualstudio.com/docs/copilot/customization/mcp-servers

Practical recommendations:

• do not keep every MCP server enabled all the time
• enable only what you need for the current workspace
• disable experimental MCP servers when you are not using them
• review duplicated or overly generic tools
• review tool descriptions: if they are too long or confusing, they may hurt tool selection
• avoid MCP servers that return huge responses by default
• limit resources that add too much context
• check whether a server is bringing more information than needed
• review MCP logs when something behaves strangely

Example:

If you are working on a local .NET API, maybe you do not need all of these enabled at the same time:

• browser automation
• extended filesystem
• cloud docs search
• GitHub
• Jira
• Slack
• database explorer
• Kubernetes
• Playwright
• internal wiki

Every extra tool can be useful.

But it can also expand the agent’s decision space.

And when an agent has too many tools, sometimes the problem is not lack of capability. It is too many temptations.

My personal rule:

MCP servers should be workspace-specific, not personality traits.

Enable what you need. Turn off what you do not.

10. Use traditional tools for traditional work

Not everything needs AI.

For many tasks, traditional tools are better, faster, and cheaper:

• formatter for formatting
• linter for style
• compiler for type errors
• tests for validation
• static analyzers for known rules
• dependency scanners for known vulnerabilities
• scripts for repeatable tasks

Copilot is excellent for reasoning, explaining, proposing, connecting ideas, and accelerating implementation.

But if you use a frontier model to discover a missing using, something went sideways.

Good pattern:

Run the build. Give Copilot only the first relevant compiler error. Ask for the minimal fix.

Bad pattern:

Ask Copilot to inspect the entire repository and find why the build might fail.

First, let deterministic tools do their job.

Then use AI where it adds value.

11. Local models: they do not replace Copilot, but they can complement it very well

We are going to see more PCs with interesting local AI capabilities: stronger GPUs, NPUs, compact workstations, and machines designed to run models locally. NVIDIA, for example, positions RTX Spark as compact PCs and laptops with NVIDIA AI and RTX graphics capabilities.

Source: https://www.nvidia.com/en-us/products/rtx-spark/

This raises an interesting question:

Does everything need to go to the cloud?

Not necessarily.

There are tasks where a local model may be enough:

• summarizing logs
• generating documentation drafts
• explaining small code snippets
• creating scaffolding
• generating initial tests
• transforming text
• preparing prompts
• analyzing snippets
• creating session summaries
• reviewing basic style

And there are tasks where cloud/frontier models still make a lot of sense:

• complex multi-file debugging
• deep reasoning
• large migrations
• high-risk refactors
• architecture
• long agentic workflows
• direct integration with GitHub, PRs, issues, and CI

The idea is not “local vs cloud.”

The idea is local for simple work, cloud for work that really needs cloud.

This post is not about advanced BYOK, routing, or gateway architectures. That deserves its own post.

But as a baseline idea: if you can solve repetitive tasks with local models, you can reserve Copilot and powerful models for the tasks where they really shine.

12. Code review: use it where it adds the most value

Copilot code review can be very useful, but it also has a cost.

GitHub documentation explains that Copilot code review is billed in two ways: token consumption through AI Credits and GitHub Actions minutes for the agentic review infrastructure.

Source: https://docs.github.com/en/copilot/reference/copilot-billing/models-and-pricing

Recommendations:

• do not enable high-effort automatic review for every PR without measuring it
• use linters and analyzers for mechanical rules
• reserve Copilot review for meaningful PRs
• define when to use standard vs higher effort
• avoid full AI review if you only changed documentation
• review usage by repository/team if you are in an organization

Copilot review can be excellent.

But you do not need an AI reviewer philosophically inspecting a three-line README change.

13. Define usage profiles for your team

In enterprise teams, the worst-case scenario is letting everyone use any model, in any mode, for any task, with no guidance.

You do not need to block everything.

You need to educate people and provide clear profiles.

Daily coding profile

• Auto Model Selection
• autocomplete and Next Edit Suggestions first
• short chat sessions
• limited context
• lightweight models for simple questions

Debugging profile

• minimal logs
• first relevant error
• specific files
• plan before changes
• relevant tests, not always the full suite

Refactor profile

• plan first
• scope by folder or feature
• changes in phases
• more powerful model only during the hard part
• frequent validation

Documentation profile

• lightweight or local model
• specific files
• limited output
• no agent mode unless needed

Agent mode profile

• clear issue
• clear stop condition
• defined scope
• defined validation commands
• do not let it run unsupervised if the goal is ambiguous

This is not about saying “do not use Copilot.”

It is about saying “use the right mode for the right job.”

14. Quick checklist for developers

Before sending the next prompt, ask yourself:

• Can I solve this with autocomplete?
• Do I need chat, or is inline edit enough?
• Do I need agent mode, or just an explanation?
• Am I using Auto, or am I using a model that is too expensive for the task?
• Does this conversation already have too much history?
• Should I start a new chat?
• Can I pass only two or three files?
• Can I paste only the relevant error?
• Can I ask for a plan first?
• Do I have MCP servers enabled that I do not need?
• Are my custom instructions too long?
• Can a linter/test/build answer this before AI?
• Could this task go to a local model?

If the answer is “yes” to several of these, you can probably save tokens without losing productivity.

15. Checklist for teams

For organizations, I would start here:

• review usage by user, team, and repository
• understand which models are used the most
• review how much usage comes from agent mode
• review Copilot code review usage
• define internal model selection guidelines
• promote Auto as the default
• teach small, scoped prompts
• clean up custom instructions by repository
• review recommended and allowed MCP servers
• create usage profiles by task type
• measure before and after changes
• do not block AI out of fear
• govern it like any other cloud resource

Because this looks a lot like cloud cost optimization.

First, everyone celebrated how easy it was to create resources.

Then the bill arrived.

Then we learned FinOps.

Now we need something similar for AI-assisted development.

Conclusion

The new GitHub Copilot usage model does not mean we need to stop using AI to code.

It means we can no longer treat every interaction as free, infinite, and invisible.

The good news is that many optimizations are simple:

• use autocomplete before chat
• choose the model intentionally
• start new chats
• reduce context
• limit logs
• separate planning and implementation
• review MCP servers
• clean up custom instructions
• use traditional tools when they fit
• reserve powerful models for powerful problems
• consider local models for simple tasks

The goal is not to use less Copilot.

The goal is to use fewer tokens and get better results.

This blog post was created with the help of AI tools. Yes, I used a bit of magic from language models to organize my thoughts and automate the boring parts, but the geeky fun and the in C# are 100% mine.

Hi!

dotnet tool install --global ElBruno.Text2Image.Cli

dotnet tool update --global ElBruno.Text2Image.Cli

t2i --provider foundry-mai25 "a photograph of a red fox in an autumn forest"

t2i --provider foundry-mai25-flash "a quick concept sketch of a city skyline"

prompt -> terminal -> image

using ElBruno.Text2Image;
using ElBruno.Text2Image.Foundry;

using var generator = new MaiImage25Generator(
    endpoint: "https://your-resource.services.ai.azure.com",
    apiKey: "your-api-key",
    httpClient: new HttpClient(),
    modelName: "MAI-Image-2.5",
    modelId: "MAI-Image-2.5");

var result = await generator.GenerateAsync(
    "A photograph of a red fox in an autumn forest");

await result.SaveAsync("mai-image25-output.png");

And for the Flash version, use the same generator with the Flash model id:

using ElBruno.Text2Image;
using ElBruno.Text2Image.Foundry;

using var generator = new MaiImage25Generator(
    endpoint: "https://your-resource.services.ai.azure.com",
    apiKey: "your-api-key",
    httpClient: new HttpClient(),
    modelName: "MAI-Image-2.5-Flash",
    modelId: "MAI-Image-2.5-Flash");

var result = await generator.GenerateAsync(
    "A clean comic-style illustration of a happy developer building AI apps");

await result.SaveAsync("mai-image25-flash-output.png");

This blog post was created with the help of AI tools. Yes, I used a bit of magic from language models to organize my thoughts and automate the boring parts, but the geeky fun and the in C# are 100% mine.

One of the most interesting announcements in the recent VS Code 1.122 release is that Bring Your Own Key (BYOK) models can now be used without signing in to GitHub. VS Code now supports BYOK scenarios, including chat, tools, and MCP integrations, without requiring GitHub authentication, making enterprise, offline, and air-gapped workflows much easier to support.

I originally came across this update thanks to a tweet from Pierce Boggan:

This immediately caught my attention because it connects directly with the experiments I’ve been running around GitHub Copilot CLI, local models, BYOK, SQUAD, and AI-assisted software engineering.

Quick recap:

CPU-only local models
Slow, useful mostly for questions and tiny tasks.
https://elbruno.com/2026/05/03/running-github-copilot-cli-offline-with-local-models-a-cpu-only-reality-check/

GPU local models
Faster, with more room for local agent experiments.
https://elbruno.com/2026/05/06/running-github-copilot-cli-offline-with-local-models-gpu-edition/

GPT-5-mini BYOK
Capable, but stabilization, quality gates, and validation became the real work.
https://elbruno.com/2026/05/11/github-copilot-cli-gpt-5-mini-byok-the-code-was-cheap-the-quality-gates-were-expensive/

GPT-5.5 BYOK
The most disciplined run so far, with better phase control, quality gates, and manual UX validation.
https://elbruno.com/2026/05/14/github-copilot-cli-squad-gpt-5-5-byok-better-engineering-same-hard-truth/

The new VS Code 1.122 BYOK flow feels like a natural next step for this series.

I haven’t rerun the ElBruno.NetAgent experiment with this new capability yet, but it is definitely on my list.

The lesson remains the same:

The code keeps getting cheaper. Validation and engineering discipline are still expensive.

This blog post was created with the help of AI tools. Yes, I used a bit of magic from language models to organize my thoughts and automate the boring parts, but the geeky fun and the in C# are 100% mine.

Hi!

What happens when a Python-based AI agent and a .NET-based AI agent need to work together?

That is the idea behind MAF-A2A-NVIDIA-NemoAgents (https://github.com/elbruno/MAF-A2A-NVIDIA-NemoAgents-private): a reference app that shows how to combine NVIDIA NeMo Agent Toolkit, Microsoft Agent Framework, Agent-to-Agent communication, and Aspire into one multi-agent workflow. The repo describes itself as a production-ready sample that demonstrates NVIDIA NeMo Agent Toolkit + Microsoft Agent Framework with A2A communication, orchestrated with Aspire.

And yes, this is exactly the kind of demo I like: different stacks, different responsibilities, one shared protocol. No “everything must be rewritten in my favorite framework” drama. Just agents talking to agents. Beautiful.

The scenario: analysis first, action second

The application models a practical enterprise workflow:

A NeMo Data Analysis Agent receives business or operational data, analyzes metrics, detects trends or anomalies, and generates insights. Then, when an action is needed, a MAF Action Agent can trigger alerts, generate reports, or execute remediation steps. The web UI acts as the human-facing chat surface where users can request analysis and trigger actions.

So the flow is simple:

User  
↓ Web Chat UI  
↓ NeMo Data Analysis Agent  
↓ Analysis result  
↓ MAF Action Agent  
↓ Alert / Report / Action

The interesting part is that these agents are not built with the same framework. The NeMo agent is Python-based. The MAF agent is .NET-based. The bridge between them is A2A, using JSON-RPC and agent discovery. The repo architecture describes A2A as the communication layer between the web UI, the NeMo agent, and the MAF agent, with Aspire providing health checks, service discovery, tracing, and startup orchestration.

Why two agents?

Because “one mega-agent to rule them all” sounds cool until you need to debug, scale, secure, or explain it.

This repo separates responsibilities:

• NeMo Agent: data analysis, trends, anomalies, metrics, recommendations.
• MAF Agent: actions, alerts, reports, remediation workflows.
• Web UI: chat experience, discovery, orchestration, response rendering.
• Aspire: local distributed app orchestration, health, logs, and OpenTelemetry traces.

The repo calls out this separation of concerns directly: data analysis expertise is not the same as action execution expertise. It also helps with scalability, reliability, and vendor flexibility.

Where A2A fits

A2A is the key enabler here. It gives agents a common way to expose capabilities and communicate across frameworks and languages.

On the Microsoft Agent Framework side, A2A support allows agents to be exposed over A2A endpoints and discovered through agent cards. Microsoft’s A2A docs show that Agent Framework can expose multiple agents with separate A2A endpoints, and the agent-framework-a2a package can both connect to external A2A-compliant agents and expose Agent Framework agents over A2A.

The .NET A2A pattern looks like this in the official MAF examples:

builder.AddA2AServer("weather-agent");
app.MapA2AHttpJson("weather-agent", "/a2a/weather-agent");
app.MapWellKnownAgentCard(new AgentCard
{
    Name = "WeatherAgent",
    Description = "A helpful weather assistant.",
    SupportedInterfaces =
    [
        new AgentInterface
        {
            Url = "https://your-host/a2a/weather-agent",
            ProtocolBinding = ProtocolBindingNames.HttpJson,
            ProtocolVersion = "1.0",
        }
    ]
});

That pattern matters because agent discovery is not a nice-to-have. In a multi-agent system, the orchestrator needs to know:

Who are you?
What can you do?
Where do I call you?
Which protocol do you speak?

That is where the Agent Card becomes useful.

NeMo as an A2A agent

On the NVIDIA side, NeMo Agent Toolkit can publish workflows as A2A agents. NVIDIA’s docs describe nat a2a serve as the command that starts an A2A server, publishes a workflow as an A2A agent, and exposes an Agent Card at /.well-known/agent-card.json.

In this repo, Aspire starts the NeMo workflow using the NeMo Agent Toolkit A2A server approach. The AppHost launches the NeMo agent as an executable, configures the workflow file, host, port, public base URL, NVIDIA API key, Azure OpenAI settings, and OpenTelemetry exporter.

A simplified version of that idea looks like this:

var nvidiaApiKey = builder.AddParameter("nvidia-api-key", secret: true);
var azureOpenAiEndpoint = builder.AddParameter("azure-openai-endpoint", secret: true);
var azureOpenAiApiKey = builder.AddParameter("azure-openai-api-key", secret: true);
var nemo = builder.AddExecutable(
        name: "nemo-agent",
        command: "powershell",
        workingDirectory: ".",
        args:
        [
            "-NoProfile",
            "-Command",
            "nat a2a serve --config_file .\\src\\NemoDataAnalysisAgent\\nemo\\workflow.yml"
        ])
    .WithHttpEndpoint(name: "http", env: "NEMO_PORT")
    .WithEnvironment("NEMO_HOST", "127.0.0.1")
    .WithEnvironment("NVIDIA_API_KEY", nvidiaApiKey)
    .WithEnvironment("AZURE_OPENAI_ENDPOINT", azureOpenAiEndpoint)
    .WithEnvironment("AZURE_OPENAI_API_KEY", azureOpenAiApiKey)
    .WithOtlpExporter();

The important idea: NeMo owns the analysis workflow, but it is exposed as an A2A-compatible service.

MAF as the action agent

The MAF side is a .NET service focused on action execution. The repo exposes endpoints for executing actions, triggering alerts, generating reports, and handling A2A JSON-RPC requests. The README describes the MAF Action Agent as responsible for pluggable action handlers, multi-level alerts, async report generation, health checks, A2A integration, and OpenTelemetry tracing.

A simplified version of the MAF action endpoint looks like this:

app.MapPost("/api/actions/execute",
    async (ActionRequest request, IActionExecutor executor) =>
    {
        var result = await executor.ExecuteActionAsync(request);
        return Results.Ok(result);
    });

And the A2A-facing endpoints follow this shape:

app.MapGet("/.well-known/agent-card.json", () =>
{
    return Results.Ok(new
    {
        name = "MAF Action Agent",
        description = "Executes actions based on NeMo analysis",
        version = "1.0.0",
        capabilities = new[]
        {
            "execute-actions",
            "trigger-alerts",
            "generate-reports"
        },
        endpoint = "/a2a/maf-action-agent",
        a2a_version = "1.0"
    });
});
app.MapPost("/a2a/maf-action-agent",
    async (HttpContext context, IA2ABridge bridge) =>
    {
        using var reader = new StreamReader(context.Request.Body);
        var body = await reader.ReadToEndAsync();
        var response = await bridge.ProcessA2ARequestAsync(body);
        return Results.Text(response, "application/json");
    });

That is the handoff: the agent advertises what it can do, then receives structured requests through the A2A endpoint.

The web UI as the orchestrator

The web chat interface is where the human interacts with the system. It discovers both agents, sends analysis requests to NeMo, and optionally sends action requests to MAF. The README calls out a NeMo-first routing pattern: chat responses come from NeMo analysis before optional MAF action execution.

A simplified orchestration pattern looks like this:

public async Task<ChatResponse> ProcessChatAsync(ChatRequest request)
{
    var message = request.Message.ToLowerInvariant();
    if (ShouldTriggerAction(message))
    {
        var action = new ActionRequest
        {
            ActionType = InferActionType(message),
            Parameters = new Dictionary<string, object?>
            {
                ["message"] = request.Message
            }
        };
        var actionResult = await orchestrator.ExecuteActionAsync(action);
        return new ChatResponse
        {
            RespondedBy = "MAF Action Agent",
            Content = actionResult.Details
        };
    }
    var nemoReply = await orchestrator.SendNemoMessageAsync(
        request.Message,
        request.SessionId);
    return new ChatResponse
    {
        RespondedBy = "NeMo Data Analysis Agent",
        Content = nemoReply
    };
}

That is a nice pattern for demos and real apps: default to insight, escalate to action only when the user explicitly asks for it.

A2A request shape

The architecture docs describe JSON-RPC 2.0 over HTTP as the protocol used between agents. The documented example sends a method such as analyze, passes parameters like metric, timeframe, and aggregation, and receives a structured result with trend, anomalies, forecast, and insights.

A simplified A2A-style request could look like this:

{
  "jsonrpc": "2.0",
  "method": "message/send",
  "params": {
    "message": {
      "kind": "message",
      "role": "user",
      "parts": [
        {
          "kind": "text",
          "text": "Analyze quarterly revenue trends"
        }
      ]
    }
  },
  "id": "request-001"
}

And the system can route that to the NeMo agent first. Later, a second request can trigger the MAF agent:

{
  "actionType": "trigger-alert",
  "parameters": {
    "message": "Trigger alert for high CPU usage",
    "analysisSummary": "CPU usage increased 35% over baseline."
  }
}

That second part is where things become useful. The action agent is not acting in isolation; it can act based on the previous analysis.

Why Aspire matters here

Aspire is doing a lot of the boring-but-important work.

The repo uses Aspire to coordinate startup order, service discovery, health checks, logging, and OpenTelemetry correlation across the NeMo agent, the MAF agent, and the web UI. The README describes Aspire as responsible for automatic agent endpoint registration, dependency management, continuous health checks, distributed tracing, unified logs, and NeMo pre-warm.

This is one of the hidden wins of the repo. Multi-agent demos often fail because they are hard to run. Here, Aspire gives the app a “one command, multiple services” developer experience:

aspire start

The README says that after starting the app, the web UI is available on port 5000, and the sample prompts include NeMo-only analysis, MAF-only alert triggering, and a combined NeMo + MAF workflow.

Why this repo is interesting

This repo is not just “another chat app.”

It demonstrates a few patterns that matter for real enterprise AI systems:

1. Cross-framework agents
   Python and .NET agents can collaborate without forcing everything into one stack.
2. Clear agent responsibility boundaries
   One agent analyzes. One agent acts. That makes the architecture easier to explain, test, and evolve.
3. A2A as the interoperability layer
   A2A gives each agent a common communication contract.
4. Aspire as the local cloud-native dev loop
   Developers can run, observe, and debug the system locally before thinking about containers or cloud deployment.
5. Observability from the beginning
   The architecture includes OpenTelemetry tracing, structured logging, and health checks instead of treating them as “we’ll add this later” work. The repo’s architecture highlights call out distributed tracing, resilience patterns, scalability, and a future roadmap for TLS, mutual authentication, and authorization.

Final thoughts

The big takeaway for me: A2A makes heterogeneous agent systems feel much more realistic.

In real organizations, not every team will use the same language, same framework, same model provider, or same runtime. Some teams will build in Python. Some will build in .NET. Some will use NVIDIA tooling. Some will use Microsoft Agent Framework. Some will deploy locally first, then move to Azure.

And that is fine.

The goal is not to force every agent into one framework. The goal is to give them a shared way to discover each other, communicate, and collaborate.

That is what this repo demonstrates: NVIDIA NeMo for analysis, MAF for action, A2A for interoperability, and Aspire for orchestration.

Agents talking to agents.

Finally, in a way we can actually run, observe, and explain.

This blog post was created with the help of AI tools. Yes, I used a bit of magic from language models to organize my thoughts and automate the boring parts, but the geeky fun and the in C# are 100% mine.

TL;DR

This was the final ElBruno.NetAgent experiment: GitHub Copilot CLI + SQUAD using Azure OpenAI GPT-5.5 BYOK against the same app-building challenge I previously tried with CPU-only local models, GPU local models, and GPT-5-mini.

The good news: GPT-5.5 was clearly better at staying inside phase boundaries, following safety rules, reducing broad stabilization loops, and working with strict quality gates. Once I switched to economy-mode prompts, the flow became much more disciplined: usually one implementation agent, one reviewer, short loops, and no wild repo-wide rewrites.

The not-so-funny news: better models do not remove the need for engineering discipline. Build green, tests green, and smoke tests green still missed a real manual UX bug: the Settings UI looked like it saved Auto Mode, but the persisted config did not actually keep the value. The fix was not “more tests”; it was the right test: one that exercised the real WPF user path, not only the ViewModel.

Also: GPT-5.5 BYOK is powerful, but not cheap. By the time the app reached final automated validation, the run was already around 15M+ tokens and roughly $30+ in Azure OpenAI usage. SQUAD is useful, but every agent has a context tax.

The biggest lesson: the code is still cheap. The validation strategy is the expensive part.

The Setup

Main repo:

• https://github.com/elbruno/ElBruno.NetAgent

Previous experiments:

1. CPU-only local model: https://elbruno.com/2026/05/03/running-github-copilot-cli-offline-with-local-models-a-cpu-only-reality-check/
2. GPU local model: https://elbruno.com/2026/05/06/running-github-copilot-cli-offline-with-local-models-gpu-edition/
3. GPT-5-mini BYOK: https://elbruno.com/2026/05/11/github-copilot-cli-gpt-5-mini-byok-the-code-was-cheap-the-quality-gates-were-expensive/

This time the goal was simple:

Run the same ElBruno.NetAgent app-building experiment using GitHub Copilot CLI + SQUAD + Azure OpenAI GPT-5.5 BYOK and compare stabilization loops against GPT-5-mini.

The stack:

• GitHub Copilot CLI
• SQUAD orchestration
• Azure OpenAI GPT-5.5 BYOK
• .NET + WPF
• Windows tray app
• Strict quality gates
• Manual UX validation

Step 0: Define “Working” Before Writing Code

One of the biggest lessons from the GPT-5-mini run was that “build green” was nowhere near enough.

So before writing any product code, the experiment started with a dedicated Step 0 phase:

• Normalize SQUAD routing to GPT-5.5
• Define team rules
• Define safety guardrails
• Define quality gates
• Define manual UX validation
• Prevent uncontrolled multi-agent fan-out

This turned out to be one of the smartest decisions in the whole experiment.

The model was better, but the stronger engineering structure mattered even more.

The Phase-Based Build

Instead of asking the model to “build the app,” the project was split into very strict phases:

This worked much better than broad “vibe coding.”

GPT-5.5 was noticeably better at respecting:

• phase boundaries
• “do not implement” instructions
• safety rules
• dry-run requirements
• deterministic testing constraints

Economy Mode Was the Real Unlock

Early SQUAD runs were expensive and noisy.

Multiple agents reading large repo context repeatedly created a huge token tax.

The biggest improvement came after switching to what I started calling “economy mode”:

• one implementation agent
• one reviewer
• no Scribe unless needed
• no doc rewrites
• no template rewrites
• read only files needed for the phase
• small targeted edits
• stop after the phase

This dramatically reduced chaos and stabilization loops.

Ironically, the better the model became, the more important project-management-style prompting became.

The Cost Checkpoint

By the time the app reached final automated validation:

• ~15.5M tokens consumed
• 400+ requests
• ~$30+ estimated Azure OpenAI cost

Most of the usage was input/context tokens, not output tokens.

That’s an important lesson:

SQUAD adds value, but every agent carries context overhead.

GPT-5.5 BYOK is powerful, but it is definitely not “free vibe coding.”

The Quality Gates Worked… Until They Didn’t

The automated gate looked solid:

dotnet clean .\ElBruno.NetAgent.sln
dotnet build .\ElBruno.NetAgent.sln -c Release
dotnet test .\ElBruno.NetAgent.sln -c Release --no-build --settings disable-parallel.runsettings
dotnet run --project src\ElBruno.NetAgent -- --smoke-test
dotnet run --project src\ElBruno.NetAgent -- --smoke-test-exit
dotnet run --project src\ElBruno.NetAgent -- --smoke-test-settings-save

And honestly, GPT-5.5 handled this surprisingly well.

The project reached:

• 39+ passing tests
• fast deterministic runs
• smoke-test validation
• WPF window construction validation
• tray exit validation
• forbidden-command safety scans

But then manual UX validation found a real bug.

The Manual UX Bug That Mattered

Manual testing showed:

• tray menu looked OK
• Help worked
• Exit worked
• Settings UI looked rough
• Save did not persist Auto Mode

At first this was confusing because:

• tests were green
• smoke tests were green
• SettingsViewModel tests passed

The problem was deeper: the tests validated the ViewModel, but not the real user path.

The real failure path was:

UI checkbox
→ Save and Close button
→ persisted config file
→ reload
→ UI state

The fix was not “more tests.”

The fix was:

• testing the actual WPF interaction path
• validating persisted config values
• validating reload behavior
• validating the same SaveAndCloseAsync() path used by the real button

That was probably the most important lesson of the entire experiment.

The right test is the one that fails for the same reason your user fails.

What GPT-5.5 Did Better Than GPT-5-mini

GPT-5.5 was clearly better at:

• phase discipline
• respecting safety boundaries
• avoiding repo-wide chaos
• using abstractions/fakes
• isolating WPF/tray behavior
• deterministic testing patterns
• targeted fixes
• reviewer coordination

The tray + exit phase was especially interesting.

GPT-5-mini had previously struggled around:

• NotifyIcon behavior
• WPF dispatcher behavior
• tray shutdown
• lingering processes

GPT-5.5 handled this much more cleanly once the prompts explicitly enforced:

• fake adapters
• no native tray tests
• no real dispatcher loops
• deterministic test behavior

But stronger models still did not remove the need for:

• manual UX testing
• safety reviews
• persistence validation
• engineering checkpoints

What I Would Do Differently Next Time

A few practical lessons:

• Start with economy mode immediately
• Use one implementer + one reviewer by default
• Treat UI-path tests as mandatory
• Validate persisted config files directly
• Manual UX validation should happen earlier
• Smoke tests should validate real user flows
• Track token usage per phase
• Keep phases narrow and explicit

Most importantly:

Define what “working” means before generating code.

Final Thoughts

This experiment ended in a much better place than the GPT-5-mini run.

The stabilization loops were smaller. The orchestration was cleaner. The engineering flow was more controlled.

But the biggest lesson did not change.

The hard part was never generating code.

The hard part was:

• defining quality
• validating behavior
• testing real user flows
• controlling orchestration
• knowing when “green” was lying

GPT-5.5 made the engineering loop better.

It did not eliminate the need for engineering discipline.

And that is probably the most important AI-assisted development lesson I’ve learned so far:

Today, the code is cheap.
The decisions, validation, and engineering discipline are still expensive.

This blog post was created with the help of AI tools. Yes, I used a bit of magic from language models to organize my thoughts and automate the boring parts, but the geeky fun and the in C# are 100% mine.

$env:COPILOT_PROVIDER_TYPE="azure"
$env:COPILOT_PROVIDER_BASE_URL="https://<resource>.openai.azure.com/openai/deployments/<deployment>"
$env:COPILOT_PROVIDER_API_KEY="<key>"
$env:COPILOT_PROVIDER_WIRE_API="responses"
$env:COPILOT_MODEL="gpt-5-mini"

$env:COPILOT_PROVIDER_MAX_PROMPT_TOKENS="32768"
$env:COPILOT_PROVIDER_MAX_OUTPUT_TOKENS="1536"

copilot --agent squad --max-autopilot-continues 6

gpt5miniGeneratedApp

The first screenshot shows GitHub Copilot CLI ready with the SQUAD agent and GPT-5-mini selected.

Then SQUAD started spawning background agents.

A build tells you the code compiles.
It does not tell you the app can start.

dotnet run --project src\ElBruno.NetAgent -- --smoke-test

A smoke-test that only resolves services is not enough for a desktop app.
It should catch XAML load errors too.

Exit clicked.
Application is shutting down...
TrayIconService stopping.

dotnet run --project src\ElBruno.NetAgent -- --smoke-test-exit

A quality gate is not valid unless tests finish quickly.

If your tests need a real tray icon, they are probably not unit tests anymore.

dotnet run --project src\ElBruno.NetAgent -- --smoke-test-settings-save

dotnet build
dotnet test

dotnet build -c Release
dotnet test -c Release --no-build

dotnet run --project src\ElBruno.NetAgent -- --smoke-test

dotnet clean
dotnet build -c Release
dotnet test -c Release --no-build --settings disable-parallel.runsettings

dotnet run --project src\ElBruno.NetAgent -- --smoke-test
dotnet run --project src\ElBruno.NetAgent -- --smoke-test-exit
dotnet run --project src\ElBruno.NetAgent -- --smoke-test-settings-save

Can GPT-5.5 write more code?

Can GPT-5.5 reduce the stabilization loops?

This blog post was created with the help of AI tools. Yes, I used a bit of magic from language models to organize my thoughts and automate the boring parts, but the geeky fun and the in C# are 100% mine.

Hi!

Some of these started as small pet projects.

IE: a quick helper for a demo, a tiny tool for a conference, a library to avoid repeating the same code again and again, or one of those “I’ll just build this in one evening” ideas that somehow becomes a real thing.

And now, thanks to GitHub Copilot, many of these experiments are becoming open source, free NuGet packages that I hope are useful to everyone.

Some are focused on AI. Some are focused on local models. Some help with embeddings, speech, QR codes, document processing, MCP tools, agents, and developer productivity.

In other words: a beautiful collection of useful chaos.

Quick package index

Versions are current as of the latest dashboard snapshot: 2026-05-10.
Dashboard repo: https://github.com/elbruno/nuget-repo-dashboard

AI evaluation: because demos are easy, validation is the hard part

The ElBruno.AI.Evaluation family is about bringing testing discipline to AI apps.

Packages:

• ElBruno.AI.Evaluation
• ElBruno.AI.Evaluation.Reporting
• ElBruno.AI.Evaluation.SyntheticData
• ElBruno.AI.Evaluation.Xunit

Repo:

https://github.com/elbruno/elbruno-ai-evaluation

These packages help with evaluation workflows, reporting, synthetic test data, and xUnit integration. The idea is simple: AI applications should not rely only on “it worked once in my demo.”

They need repeatable checks.

They need quality gates.

They need tests that can run again tomorrow, when the model, prompt, data, or weather in the cloud changes.

Because yes, AI apps are fun. But “trust me bro, the prompt is good” is not a testing strategy.

Agents and orchestration

The agents orchestration packages are focused on coordinating multiple AI agents through a lightweight workflow.

Packages:

• ElBruno.AgentsOrchestration.Abstractions
• ElBruno.AgentsOrchestration.Orchestration

Repo:

https://github.com/elbruno/elbruno.agentsorchestration

This is useful when you want agents to do more than just reply to a prompt. The orchestration repo describes a 6-step pipeline:

Plan → Parse → Execute → Verify → Review → Report

That is a nice mental model for agent-based workflows. It also fits very well with GitHub Copilot, SQUAD-style automation, and repo-based development experiments.

Because once you have more than one agent, you need orchestration.

Otherwise, congratulations, you invented a very expensive group chat.

AOT-friendly mapping for .NET

The ElBruno.AotMapper family is focused on compile-time DTO mapping.

Packages:

• ElBruno.AotMapper
• ElBruno.AotMapper.AspNetCore
• ElBruno.AotMapper.EntityFramework
• ElBruno.AotMapper.Generator

Repo:

https://github.com/elbruno/ElBruno.AotMapper

This project is especially interesting for modern .NET workloads because it avoids runtime reflection and generates mapping code at compile time.

That makes it useful for:

• NativeAOT apps
• trimmed applications
• cloud-native workloads
• serverless scenarios
• places where startup time and predictability matter

In short: less runtime magic, more generated code that you can actually inspect.

And sometimes that is exactly what you want.

Local embeddings

The ElBruno.LocalEmbeddings family is one of the most useful groups for AI developers building RAG, semantic search, local-first AI apps, or privacy-aware demos.

Packages include:

• ElBruno.LocalEmbeddings
• ElBruno.LocalEmbeddings.Harrier
• ElBruno.LocalEmbeddings.ImageEmbeddings
• ElBruno.LocalEmbeddings.ImageEmbeddings.Downloader
• ElBruno.LocalEmbeddings.KernelMemory
• ElBruno.LocalEmbeddings.Npu
• ElBruno.LocalEmbeddings.Npu.Intel
• ElBruno.LocalEmbeddings.Npu.Qualcomm
• ElBruno.LocalEmbeddings.VectorData

Repo:

https://github.com/elbruno/elbruno.localembeddings

This family gives you local embedding generation in .NET, including support for text embeddings, image embeddings, vector data integrations, Kernel Memory, and NPU-specific packages.

The NPU packages are especially cool because they connect directly with the AI PC story.

Not every embedding call needs to cross the internet.

Sometimes the best cloud call is the one you did not make.

Local LLMs

The ElBruno.LocalLLMs packages are focused on running and integrating local language models from .NET.

Packages:

• ElBruno.LocalLLMs
• ElBruno.LocalLLMs.BitNet
• ElBruno.LocalLLMs.Rag

Repo:

https://github.com/elbruno/ElBruno.LocalLLMs

These are useful for local chat, local model experimentation, and RAG-style workflows.

Cloud models are amazing. But sometimes you want the model running right there next to your code, your logs, your fan noise, and your questionable coffee.

MarkItDotNet: from files to AI-ready Markdown

The ElBruno.MarkItDotNet family is probably one of the biggest and most useful areas in this package collection.

Packages include:

• ElBruno.MarkItDotNet
• ElBruno.MarkItDotNet.AI
• ElBruno.MarkItDotNet.AzureSearch
• ElBruno.MarkItDotNet.Chunking
• ElBruno.MarkItDotNet.Citations
• ElBruno.MarkItDotNet.Cli
• ElBruno.MarkItDotNet.CoreModel
• ElBruno.MarkItDotNet.DocumentIntelligence
• ElBruno.MarkItDotNet.Excel
• ElBruno.MarkItDotNet.Metadata
• ElBruno.MarkItDotNet.PowerPoint
• ElBruno.MarkItDotNet.Quality
• ElBruno.MarkItDotNet.Sync
• ElBruno.MarkItDotNet.VectorData
• ElBruno.MarkItDotNet.Whisper

Repo:

https://github.com/elbruno/ElBruno.MarkItDotNet

This family is about converting, preparing, enriching, chunking, indexing, validating, and syncing content for AI workflows.

In a typical RAG project, everyone wants the fancy chat UI.

But before that, someone has to solve the real problem:

Can we clean and prepare the documents first?

That is where this package family fits.

It helps turn files into AI-ready Markdown and supports scenarios like document conversion, chunking, metadata extraction, citations, Azure AI Search, Whisper transcription, and quality checks.

Because every RAG project eventually becomes a document-cleanup project wearing an AI hat.

Text-to-image generation

The ElBruno.Text2Image packages provide a .NET-friendly way to work with image generation.

Packages:

• ElBruno.Text2Image
• ElBruno.Text2Image.Cli
• ElBruno.Text2Image.Cpu
• ElBruno.Text2Image.Cuda
• ElBruno.Text2Image.DirectML
• ElBruno.Text2Image.Foundry

Repo:

https://github.com/elbruno/ElBruno.Text2Image

The nice part here is the multi-backend design:

• CPU
• CUDA
• DirectML
• Microsoft Foundry
• CLI

That gives you flexibility depending on the machine, the demo, the budget, and how much your GPU is already crying.

One API, multiple ways to make pixels appear like magic.

Very expensive magic sometimes, but still magic.

Realtime audio, Whisper, and voice

This group is about speech, transcription, realtime audio, text-to-speech, and voice scenarios.

Packages:

• ElBruno.Whisper
• ElBruno.Realtime
• ElBruno.Realtime.SileroVad
• ElBruno.Realtime.Whisper
• ElBruno.QwenTTS
• ElBruno.QwenTTS.VoiceCloning
• ElBruno.VibeVoiceTTS
• ElBruno.PersonaPlex

Repos:

https://github.com/elbruno/ElBruno.Whisper
https://github.com/elbruno/ElBruno.Realtime
https://github.com/elbruno/ElBruno.QwenTTS
https://github.com/elbruno/ElBruno.VibeVoiceTTS
https://github.com/elbruno/ElBruno.PersonaPlex

This is useful for voice agents, transcription tools, accessibility scenarios, podcast workflows, and realtime conversational demos.

Because sooner or later every AI demo becomes:

Can I talk to it?

And then, ten minutes later:

Why is my microphone still open?

QR code generation

The ElBruno.QRCodeGenerator family is a lightweight utility set for generating QR codes in different formats.

Packages:

• ElBruno.QRCodeGenerator.Ascii
• ElBruno.QRCodeGenerator.CLI
• ElBruno.QRCodeGenerator.Image
• ElBruno.QRCodeGenerator.Payloads
• ElBruno.QRCodeGenerator.Pdf
• ElBruno.QRCodeGenerator.Svg
• ElBruno.QRCodeGenerator.Tool

Repos:

https://github.com/elbruno/ElBruno.QRCodeGenerator
https://github.com/elbruno/ElBruno.QRCodeGenerator.CLI

This one is very practical: terminal output, images, SVG, PDF, payloads, and a global tool.

Because every conference session eventually needs a QR code.

Usually five minutes before going live.

MCP and tool routing

The ElBruno.ModelContextProtocol.MCPToolRouter package focuses on smarter tool selection for Model Context Protocol scenarios.

Package:

• ElBruno.ModelContextProtocol.MCPToolRouter

Repo:

https://github.com/elbruno/ElBruno.ModelContextProtocol

This is useful when working with agents that have access to many tools.

Sending every possible tool to the model all the time is not always a good idea. It burns tokens, increases noise, and makes the model work harder than needed.

Tool routing helps select the most relevant tools for the task.

Agents are great.

Agents with 97 tools in context are a token bonfire.

Search, ranking, and retrieval

These packages help with retrieval, ranking, and search scenarios.

Packages:

• ElBruno.BM25
• ElBruno.Reranking
• graphify-dotnet

Repos:

https://github.com/ElBruno/ElBruno.BM25
https://github.com/elbruno/ElBruno.Reranking
https://github.com/elbruno/graphify-dotnet

This group fits nicely into RAG and knowledge discovery workflows.

You need search.

Then you need better search.

Then you need reranking.

Then you need graphs.

Then you realize your “simple chatbot” is now a distributed knowledge system.

Classic.

Developer desktop utilities

These are small tools that make developer life better.

Packages:

• ElBruno.AspireMonitor
• ElBruno.ClockTray
• ElBruno.OllamaMonitor

Repos:

https://github.com/elbruno/ElBruno.AspireMonitor
https://github.com/elbruno/ElBruno.ClockTray
https://github.com/elbruno/ElBruno.OllamaMonitor

These are the kind of tools that start with:

I just need a tiny helper.

And then become useful enough to publish.

AspireMonitor helps with Aspire monitoring.
ClockTray helps with Windows tray clock scenarios.
OllamaMonitor gives quick visibility into local Ollama runtime status.

Tiny tools. Big quality-of-life improvement.

The best kind of yak shaving.

Hugging Face helpers

The Hugging Face downloader packages help with downloading models and related assets from Hugging Face.

Packages:

• ElBruno.HuggingFace.Downloader
• ElBruno.HuggingFace.Downloader.Cli

Repo:

https://github.com/elbruno/ElBruno.HuggingFace.Downloader

This is useful across many of the local AI packages, because local AI usually starts with:

Great, now where do I get the model files?

And then:

Why is this model 4 GB?

OllamaSharp extensions

Package:

• ElBruno.OllamaSharp.Extensions

Repo:

https://github.com/elbruno/elbruno.OllamaSharp.Extensions

This package adds useful extensions around OllamaSharp, especially for scenarios where local LLM calls can take longer and timeout management becomes important.

If you have ever waited for a local model to respond and wondered whether it was thinking, frozen, or silently judging your prompt, this one makes sense.

MemPalace: memory for AI apps

The MemPalace family is focused on memory infrastructure for AI apps and agents.

Packages:

• MemPalace.Core
• MemPalace.Ai
• MemPalace.Agents
• MemPalace.Backends.Sqlite
• MemPalace.KnowledgeGraph
• MemPalace.Mcp
• MemPalace.Mining
• MemPalace.Search
• mempalacenet
• mempalacenet-bench

Repo:

https://github.com/elbruno/ElBruno.MempalaceNet

This is about local-first AI memory, storage, search, knowledge graphs, agents, MCP integration, mining, and benchmarking.

Because agents without memory are just very confident goldfish.

Closing thoughts

Most of these packages started as small ideas, experiments, demos, or helper libraries.

But this is one of the things I love about modern development with GitHub Copilot: it makes it easier to move from:

This works on my machine

to:

This is packaged, documented, published, open source, and maybe useful for someone else.

Are all of these perfect?

Of course not.

Are they useful?

I hope so.

Are they free, open source, and ready for you to try, break, improve, fork, complain about, and maybe even use in a real project?

Yes. That is the idea.

And as always:

Today, code is cheap. The decisions are expensive.

This blog post was created with the help of AI tools. Yes, I used a bit of magic from language models to organize my thoughts and automate the boring parts, but the geeky fun and the in C# are 100% mine.

TL;DR

After my first CPU-only experiment with GitHub Copilot CLI and local models, I wanted to try the same idea again, but this time with a GPU-powered setup.

The first experiment proved that running GitHub Copilot CLI offline with local models was technically possible.

This second experiment showed something more interesting:

With the right model, GPU acceleration, small bounded phases, and strict human checkpoints, local agentic coding can become practical enough to move a real .NET project forward.

The setup:

GitHub Copilot CLI
LM Studio
Qwen3.6 35B A3B
GPU acceleration
.NET 10
PowerShell
GitHub CLI
GitHub Actions

The project:

ElBruno.NetAgent
A Windows-first .NET network utility, built with dry-run safety first.

Repository:

https://github.com/brunoghcpft-oss/ElBruno.NetAgent

Previous CPU-only post:

The short version:

Cloud models would have been much faster.
Local mode took more than a day.
But the local workflow actually worked.
And the lessons were worth it.

From CPU-only reality check to GPU-assisted local agents

In the first experiment, I tested GitHub Copilot CLI offline using local models on a CPU-only environment.

That test was useful, but also humbling.

The model could reason, but it was slow. Broad prompts were painful. Asking something like:

How does this repository work?

was not a good idea. The model had too much to process, tool calls became expensive, and long-running attempts could easily end in timeouts or partial answers.

So the first big lesson was simple:

Offline local agentic coding is possible, but CPU-only is a reality check.

This time I wanted to answer a different question:

What changes when we add GPU acceleration?

Not in a synthetic benchmark. Not in a “hello world” repo. But in a real .NET project with tests, CI, packaging, docs, safety constraints, and GitHub Actions.

The setup

The local provider was LM Studio, exposing an OpenAI-compatible endpoint.

The model was:

qwen/qwen3.6-35b-a3b

LM Studio was configured with a large context window:

Context length: 262,144 tokens
GPU offload enabled
Unified KV cache enabled
Model kept in memory

For this GPU experiment, I used a Microsoft Dev Box with an NVIDIA Tesla T4 GPU with 16 GB of VRAM, an AMD EPYC 7V12 64-core processor, and 110 GB of RAM. This was not a high-end consumer GPU workstation, but it was enough to make the local Copilot CLI + LM Studio + Qwen workflow practical. Compared with the CPU-only experiment, the difference was very noticeable, even though powerful cloud models would still be significantly faster.

Copilot CLI was configured to use the local LM Studio endpoint:

cd C:\src\ElBruno.NetAgent
$env:COPILOT_OFFLINE = "true"
$env:COPILOT_PROVIDER_TYPE = "openai"
$env:COPILOT_PROVIDER_BASE_URL = "http://localhost:1234/v1"
$env:COPILOT_MODEL = "qwen/qwen3.6-35b-a3b"

Depending on the task, I adjusted the context and output limits.

For diagnostic tasks with logs:

$env:COPILOT_PROVIDER_MAX_PROMPT_TOKENS = "32768"
$env:COPILOT_PROVIDER_MAX_OUTPUT_TOKENS = "1536"

For large documentation or release-readiness tasks:

$env:COPILOT_PROVIDER_MAX_PROMPT_TOKENS = "131072"
$env:COPILOT_PROVIDER_MAX_OUTPUT_TOKENS = "4096"

For full repo audit or very large synthesis:

$env:COPILOT_PROVIDER_MAX_PROMPT_TOKENS = "196608"
$env:COPILOT_PROVIDER_MAX_OUTPUT_TOKENS = "4096"

Or, when really needed:

$env:COPILOT_PROVIDER_MAX_PROMPT_TOKENS = "262144"
$env:COPILOT_PROVIDER_MAX_OUTPUT_TOKENS = "4096"

But I quickly learned not to use maximum context by default.

More context is not always better.

More context can also mean:

slower responses
more token burn
more chance of runaway generation
more opportunity for the model to overthink
more tool-call noise

The short rule became:

Small context for precision. Large context for synthesis. Max context only when the task truly needs it.

Launching Copilot CLI offline

For most implementation phases, I launched Copilot CLI like this:

copilot --no-remote --disable-builtin-mcps --stream on --max-autopilot-continues 6

When file edits were needed, I enabled full tool permissions inside Copilot CLI:

/allow-all on

And verified with:

/allow-all show

This mattered a lot.

Without /allow-all on, Copilot CLI could read files and run read-only commands, but file-edit tools were blocked with errors like:

Permission denied and could not request permission from user

After enabling /allow-all on, Copilot CLI was able to apply targeted changes.

That became another useful rule:

Diagnosis mode:

• no yolo
• smaller context
• read files
• read logs
• analyze
• stop

Implementation mode:

• /allow-all on
• constrained prompt
• explicitly listed files
• low max-autopilot-continues
• validate
• stop

The project: ElBruno.NetAgent

The project used for the experiment was ElBruno.NetAgent:

https://github.com/brunoghcpft-oss/ElBruno.NetAgent

The goal of the app is to become a Windows-first network utility that can monitor network interfaces, evaluate connection quality, and eventually help with network-switching decisions.

The important part: during this experiment, the app stayed dry-run only.

No real network mutation. No actual interface metric changes. No live switching. No NuGet publishing.

This was intentional. Since I was letting Copilot CLI and a local model modify code, scripts, tests, docs, and CI, safety constraints were non-negotiable.

The app had to stay in this mode:

Dry-run only
Live mode blocked by default
Unsafe config rejected
Audit logs for simulated actions
No real network mutation

What the local model actually helped build

This was not a single prompt experiment.

It was a sequence of bounded phases.

Some of the validated phases included:

Phase 6: Network controller dry-run foundation
Phase 7: Audit log for simulated controller actions
Phase 8: Tray UI status + audit log viewer
Phase 9: Packaging validation
Phase 10: Safety guardrails
Phase 11: NuGet package icon with t2i
Phase 12: Local package smoke test
Phase 13: CI packaging validation
Phase 14: CI test isolation fix

By the end, the project had:

.NET 10 project structure
WPF tray shell
configuration service
network inventory foundation
network quality monitor
decision engine
dry-run network controller
audit log service
UI status surface
NuGet metadata
package icon
local package smoke test
GitHub Actions CI validation
safety guardrails
125 passing tests

That is the part that made this experiment interesting.

The local model was not just generating sample code. It was participating in a real workflow.

Model choice mattered

This experiment also reminded me that “local model” is not a single category.

I originally started experimenting with Gemma 4, but eventually switched to Qwen3.6 35B A3B.

In this setup, Qwen behaved better.

It felt more disciplined for bounded tasks. It handled tool-assisted workflows better. It was also faster in the specific LM Studio + GPU configuration I was using.

That does not mean Qwen is universally better than Gemma.

It means that for this specific setup:

GitHub Copilot CLI
LM Studio
large-context local model
.NET repo
PowerShell tools
GitHub CLI
bounded coding tasks

Qwen was the model that made the workflow practical.

This is an important point: local agentic coding is not just about having “a local model.”

The specific model matters. The runtime matters. The prompt matters. The tool orchestration matters.

Cloud would have been faster. That was not the point.

Let’s be honest.

A powerful cloud model could probably have completed most of this much faster.

My guess: with a strong cloud model, good repo context, and the same human guidance, many of these phases could probably be completed in one or two hours.

The local GPU workflow took more than a day.

There were restarts. There were prompt adjustments. There were permission issues. There were GitHub CLI authentication steps. There were runaway generations. There were context-tuning experiments. There were CI failures. There were moments where I had to stop the agent and take back control.

So no, this was not faster than using a powerful cloud model.

But speed was not the only variable I wanted to test.

I wanted to understand:

Can Copilot CLI work with a local OpenAI-compatible provider?
Can a local model use tools well enough to move a real repo forward?
Can it diagnose GitHub Actions failures from logs?
Can it respect dry-run safety constraints?
Can it generate packaging assets?
Can it validate build, test, pack, and smoke-test flows?
How much human steering is required?
Where does the local workflow break?

The answer was:

Yes, it can work. But it needs constraints, checkpoints, and patience.

Local models are not yet the fastest path for this workflow.

But they are becoming a realistic path for controlled, private, offline-capable experimentation.

The token burn is real

One of the most useful screenshots from the experiment showed a real Copilot CLI run with something like:

Duration: 1h 30m
Input tokens: ~1.8M
Output tokens: ~13.5K
Reasoning tokens: ~2.2K

This is a very important part of the story.

Local does not mean free.

It means the cost moves somewhere else:

your GPU
your CPU
your memory
your time
your electricity
your patience
your prompt discipline

Or, in a more honest way:

The model does not charge per token, but your GPU, your laptop, and your coffee do have limits.

This changed how I structured the work.

I stopped thinking in terms of “one big prompt.”

Instead, I used phases.

Bounded phases were the real unlock

The most important lesson was not “use a GPU.”

The most important lesson was:

Small, bounded phases work. Huge open-ended prompts fail.

Good prompts looked like this:

Implement only this phase.
Modify only these files.
Do not use agents.
Do not use read_agent.
Do not use SQL.
Do not publish.
Do not mutate network state.
Run this exact validation command.
Stop after the summary.

Bad prompts looked like this:

Analyze the whole repo and improve everything.
Make it production ready.
Fix all warnings.
Validate everything.
Continue until done.

The local model could handle focused tasks much better than open-ended ones. A good implementation prompt looked like this:

Apply this exact minimal fix.

Do not diagnose.
Do not use agents.
Do not use read_agent.
Do not use SQL.
Do not use todo tracking.
Do not edit CI YAML.
Do not modify any files except:

• src\ElBruno.NetAgent\Services\Configuration\ConfigurationService.cs
• tests\ElBruno.NetAgent.Tests\SafetyGuardrailTests.cs

If any write/edit tool fails with “Permission denied and could not request permission from user”, stop immediately. Do not try alternate write methods.

Required change 1:
In ConfigurationService.cs, add an optional constructor parameter:
string? configDirectoryOverride = null

Default behavior must remain unchanged.
If configDirectoryOverride is null, continue using:
Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData)
combined with ElBruno.NetAgent.

If configDirectoryOverride is provided, use that directory as the configuration directory.

Required change 2:
In SafetyGuardrailTests.cs, update only the test:
SafetyChain_DefaultConfig_AllowsNoLiveExecution

Make this test use a unique temp directory:
Path.Combine(Path.GetTempPath(), “ElBruno.NetAgent.Test-” + Guid.NewGuid().ToString(“N”))

Create the directory before using it.
Pass it to the ConfigurationService constructor.
Clean it up in finally if practical.

Validation:
Run only:
dotnet test .\tests\ElBruno.NetAgent.Tests\ElBruno.NetAgent.Tests.csproj –configuration Release –verbosity minimal

After validation, summarize:

• exact files changed
• test result
• whether I should commit and push

Stop after summary.

Tool-assisted diagnosis worked better than full autopilot

One of the best parts of the experiment happened when GitHub Actions failed.

Local validation passed:

dotnet build: passed
dotnet test: 125/125 passed
dotnet pack: passed
local package smoke test: passed

But GitHub Actions failed in CI.

Instead of asking Copilot CLI to “fix CI,” I gave it a diagnostic-only prompt:

Goal:
Diagnose a failing GitHub Actions workflow using minimal tool-assisted analysis.

Use tools only to gather the minimum data:

1. Read the local workflow:
   Get-Content ..github\workflows\ci.yml
2. Read the test project file:
   Get-Content .\tests\ElBruno.NetAgent.Tests\ElBruno.NetAgent.Tests.csproj
3. Read the app project file:
   Get-Content .\src\ElBruno.NetAgent\ElBruno.NetAgent.csproj
4. Fetch the failed GitHub Actions job log:
   gh run view 25378546671 –job 74420179140 –log-failed

After gathering data, return:

1. exact failing evidence from the CI log
2. likely root cause
3. smallest YAML-only fix, if any
4. exact YAML lines to change
5. whether I should validate locally or push directly

Do not edit files.
Stop after the analysis.

This worked.

Copilot CLI used the GitHub CLI log and found the real failure:

System.IO.IOException:
The process cannot access the file
C:\Users\runneradmin\AppData\Local\ElBruno.NetAgent\config.json
because it is being used by another process.

The failing test was:

SafetyGuardrailTests.SafetyChain_DefaultConfig_AllowsNoLiveExecution

The important part: Copilot correctly concluded that this was not a YAML problem.

It was a test isolation issue.

The test was using the real user config path under %LOCALAPPDATA%, and in CI that file could be locked by another test/process.

The fix was to use a unique temporary config directory for that test.

The CI fix

The production behavior needed to stay unchanged.

So the fix was small:

1. Add an optional config directory override to ConfigurationService.
2. Keep the default path as %LOCALAPPDATA%\ElBruno.NetAgent.
3. In the failing test, pass a unique temp directory.
4. Clean it up after the test.

Conceptually:

public ConfigurationService(
    ILogger<ConfigurationService> logger,
    string? configDirectoryOverride = null)
{
    _logger = logger;
    var baseDirectory = configDirectoryOverride
        ?? Path.Combine(
            Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData),
            "ElBruno.NetAgent");
    _configurationDirectory = baseDirectory;
    _configurationPath = Path.Combine(_configurationDirectory, "config.json");
}

And in the test:

var tempDirectory = Path.Combine(
    Path.GetTempPath(),
    "ElBruno.NetAgent.Test-" + Guid.NewGuid().ToString("N"));
Directory.CreateDirectory(tempDirectory);
try
{
    var configService = new ConfigurationService(_configLogger, tempDirectory);
    var options = configService.LoadConfiguration();
    // assertions...
}
finally
{
    if (Directory.Exists(tempDirectory))
    {
        Directory.Delete(tempDirectory, recursive: true);
    }
}

After this fix:

Local test passed
GitHub Actions passed
CI packaging validation succeeded

That was a very nice moment in the experiment.

The local model diagnosed a real CI failure using real logs, then helped apply a minimal fix.

Permissions mattered more than expected

Another lesson: tool permissions are part of the system.

At one point, Copilot CLI could read files but could not write them.

The logs showed repeated failures like:

Permission denied and could not request permission from user

It tried:

edit tool
PowerShell write
Python write
Copy-Item
regex replace
backup file

That was a useful failure.

It showed that the model understood the fix, but the Copilot CLI tool environment could not write files.

After enabling:

/allow-all on

Copilot CLI could edit files successfully.

But there was a tradeoff.

With full permissions enabled, I had to watch the run more carefully.

The practical rule became:

If you see “Continuing autonomously” after the summary, stop it.
If you see read_agent, stop it.
If you see SQL/todo tracking, stop it.
If it touches files outside the allowed list, stop it.
If it tries to publish, stop it.

This is not “fire and forget.”

This is human-guided automation.

Packaging, icon generation, and t2i

The experiment also included preparing the NuGet package.

No publishing yet. Only validation.

The package included:

Package metadata
README.md
NuGet icon
local .nupkg generation
static package smoke test
CI packaging validation

For the package icon, I used the local t2i skill and the ElBruno.Text2Image.Cli package:

https://www.nuget.org/packages/ElBruno.Text2Image.Cli

The image generation prompt was something like:

Modern square app icon for “ElBruno.NetAgent”, a Windows-first network tray utility. Minimal semi-flat vector style. Central symbol combining Wi-Fi arcs, a small network switch/router, and a subtle shield/checkmark representing safe dry-run mode. Clean dark blue and cyan palette, high contrast, rounded square background, no text, no letters, no tiny details, readable at small NuGet package icon size.

The generated asset was wired into the project file as the NuGet package icon.

The local package smoke test checked:

package exists
README.md exists in package
icon exists in package
.nuspec contains icon metadata
packaged DLL exists
dry-run references exist

The smoke test was intentionally static.

It did not launch the app. It did not mutate network state. It did not require admin permissions.

CI packaging validation

The GitHub Actions workflow was created to validate packaging without publishing.

It validates:

restore
build
test
pack
local package smoke test
artifact upload

No secrets. No NuGet publishing. No app execution that mutates network state.

A simplified version:

name: CI - Packaging Validation (No Publish)
on:
  push:
    branches:
      - main
  pull_request:
  workflow_dispatch:
jobs:
  packaging:
    name: CI Packaging Validation
    runs-on: windows-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Setup .NET 10
        uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '10.0.x'
      - name: Restore
        run: dotnet restore .\ElBruno.NetAgent.sln
      - name: Build
        run: dotnet build .\ElBruno.NetAgent.sln --configuration Release --no-restore
      - name: Test
        run: dotnet test .\ElBruno.NetAgent.sln --configuration Release --no-build --verbosity minimal
      - name: Pack
        run: dotnet pack .\src\ElBruno.NetAgent\ElBruno.NetAgent.csproj --configuration Release --no-build --output .\artifacts
      - name: Smoke test local package
        shell: pwsh
        run: .\scripts\smoke-test-local-package.ps1 -PackagePath .\artifacts\ElBruno.NetAgent.0.1.0.nupkg
      - name: Upload package artifact
        uses: actions/upload-artifact@v4
        with:
          name: ElBruno.NetAgent-nupkg
          path: artifacts/*.nupkg

This gave the repo a safe release-readiness gate without publishing anything.

Safety guardrails were non-negotiable

Because this project is about network behavior, safety had to be part of the experiment from the beginning.

The model was repeatedly instructed:

Do not execute real network changes.
Keep controller behavior dry-run only.
Do not publish to NuGet.
Do not add live network mutation.
Do not change safety behavior.

The app added guardrails such as:

DryRunMode = true by default
LiveModeAllowed = false by default
unsafe config rejected
audit logs mark dry-run actions
live mode blocked
network mutation not implemented

The tests also checked these behaviors.

That was important because local agentic coding is powerful, but the app domain matters.

If the app can affect a machine’s network behavior, dry-run safety is not optional.

Prompt samples that worked well

1. Diagnostic prompt for GitHub Actions

We are continuing the ElBruno.NetAgent project.

Goal:
Diagnose a failing GitHub Actions workflow using minimal tool-assisted analysis.

Repo:
C:\src\ElBruno.NetAgent

Failed GitHub Actions job:
https://github.com/brunoghcpft-oss/ElBruno.NetAgent/actions/runs//job/

Important:

• gh auth is configured.
• Do not edit files.
• Do not run build/test/pack.
• Do not use SQUAD.
• Do not use task agents.
• Do not use read_agent.
• Do not use SQL or todo tracking.
• Do not continue autonomously after the analysis.
• Do not propose fixes without citing exact evidence from the CI log.
• Use at most 4 shell commands.
• Stop after the analysis.

Run only these commands:

1. Get-Content ..github\workflows\ci.yml
2. Get-Content .\tests\ElBruno.NetAgent.Tests\ElBruno.NetAgent.Tests.csproj
3. Get-Content .\src\ElBruno.NetAgent\ElBruno.NetAgent.csproj
4. gh run view –job –log-failed

Return only:

1. exact failing evidence from the CI log
2. likely root cause
3. smallest YAML-only fix, if any
4. exact YAML lines to change
5. whether I should validate locally or push directly

Then stop. Do not edit anything.

2. Minimal implementation prompt

Apply this exact minimal fix.

Do not diagnose.
Do not use agents.
Do not use read_agent.
Do not use SQL.
Do not use todo tracking.
Do not edit CI YAML.
Do not modify any files except:

• src\ElBruno.NetAgent\Services\Configuration\ConfigurationService.cs
• tests\ElBruno.NetAgent.Tests\SafetyGuardrailTests.cs

If any write/edit tool fails with “Permission denied and could not request permission from user”, stop immediately. Do not try alternate write methods.

Required change:
Add a test-only configuration directory override while preserving production default behavior.

Validation:
Run only:
dotnet test .\tests\ElBruno.NetAgent.Tests\ElBruno.NetAgent.Tests.csproj –configuration Release –verbosity minimal

After validation, summarize:

• exact files changed
• test result
• whether I should commit and push

Stop after summary.

3. Release readiness prompt

We are continuing the ElBruno.NetAgent project.

Current repo:
C:\src\ElBruno.NetAgent

Current status:

• Build passes.
• Tests pass.
• Pack passes.
• Local package smoke test passes.
• CI packaging validation passes.
• No NuGet publishing has been performed.
• The app remains dry-run only.
• Live mode is blocked by default.
• No real network mutation must be executed.

Important constraints:

• Do not use SQUAD.
• Do not use task agents.
• Do not use read_agent.
• Do not use SQL or todo tracking.
• Do not publish to NuGet.
• Do not execute the app in a way that mutates network state.
• Do not change dry-run safety behavior.
• Do not add live network mutation.
• Keep the phase bounded.

Implement Release Candidate Readiness, No Publish.

Requirements:

1. Review release readiness docs.
2. Add or update docs\RELEASE_CHECKLIST.md.
3. Confirm package metadata.
4. Confirm safety warnings are documented.
5. Confirm publishing remains manual.
6. Do not add NuGet publishing workflow.

Validation:
Run only:
dotnet build .\ElBruno.NetAgent.sln –configuration Release –no-restore
dotnet test .\ElBruno.NetAgent.sln –configuration Release –no-build –verbosity minimal
dotnet pack .\src\ElBruno.NetAgent\ElBruno.NetAgent.csproj –configuration Release –no-build –output .\artifacts
powershell -NoProfile -ExecutionPolicy Bypass -File .\scripts\smoke-test-local-package.ps1 -PackagePath .\artifacts\ElBruno.NetAgent.0.1.0.nupkg

After validation, summarize:

• files changed
• build result
• test result
• pack result
• smoke test result
• whether this is ready for manual release review

Stop after summary.

What did not work perfectly

This is the part that makes the experiment honest.

Several things did not work smoothly.

Runaway generation

Sometimes LM Studio kept generating tokens without returning a useful answer.

The fix was usually:

lower output token limit
reduce context
restart Copilot CLI
restart LM Studio server if needed
make the prompt smaller
add a clear stop condition

read_agent despite instructions

Even when the prompt said:

Do not use read_agent.

Copilot CLI sometimes attempted it anyway.

When that happened, I stopped the run.

SQL/todo tracking attempts

Copilot CLI sometimes tried to use SQL/todo tracking even when I explicitly said not to.

This often failed because the tool call was malformed, and it burned time and tokens.

Tool permission issues

Before /allow-all on, write tools were blocked.

After /allow-all on, writing worked, but I had to watch the run closely.

Long validation loops

When I asked Copilot to validate everything, it sometimes got stuck in long shell/output loops.

A better pattern was:

Copilot edits.
Copilot runs one targeted validation.
Human runs full validation manually.

Bigger context sometimes made things worse

Large context helped for docs and synthesis.

But for CI diagnosis, smaller context was better.

Final result

By the end of this experiment, the project reached a solid validation state:

Build: passed
Tests: 125/125 passed
Pack: passed
Smoke test: passed
CI: passed
NuGet publish: not performed
Network mutation: not performed
Dry-run: preserved

The GitHub Actions workflow validates:

restore
build
test
pack
local package smoke test
artifact upload

The app remains safe:

dry-run by default
live mode blocked
no real network mutation

What I learned

The GPU did not make the local model magical.

But it did change the workflow from:

This is technically possible.

to:

This can be useful if you control the scope.

The winning formula was:

GitHub Copilot CLI

• LM Studio
• Qwen local
• GPU
• small phases
• strict prompts
• build/test validation
• human checkpoints

The dangerous formula was:

huge prompt

• huge context
• full autonomy
• unclear stop condition
• long validation loops

The best use case was not full autonomous coding.

The best use case was:

tool-assisted development
bounded implementation
targeted diagnosis
human-controlled validation

My final take

If I needed to ship this as fast as possible, I would use a powerful cloud model.

No debate.

A cloud model would likely be faster, more stable, and easier to orchestrate.

But that was not the point of this experiment.

The point was to understand whether a local model could participate in a real developer workflow through GitHub Copilot CLI.

And the answer is:

Yes, but with constraints.

Local models are not yet the easiest path.

They are not always the fastest path.

But they are becoming good enough for serious experimentation, especially when you care about control, offline capability, privacy, and understanding how agentic coding behaves under real constraints.

The human remains the control plane.

And honestly, that is probably a good thing.

Cloud models are still faster and more convenient.
Local models are becoming good enough to be dangerous — in the best possible way.

Resources

Here are the main resources, tools, and references mentioned in this experiment.

• ElBruno.NetAgent repository
  https://github.com/brunoghcpft-oss/ElBruno.NetAgent
• Previous CPU-only experiment
  https://elbruno.com/2026/05/03/running-github-copilot-cli-offline-with-local-models-a-cpu-only-reality-check/
• GitHub Copilot CLI documentation
  https://docs.github.com/en/copilot/how-tos/copilot-cli
• Using GitHub Copilot CLI
  https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli
• GitHub Copilot CLI product page
  https://github.com/features/copilot/cli
• LM Studio
  https://lmstudio.ai/
• LM Studio GitHub organization
  https://github.com/lmstudio-ai
• Qwen3.6-35B-A3B model on Hugging Face
  https://huggingface.co/Qwen/Qwen3.6-35B-A3B
• LM Studio community GGUF for Qwen3.6-35B-A3B
  https://huggingface.co/lmstudio-community/Qwen3.6-35B-A3B-GGUF
• Qwen3.6-35B-A3B announcement
  https://qwen.ai/blog?id=qwen3.6-35b-a3b
• Qwen3.6 GitHub repository
  https://github.com/QwenLM/Qwen3.6
• .NET downloads
  https://dotnet.microsoft.com/en-us/download
• GitHub CLI
  https://cli.github.com/
• GitHub Actions documentation
  https://docs.github.com/en/actions
• NuGet package: ElBruno.Text2Image.Cli
  https://www.nuget.org/packages/ElBruno.Text2Image.Cli
• NuGet documentation
  https://learn.microsoft.com/en-us/nuget/
• xUnit.net
  https://xunit.net/

This blog post was created with the help of AI tools. Yes, I used a bit of magic from language models to organize my thoughts and automate the boring parts, but the geeky fun and the in C# are 100% mine.

TL;DR

I tested GitHub Copilot CLI running offline with local models on a CPU-only Microsoft Dev Box.

The short version:

• Ollama worked for basic offline prompts, but struggled with long-context agentic workflows and tool execution on CPU-only hardware.
• LM Studio worked better as the local OpenAI-compatible provider.
• google/gemma-4-e2b successfully executed Copilot CLI PowerShell tools.
• 32K and 64K context were the practical sweet spot for guided development.
• 131K context worked as a stress test, but it was not practical as a daily CPU-only workflow.
• Copilot CLI interactive mode worked well with small, explicit, validated tasks.
• SQUAD/autopilot long workflows were not reliable enough on CPU-only hardware.
• Final takeaway: local Copilot CLI works on CPU-only, but as a guided pair-programming workflow, not as a fully autonomous engineering team.

Or, in one sentence:

CPU-only can be your copilot. Just do not promote it to engineering manager yet

The experiment goal

This experiment started with a simple question:

Can I use GitHub Copilot CLI with a local model, offline, to work on a real .NET project?

The project was:

https://github.com/brunoghcpft-oss/ElBruno.NetAgent

The bigger idea was also very attractive:

GitHub Copilot CLI
+ SQUAD
+ local models
+ GitHub Copilot Free Tier
+ .NET
+ offline/local execution

That combination matters because it hints at a future where developers can experiment with local agentic workflows without always depending on cloud-hosted inference.

But I did not want to only ask the model questions.

I wanted to know if it could perform real developer tasks:

dotnet new sln
dotnet new wpf
dotnet new xunit
dotnet build
dotnet test
git status
create files
update docs
work inside Copilot CLI interactively
use tools

That was the real test.

Not “Can the model answer?”

But:

Can the model act through Copilot CLI tools and help build a real .NET project?

First attempt: Ollama

The first local provider I tested was Ollama.

Ollama is a great tool for running local models. It is simple, developer-friendly, and works very well for many local AI experiments.

The initial Copilot CLI setup looked like this:

$env:COPILOT_PROVIDER_BASE_URL = "http://localhost:11434/v1"
$env:COPILOT_PROVIDER_TYPE = "openai"
$env:COPILOT_MODEL = "qwen3.5"
$env:COPILOT_OFFLINE = "true"

I tried several models, including:

qwen3.5
qwen3.5:4b
llama3.2
devstral-small-2
gemma4:e2b
qwen2.5-coder

The first big surprise was how large a “simple” Copilot CLI prompt actually becomes.

Even something like:

Reply exactly: OK

is not just that text. Copilot CLI also includes system instructions, tool definitions, environment data, agent instructions, and other context.

So a tiny user prompt can quickly become a large request.

With Ollama on this CPU-only machine, I saw a consistent pattern:

Small context → truncation or failure
Larger context → very slow prompt processing
Tool execution → unreliable
CPU-only → retries, transient errors, long waits

Ollama did work in some scenarios. It responded to simple prompts and could be useful for ask-style interactions.

But for Copilot CLI tool execution and agentic workflows, it was not reliable enough on this hardware.

My conclusion for Ollama:

Ollama worked, but mostly for ask mode. In this CPU-only setup, it was not a good fit for full Copilot CLI agentic coding.

The context problem

One of the most important lessons was about context size.

Copilot CLI does not only need room for your prompt. It also needs context for:

system instructions
tool definitions
agent instructions
workspace information
command outputs
conversation history
MCP/tool metadata
custom agent context

The GitHub Copilot CLI best practices mention the value of models with large context windows for agentic work:

https://docs.github.com/en/copilot/how-tos/copilot-cli/cli-best-practices

The command reference is also useful when exploring Copilot CLI behavior and options:

https://docs.github.com/en/copilot/reference/copilot-cli-reference/cli-command-reference

A task that looks small to us can become a much larger request for the CLI.

For example:

Create a WPF project and run tests.

That sounds simple. But an agentic CLI workflow may need to include repo state, tools, instructions, command outputs, and validation steps.

More context helps because the request fits better.

But on CPU-only hardware, more context is not free:

more context
= more prompt prefill
= more CPU work
= more waiting
= more chances for retries or timeouts

So context solved one problem and created another.

The request could fit.

But now the CPU had to process it.

Slowly.

Very slowly.

Moving from Ollama to LM Studio

The experiment changed when I moved from Ollama to LM Studio.

LM Studio provides a local OpenAI-compatible server. In this setup, the endpoint was:

http://localhost:1234/v1

The Copilot CLI environment variables became:

$env:COPILOT_PROVIDER_BASE_URL = "http://localhost:1234/v1"
$env:COPILOT_PROVIDER_TYPE = "openai"
$env:COPILOT_MODEL = "google/gemma-4-e2b"
$env:COPILOT_OFFLINE = "true"

The model I used for the successful runs was:

google/gemma-4-e2b

One LM Studio setting was critical:

Max Concurrent Predictions = 1

This matters because if the context length is set high but the server splits capacity across multiple concurrent predictions, each request may effectively get less usable context.

For this experiment, I wanted one Copilot CLI request to get the full available context.

The key LM Studio settings became:

Context Length: 32768, 65536, and 131072 during stress testing
Max Concurrent Predictions: 1
Keep Model in Memory: ON

LM Studio also gave me much better observability.

With Ollama, I was mostly reading logs and guessing.

With LM Studio, I could see the loaded model, server status, effective configuration, and live prompt processing progress.

That mattered a lot.

With LM Studio, I stopped guessing. I could see the prompt processing percentage moving.

The first real tool execution

The first major breakthrough was not the model answering a question.

The breakthrough was tool execution.

I asked Copilot CLI to use the PowerShell tool and create a file.

The first attempt almost worked, but failed because the tool call was missing a required field:

“description”: Required

That was an important lesson.

The model was trying to use the tool, but the function call was incomplete.

So I changed the prompt pattern.

The working pattern became:

Use the powershell tool. The powershell tool call must include both required fields: command and description. Run this exact command: . Use this description: . Do not only describe the action.

Example:

Use the powershell tool. The powershell tool call must include both required fields: command and description. Run this exact command: echo LMSTUDIO_E2B_TOOL_TEST > lmstudio-e2b-tool-test.txt. Use this description: Create LM Studio tool test file. Do not only describe the action.

This time, Copilot CLI executed the command.

The file was created.

That was the first real “OK”.

Not just:

The model answered.

But:

The model used Copilot CLI tools to change the filesystem.

That changed the experiment.

From 16K to 32K

At 16K context, basic tool execution worked.

But when I tried to create a larger Markdown file using multiline content, the result became unreliable. The model claimed success, but the file was not created correctly.

This taught me something important:

More context is not the only problem. Command complexity matters too.

Long multiline here-strings, large embedded Markdown blocks, and complex PowerShell escaping were too much for this local setup.

So I moved to a stricter execution rule:

one prompt
one tool
one bounded command
one validation

Then I increased the context to 32K and started running real Phase 0-style .NET setup tasks.

This worked.

Copilot CLI successfully executed commands like:

dotnet new sln -n ElBruno.NetAgent

Then:

New-Item -ItemType Directory -Force -Path .\src
New-Item -ItemType Directory -Force -Path .\tests

Then:

dotnet new wpf -n ElBruno.NetAgent -o .\src\ElBruno.NetAgent

Then:

dotnet new xunit -n ElBruno.NetAgent.Tests -o .\tests\ElBruno.NetAgent.Tests

Then:

dotnet sln .\ElBruno.NetAgent.sln add .\src\ElBruno.NetAgent\ElBruno.NetAgent.csproj
dotnet sln .\ElBruno.NetAgent.sln add .\tests\ElBruno.NetAgent.Tests\ElBruno.NetAgent.Tests.csproj

And finally:

dotnet build .\ElBruno.NetAgent.sln
dotnet test .\ElBruno.NetAgent.sln

This was a big milestone.

With LM Studio, Gemma 4 E2B, and explicit tool instructions, Copilot CLI created a real .NET solution and validated it.

The runtime was not fast. Most commands took several minutes.

But they worked.

The practical prompt pattern

The reliable prompt style was very explicit.

For example:

Use the powershell tool. The powershell tool call must include both required fields: command and description.

Run this exact command:
dotnet build .\ElBruno.NetAgent.sln

Use this description:
Build ElBruno NetAgent solution.

Do not only describe the action.

This is not elegant.

But it was reliable.

The important parts were:

name the tool
state the required fields
give the exact command
give the description
tell it not to only describe the action
include validation when possible

A better workflow emerged:

ask for one small task
execute one command
validate the result
continue

That was the first point where the experiment became useful.

Not autonomous.

But useful.

Moving to 64K context

After 32K worked, I tested 64K.

The environment variables became:

$env:COPILOT_PROVIDER_BASE_URL = "http://localhost:1234/v1"
$env:COPILOT_PROVIDER_TYPE = "openai"
$env:COPILOT_MODEL = "google/gemma-4-e2b"
$env:COPILOT_PROVIDER_MAX_PROMPT_TOKENS = "65536"
$env:COPILOT_PROVIDER_MAX_OUTPUT_TOKENS = "512"
$env:COPILOT_OFFLINE = "true"

In LM Studio:

Context Length: 65536
Max Concurrent Predictions: 1

I tested a combined command:

git status --short; dotnet test .\ElBruno.NetAgent.sln; git status --short

It worked.

The important observation was that 64K did not magically transform the model.

The effective token usage was still around the same range as several 32K tests.

So 64K gave the workflow more room, but it did not remove the need for disciplined prompts.

My conclusion:

64K worked, but it did not magically make the model smarter. It just gave the workflow more breathing room.

Testing Copilot CLI interactive mode

Up to this point, many tests used:

copilot -p "<prompt>"

That was useful for deterministic experiments, but it was not the workflow I really cared about.

The real workflow should happen inside Copilot CLI.

So I launched Copilot CLI interactively:

copilot `
--disable-builtin-mcps `
--no-remote `
--yolo `
--stream on

Then I gave instructions inside the CLI.

This also worked.

I tested:

git status –short
dotnet test .\ElBruno.NetAgent.sln
create folders
validate files

The interactive workflow was more natural.

But the same rule still applied:

small steps
explicit tool call
validation
no giant task requests

At this point, the conclusion was:

Interactive Copilot CLI with a local model is usable on CPU-only hardware, as long as the work is guided and constrained.

The 131K context stress test

LM Studio showed that google/gemma-4-e2b could be configured with a context length of 131072 tokens.

So I tried the big one.

In LM Studio:

Context Length: 131072
Max Concurrent Predictions: 1

In PowerShell:

$env:COPILOT_PROVIDER_MAX_PROMPT_TOKENS = "131072"
$env:COPILOT_PROVIDER_MAX_OUTPUT_TOKENS = "1024"

Then I ran Copilot CLI interactively and enabled autopilot.

The stress test asked Copilot CLI to:

inspect git status
inspect solution contents
run build
run tests
create a status file
validate the status file
show final git status

This worked well enough.

The model executed build and tests, created the status file, and I manually validated the result.

The generated status file contained:

provider: LM Studio
model: google/gemma-4-e2b
context: 131072
execution mode: Copilot CLI interactive autopilot

Then I corrected it with a micro-prompt to add the missing result summary.

Manual validation passed:

Test-Path .\docs\PHASE0_STRESS_TEST_RESULT.md
Get-Content .\docs\PHASE0_STRESS_TEST_RESULT.md
git status --short
dotnet test .\ElBruno.NetAgent.sln

So, yes:

131K context worked.

But there is an important nuance:

131K worked technically. That does not mean 131K was practical on CPU-only hardware.

For the successful stress test, Copilot CLI did not actually need to consume the full 131K context. The larger context was available, but the workflow still depended on bounded tasks.

The SQUAD test

Finally, I tried the big question:

Can SQUAD run this as a more autonomous workflow?

This was the most interesting failure.

I reactivated the SQUAD custom agent and asked it to:

1. Inspect the repository.
2. Update the existing SQUAD execution rules with a local model execution rule.
3. Implement a simple WPF status display.
4. Build.
5. Test.
6. Show final git status.
7. Summarize the changes.

This is where CPU-only started to show the real limit.

Copilot CLI selected the custom agent:

Selected custom agent: Squad

Then transient API errors started appearing.

Then a tool call failed because it was missing the required description field:

“description”: Required

After that, it executed git status --short, but then started claiming that the workflow had completed, including rule updates, build/test sequence, and feature integration.

The problem: the log did not show reliable tool-call evidence for all those claimed actions.

That is the danger zone.

The model can say:

Done.

But as developers, we need:

Show me the tool output.
Show me the file diff.
Show me the build.
Show me the test result.

The LM Studio logs showed the other side of the problem: long SQUAD/autopilot workflows generate lots of reasoning and inflate the prompt. The model was processing a large conversation and spending a lot of time in reasoning rather than clean tool execution.

This was the final conclusion for SQUAD on CPU-only:

SQUAD/autopilot long workflows are not reliable enough on this hardware. The model can drift, retries can appear, malformed tool calls can happen, and it may claim completion without enough verified execution.

What worked well

This setup worked well for guided work:

LM Studio

• google/gemma-4-e2b
• Copilot CLI
• offline mode
• PowerShell tools
• 32K / 64K context
• small tasks
• manual validation

It successfully handled:

dotnet new sln
dotnet new wpf
dotnet new xunit
dotnet sln add
dotnet build
dotnet test
git status
file creation
small docs updates
interactive Copilot CLI prompts
autopilot stress test with manual validation

That is a real result.

It means local model workflows for .NET development are possible on CPU-only hardware.

Slow, yes.

But possible.

What did not work well

This setup did not work well for:

long autonomous SQUAD execution
large “do the whole phase” prompts
complex multiline file generation
large here-strings
unattended autopilot loops
claims without validation
CPU-only 131K workflows as a daily mode

The main risks were:

very slow prompt processing
transient API errors
malformed tool calls
missing required tool fields
reasoning drift
false completion claims
too much context for CPU-only hardware

The most important failure mode was not:

The model cannot answer.

The most important failure mode was:

The model claims that work is complete, but the validated tool evidence is incomplete.

That is why manual validation is not optional.

The sweet spot

For this CPU-only VM, the sweet spot is:

Provider: LM Studio
Model: google/gemma-4-e2b
Context: 32K or 64K
Max Concurrent Predictions: 1
Copilot CLI: offline + no remote
Mode: interactive
Workflow: one bounded task at a time
Validation: always

The best working rule:

One prompt.
One tool.
One bounded command.
One validation.

This is not as flashy as “fully autonomous AI developer.”

But it is much more realistic.

And it works.

Recommended Copilot CLI setup

This is the setup I would keep for guided local work:

$env:COPILOT_PROVIDER_BASE_URL = "http://localhost:1234/v1"
$env:COPILOT_PROVIDER_TYPE = "openai"
$env:COPILOT_MODEL = "google/gemma-4-e2b"
$env:COPILOT_PROVIDER_MAX_PROMPT_TOKENS = "65536"
$env:COPILOT_PROVIDER_MAX_OUTPUT_TOKENS = "512"
$env:COPILOT_OFFLINE = "true"
copilot `
  --disable-builtin-mcps `
  --no-remote `
  --yolo `
  --stream on

Then inside Copilot CLI, use prompts like this:

Use the powershell tool. The powershell tool call must include both required fields: command and description.

Run this exact command:
dotnet test .\ElBruno.NetAgent.sln

Use this description:
Run ElBruno NetAgent tests.

Do not only describe the action.

Again, not elegant.

But reliable.

Test environment

These results are based on one CPU-only virtual machine. They should not be treated as a universal benchmark for Copilot CLI, LM Studio, Ollama, or Gemma 4 E2B.

Hardware and OS:

Environment: Microsoft Dev Box
Dev Box size: AMD 8 vCPU / 32 GB RAM / 1024 GB storage
Processor: AMD EPYC 7763 64-Core Processor @ 2.44 GHz
Installed RAM: 32.0 GB
Storage: 1.00 TB
GPU: None
Dedicated VRAM: None
System type: 64-bit operating system, x64-based processor
Operating system: Windows 11 Enterprise
Windows version: 25H2
OS build: 26200.8246

Experiment setup:

Shell: PowerShell
Main successful local model host: LM Studio
Main successful model: google/gemma-4-e2b
Other local model host tested: Ollama
Copilot account: GitHub Copilot Free Tier
Copilot CLI mode: offline / local provider
Project type: .NET WPF app + xUnit test project

The important detail is that this machine had no dedicated GPU and no dedicated VRAM.

All local model inference happened on CPU.

That is why long-context workflows, especially SQUAD/autopilot runs, became slow and fragile even when the model technically supported 131K context.

Final conclusion

This experiment changed my expectations.

At the beginning, I thought the question was:

Which local model works with Copilot CLI?

By the end, the real question was:

What workflow makes local Copilot CLI reliable enough to be useful?

The answer was not just the model.

The answer was the combination of:

LM Studio

• Gemma 4 E2B
• enough context
• low concurrency
• explicit tool instructions
• small tasks
• constant validation

On CPU-only hardware, the result is clear:

Good for guided pair programming.
Good for small .NET tasks.
Good for local/offline experiments.
Good for learning how agentic workflows behave.

Not good for fully autonomous SQUAD execution.
Not good for long unattended implementation phases.
Not good for pretending CPU-only is a cloud GPU cluster.

Local AI is real.

Offline developer workflows are real.

Copilot CLI with local models is real.

But autonomy still needs the right model, the right hardware, and a lot of discipline.

CPU-only can be your copilot.

Just do not promote it to engineering manager yet

This blog post was created with the help of AI tools. Yes, I used a bit of magic from language models to organize my thoughts and automate the boring parts, but the geeky fun and the in C# are 100% mine.

Hi!

If you’re running Ollama locally on Windows—whether you’re tinkering with LLMs, building local AI demos, or just curious about the overhead of large models—you’ve probably wondered: Is it still running? How much CPU is it chewing? Did that model load?

Welcome to ElBruno.OllamaMonitor.

It’s a no-frills system tray app that sits in your Windows notification area and tells you, at a glance, exactly what your local Ollama instance is doing. No dashboards. No complexity. Just real-time status, resource metrics, and a floating details window when you need more info.

ElBruno.OllamaMonitor sits in your Windows system tray and tells you:

• Is Ollama running? A glance at the tray icon shows you the status.
• Is a model loaded? See what’s currently active.
• How much CPU, RAM, and GPU is it using? Real-time resource metrics from the Ollama process.
• Any errors? Get instant visual feedback if something’s wrong.

Perfect for:

• Local AI developers who need quick visibility into Ollama
• Demo presenters who want to know resource impact in real-time
• Anyone running large models locally who’s curious about the overhead

Installation

Via NuGet (Recommended)

dotnet tool install --global ElBruno.OllamaMonitor

Then launch anytime:

ollamamon

From Source

git clone https://github.com/elbruno/ElBruno.OllamaMonitor.git
cd ElBruno.OllamaMonitor
dotnet build src/ElBruno.OllamaMonitor/
dotnet run --project src/ElBruno.OllamaMonitor/

Quick Start

1. Launch the app:ollamamon The app starts minimized to the tray. Click the icon to open the details window or mini monitor.
2. Check your status: Look at the tray icon color—it tells you Ollama’s status at a glance.
3. Configure (optional): See Configuration Guide for endpoint, refresh rate, and threshold settings.

Features

•  System Tray Integration — Runs in the background, always visible
•  Visual Status Indicators — Color-coded icons for quick status checks
•  Standard Details Window — A normal Windows window with minimize/close behavior that keeps the app in the tray when closed
•  Mini Monitor Window — A semi-transparent always-on-top compact view for CPU, RAM, GPU, and model status
•  Local Configuration — Customize endpoint, refresh rate, thresholds
•  CLI Commands — Fully scriptable configuration
•  GPU Metrics — Best-effort NVIDIA GPU tracking (if nvidia-smi is available)
•  Copy to Clipboard — Quickly share diagnostics
•  Manual Refresh — Force an immediate check
•  Open Ollama URL — Quick link to the Ollama API

Requirements

• Windows 10 / Windows 11 (requires .NET 10 runtime, which can be downloaded from dotnet.microsoft.com)
• Ollama running locally (download from ollama.ai)
• .NET 10 SDK to build from source

Optional:

• nvidia-smi (NVIDIA GPU drivers) for GPU metrics

Configuration

See Configuration Guide for detailed setup, CLI commands, custom thresholds, and advanced options like remote Ollama monitoring.

Try it: dotnet tool install --global ElBruno.OllamaMonitor

Docs: See the GitHub repository

Made by: El Bruno — A .NET developer obsessed with local AI and productivity.

This blog post was created with the help of AI tools. Yes, I used a bit of magic from language models to organize my thoughts and automate the boring parts, but the geeky fun and the in C# are 100% mine.

Hi!

dotnet tool install --global ElBruno.AspireMonitor
aspiremon

What it is

AspireMonitor is a Windows tray app that puts your Aspire AppHost status one click away. No browser tabs. No switching context. Click the tray icon, see what’s running, Start/Stop your app, or pin the resources you actually care about in a compact mini window.

Why it exists

If you use Aspire, you know the dashboard is useful—but you don’t want a browser tab open all day. You’re writing code, not monitoring. AspireMonitor solves the friction: a lightweight tray icon that gives you “is my API up?” and “what URL does this service run on?” without leaving your IDE.

Why it’s useful

v1.4.0 ships with two killer features:

The mini window pins only the resources you care about (configure once: web, store, gateway) with their live URLs and Start/Stop buttons. The main window shows the full resource list when you need it.

Start now works correctly—it stays disabled with ⏳ Starting Aspire... (12 / 90s) so you know when resources are actually ready. Stop actually stops. URLs are real (http://localhost:5021), not generic “Open” links.

Get it

• NuGet: https://www.nuget.org/packages/ElBruno.AspireMonitor
• GitHub: https://github.com/elbruno/ElBruno.AspireMonitor
• MIT licensed. Issues and PRs welcome.

Built with .NET 10 + WPF. Shells out to aspire describe—no third-party SDK dependency.

This blog post was created with the help of AI tools. Yes, I used a bit of magic from language models to organize my thoughts and automate the boring parts, but the geeky fun and the in C# are 100% mine.

Hi!

usually hide my taskbar clock while recording videos, and after doing that dance one too many times, I had one goal: save a few clicks.

Then yesterday, during a GitHub Copilot CLI session (watch it here), I decided to pick up the ClockTray app and turn it into a CLI tool.

And… here we are.

Introducing the ClockTray CLI

ClockTray v1.0.0 is now a dual-mode utility combining a user-friendly GUI with powerful command-line controls.

The headline feature? Full CLI support. You can now control your taskbar clock entirely from PowerShell, batch scripts, or any automation tool. Show it, hide it, check its status—all without touching the mouse.

The New CLI Commands

Here’s what you can do right from your terminal:

# Show the clock on your taskbar
clocktray show
# Hide the clock
clocktray hide
# Check the current status
clocktray status
# View all available commands
clocktray --help
# Check the version
clocktray --version

Each command is instant, non-blocking, and integrates seamlessly with your scripts and workflows.

One Tool, Two Modes

ClockTray now works the way you work:

GUI Mode: Launch the application normally for a traditional system tray experience. Right-click the icon to toggle your clock or access settings—perfect for quick manual control.

CLI Mode: Run clocktray commands from PowerShell, Windows Terminal, or your build scripts. Perfect for automation, CI/CD pipelines, and repetitive tasks.

You don’t need separate tools. You get both, in a single 30-second install.

Automation & Real-World Use Cases

Imagine these scenarios—now all possible with ClockTray:

• Streaming Setup: Hide the clock before you go live, show it again when you stop.
• Multi-Monitor Management: Toggle the clock based on which display you’re using—via a custom PowerShell profile.
• Build Pipelines: Hide the clock during automated testing, restore it when complete.
• Accessibility Workflows: Create quick-access scripts that adapt your desktop to different needs.
• Time-Tracking Scripts: Check the clock status as part of a larger automation routine.

PowerShell scripters and DevOps engineers, you’re going to love this.

Bonus Feature: Chinese Lunar Calendar Overlay

ClockTray also includes a beautiful overlay showing the Chinese lunar calendar—perfect if you’re tracking traditional holidays, working with international teams, or simply interested in lunar dates. This overlay displays alongside your taskbar clock and respects your show/hide commands.

Installation in 30 Seconds

You can install ClockTray as a global .NET tool from NuGet:

dotnet tool install --global ElBruno.ClockTray

That’s it. You’ll have clocktray available in any PowerShell session or terminal immediately.

Update an existing installation? Use:

dotnet tool update --global ElBruno.ClockTray

Get ClockTray Today

• GitHub: github.com/elbruno/ElBruno.ClockTray
• NuGet: nuget.org/packages/ElBruno.ClockTray

Explore the source code, contribute features, or report issues on GitHub. The project is open-source and welcomes your feedback.

What’s Next

With v1.0.0 released, we’re already thinking ahead. Future updates may include:

• Configuration files for default behavior
• Extended automation scenarios
• Cross-platform considerations

Your input shapes this tool. If you have ideas, open an issue or discussion on GitHub.

Try It Now

Whether you’re a PowerShell enthusiast, a DevOps engineer, or someone who just wants better desktop control, ClockTray v1.0.0 has something for you. Install it today, explore the CLI, and tell us what you build.

This blog post was created with the help of AI tools. Yes, I used a bit of magic from language models to organize my thoughts and automate the boring parts, but the geeky fun and the in C# are 100% mine.

Hi!

Two weeks ago, I shipped t2i — a terminal-first CLI for text-to-image generation. Today I’m excited to announce two major additions that make t2i even more powerful:

1. GPT-Image-1.5 and GPT-Image-2 support — Microsoft’s DALL-E 3 and next-gen models via Azure OpenAI
2. AI agent skill integration — Teach GitHub Copilot and Claude Code to use t2i automatically

TL;DR

• New models: GPT-Image-1.5 (DALL-E 3) and GPT-Image-2 (next-gen) now available via Azure OpenAI
• Skill integration: Run t2i init to teach GitHub Copilot and Claude Code how to generate images autonomously
• Updated providers: Now supporting 5 cloud models (FLUX.2 Pro, FLUX.2 Flex, MAI-Image-2, GPT-Image-1.5, GPT-Image-2)
• Version: Available in t2i v0.16.0+ via dotnet tool update --global ElBruno.Text2Image.Cli

Part 1: AI Agent Skills — The Biggest Feature

This is the feature I’m most excited about: teaching AI agents how to use t2i automatically

What Are Skills?

Skills are packages of functionality that AI coding agents can discover and invoke on their own. By installing a skill file, you enable agents like GitHub Copilot and Claude Code to:

• Generate images directly within your development workflow
• Automate batch creation based on natural language requests
• Integrate image generation into CI/CD pipelines and automation scripts

Skills work by placing metadata files in well-known directories (.github/skills/ for Copilot, .claude/skills/ for Claude Code) that agents scan during initialization. Once installed, these agents understand:

• Which t2i commands exist and when to use each one
• How to set up secrets safely (env vars first, never commit keys)
• The full provider list and which one to default to
• Common workflows: first-time setup, single image, batch loops

How to Set It Up

Install the cli tool locally, setup the tool and from any repository:

t2i init

That’s it. This command writes skill metadata to:

• .github/skills/t2i/SKILL.md (for GitHub Copilot)
• .claude/skills/t2i/SKILL.md (for Claude Code)

Want only one target?

t2i init --target github   # GitHub Copilot only
t2i init --target claude   # Claude Code only

The skill files include:

• Tool overview and capabilities
• Command syntax with examples
• Provider configuration instructions
• Best practices and troubleshooting tips

Real-World Example: GitHub Copilot

After running t2i init --target github, you can interact with Copilot naturally:

You: “Generate a futuristic cityscape with neon lights and save it as hero.png”

Copilot: Automatically invokes:

t2i "futuristic cityscape with neon lights, cyberpunk style, volumetric fog" \
  --provider foundry-flux2 \
  --width 1792 \
  --height 1024 \
  --output hero.png

You: “Create a series of social media images for our product launch — abstract tech theme”

Copilot: Automatically invokes:

t2i "abstract tech background with circuit patterns" --output social-1.png
t2i "geometric tech shapes with gradient colors" --output social-2.png
t2i "digital network visualization, modern style" --output social-3.png

No need to remember the exact syntax or provider flags — Copilot handles it.

Real-World Example: Claude Code

After running t2i init --target claude, Claude can drive t2i based on your requests:

You: “I need an image of a sunset over mountains for the landing page, wide format”

Claude: Automatically invokes:

t2i "sunset over mountains, warm golden hour colors, panoramic view" \
  --provider foundry-flux2 \
  --width 1792 \
  --height 1024 \
  --output landing-hero.png

You: “Generate icon placeholders: home, settings, profile — all square, simple line art”

Claude: Automatically invokes multiple commands:

t2i "home icon, simple line art, minimalist, 512x512" --out icon-home.png
t2i "settings icon, simple line art, minimalist, 512x512" --out icon-settings.png
t2i "profile icon, simple line art, minimalist, 512x512" --out icon-profile.png

Why This Matters

Before skills, you had to:

1. Remember t2i syntax
2. Look up provider names
3. Check configuration flags
4. Write your own automation scripts

With skills installed, AI agents become your image generation assistant:

• They know the syntax
• They pick the right provider
• They handle dimensions and output paths
• They batch generate when appropriate

This is especially powerful in CI/CD scenarios. Imagine a GitHub Actions workflow where Copilot autonomously generates marketing assets, social media images, or documentation screenshots based on a simple prompt list.

Configure providers first

Before your AI agent can use t2i, ensure at least one provider is configured:

t2i config   # Interactive setup

Use environment variables in CI/CD

For automated workflows, configure via env vars:

# GitHub Actions example
- name: Generate images
  env:
    T2I_FOUNDRY_FLUX2_ENDPOINT: ${{ secrets.FOUNDRY_ENDPOINT }}
    T2I_FOUNDRY_FLUX2_APIKEY: ${{ secrets.FOUNDRY_APIKEY }}
  run: |
    dotnet tool install --global ElBruno.Text2Image.Cli
    t2i init
    t2i "hero image for landing page" --provider foundry-flux2 --out assets/hero.png

Update skills after CLI upgrades

When you update t2i, refresh the skill metadata:

dotnet tool update --global ElBruno.Text2Image.Cli
t2i init   # Regenerates skill files with latest docs

More Details

For the complete skill integration guide, including troubleshooting, advanced customization, and platform-specific instructions, see:

→ docs/skill-integration.md

Part 2: GPT-Image Models — More Choices

Now for the second big update: GPT-Image-1.5 and GPT-Image-2 support.

These are Microsoft’s image generation models available via Azure OpenAI Service. Both are based on OpenAI technology but deployed in Azure for enterprise-grade reliability, compliance, and control.

GPT-Image-1.5 (DALL-E 3)

What it is: Azure OpenAI’s implementation of OpenAI’s DALL-E 3 model.

Best for:

• Natural language prompts — Excellent at understanding complex, conversational descriptions
• Photorealistic images — Great for realistic scenes, portraits, and product photography
• Text rendering — Better at including readable text in images (though still not perfect)
• Enterprise compliance — Deployed in your Azure region with full data residency

Supported sizes:

• 1024×1024 (square)
• 1792×1024 (landscape)
• 1024×1792 (portrait)

Example use cases:

• Marketing visuals with text overlays
• Product mockups and packaging designs
• Editorial illustrations for blog posts
• Social media graphics

GPT-Image-2 (Next-Gen)

What it is: Microsoft’s next-generation image model — more advanced than DALL-E 3.

Best for:

• High-quality artistic images — Improved coherence and style consistency
• Complex compositions — Better at multi-object scenes with detailed relationships
• Stylized rendering — Excels at specific art styles (watercolor, oil painting, digital art)
• Prompt adherence — Follows instructions more accurately, especially for abstract concepts

Supported sizes:

• 1024×1024 (square)
• 1792×1024 (landscape)
• 1024×1792 (portrait)

Example use cases:

• Concept art and game design
• Artistic book cover designs
• Abstract and stylized illustrations
• Character design and visual development

How to Use Them

Both models use the Azure OpenAI Service, so you need:

1. An Azure subscription
2. An Azure OpenAI resource
3. A deployment of gpt-image-1.5 or gpt-image-2
4. Your endpoint URL and API key

Quick Setup (GPT-Image-1.5)

# Interactive setup wizard
t2i config set foundry-gpt-image-1p5

The wizard prompts for:

• Endpoint URL (e.g., https://my-resource.openai.azure.com/)
• API Key (from Azure Portal)
• Deployment name (e.g., gpt-image-15)

Then generate:

t2i "an impressionist painting of a garden in spring" \
  --provider foundry-gpt-image-1p5

Quick Setup (GPT-Image-2)

# Interactive setup wizard
t2i config set foundry-gpt-image-2

Then generate:

t2i "a sci-fi space station orbiting a ringed planet, digital art" \
  --provider foundry-gpt-image-2

PowerShell Examples

# GPT-Image-1.5: Photorealistic product shot
t2i "professional product photo of a smartwatch on marble, studio lighting" `
  --provider foundry-gpt-image-1p5 `
  --width 1792 `
  --height 1024 `
  --output product-hero.png
# GPT-Image-2: Abstract art for website header
t2i "abstract geometric patterns with vibrant gradients, modern tech aesthetic" `
  --provider foundry-gpt-image-2 `
  --output header-bg.png

Bash Examples

# GPT-Image-1.5: Editorial illustration
t2i "a serene lake at sunrise with mountains in the distance, photorealistic" \
  --provider foundry-gpt-image-1p5 \
  --width 1792 \
  --height 1024 \
  --output editorial.png
# GPT-Image-2: Character concept art
t2i "character concept art of a futuristic knight, armor with neon accents, digital painting" \
  --provider foundry-gpt-image-2 \
  --width 1024 \
  --height 1792 \
  --output character.png

Switching Models

You can set a default provider in your config:

# Use GPT-Image-2 as default
t2i config set default-provider foundry-gpt-image-2
# Now this uses GPT-Image-2
t2i "your prompt here"

Or specify per-command:

# Compare outputs from different models
t2i "a cyberpunk cityscape" --provider foundry-flux2 --output flux-city.png
t2i "a cyberpunk cityscape" --provider foundry-gpt-image-2 --output gpt-city.png

Complete Provider List

Here’s the full lineup after this update:

How to choose:

Model Comparison

Here’s a quick comparison to help you choose:

Feature	FLUX.2 Pro	MAI-Image-2	GPT-Image-1.5	GPT-Image-2
Quality
Speed	~30-40s	~15-20s	~8-12s	~8-12s
Photorealism	Excellent	Good	Excellent	Excellent
Artistic Styles	Good	Excellent	Good	Excellent
Text Rendering	Poor	Fair	Good	Good
Prompt Adherence	Excellent	Very Good	Very Good	Excellent
Custom Sizes	Any size	Any size	Fixed sizes	Fixed sizes
API Type	Async (polling)	Async (polling)	Sync	Sync
Provider	Microsoft Foundry	Microsoft Foundry	Azure OpenAI	Azure OpenAI

Performance notes:

• FLUX.2 and MAI models use asynchronous polling (submit → poll → retrieve)
• GPT-Image models use synchronous API (submit → wait → receive)
• First request may be slower due to model warm-up
• Batch jobs benefit from parallel requests

Migration Guide

If you’re already using t2i with FLUX.2 or MAI-Image-2, upgrading is straightforward.

Step 1: Update the CLI

dotnet tool update --global ElBruno.Text2Image.Cli

Verify:

t2i --version
# Should show v0.16.0 or later

Step 2: List New Providers

t2i providers

You should see:

• foundry-gpt-image-1p5 — GPT-Image-1.5 / DALL-E 3
• foundry-gpt-image-2 — GPT-Image-2 (Next-Gen)

Step 3: Configure GPT Models (Optional)

If you want to use GPT-Image models:

t2i config set foundry-gpt-image-1p5   # Configure GPT-Image-1.5
t2i config set foundry-gpt-image-2     # Configure GPT-Image-2

Step 4: Update Skill Files

If you previously ran t2i init, refresh your skill metadata:

t2i init --force   # Overwrites existing skill files

This ensures GitHub Copilot and Claude Code know about the new models.

Step 5: Test

t2i doctor

Check that all providers show as “configured” and “healthy.”

What’s Next

This release adds major capabilities, but there’s more coming:

v0.17.0+ (Q2 2026):

• Local inference edition — CPU, CUDA, DirectML providers (no cloud required)
• Model marketplace — Download and manage local ONNX models
• Batch API — Submit multiple prompts in one call
• Image-to-image — Use existing images as input for variations

Community-requested features:

• Negative prompts — Specify what not to include
• Style presets — Quick templates (e.g., --style cinematic)
• Config profiles — Switch between dev/prod configurations
• Web UI — Optional browser-based interface

Want to influence the roadmap? File a feature request:

→ github.com/elbruno/ElBruno.Text2Image/issues

Links & Resources

Documentation:

• CLI Tool Reference
• Skill Integration Guide
• GPT-Image-1.5 Setup Guide

Installation:

• NuGet Package
• GitHub Releases

Community:

• GitHub Repository
• Report Issues

Model: GPT-Image-2
Size: 1792×1024 (landscape)
Generation time: ~9.2 seconds
Cost: ~$0.15

This demonstrates GPT-Image-2’s ability to understand abstract concepts (a terminal “emitting” images) and render them with artistic style.

Questions? Feature requests? Found a bug?

→ github.com/elbruno/ElBruno.Text2Image/issues

This blog post was created with the help of AI tools. Yes, I used a bit of magic from language models to organize my thoughts and automate the boring parts, but the geeky fun and the in C# are 100% mine.

Hi!

I just shipped t2i, a terminal-first CLI tool for ElBruno.Text2Image. Generate images from your shell in two commands — no UI, no browser, just a simple cli interface to image generation from the cloud.

This is the Lite edition (cloud-only, ~2.4 MB on NuGet) — perfect for CI/CD pipelines, deployment scripts, batch jobs, and developers who live in the terminal.

Install

Option 1: .NET Tool (recommended)

If you have .NET 8+ installed:

dotnet tool install --global ElBruno.Text2Image.Cli

Then use t2i from anywhere on your machine.

Option 2: Self-Contained Binaries

No .NET? Download pre-built binaries from the release page. Currently available for:

• Windows x64
• Linux x64
• macOS arm64 (Intel coming back soon)

Just extract and run. One file, no dependencies.

First Image in 30 Seconds

Ready to generate? Two commands:

t2i config

This launches an interactive setup wizard (powered by Spectre.Console, so it’s pretty). Pick your provider, enter your API key, and you’re done. The CLI stores everything securely.

Then generate:

t2i "a robot painting a landscape"

That’s it. The image appears in your current directory.

Where Do My Secrets Live?

Short version: t2i config stores credentials securely on your machine — DPAPI-encrypted on Windows, 0600-permissioned file on macOS/Linux. Env vars are for CI only. CLI --api-key is for one-off tests.

For the full resolution chain, CI/CD guidance, and the do/don’t table, see docs/cli-secrets.md.

Providers in Lite

This release ships with two cloud providers on Azure AI Foundry:

More providers (Anthropic, OpenAI) coming in future releases.

Useful Commands

Here’s the CLI cheat sheet:

# List available providers
t2i providers
# Run health checks (config + API connectivity)
t2i doctor
# Show stored secrets (redacted)
t2i secrets list
# Display version + commit SHA
t2i version
# Interactive config setup
t2i config
# Generate with default provider
t2i "a cyberpunk cityscape at night"
# Generate with specific provider, dimensions, and output file
t2i "my prompt" \
  --provider foundry-mai2 \
  --width 1024 \
  --height 1024 \
  --output ./my-image.png
# Show help
t2i --help
t2i generate --help
# Teach your AI agent
t2i init

Switching Models (v0.10.0+)

Both providers support multiple model variants. By default, foundry-mai2 uses MAI-Image-2 and foundry-flux2 uses FLUX.2-pro. To switch models:

# Use MAI-Image-2e
t2i config set foundry-mai2.model MAI-Image-2e
# Use FLUX.2 Flex for text-heavy design and logos
t2i config set foundry-flux2.model FLUX.2-flex
# View your configuration
t2i config show

The config show command displays your endpoint and model in plain text, with only the API key masked. This makes it easy to verify your setup without revealing sensitive credentials.

Teach Your AI Agent — t2i init

Inspired by Aspire’s agent init pattern, t2i now ships with a skill file your AI coding agent can read. Run this in any repo:

t2i init

That writes a SKILL.md to both .github/skills/t2i/ and .claude/skills/t2i/. From that point on, GitHub Copilot, Claude Code, and any MCP-aware agent know:

• Which t2i commands exist and when to use each one
• How to set up secrets safely (env vars first, never commit keys)
• The full provider list and which one to default to
• Common workflows: first-time setup, single image, batch loops

Want only one target?

t2i init --target github   # only .github/skills/t2i/
t2i init --target claude   # only .claude/skills/t2i/
t2i init --force           # overwrite existing skill files

The canonical version of this skill also lives in this repo at .github/skills/t2i/SKILL.md — that means if you open the ElBruno.Text2Image source itself in Copilot or Claude Code, your agent already knows how to drive the CLI.

Coming Soon — Other Platforms

winget

The manifest stub is already in the repo (winget/manifests/E/ElBruno/Text2Image/0.10.0/). First submission to microsoft/winget-pkgs is queued. Automation will come in v0.2.0.

Homebrew

Tap elbruno/elbruno is planned for v0.2.0.

macOS Intel (osx-x64)

GitHub’s macOS-13 runner queue has been a bit slow lately. Intel Mac users should use dotnet tool install for now. The self-contained binary will return once the runners stabilize.

Full Edition (Local GPU)

The Cli.Full edition — supporting local inference with ONNX Runtime (CPU, CUDA, DirectML, NPU) — is coming in a future release. ~200 MB, separate package.

Sample Usages

Here are some fun one-liners to try:

t2i "a cyberpunk taco truck at sunset, cinematic lighting, volumetric fog"
t2i "a low-poly 3D render of a friendly robot waving" --provider foundry-mai2
t2i "minimalist line art of a cat reading a book" --width 1024 --height 1024 --output cat.png
t2i "watercolor painting of the Madrid skyline at dusk, golden hour" --output madrid.png

Tip: The better your prompt, the better the image. Be specific about style (cinematic, watercolor, line art), mood (peaceful, energetic), and composition (wide-angle, close-up). Models reward detail.

Let’s Go

Download it now, run t2i config, and start generating. Found a bug? File an issue.

Links:

•  NuGet: ElBruno.Text2Image.Cli/0.10.0
•  Release: github.com/elbruno/ElBruno.Text2Image/releases/tag/cli-v0.10.0
•  Full Docs: docs/cli-tool.md
•  Hero image prompt: docs/blogs/20260420-introducing-t2i-cli-image-prompt.md
•  Issues: github.com/elbruno/ElBruno.Text2Image/issues

This blog post was created with the help of AI tools. Yes, I used a bit of magic from language models to organize my thoughts and automate the boring parts, but the geeky fun and the in C# are 100% mine.

Hi!

So, I’ve been away from any scenario that involves and needs data mapping, until I get to OpenClawNet. So I got to the point that I need to map my entities to DTOs?

I read this a lot >> runtime reflection doesn’t play nice with AOT and trimming. 

So I SQUAD myselft and built:

 ElBruno.AotMapper

A Roslyn source-generator library that creates all your mapping code at compile time. No reflection. No dynamic IL. Just clean, generated C# that works everywhere — including NativeAOT and trimmed apps.

Note: this is a WIP, so I expect to learn more during my usage. If you find any issue or have any ideas, please drop an issue on the repo, or even better > a PR with some cool fixes / updates!

Let me show you how it works.

Install

Two packages — the core attributes and the generator:

dotnet add package ElBruno.AotMapper
dotnet add package ElBruno.AotMapper.Generator

That’s it. The generator runs during build and creates extension methods for you automatically.

The Simplest Mapping — One Attribute, Done

Let’s start with the basics. You have a Product entity and you need a DTO:

using ElBruno.AotMapper;
public class Product
{
    public int Id { get; set; }
    public string Name { get; set; } = string.Empty;
    public decimal Price { get; set; }
    public ProductCategory Category { get; set; }
    public List<string> Tags { get; set; } = new();
}
public enum ProductCategory { Library, Tool, Framework }
[MapFrom(typeof(Product))]
public partial record ProductDto(int Id, string Name, decimal Price, string Category, List<string> Tags);

See that [MapFrom] attribute? That’s the magic. The generator sees it, matches properties by name, and creates a .ToProductDto() extension method for you.

Now you use it like this:

var product = new Product
{
    Id = 42,
    Name = "ElBruno.AotMapper",
    Price = 0.0m,
    Category = ProductCategory.Library,
    Tags = new List<string> { "aot", "mapper", "dotnet" }
};
var dto = product.ToProductDto();
Console.WriteLine($"Product: {dto.Name} (#{dto.Id})");
Console.WriteLine($"  Category: {dto.Category}");
Console.WriteLine($"  Tags: {string.Join(", ", dto.Tags)}");

I forgot how fun this was > no reflection, no runtime overhead, AOT safe (I think, still checking stuff here)

Remapping Properties with [MapProperty]

What if your source and destination properties don’t have the same name? Easy — use [MapProperty]:

using ElBruno.AotMapper;
public class Customer
{
    public int Id { get; set; }
    public string FirstName { get; set; } = string.Empty;
    public string LastName { get; set; } = string.Empty;
    public string Email { get; set; } = string.Empty;
    public CustomerTier Tier { get; set; }
}
public enum CustomerTier { Standard, Premium, Enterprise }
[MapFrom(typeof(Customer))]
[MapProperty(nameof(Customer.FirstName), nameof(CustomerDto.Name))]
public partial record CustomerDto(int Id, string Name, string Email, string Tier);

Here FirstName on the source gets mapped to Name on the DTO. The generator handles it at build time — zero surprises at runtime.

Minimal API — Full Example

Here’s where it gets fun. Let’s use AotMapper in an ASP.NET Core Minimal API.

First, add the ASP.NET Core integration:

dotnet add package ElBruno.AotMapper.AspNetCore

Then wire it up:

using MinimalApiSample.Models;
using ElBruno.AotMapper.AspNetCore;
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddAotMapper();
var app = builder.Build();
var customers = new List<Customer>
{
    new() { Id = 1, FirstName = "Bruno", LastName = "Capuano",
            Email = "bruno@example.com", Tier = CustomerTier.Enterprise },
    new() { Id = 2, FirstName = "Jane", LastName = "Smith",
            Email = "jane@example.com", Tier = CustomerTier.Premium }
};
app.MapGet("/customers", () => customers.Select(c => c.ToCustomerDto()));
app.MapGet("/customers/{id}", (int id) =>
{
    var customer = customers.FirstOrDefault(c => c.Id == id);
    return customer is null ? Results.NotFound() : Results.Ok(customer.ToCustomerDto());
});
app.Run();

All the magic in the endpoing handlers with > c.ToCustomerDto() (that’s the generated extension method)

EF Core — In-Memory Mapping and SQL Projections

If you’re using Entity Framework, there’s a package for that, and I have some samples in the repo (I think I can do more here … I didn’t have time yet for this)

More Attributes You Should Know

The library has a few more tricks:

And for custom converters, you implement IMapConverter<TSource, TDestination>:

public class UpperCaseConverter : IMapConverter<string, string>
{
    public string Convert(string source) => source.ToUpperInvariant();
}

How It Works Under the Hood

The flow is simple:

1. You add [MapFrom] (or [MapTo]) to your DTO
2. During build, the Roslyn incremental source generator kicks in
3. It matches source and destination properties by name and type
4. It generates strongly-typed extension methods (like .ToProductDto())
5. If something doesn’t match, you get a compile-time error — not a runtime surprise

That’s the whole point: move the errors to build time, move the mapping to generated code, and keep the runtime clean.

Samples

The repo includes three complete samples you can run right now:

•  NativeAotSample — Basic mapping in a NativeAOT console app
•  MinimalApiSample — ASP.NET Core Minimal API with DI
•  EfProjectionSample — EF Core with in-memory and SQL projections

Resources

•  NuGet: ElBruno.AotMapper
•  GitHub: github.com/elbruno/ElBruno.AotMapper
•  Docs: Quick Start | Supported Mappings | EF Integration
•  License: MIT

This blog post was created with the help of AI tools. Yes, I used a bit of magic from language models to organize my thoughts and automate the boring parts, but the geeky fun and the in C# are 100% mine.

Hi!

When Microsoft announced MAI-Image-2, I immediately thought: “I need to add this to ElBruno.Text2Image. Today.”

So I did.

MAI-Image-2 is Microsoft’s new image generation model on Microsoft Foundry — high-quality generation, a synchronous API (no polling!), a 32K character prompt limit, and flexible dimensions. And it’s already supported in ElBruno.Text2Image with the same clean interface you already know.

Let me show you how it works.

Getting Started — MAI-Image-2 on Azure AI Foundry

MAI-Image-2 delivers high-quality image generation with a simpler developer experience than FLUX.2. The API is synchronous — you send a request, you get an image back. No 202 status codes, no polling loops, no waiting callbacks. Just a prompt and a picture.

Here’s all you need:

using ElBruno.Text2Image;
using ElBruno.Text2Image.Foundry;
using var generator = new MaiImage2Generator(
    endpoint: "https://your-resource.services.ai.azure.com",
    apiKey: "your-api-key",
    modelId: "MAI-Image-2");
var result = await generator.GenerateAsync(
    "a futuristic cityscape with neon lights, cyberpunk style");
await result.SaveAsync("mai-image2-output.png");
Console.WriteLine($"Generated in {result.InferenceTimeMs}ms");

Setting up credentials

The library reads from User Secrets, environment variables, or appsettings.json. For local development:

dotnet user-secrets set MAI_IMAGE2_ENDPOINT "https://your-resource.services.ai.azure.com"
dotnet user-secrets set MAI_IMAGE2_API_KEY "your-api-key-here"
dotnet user-secrets set MAI_IMAGE2_MODEL_ID "MAI-Image-2"

 Fun fact: MAI-Image-2 uses a dedicated /mai/v1/images/generations endpoint. The library handles this automatically — just provide your .services.ai.azure.com base URL and it builds the correct API path for you.

Key Differences from FLUX.2

If you’re already using FLUX.2 with this library, here’s how MAI-Image-2 compares:

Feature	MAI-Image-2	FLUX.2
API style	Synchronous (direct response)	Asynchronous (202 + polling)
API path	/mai/v1/images/generations	BFL provider path
Prompt limit	32,000 characters	~1,000 characters
Min dimensions	768px (per side)	256px
Max dimensions	1M total pixels	Model-dependent
Interface	IImageGenerator	IImageGenerator
DI support	Same pattern	Same pattern
Endpoint auto-conversion

The synchronous API is a big deal for developer experience. No more writing polling loops or handling intermediate states. Send a prompt, get an image. Done.

Same Interface, Multiple Backends

Microsoft.Extensions.AI Compatible

Every generator in the library — including the new MaiImage2Generator — implements the standard Microsoft.Extensions.AI.IImageGenerator interface from the
Microsoft.Extensions.AI.Abstractions package. This means you can use ElBruno.Text2Image as a drop-in provider anywhere the MEAI abstraction is expected — dependency
injection, middleware pipelines, or any framework that programs against IImageGenerator. Cloud or local, FLUX.2 or MAI-Image-2 or Stable Diffusion — they all plug
into the same standard .NET AI contract.

// MAI-Image-2 (cloud)
IImageGenerator generator = new MaiImage2Generator(endpoint, apiKey, modelId: "MAI-Image-2");
// FLUX.2 Pro (cloud)
IImageGenerator generator = new Flux2Generator(endpoint, apiKey, modelId: "FLUX.2-pro");
// Stable Diffusion 1.5 (local)
IImageGenerator generator = new StableDiffusion15();
// Same API for all three
var result = await generator.GenerateAsync("a beautiful landscape");

Dependency Injection

If you’re building with DI, the library has an extension method ready to go:

services.AddMaiImage2Generator(
    endpoint: "https://your-resource.services.ai.azure.com",
    apiKey: "your-api-key",
    modelId: "MAI-Image-2");

Same pattern as the FLUX.2 registration. Inject IImageGenerator and you’re done.

Links

• Repository: github.com/elbruno/ElBruno.Text2Image
• NuGet: nuget.org/packages/ElBruno.Text2Image.Foundry
• MAI-Image-2 Announcement: Introducing MAI-Image-2
• Setup Guide: MAI-Image-2 Setup Guide
• v0.8.0 Release: github.com/elbruno/ElBruno.Text2Image/releases/tag/v0.8.0

This blog post was created with the help of AI tools. Yes, I used a bit of magic from language models to organize my thoughts and automate the boring parts, but the geeky fun and the in C# are 100% mine.

The Microsoft Bing Search team just dropped something big:

https://blogs.bing.com/search/April-2026/Microsoft-Open-Sources-Industry-Leading-Embedding-Model

They’ve open-sourced a new set of high-quality embedding models, designed to be competitive with state-of-the-art approaches — and ready to run in modern AI workflows.

And here’s the fun part

You can already use these models from C#/.NET.

From Announcement to .NET in Minutes

I integrated these new models into a C# library:

https://www.nuget.org/packages/ElBruno.LocalEmbeddings.Harrier

Now you can:

• Run embeddings locally
• Use Bing’s open models
• Plug into your .NET apps

A Personal Take: Multilingual FTW

Harrier shines with multilingual support.

You can embed content like:

• “Hello world!”
• “Hola mundo!”

…and still get meaningful semantic relationships — out of the box.

Perfect for global-ready AI apps

.NET + AI Ecosystem

You can combine this with:

• Foundry Local or Ollama for local AI
• Microsoft Foundry for cloud
• Microsoft Agent Framework for agents

Getting Started

https://www.nuget.org/packages/ElBruno.LocalEmbeddings.Harrier

using ElBruno.LocalEmbeddings.Harrier;

await using var generator = await HarrierEmbeddingGenerator.CreateAsync();

var embeddings = await generator.GenerateAsync(["Hello world!", "Hola mundo!"]);
Console.WriteLine($"Dimensions: {embeddings[0].Vector.Length}"); // 640

Samples:

https://github.com/elbruno/elbruno.localembeddings/tree/main/samples/HarrierConsoleApp
https://github.com/elbruno/elbruno.localembeddings/tree/main/samples/HarrierMultilingualSample

This blog post was created with the help of AI tools. Yes, I used a bit of magic from language models to organize my thoughts and automate the boring parts, but the geeky fun and the in C# are 100% mine.

Hi!

Earlier this year, Andrej Karpathy tweeted about using LLMs as “knowledge compilers” — a mind-bending idea: instead of asking an LLM questions, feed it raw data (papers, code, images) and let it automatically build a structured, navigable knowledge base. No RAG. No vector databases. Just pure understanding compiled into a graph.

Then I saw @socialwithaayan showcase graphify — a Python tool that does exactly this for codebases. It reads your source code, extracts relationships, builds a knowledge graph, and exports it as an interactive visualization, Obsidian vault, Neo4j script, or JSON.

I thought: “This needs to exist in .NET.”

So I built graphify-dotnet.

What is graphify-dotnet?

graphify-dotnet is a .NET 10 tool that reads your codebase — all those files scattered across folders, all that implicit structure hidden in class hierarchies and imports — and transforms it into a visual knowledge graph. No more navigating by keyword search. Instead, you see the actual structure: which classes talk to each other, which modules form natural clusters, which functions are the “god nodes” that everything depends on.

It’s a multi-stage pipeline:

┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
│  Detect  │ -> │ Extract  │ -> │  Build   │ -> │ Cluster  │
│  Files   │    │ Features │    │  Graph   │    │ (Louvain)│
└──────────┘    └──────────┘    └──────────┘    └──────────┘
                                                     │
                                                     v
┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
│  Export  │ <- │  Report  │ <- │ Analyze  │ <- │ Clustered│
│ Formats  │    │Generator │    │  Graph   │    │  Graph   │
└──────────┘    └──────────┘    └──────────┘    └──────────┘

Scan → Extract relationships → Build the graph → Find communities → Analyze structure → Export to multiple formats.

Let’s See It in Action

Here are some real commands you can run right now:

Build a knowledge graph from your project:

dotnet run --project src/Graphify.Cli -- run .

Query the graph for connections:

dotnet run --project src/Graphify.Cli -- query "what connects AuthService to Database?"

Explain a node:

dotnet run --project src/Graphify.Cli -- explain "UserController"

Export to multiple formats:

dotnet run --project src/Graphify.Cli -- export --format html
dotnet run --project src/Graphify.Cli -- export --format neo4j

The HTML export gives you an interactive vis.js graph. Click nodes, search by concept, filter by community. The Neo4j export lets you load the entire graph into a real graph database.

Key Features

• Multi-language parsing: Python, TypeScript, JavaScript, Go, Rust, Java, C#, C++, and more via tree-sitter AST extraction
• Hybrid extraction: Deterministic AST parsing + AI semantic analysis for docs and images
• Graph clustering: Louvain community detection so you can see natural groupings in your architecture
• Confidence tracking: Every relationship tagged as EXTRACTED, INFERRED, or AMBIGUOUS
• Multiple export formats: JSON, HTML, SVG, GraphML, Wiki, Obsidian vault, Neo4j Cypher
• SHA256 caching: Skip unchanged files — incremental updates instead of full rebuilds
• MCP server: Integrate with Claude, Copilot, and other AI assistants
• Multimodal: Handles code, Markdown, PDFs, and images (diagrams, screenshots, whiteboards)