GitHub Desktop 3.6, vLLM on HF Jobs, and QHexRT — AI Digest for June 26, 2026

Today’s useful builder news sits close to the development loop: GitHub Desktop learned worktrees and deeper Copilot flows, Hugging Face made temporary vLLM serving easier, RunAnywhere pushed a Qualcomm NPU runtime, JetBrains is moving more LSP plumbing into open source, and GitHub published a benchmark-heavy look at Copilot’s agent harness.

Coverage window: June 26, 2026 in this channel’s timezone. Items below are included only where the source page disclosed a same-day publication or update signal.

GitHub Desktop 3.6 is not just a cosmetic client update. The new release adds Git worktree support, so a repository can have multiple linked working directories for different branches. GitHub frames this as useful alongside coding agents, which often need isolated parallel sessions. 1

Copilot also moves deeper into the desktop Git flow. Commit message generation now picks up custom instructions from .github/copilot-instructions.md and AGENTS.md, and GitHub says it honors repository commit metadata rules. 1 Merge conflict help can explain conflicting changes and suggest a resolution that the developer can review, accept, or edit. 1

The practical caveat: this makes the Git client more agent-aware, but it also puts more trust in repo-level instruction files. Teams already using AGENTS.md should review what those instructions say before relying on generated commits or conflict suggestions.

Hugging Face’s new guide shows how to launch a private vLLM server with hf jobs run, expose port 8000, and call the running job through an OpenAI-compatible API. The example serves Qwen/Qwen3-4B on an a10g-large flavor. 2

Two details are easy to miss. First, the endpoint is gated: every request needs an HF token with read access to the job namespace. 2 Second, Jobs are meant for flexible, temporary runs. Hugging Face distinguishes Jobs from Inference Endpoints, which add production features such as access-control options and scale-to-zero. 2

For builders, this is useful when the question is narrow: Does this model pass my eval? Can it run a batch job? Does it work as a coding-agent backend before I commit to a longer-lived service? The guide also includes an example of using the endpoint behind Pi, a provider-agnostic terminal coding-agent harness. 2

RunAnywhere’s QHexRT announcement is narrower than the headline sounds, but the technical direction is important. The first supported model is LiquidAI’s LFM 2.5 230M on Hexagon v81, with a downloadable NPU bundle on Hugging Face. 3

The vendor-reported numbers are sharp on prefill: 12,540 tokens per second on the NPU versus 871 tokens per second for llama.cpp CPU Q8_0 on the same chip. Decode is different; the CPU wins at 250 tokens per second versus 172 on the NPU. 3 RunAnywhere’s own summary says the NPU wins end-to-end once the prompt exceeds about 1.5 times the generated length. 3

That split matters. Local AI performance is not a single number. Short chatty generations may stress decode. Retrieval-heavy or prompt-heavy tasks care more about prefill and time-to-first-token. QHexRT is early, vendor-measured, and currently focused on a small model, but it is a useful signal for anyone watching mobile and edge AI runtimes.

JetBrains is moving its LSP client API into the open-source IntelliJ Platform. The reason is straightforward: LSP standardizes language-server behavior, but IDE integration still needs code for starting the server, routing editor features, and handling product differences. 4

The current split caused problems for plugin authors. JetBrains cites an Azure DevOps Pipeline plugin case where Android Studio did not start the language server because the LSP integration was a commercial IDE extension rather than part of the open-source platform. 4

Plugin authors should not blindly migrate. JetBrains tells existing LSP4IJ or custom-client users to check minimum IDE version, Android Studio support, feature coverage, customization hooks, and remote or split-mode needs before moving. 4

GitHub’s agentic harness post compares the Copilot CLI with model-vendor harnesses while holding the model and task fixed. The compared model families include Claude Sonnet 4.6, Claude Opus 4.7, GPT-5.4, and GPT-5.5. 5

The claimed result: task completion is broadly on par with vendor harnesses, while token consumption is lower across many configurations. 5 The post also calls out variance: each TerminalBench 2.0 agent-model combination was run at least five times, with one-sigma spreads shown around each point. 5

For a builder, the benchmark winner is less important than the testing shape. If you are evaluating coding agents internally, measure at least three things together: whether the task completes, how many tokens or dollars it burns, and how unstable the result is across repeated runs. A cheap agent that flips outcomes every other run is not really cheap.

The day’s pattern is practical rather than flashy. AI tools are moving into Git clients, temporary model-serving jobs, IDE plugin APIs, and edge runtimes. That is where many teams will feel AI progress first: fewer side setups, better local integration, and more control over which model runs where.