AI Dev Gallery: Microsoft's Sample Browser for Local AI on Windows

The gap AI Dev Gallery fills for Windows developers

Adding a local model to a Windows app usually starts the same way: find a model, work out which runtime loads it, wire up tokenization, then discover your machine cannot run it at a usable speed. AI Dev Gallery compresses that loop. It is a WinUI 3 desktop application that ships over 25 interactive samples, each paired with the C# source that drives it. You browse a sample, pick a model, run it, and read the code that made it work.

The audience is narrow and stated plainly. The README says the project is "Designed for Windows developers." The stack assumes C#, Visual Studio 2022 or later, and the Windows App SDK. If you write Windows apps in C# and want to evaluate local inference without assembling a toolchain first, this is aimed at you. If you write Python or target a server, the samples are still readable, but the export path produces Visual Studio projects you cannot use.

The repository topics sketch the surface area: onnxruntime, onnxruntime-genai, directml, qnn, phi3, mistral, whisper, stable-diffusion, npu. That is a broad set of runtimes and model families under one shell, which is the actual value. You are not learning one vendor's API. You are comparing how the same class of task looks across several.

How the samples, model downloads and export actually fit together

The gallery is a host application, not a library. Samples live inside the app; the README describes them as interactive samples powered by local AI models, with the C# source viewable in place. Models are not bundled. The app browses, downloads and runs models from Hugging Face and GitHub, and the README confirms offline use works only after a model has been downloaded locally.

That gives a two-stage data flow. First, a sample declares the model it needs, and the gallery fetches it to local storage. Second, the sample loads that model through one of the runtimes named in the repository topics and runs inference on your machine. Nothing is sent to a hosted endpoint for the local-model path, which is why the app functions without a connection once the weights are on disk.

The export step is the part with the most consequence. The README states you can export a sample as a Visual Studio project and run it independently, and that a model downloaded through the app can then be used by that exported project. So the gallery is a scaffold generator as much as a demo browser. The repository layout supports this reading: the solution splits into AIDevGallery, AIDevGallery.Utils, AIDevGallery.SourceGenerator, AIDevGallery.Tests and AIDevGallery.Fuzz, with Directory.Build.props and Directory.Packages.props centralizing build and package versions. A source generator in the tree suggests sample metadata is generated rather than hand-maintained, which is how a catalog of this size stays consistent.

One design choice worth flagging: the app is required to run any sample, per the README FAQ. You cannot point a script at a sample and run it headless. Everything routes through the GUI.

Installing AI Dev Gallery and exporting your first sample

There are two install paths. The fastest is the Microsoft Store, linked from the README. The manual path needs Visual Studio 2022 or later with the Windows application development workload, and Windows 10 version 1809 (build 17763) or newer to run.

Start by cloning the repository and opening the solution. The README uses this exact command:

git clone https://github.com/microsoft/AI-Dev-Gallery.git

Open AIDevGallery.sln in Visual Studio, confirm that the AIDevGallery project is set as the startup project, and press F5. That is the whole build. If you are on an ARM64 Copilot+ PC, the README is explicit that you must build and run the solution as ARM64 and not x64, particularly for samples that talk to models such as Phi Silica. Getting this wrong is the most likely first failure.

Once the app is running, pick a sample, let it download its model, and run it. When you want the code out, export the sample as a Visual Studio project. The README notes the exported project can run independently once the model has been downloaded through the app. Treat that exported project as the real deliverable: it is the thing you will modify.

Before any of this, check the machine. The README recommends at least 16 GB of memory, at least 20 GB of free disk space, and 8 GB of VRAM for running samples on the GPU. Those are recommendations, not hard gates, but a machine below them will run some samples and not others.

Where AI Dev Gallery stops being the right tool

The public preview label is not decorative. There are no retrieved releases, so the project is consumed from the repository rather than from versioned packages. If your team needs a pinned artifact with a changelog, this is not that yet.

The platform boundary is absolute. Windows only, x64 or ARM64. The README lists no Linux or macOS path, and the UI is WinUI 3, so the sample shell does not port. A cross-platform team gets reference C# and nothing runnable.

The hardware requirements are the quiet constraint. 16 GB of RAM and 20 GB of disk are recommendations, and model weights are large. On a laptop with 8 GB, several samples will simply not be viable, and the gallery will not tell you that until you try. GPU samples want 8 GB of VRAM, which excludes most integrated graphics.

There is also a coupling problem in the export path. The README confirms a model downloaded through the app can be used by an exported project, which implies the exported code still expects that local model layout. Move the project to another machine and you re-download. And because the app is required to run any sample, you cannot use the gallery as a headless test harness in CI.

Finally, telemetry. The README states the application logs basic telemetry and points at the Microsoft privacy statement. If you work somewhere that treats outbound telemetry as a review item, that is a fact to record before rollout, not after.

How it compares with ONNX Runtime samples and Semantic Kernel

The closest alternative is going straight to the ONNX Runtime GenAI samples. Those give you a minimal, single-purpose program: load a model, generate tokens, print them. The difference is scope. ONNX Runtime samples assume you already know which model and which execution provider you want. AI Dev Gallery inverts that by making model selection part of the interface, so you can try Phi, Mistral, Whisper or Stable Diffusion in the same shell before you commit. The cost is that the gallery carries a full WinUI application around each sample, which is more code to strip out when you export.

Semantic Kernel sits at a different layer. It is an orchestration library for calling models, plugins and planners from your own application, and it is not a sample browser. If your question is "how do I structure an agent loop," Semantic Kernel answers it. If your question is "which local model can this laptop actually run for image generation," the gallery answers it and Semantic Kernel does not. They are complementary rather than competing, and the gallery's samples are the faster way to find out whether you need the orchestration layer at all.

A third option is writing the interop yourself against the runtime named in the topics. That gives full control and no preview dependency. It also means you own tokenizer handling and model download logic, which is exactly the work the gallery has already done for 25-plus cases.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-09, so the project is being worked on. That matters more than usual here because the app is in public preview and there are no retrieved releases, which means there is no versioned upgrade path to reason about. You track main, or you pin a commit and accept that the samples around it move.

Upgrade cost concentrates in two places. The solution pins package versions through Directory.Packages.props and build settings through Directory.Build.props, so a pull that changes either file can shift the runtime versions under every sample at once. And because the app downloads models at runtime rather than bundling them, an upstream model removal on Hugging Face or GitHub breaks a sample without any change in this repository. Neither risk is documented with a rollback procedure; the README does not describe one.

The licence is MIT, which is permissive and permits commercial use and modification. Two things sit outside that grant and are worth reading in full rather than skimming. The README's trademark section states that use of Microsoft trademarks must follow Microsoft's Trademark & Brand Guidelines and that modified versions must not imply Microsoft sponsorship. Separately, contributions require a Contributor License Agreement. Model weights you download are governed by their own licences on Hugging Face or GitHub, not by this repository's MIT licence, and the README does not enumerate them. That last point is the one to resolve before shipping anything, and it is a question for your own legal review, not one this article can answer.

Editorial conclusion

Adopt AI Dev Gallery if you are a Windows developer who wants runnable C# reference code for local models before committing to an architecture, and if you have a machine with 16 GB of RAM and roughly 20 GB of free disk space. Skip it if you target Linux, macOS, or the web, or if you need a stable API surface rather than a preview app. Before you build anything on top of it, verify three things: that your CPU architecture matches the build configuration you need (ARM64 Copilot+ PCs must build as ARM64, not x64), that the specific model a sample depends on is still downloadable, and that the exported project still compiles outside the gallery after you remove the sample-hosting code. The gallery is a starting point you copy from, not a runtime you ship.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. microsoft/ai-dev-gallery on GitHub
4. README