Foundry Local Chat by Senssei

Adds your locally-downloaded Foundry Local models to the VS Code chat model picker. No cloud, no API key, no per-token cost — prompts never leave the machine.

Works with the foundry CLI and with the AI Toolkit, which serve the same /v1 API. Models are shown in separate Foundry Local CLI and Foundry Toolkit groups.

Install

npm install
npm run package
code --install-extension foundry-local-chat-provider-0.1.1.vsix

Then reload the window. Foundry Local appears as its own group in the model picker.

The Foundry Toolkit group is discovered independently at its default http://127.0.0.1:5272 or http://localhost:5272 endpoint. Start the Toolkit local server before refreshing the model picker. The CLI daemon's random endpoint is not used as a Toolkit endpoint.

Press F5 instead to run it from source in the Extension Development Host.

Prerelease

Build a Marketplace prerelease VSIX without publishing it:

npm test
npm run package:pre-release

To publish the prerelease after setting VSCE_PAT:

npm run publish:pre-release

Getting a model

foundry model download qwen2.5-0.5b

Or run Foundry Local: Manage Models from the command palette, which lists the catalog and shells out to the CLI for the download.

Only downloaded chat models show up in the picker — Whisper and embedding models are filtered out, and there's no point offering a 12 GB download from a dropdown.

Settings

All settings are machine-scoped, so a cloned repo can't point the extension at a different endpoint or executable.

The picker shows 12K context for a default install: VS Code displays maxInputTokens + maxOutputTokens.

Platform notes

Foundry Local runs on Windows, macOS (Apple silicon) and Linux, and so does this extension. Three things differ by platform:

• Windows — the CLI is resolved as foundry.exe first, then the .cmd/.bat shims. Since Node 18.20 a .cmd can't be spawned without shell: true, so shim installs go through a shell with every argument quoted, and model ids are validated against [A-Za-z0-9._:-]+ before they get there. After winget install, VS Code keeps its old PATH until restarted — restart it, or set foundryLocal.cliPath.
• Linux — there's no package manager recipe; grab the Linux asset from the releases page. You can also skip the CLI entirely and set foundryLocal.endpoint, though then nothing can load a model on demand.
• All platforms — the AI Toolkit fallback probes port 5272 on both 127.0.0.1 and localhost, because a dual-stack box may resolve localhost to ::1 while the server only listens on IPv4.

Troubleshooting

The two providers are independent:

• Foundry Local CLI uses foundry server status and the random port reported by the CLI.
• Foundry Toolkit uses only http://127.0.0.1:5272 or http://localhost:5272.

If Foundry Toolkit is missing from the model picker, its server is not responding at either Toolkit endpoint. VS Code hides providers that return no models. Start the Toolkit local server, confirm that GET http://127.0.0.1:5272/v1/models returns a model list, and refresh the picker. Seeing Microsoft Foundry via Foundry Toolkit in the picker is a separate built-in provider; it does not mean this extension's Toolkit endpoint is running.

Development

npm test            # unit — SSE framing, tool-call reassembly, message mapping, shell quoting
npm run live        # HTTP end-to-end against a running daemon
npm run integration # full end-to-end through vscode.lm in a real extension host
node scripts/make-icon.mjs   # regenerate icon.png

npm test is the one that runs in CI on all three OSes; the other two need a local daemon with a model downloaded.

Running the tests from a terminal inside VS Code works — runTest.ts strips the inherited ELECTRON_RUN_AS_NODE and VSCODE_* variables that would otherwise make the child VS Code boot as plain Node and die with bad option: --disable-extensions.

On Linux CI, npm run integration needs a display: xvfb-run -a npm run integration.

How it talks to the daemon

Verified against CLI 0.10.3. Two things differ from the published REST reference, which still documents an older server — worth knowing if you're extending this:

• Only /v1/* and /status exist. /openai/* and /foundry/list return 404, so the catalog, downloads and model loading all go through the CLI. /v1/models is used for the model list because it also works against an AI Toolkit server with no CLI present; the CLI then enriches it with supportsToolCalling, which the HTTP route omits.
• Asking for a model that isn't resident returns 200 + an empty event stream that then drops the socket, with no error payload at all. So an empty stream is the only available signal: the extension treats it as "not loaded", loads the model, and retries once. That retry is guarded on nothing having been emitted yet, so a stream that fails half-way through never duplicates output.

There's no tokenizer endpoint on this build (/v1/chat/completions/tokenizer/encode/count 404s), so countTokens is the usual 4-characters-per-token estimate.

The daemon binds a fresh random port on every start, which is the main reason to use this rather than Copilot Chat's built-in OpenAI-compatible BYOK option. If you pin the port (foundry server start --port 39839 --idle-timeout 0) and only ever use one model, BYOK covers it without an extension.

Not implemented

• Image input — reported as false; add it when a vision model reaches the catalog.
• Embeddings and transcription — this is a chat provider; Whisper models are filtered out.
• Real per-model context lengths — Foundry Local doesn't publish them, hence the setting.
• Tool calling verified against a live model — the wire format is unit-tested and tools is accepted by the daemon, but qwen2.5-0.5b is too small to actually emit a call. Worth re-checking with a 7B before relying on agent mode.

Trademarks

Not affiliated with or endorsed by Microsoft. "Foundry Local" and "Azure AI Foundry" are Microsoft trademarks, used here only to say what this extension connects to. The icon is an original mark, not a derivative of Microsoft's.

License

MIT