Local AI on Windows: what ships, and how to run a coding agent
Windows has a native local AI stack: Windows ML, Foundry Local, and the Windows AI APIs around Phi Silica. None of them is a portable coding-agent runtime with a manifest, a lock, and evidence. oloop's supported path on Windows today is WSL2 plus a Linux setup; native oloop support and a qualified Foundry Local endpoint are not built or measured.
What Windows ships
Microsoft ships 3 layers, and the names are easy to confuse.
| Layer | What it is | Interface | What it is not |
|---|---|---|---|
| Windows ML | The OS inference framework, built on ONNX Runtime; CPU, GPU, and NPU execution; an experimental GGUF path. | App API and execution providers. | Not an agent runtime, not a model catalog, and not an endpoint by itself. |
| Foundry Local | Microsoft's local runtime and SDK, with curated models and automatic acceleration that varies by OS and device. It can expose an OpenAI-compatible local server. | SDK, plus an optional local server. | Not a multi-user server stack, and it has no manifest, lock, or evidence layer. |
| Windows AI APIs / Phi Silica | Ready-to-use app APIs, with Phi Silica as a local language model under a Limited Access Feature, mostly on Copilot+ PCs. | App API. | Not a general OpenAI endpoint for a CLI coding agent. |
Sources: Windows ML, Foundry Local, Windows AI overview, and Phi Silica on Microsoft Learn.
What the stack leaves out
The layers handle inference. An agent also needs a pinned configuration, a harness that behaves the same on another machine, a lock, checksums, evidence, and one root you can remove. oloop adds those, and it does not replace the runtime underneath.
| Concern | Windows native stack | oloop |
|---|---|---|
| Runtime | Windows ML, Foundry Local, Phi Silica | References the runtime; does not replace it |
| Model catalog | Curated in Foundry Local | Setup catalog with pins and evidence |
| Acceleration | Chosen by the runtime and device | Recorded in the qualification, not assumed |
| API shape | Local server (Foundry Local) | A manifest, not an API |
| Harness portability | Not addressed | One pinned harness under the root |
| Lock | Not addressed | oloop.lock pins host, harness, and model |
| Checksums | Not addressed | The bundle and model rows carry digests |
| Evidence | Not addressed | A qualification record per machine class |
| One root | Not addressed | Everything under one root you choose |
| Removal | App and OS managed | Remove the root; oloop remove stops its hosts |
The 3 paths, and which one works today
One path is supported today.
| Path | Status | What is missing or unqualified |
|---|---|---|
| WSL2 + oloop + a Linux CPU or L4 setup | Supported. Measured Linux evidence. | GPU passthrough is expected to fit; we have not qualified it. |
| Windows + Foundry Local + oloop as a referenced endpoint | Experimental. Not qualified. | Native oloop install, harness provisioning, endpoint reachability from WSL2 or Windows, and an immutable model identity for a lock. |
| Windows AI APIs / Phi Silica | Not a fit for a CLI coding agent. | App-level APIs and a Limited Access Feature, not a general endpoint. |
The WSL2 path
WSL2 runs a Linux distribution under Windows. Install it, install the CLI inside the distribution, then use the Linux x64 CPU setup. This assumes an x64 Windows host; Windows on ARM is a different path that we have not qualified.
The Linux setup is an explicit setup, not the no-arg bootstrap. It runs on the OS its catalog entry declares, and it passes the same RAM and disk checks as any other Linux x64 machine.
wsl --install
curl -fsSL https://oloop.run/install.sh | sh
oloop host start --setup linux-x64-cpu@1.2.2
oloop host openNPU, GPU, and CPU are different measurements
NPU TOPS is not a coding benchmark. It measures an accelerator's peak arithmetic rate for the operations it supports, not how a 7B coding model behaves with a context window, a harness, and a tool loop. A model that size wants RAM and memory bandwidth before it wants a TOPS number.
Foundry Local picks an execution provider for the device it runs on. That is not the same thing as Ollama or llama.cpp using the NPU; they are different runtimes with different supported paths. We make no TOPS or tokens-per-second claim.
Foundry Local is a client runtime
Foundry Local is optimized for single-user client devices. It can serve a model to an app on the same machine, which is useful. It is not a multi-user server stack: there is no tenant model, no shared runtime control, and no evidence layer for a team.
For a team or a server, the measured path is the self-hosted guide and the L4 page.
What Windows does not have yet
There is no native oloop install for Windows, and no Windows setup in the catalog. A Foundry Local endpoint is not qualified either. oloop does not run natively on Windows today.
A native path needs a Windows build, a catalog entry, and a measured run. None of the 3 exists yet, so WSL2 is the supported route.
Facts about Windows, Foundry Local, and Phi Silica were verified 2026-10-20 against Microsoft Learn. They are re-checked quarterly; a changed source becomes an edit or a removed claim.
Install
Install the CLI, then pick the setup for your machine class.
curl -fsSL https://oloop.run/install.sh | shQuestions
Can I run oloop natively on Windows?
No. There is no native Windows install, and the catalog has no Windows entry. The supported path is WSL2 plus a Linux x64 setup.
Can oloop use Foundry Local as its model endpoint?
Not as a qualified path. Foundry Local can expose an OpenAI-compatible local server, and a referenced endpoint still needs a native install, harness provisioning, reachability, and a lockable model identity. We have not measured those.
Is Phi Silica a coding-agent endpoint?
No. It is an app-level API for apps on Copilot+ PCs, and it is not something a CLI coding agent can call.
Does an NPU make a coding model faster?
TOPS does not answer that. A coding run also depends on memory capacity, memory bandwidth, the model, the quantization, and the runtime's supported execution path.
Which Windows path should I use today?
WSL2 with the Linux x64 CPU setup. With a GPU, the L4 path is measured on Linux hardware, and GPU passthrough from Windows is not qualified.