v6.19.0

Security

• A registry refresh can no longer change what runs, or how an agent is set up. It kept any recipe whose engine image came from a repository the plugin's recipes used, at any digest, and it never compared a recipe's arguments, environment, weights or serving settings, so a refresh could bring back an image 6.18.0 dropped (ghcr.io/0xsero/sglang-exl3@sha256:9d95829a…), hand a shipped image a script, an LD_PRELOAD or another model repository with --trust-remote-code, or put a context length with TOML in it into an agent's config, which Grok would then run. A refresh can now only withdraw, reorder or relabel the recipes the plugin ships: each recipe it lists that the plugin's own recipes.json (the reviewed file, not an earlier refresh) has under the same card kind becomes that shipped recipe, and only its name, family and format (plain text, at most 120 characters), size and score (finite numbers) and capability flags (booleans) are taken from the registry, each when it passes its check. Everything else always comes from the shipped recipe, each card kind keeps the match the plugin ships, and a recipe the plugin does not ship is left out until a release ships it. Agent configs also take only a number for the context length and a quoted model name, wherever they came from. The refreshed catalog now lives in a v4 folder, so a catalog 6.18 or earlier refreshed under the old checks is never read (Remove deletes the old one). A refresh installs a catalog only once the panel can be drawn from it, and one that later cannot be read or drawn is skipped for the shipped recipes, with a line in the log, so a bad catalog can never stop the panel from refreshing. Reported by HANCORE-linux (omacom/omarchy-plugin-marketplace#11207).
• An update that stops offering a recipe strands nothing. A model running on it keeps Stop, and a failed one Dismiss, without Run again; its download is removed by what its start recorded once its containers are gone, and any model folder no recipe here and no running model uses (a recipe the update withdrew, such as the B70's Qwen3.8-Flash-Next whose id the registry changed) is listed on home under No longer offered with its size and Remove, which waits while a download is writing it. Nothing is listed while a model started by 6.9 or earlier, which recorded no downloads, is still running. Until now such a download could only be deleted by hand.
• Local AI stops while polkit files that Local AI 6.0-6.4 wrote, for this account or any other, are still on the machine. Their action ran the backend in that account's own plugin folder as root and their rule let it run without a password, so any program of that account could become root through them; 6.8 only printed their paths at the end of setup, where they were easy to miss. Now the panel shows a red banner that does not go away until they are gone, and starting a model, sharing one and setup refuse with the same reason. Only root can delete them, so Local AI does not: the banner links docs/legacy-polkit.md, which says what the two files are and gives the commands to remove them and to check they are gone. The banner clears on the next refresh after that.
• The model's page now copies the gateway's address on the model's own Docker network, where the key is safe to send, and the README says to use that one. Both used to point your own clients at http://127.0.0.1:<port>, which any account can bind the moment the gateway stops, and so collect the key from the next client that sends it. Local AI and the agents it opens already used the bridge address; the loopback port now only serves the keyless health check.
• Update Local AI opens Omarchy's own plugin update in a terminal, which shows what changes and asks before it installs. It ran omarchy-plugin-update --yes in the background, so a new release was installed without you seeing it. The panel picks up the result on its next refresh.
• Usage reports are off until you allow them. Home asks once whether to share minimal, anonymous usage counts (No thanks or Allow, either kept; Settings changes it later); until you answer nothing is counted or sent and no install id is made. An install that never chose, which until now reported by default, is treated as not having answered.
• Small files from Hugging Face (configs, tokenizers, chat templates, model code) are checked against the Git blob SHA-1 the Hub lists for them, as large files are against their SHA-256. They were checked by size only, so a same-size file with other content, downloaded or found in your Hugging Face cache, was used as it was; a chat template or remote code file is enough to change what the engine runs. Listings an earlier version kept are fetched again. Weights an earlier version marked as checked are checked again once, by hash, since that mark covered sizes only for small files; files that match are kept, nothing is downloaded again.
• The lock that serializes model starts is now your own, in your runtime directory. It was a lock on the shared /run, which any account on the machine could hold forever and so stop every start for everyone. Two accounts that take the same card at the same moment are settled by Docker: the container created first keeps it, and the later start removes its own and says the card is in use. Docker's check counts a container that is created but not started yet, restarting or paused, and names a card the same however it was asked for (--gpus device=0, its UUID, or a CDI name such as nvidia.com/gpu=GPU-…); an NVIDIA id it cannot place counts as every card.
• The engine's private network is created with IPv6 off, and a start checks that it came out without IPv6 as well as internal and isolated. The isolation Docker applies is IPv4's, so a daemon with IPv6 on by default would have given the host a route to the engine around it. A model 6.17 or 6.18 started on such a network keeps it while it runs: the panel now shows that model as needing to run again (which makes its network anew, without IPv6), and it cannot be shared until then.

v6.18.0

Security

• Every engine image the plugin offers is now built by our attested image workflow, or published by its upstream project. Each of ours carries a GitHub build attestation that binds its digest to a source commit and a build; check one with gh attestation verify oci://<image>@<digest> --owner sybil-solutions (or --owner 0xSero for the older namespace). Fifteen recipes ran on three images without that provenance: a hand-built SGLang EXL3 image (13 recipes on the RTX 3090 Ti, 4090, 5070, 5070 Ti, 5090 and RTX PRO 6000), the 4×3090 Qwen3.8-27B image and a contributor's CMP 170HX vLLM image. They are left out until they are lab-proven on attested rebuilds. Every affected card except the CMP 170HX keeps other recipes, and the attested SGLang rebuild already exists (registry #287). Reported by HANCORE-linux (omacom/omarchy-plugin-marketplace#11207).

Added

• Qwen3.8-Flash-Next on every RTX 30-series card we could test, with its routed experts offloaded to system RAM. Each recipe passed all six lab gates, at 25 tok/s decode or more and 500 tok/s prefill or more:

  Card	Quant	Context	Decode tok/s
  RTX 3060 Ti 8 GB	2.05 bpw	64K	25.4
  RTX 3070 8 GB	2.05 bpw	64K	34.9
  RTX 3080 10 GB	2.05 bpw	128K	35.1
  RTX 3080 Ti 12 GB	3.05 bpw	128K	33.2
  RTX 3090	3.05 bpw	256K	45.5
  RTX 3090 Ti	3.05 bpw	256K	43.3

  They need 48 GB or more of RAM and an NVMe drive, and the panel offers them only on machines that have both. They run on a new attested image, ghcr.io/sybil-solutions/sglang-exl3-flashnext (registry #286). Recipes are at registry 1b978129.

Fixed

• An NVIDIA GPU that shares the host's memory (DGX Spark's GB10, the RTX Spark N1X) no longer breaks the panel. nvidia-smi prints [N/A] for its memory, which the snapshot could not read, so the panel showed nothing at all. Such a card is now unified: it shows the host's memory and matches its card kind by host RAM, like a unified-memory APU. A unified card's allowance for firmware and kernel reservations is a tenth of its stated memory, at least 8 GiB, since a 128 GiB GB10 or RTX Spark has 119.5 GiB MemTotal and fell 500 MiB short of the flat 8 GiB.

v6.17.0

Security

• Each engine runs on its own internal Docker network that the host has no address on, shared only with its gateway. Docker routes every bridge address from the host whether or not a port is published, so until now any local account could talk to an engine directly and skip the gateway's key; that mattered for engines with no key of their own (TabbyAPI with disable_auth, llama-server without --api-key). The gateway joins both networks: the engine's, and the bridge Local AI and the agents reach it on. A model started by an earlier version is moved to its private network while it runs, without a restart, the first time the panel refreshes. This needs Docker 28 or later (Omarchy ships 29); an older Docker refuses to start a model and says why. Engines also lose outbound network access, which they never needed: weights are mounted and Hub downloads are already offline. Reported by HANCORE-linux (omacom/omarchy-plugin-marketplace#11207).

Added

• The Intel Arc Pro B65 (8086:e222, 32 GB) is detected, with its three llama.cpp SYCL recipes (Qwen3.8-27B, Gemma 4 31B QAT and Muse Glimmer 30B; registry #260, thanks @snowopsdev). Recipes are at registry 1eecf510.

v6.16.0

Security

• The agent's folder is chosen in the panel's own folder browser: the folder row opens the current folder, a click enters a subfolder or goes up, recent folders are one click away, and Use this folder sets it. The panel no longer opens Qt's native file dialog, which ran GTK3's chooser inside the shell; a paste there made the shell read another program's clipboard without a size limit, so a hostile clipboard owner could exhaust the shell's memory. Nothing in the browser is typed or pasted. The backend's new dirs <folder> lists a folder's visible subfolders (at most 400) and falls back to home for anything that is not a folder. Reported by HANCORE-linux (omacom/omarchy-plugin-marketplace#11207). This also ends the shell crash the native chooser caused on some machines (gmem.c: failed to allocate, #108).

Added

• The Intel Arc B390 (Panther Lake iGPU, 8086:b080) is detected alongside the Arc Pro B70, so its registry recipes are offered (#106, thanks @rados10).
• Apple Silicon under Asahi Linux is offered its CPU recipes, sized by unified RAM (#62, thanks @mstrelko).

Changed

• Panel text and width follow Omarchy's type scale (#103, thanks @Zeus-Deus).
• Open tells the agent how much the engine's cache holds, not just its context, so a long conversation is compacted before the engine runs out (#109, thanks @maralcbr).

Fixed

• AMD cards are found when a mise or pyenv python3 comes first on PATH (amd-smi runs under the system Python), and a Strix Halo's BIOS carve-out counts toward its unified memory, so a 128 GB machine matches its card at any carve-out (#116, thanks @joonsp; #63).
• An amd-smi that crashes its Python (a segfault in libpython3.14, issue #118) is no longer run again on every poll. A subcommand that died of a signal is skipped for a day; the card stays listed from amd-smi static, with memory use and temperature unknown.

Usage dashboard

• usage.sybilsolutions.ai leads with Work: bounties against the $1,000 monthly cap, open PRs and issues, the marketplace listing, and supported card and recipe counts, from the registry's hourly ops.json (#131).

v6.15.0

Added

• Settings on home, with one setting for now: send usage reports, on or off, and what reporting sends in plain words (minimal and anonymous: no user or account ID, a random number made on this computer, version, card kinds, model and action counts; never prompts, files, folders, model names or agents; the IP address is not stored). Turning it off deletes counts not yet sent. With DO_NOT_TRACK set it shows as off, without a switch.

Security

• Two first starts at once could leave a running gateway with an empty key: both passed the key-existence check and the second truncated the shared key file, and the gateway treated an empty key as "no key required". The key is now written whole to a temporary file and linked into place, never truncated, so concurrent starts share one key. The gateway (org-v5, sha256:9ab834c2…) refuses every request while its key file is missing, unreadable or empty, and compares the key in constant time. A running model gets the new gateway when it is stopped and started again. Reported by HANCORE-linux (omacom/omarchy-plugin-marketplace#11207).
• The usage server (usage/) keeps no request logs and has no workers.dev or preview address, so only usage.sybilsolutions.ai answers and Cloudflare stores no caller addresses for it. It accepts only JSON pings of at most 1 KB (refused before reading), sends nosniff, no-referrer, HSTS and DENY framing on every response, serves the dashboard under a CSP that allows only its own script (by hash) and the plugin's traffic files, allows other sites to read the public stats only, and answers any internal error with a bare 503.

Changed

• The install count measures use, not a moment. Each ping also says whether a model has ever answered on this machine (launched, read from the gateway's usage log, so models run before updating count) and how many models started, how many starts failed, how many agents opened and how many models were downloaded since the last ping that arrived. Totals only, never which model, agent or folder. They wait in counts.json until a ping arrives, so none are lost or sent twice, and using Local AI sends nothing extra: pings stay at most twice a day. Turning counting off deletes what was not sent. The dashboard shows "ran a model, ever" and the 30-day actions instead of "running at a check-in".

v6.14.0

Added

• Update Local AI on the home page when main has a release this copy lacks. The agent update check (every 6 hours) also asks the plugin's origin for its default branch's commit with git ls-remote (nothing is fetched), and the button runs Omarchy's omarchy plugin update. A checkout that already contains that commit is not offered it, and a copy that is not a git checkout is never offered an update.

Changed

• main carries releases only and development lands on dev, so the commit Omarchy installs and the marketplace reviews stays still between releases. Recipes reach installed copies through the panel's registry check and do not need a release. The release workflow merges each release back into dev; pull requests into main must come from dev.

v6.13.8

Security

• The gateway key never goes to 127.0.0.1:<port> any more. The panel's status poll sent it there every few seconds while a model ran; if the gateway exited outside Stop, another local account could bind the vacated port and receive the key. The poll now reads the gateway's keyless /health, and every keyed request (the start's readiness and answer checks, the agents open starts, a tailnet share) goes to the gateway's address on the model's own Docker network, which only Docker assigns and no other account can listen on. Keyed requests bypass proxies, and agents start with that address in NO_PROXY/no_proxy, so an inherited HTTP_PROXY cannot receive the key either. Reported by HANCORE-linux (omacom/omarchy-plugin-marketplace#11207).

v6.13.7

Fixed

• When an agent gives up on an answer, the engine stops generating it. The gateway (org-v4, registry at 7c15d9ca) watches the client's connection while it waits on the engine and closes the engine request the moment the client is gone. Before, a non-streamed request, or a streamed one between chunks, ran to its end behind a client that had timed out; on a recipe that runs one request at a time (Qwen3.8-Flash-Next on an Arc Pro B70), the agent's retry then queued behind it and timed out as well. A running model gets the new gateway when it is stopped and started again.

v6.13.6

Fixed

• A failed start keeps the engine's last 400 log lines (it kept 60). vLLM prints an engine core's cause above two tracebacks, so the Qwen3.8-27B ValueError on the display card was not in the kept log; the reason shown and the kept log now come from the same lines.

v6.13.5

Fixed

• On a machine with several Arc Pro B70s, Start no longer picks the card that drives the desktop when another is free. The compositor, Xwayland and browsers hold about 1.7 GiB on the display card, less than vLLM's 96.5% request leaves, so Qwen3.8-27B failed to start there ("the engine keeps crashing") while it loads on the other card. A card with a connected monitor is offered last, and the hardware page marks it "display".
• When an engine fails, the message names its exception (for example ValueError: Free memory on device xpu:0 (30.16/31.89 GiB) on startup is less than desired GPU memory utilization) instead of the first traceback line, which read raise RuntimeError(.