vLLM updates land weekly. Your Mac agent does not need to notice.

Three releases in a 14-day window. v0.18.0 landed in late March 2026 with gRPC serving behind the new --grpc flag, GPU-based NGram speculative decoding, and a new KV cache offload backend named FlexKV. v0.19.0 landed on April 2 with day-one Gemma 4 support across E2B, E4B, 26B MoE, and 31B Dense, plus async scheduler on by default and Model Runner V2. v0.19.1rc0 followed on April 3 as a release candidate. That is a tight cadence by any standard. If you run vLLM as the backend for a desktop agent, you will be upgrading often in 2026.

Nothing. The client side is a single string in UserDefaults under the key customApiEndpoint. Fazm's ACP bridge reads that value at spawn time inside Desktop/Sources/Chat/ACPBridge.swift lines 379 to 382 and exports it as ANTHROPIC_BASE_URL on the Node subprocess. vLLM changes behind that URL, the bridge does not. When you run pip install -U vllm on the server and restart the server process on the same port, Fazm keeps working with no app update, no recompile, no Settings change.

Yes, with a caveat. The Fazm UI keeps the conversation history alive in the app. The bridge process gets torn down and respawned lazily on the next query, which is what restartBridgeForEndpointChange() at Desktop/Sources/Providers/ChatProvider.swift lines 2101 to 2106 does. The caveat is that any streaming token generation in progress at the moment you bounce the vLLM server dies with the old connection, as you would expect from any long-lived HTTP stream. Restart the vLLM server between user turns, not mid-response.

restartBridgeForEndpointChange(), an async Swift method on ChatProvider. It guards on acpBridgeStarted so it is a no-op if the bridge never started. It reads customApiEndpoint from UserDefaults, writes a log line naming the new endpoint for debuggability, calls await acpBridge.stop(), flips acpBridgeStarted to false, and returns. That is it. The bridge then respawns on the next outgoing query, re-reading UserDefaults at spawn time. It is deliberately small. Most of the complexity of safe endpoint-swapping lives in the stop-and-respawn model, not in the function itself.

One helps, one does not. gRPC is server-to-server and matters when vLLM sits behind a shared gateway for a fleet. For a single laptop routing through a single vLLM process, vanilla OpenAI-compatible HTTP is fine and you will see no difference. The async scheduler matters. It overlaps engine scheduling with GPU execution, so time-to-first-token drops. On an agent that emits tool calls in a loop, lower TTFT compounds: the UI feels snappier because each tool-call round trip is shorter. Turning it on is now the default, so most users will get this by upgrading and doing nothing else.

Indirectly. CVE-2026-0994 was a deserialization issue in vLLM's Completions API prompt_embeds handling. Fazm does not call vLLM's Completions endpoint directly; it goes through an Anthropic-to-OpenAI shim that usually translates to /v1/chat/completions, which has a different surface. You should still upgrade the vLLM server to a patched v0.19.x build. Never treat 'I use a different endpoint than the vulnerable one' as a substitute for patching.

The 26B MoE variant is the interesting one. MoE active-parameter cost with dense-style reasoning quality is a sweet spot for self-hosted agent workloads, especially for structured tool use. The E4B effective-4B variant is small enough to run on a single consumer GPU and strong enough to drive a responsive agent. Fazm is model-agnostic at the protocol level: it speaks Anthropic Messages on the client, an OpenAI-compatible shim translates, and vLLM serves whatever is behind it. Gemma 4 is not special from Fazm's side, it is just a better point on the cost/quality curve than what you had in March.

Five commands. On the server: pip install -U vllm. Stop the vllm serve process cleanly. Start it again with the same model and same port. Verify with a single curl to /v1/models. Return to Fazm and continue the conversation. If your shim is running in the same venv as vLLM, restart the shim too. If the shim is a separate service, it does not need to be touched unless the OpenAI API surface it depends on changed, which almost never happens patch-to-patch in vLLM.

Three files. Desktop/Sources/Chat/ACPBridge.swift lines 379 to 382, the four-line read of customApiEndpoint from UserDefaults and the export as ANTHROPIC_BASE_URL. Desktop/Sources/MainWindow/Pages/SettingsPage.swift lines 906 to 952, the Settings card titled 'Custom API Endpoint' with placeholder https://your-proxy:8766. Desktop/Sources/Providers/ChatProvider.swift lines 2101 to 2106, the six-line restart function. CHANGELOG.json dated 2026-04-11 records the release (v2.2.0) that first shipped the Custom API Endpoint setting. The full tree is MIT-licensed at github.com/mediar-ai/fazm.

It does not hard-code one. acp-bridge/src/index.ts line 1245 declares DEFAULT_MODEL = 'claude-sonnet-4-6' as a warmup seed, but when you send a message the bridge uses whatever the app passes as msg.model or falls back to DEFAULT_MODEL if nothing is set. In the Anthropic-to-OpenAI shim in front of vLLM, model names are translated (sonnet goes to whatever you configured, for example a Gemma 4 26B MoE checkpoint). The Fazm side cares about the Messages API shape, not the model string.

Because vLLM is server infrastructure and its audience is ML ops. Every mainstream release notes page is written for people operating inference clusters. The question 'what do I rebuild on my desktop when I run pip install -U vllm on my server' is asked by agent builders, not platform operators. Those audiences read different pages. This guide is the overlap: vLLM's 2026 release cadence, read through the lens of a consumer Mac agent whose source tree has a six-line function saying 'the answer is nothing'.