vLLM release notes, April 2026. Your Mac still can't run any of them.

Three releases inside roughly two weeks. v0.18.0 added gRPC serving and GPU NGram speculative decoding as a stable feature. v0.19.0 arrived with day-one Gemma 4 support across E2B, E4B, 26B MoE, and 31B Dense variants, and it flipped the async scheduler on by default, which lowers time-to-first-token for most workloads. v0.19.1rc0 shipped the next day as a release candidate with small fixes. The practical story is that vLLM kept pace with the open-weight model wave so the newest checkpoints were servable the moment they landed.

Not comfortably, and not the way you run Ollama or LM Studio. vLLM is CUDA-first. The project has experimental CPU and Apple Silicon paths but the performance story, and therefore every vLLM release note, is written for NVIDIA GPUs. If you searched for vLLM April 2026 release notes from a Mac hoping to upgrade your local setup, the honest answer is that you should run vLLM on a Linux box with a GPU and talk to it over the network, or run Ollama or LM Studio on your Mac instead.

Because the model throughput and agent quality you get at your desk depends on whoever is serving the weights, even if that someone is a small server in your closet, a vLLM endpoint at work, or a hosted vLLM shim like any of the Anthropic-compatible proxies. A 14-day release cadence with async scheduler flipped on by default is the difference between a tool call that returns in 700 ms and one that returns in 2.4 s. It is also how Gemma 4 served on vLLM v0.19.0 starts answering faster than the same weights served on v0.18.0.

Settings > Advanced > Custom API Endpoint, paste the URL, restart the chat. Behind the scenes that field is persisted as a UserDefaults key named customApiEndpoint at Desktop/Sources/MainWindow/Pages/SettingsPage.swift line 840, then exported as ANTHROPIC_BASE_URL onto the Node child process at Desktop/Sources/Chat/ACPBridge.swift lines 380 to 381. vLLM does not speak the Anthropic Messages API directly; you need a small shim in front of it that translates Messages to OpenAI-compatible, which is what vLLM exposes. The Fazm side is protocol-agnostic; the shim is where you wire it to vLLM.

No. vLLM exposes an OpenAI-compatible /v1/chat/completions surface by default. Fazm speaks Anthropic Messages. The two interlock through an Anthropic-to-OpenAI shim, of which several open-source options exist. You run the shim on any machine, point it at your vLLM URL, and hand the shim URL to Fazm's Custom API Endpoint. ANTHROPIC_BASE_URL on Fazm's end, OpenAI-compatible on vLLM's end, shim in the middle.

v0.19.0. The async scheduler flipped on by default reduces time-to-first-token, which is the metric that dominates agent feel because an agent emits many short tool calls in a loop. Every one of those calls is a fresh TTFT bill. Faster scheduling means the agent feels snappier regardless of model size. The Gemma 4 26B MoE support is the second-most-important item if you care about reasoning per active parameter, which is where MoE math pays off.

Speculative decoding uses a small draft path to propose a few tokens ahead of the main model, then verifies them in a single pass. GPU NGram specifically proposes continuations from a running n-gram index on the GPU, so you do not have to run an entire separate draft model. It is a speed win on long-form completion without the memory cost of a draft-and-verify two-model pipeline. For agents that emit short structured tool calls, the gain is smaller than it is for chat-completion workloads.

Fazm itself does not need vLLM. It talks Anthropic Messages to a Node child process over ACP, and that child process can be pointed at any Anthropic-shaped endpoint via ANTHROPIC_BASE_URL. If you want vLLM's throughput, you wire a shim in front of it and put the shim URL in Settings. If you prefer Ollama or LM Studio, the same seam works; both of those expose an OpenAI-compatible endpoint natively and you still put a Messages shim in front of them. The design is that the serving stack is yours to choose; Fazm is a consumer Mac app, not a model server.

Not a screenshot. Fazm ships a bundled macOS binary called mcp-server-macos-use that returns the accessibility tree (AXUIElement roles, labels, values, window hierarchy) for the focused app as a structured document. That document goes to the model inside the tool-call response, so even a locally served 7B to 13B-class model has a realistic shot at picking the right button. The Fazm onboarding tells you this too; the feature shipped the same month as the vLLM v0.19.0 release and they compose.

Four files in the MIT-licensed repo. Desktop/Sources/Chat/ACPBridge.swift lines 380 to 381 for the ANTHROPIC_BASE_URL export. Desktop/Sources/MainWindow/Pages/SettingsPage.swift line 840 for the @AppStorage("customApiEndpoint") declaration and line 936 for the TextField that writes to it. Desktop/Sources/Providers/ChatProvider.swift line 2103 for the consumer reading the same key. CHANGELOG.json for v2.2.0 on 2026-04-11, which is the release that shipped the Custom API Endpoint setting into the public Fazm build.

Yes. The throughput gain from vLLM is about tokens per second; the agent-quality gain on a Mac is about whether the model can identify the right element. A fast local model that receives a screenshot and hallucinates the Save button is worse than a slower model that receives a structured accessibility tree and names it. The two gains stack. vLLM v0.19.0 plus accessibility-tree context is roughly where a consumer Mac agent becomes actually useful, not a demo.