Docker Model Runner vs Foundry Local

Docker Model Runner

CI passes on the main branch, and Docker has published two security advisories with CVEs and fixed versions for the project. The API takes no credential, so any client or container that reaches it can pull, delete and run models, and the documentation has no OpenAPI file or error reference.

Foundry Local

The SDK and its native runtime are MIT, at 2.1.0 on four registries, and pick a CPU, GPU or NPU model variant automatically. The optional local server has no credential, its current routes aren't in the published REST reference, and telemetry is on by default with an opt-out.

Docker Model Runner

1. Use base URL http://localhost:12434/engines/v1 for OpenAI clients and http://localhost:12434 for Anthropic and Ollama clients. Any API key value is accepted
2. In Docker Desktop, run docker desktop enable model-runner --tcp 12434 first. Host-side TCP is off by default
3. From a container, call http://model-runner.docker.internal on Docker Desktop or http://172.17.0.1:12434 on Docker Engine
4. Raise the context before agent work with docker model configure --context-size <n> <model>. The llama.cpp default is 4,096 tokens
5. Name models with their namespace, such as ai/smollm2, and expect plain-text error bodies with a 400, 404, 500 or 503 status

Foundry Local

1. Read the server URL from manager.urls[0] or foundry server status. The port is dynamic unless the owner sets web.urls or foundry server start --port
2. Send the model ID that GET /v1/models returns, not the alias. The alias resolves to a hardware-specific variant
3. Check supportsToolCalling before sending tools. Support differs by variant, and issue #1183 reports Qwen tool calling failing on QNN
4. Set your own request timeout. Inference has no built-in one, and cancellation takes effect only after the current generation step
5. Ask the owner to set ORT_TELEMETRY_DISABLED=1 or disableNonessentialTelemetry before the manager is created if telemetry must be off