DEV Community: Alan West

How to Run Mage-VL-Cowork Locally: Microsoft's 4B Agent Beats Sonnet 4.5

Alan West — Sun, 01 Nov 2026 13:30:03 +0000

Microsoft's Mage-VL-Cowork is a 4B computer-use model that scores 66.0% on OSWorld-Verified. That's ahead of Claude Sonnet 4.5 (62.9%, and Sonnet got twice the step budget) and of an open 72B model that manages 44.9%. The BF16 weights are 9.48 GB and the license is Apache-2.0, so a 16 GB GPU is enough to run it locally. A 4-bit GGUF fits in 8 GB. Before you point it at anything, though, read the part of the model card that tells you to keep it in a disposable VM.

microsoft/Mage-VL-Cowork showed up on Hugging Face at the end of October. The "Cowork" in the name makes it sound like a friendly screen buddy that watches you work. What you actually get is an agent policy that takes a screenshot and emits either a GUI action or a shell command. Everything below comes from the model card, the config, and the community ports. I haven't run it myself, and I'll say where the published numbers stop.

What Mage-VL-Cowork is (and how it differs from Phi vision)

Microsoft's earlier small VLMs were general models. Phi-4-multimodal is about 5.6B params, takes text, images and audio, has a 128K context and ships under MIT. You ask it about an image and it answers.

Mage-VL-Cowork does a different job. Every turn has the same output format: a <think> block, a one-line Action: summary, then a <tool_call>. There are two tool channels:

computer_use: 11 GUI primitives with coordinates normalized to [0, 999]
bash: arbitrary shell commands

The project page's tagline is "One 4B policy that knows when to click—and when to code." That claim holds up best in the training mix: 68.19% of the 318,837 hybrid trajectories are GUI tool calls and 31.81% are terminal calls. The model learned to stop dragging the mouse around LibreOffice when a Python one-liner will do the job.

It's also not a Phi descendant. The language backbone is Qwen3-4B-Instruct-2507 and the vision encoder is Microsoft's own Mage-ViT. The closer Microsoft relative is Fara-7B (Qwen2.5-VL base, MIT, released November 2025), which is built for web tasks.

Mage-VL-Cowork specs: 4B or 4.7B parameters?

	Mage-VL-Cowork	Phi-4-multimodal	Fara-7B
Params	4B (card), 4.74B (Hub metadata)	~5.6B	7B
Backbone	Qwen3-4B-Instruct-2507 + Mage-ViT	Phi-4-mini	Qwen2.5-VL-7B
Context	32,768 active (262,144 max in config)	128K	128K
License	Apache-2.0	MIT	MIT
Job	Desktop + terminal agent	General multimodal	Web agent

About the mismatch: the card says 4B, but the Hub's safetensors metadata counts 4.74B parameters. That matches 9.48 GB divided by 2 bytes per BF16 weight. The config has 36 text layers, hidden size 2560, and 8 KV heads. The vision side is 24 layers at 1024 hidden.

The context number trips people up. The architecture supports 262,144 tokens, but Microsoft trained and evaluated at 32,768 and runs a sliding window that keeps the 3 latest screenshots and 4 full assistant turns. Older turns get folded into their Action: lines. Don't push it to 262K and expect it to behave.

OSWorld-Verified: where 66.0% actually sits

The headline number is OSWorld-Verified: 361 tasks with Google Drive tasks excluded and a 50-step budget. The 66.0% is the mean of two runs, 65.33% and 66.75%.

Model	Params	OSWorld-Verified
GPT-5.4-mini	—	69.6
ScaleCUA-Qwen3.5-9B	9B	68.7
Mage-VL-Cowork	4B	66.0
Muse Glimmer-30B	30B	65.9
Qwen3.6-27B	27B	63.9
Claude Sonnet 4.5 (100 steps)	—	62.9
OpenCUA-72B	72B	44.9
Fara1.5-4B	4B	13.9

The frontier models are still well ahead. GPT-5.5 is at 78.7 and Claude Opus 4.7 at 78.0, and the card's human reference is 72.4. The 66.0 mostly shows how much a small model gets out of a task-specific curriculum. The RL stage alone took it from 55.84% to 66.04% while cutting output tokens per task from 7,374 to 5,499.

Two things I'd flag before anyone quotes these numbers in a pitch deck:

The WebVoyager-Static figure (58.6%) comes from the SFT checkpoint, not the released RL model, and Microsoft's own Fara1.5-4B beats it there with 68.0%.
The web results use offline replicas. The card has no live-web number for Mage-VL-Cowork.

How much VRAM Mage-VL-Cowork needs

The card does not state a minimum VRAM. Here's what the published files and config let you work out.

Start with the weights. BF16 is 9.48 GB across 2 safetensors shards. The community Q4_K_M GGUF is 2.72 GB plus a 0.35 GB Q8_0 mmproj. The MLX 4-bit build is about 3.14 GB.

Then the KV cache. I worked this out from config.json and haven't measured it: 36 layers × 8 KV heads × 128 head dim × 2 (K and V) × 2 bytes comes to about 144 KB per token. At the full 32,768 window that's roughly 4.8 GB in FP16.

Setup	Weights	+ KV at 32K	Card to plan for
BF16 (Transformers/SGLang)	9.48 GB	~4.8 GB	16 GB
Q8_0 GGUF + mmproj	5.05 GB	~4.8 GB	12 GB
Q4_K_M GGUF + mmproj	3.07 GB	~4.8 GB	8 GB
MLX 4-bit (Apple Silicon)	3.14 GB	—	16 GB unified memory Mac

Screenshots are the other big cost. Microsoft recommends SGLANG_MAX_PIXELS=4000000 so a 1920×1080 capture keeps its full detail, which means a lot of vision tokens per turn. If you're tight on memory, lower the screenshot resolution before you drop to Q2_K. Grounding is what I'd expect quantization to break first. In the MLX port's tiny 3-task demo, the 4-bit build missed a Dark Mode toggle by 42px while the BF16 build hit it.

Which runtimes load it today: SGLang, Transformers, vLLM, llama.cpp, Ollama, MLX

Transformers

Works, needs trust_remote_code=True:

pip install "transformers>=4.57.3" accelerate pillow torch torchvision qwen-vl-utils

import torch
from transformers import AutoModelForCausalLM, AutoProcessor

processor = AutoProcessor.from_pretrained("microsoft/Mage-VL-Cowork", trust_remote_code=True)
model = AutoModelForCausalLM.from_pretrained(
    "microsoft/Mage-VL-Cowork", trust_remote_code=True,
    torch_dtype=torch.bfloat16, device_map="auto",
).eval()

Use the card's sampling settings (temperature 0.7, top_p 0.8, max_new_tokens 4096) and its full MAGE_HYBRID_SYSTEM_PROMPT. That prompt is where the tool schemas and the reply format are defined, so don't skip it.

SGLang

This is the path the card's Quick Start recommends, and the one I'd pick:

python -m sglang.launch_server --model-path microsoft/Mage-VL-Cowork \
  --trust-remote-code --dtype bfloat16 --context-length 32768

There's also a prebuilt image, xiaoyizhang/mage-vl-cowork:0.1.0 (SGLang 0.5.2, PyTorch 2.8.0+cu128). Screenshots go through the native POST /generate endpoint with image_data.

vLLM

The Hub's "Use this model" panel suggests vllm serve "microsoft/Mage-VL-Cowork", but the card doesn't test that path. With a custom llava_onevision2 architecture, I wouldn't count on it until someone posts a working run.

llama.cpp

Only through a fork. The GGUF repo points to ch686/llama.cpp-locateanything-magevl at commit e07bdc8, and the upstream PR (#26796) was closed without being merged. Loading the text side is easy enough; the fork exists because of the custom Mage-ViT projector.

Ollama and LM Studio

The Hub lists ollama run hf.co/Hansda/Mage-VL-Cowork-GGUF:Q4_K_M, but the GGUF author says outright: "Stock llama.cpp, Ollama and LM Studio have not been validated for this projector." Maybe it works fine. For an agent that has to click within a few pixels, though, I'd treat it as broken until someone posts grounding results.

MLX on Apple Silicon

Works with mlx-vlm 0.7.11, which has a built-in mage_vl model:

pip install -U mlx-vlm
python -m mlx_vlm.generate --model pratikgx/Mage-VL-Cowork-MLX-4bit \
  --image screenshot.png --prompt "Turn on Dark Mode." --max-tokens 512

None of the community quants has an OSWorld score. The only published numbers are for Microsoft's BF16 checkpoint.

The part nobody reads: Microsoft's sandbox rules

The card isn't vague about deployment. Run the agent inside an isolated container or VM with no access to host filesystems, local networks or personal environment variables. Require human confirmation before irreversible actions like external submissions, account logins, payments and privilege changes. Don't mount SSH keys, cloud tokens, browser cookies or password stores. Restrict outbound network access when the model handles untrusted web pages.

So the "cowork" fantasy, a local model watching your real desktop and helping out, is exactly what Microsoft tells you not to do. The model has a bash channel, and a web page with injected instructions is just more pixels to it. A local model keeps your data off someone else's server, but it doesn't stop the model from running rm on your files.

What I'd do with it today: spin up a snapshot-reverted Ubuntu VM with no credentials in it, serve the model with SGLang on a 16 GB card, and use the osworld_eval/ harness in the repo as a starting point for your own agent loop. That setup gives you a 4B agent that beats several 27–72B open models on OSWorld-Verified, and the worst it can do is wreck a VM you'll throw away anyway.

Would you let a local vision model watch your screen and act on it, as long as nothing leaves your machine? Or does a bash tool make "local" irrelevant? Tell me where you draw the line.

Sources

How to Run LFM3-Omni-2B GGUF Locally (Only llama.cpp Makes It Talk Back)

Alan West — Sat, 31 Oct 2026 20:20:01 +0000

LFM3-Omni-2B is Liquid AI's new 2B model that takes text, images, video and audio in and answers in text or 24 kHz speech. The Q4_K_M GGUF is 1.1 GB, plus a 292 MB mmproj file, and llama.cpp v0.8.0 runs all of it, voice output included. Ollama and LM Studio load it too, but neither of them makes it speak. If you just want it running:

llama serve -hf LiquidAI/LFM3-Omni-2B-GGUF:Q4_K_M --reasoning off --temp 0 --port 8080

When I covered d1-Omni-2B earlier this week, my main complaint was that it listens to audio but can only answer with a typed probability. LFM3-Omni-2B is the model it was built on, and it still has the speech output. The GGUF repo picked up 69,967 downloads in the few days since launch, so I'm clearly not the only one curious.

This post covers which quant to pick, the llama.cpp commands for ASR, image, video and TTS, the realtime voice endpoint, which apps can make it speak, and where it loses to LFM3-VL-2B and Gemma 4. I haven't run it myself yet. Everything here comes from Liquid's cards, the llama.cpp release notes and the PR that added realtime voice.

What LFM3-Omni-2B actually is

It came out on October 27, 2026, as part of the LFM3 family: six roughly 2B models, all built on LFM3-1.7B-Base. The Omni model combines four parts:

the LFM3-1.7B backbone
an LFM3 vision encoder (native resolution, each 2×2 patch block becomes one token)
a causal audio encoder that takes 16 kHz input
a "depthformer" plus the Liquid Audio Codec for speech output at 24 kHz

That adds up to 2.17B parameters. Input can be text, images, video (with or without the soundtrack) and audio. Output can be text, speech, or both interleaved. Text works in 16 languages. Speech covers 19 languages and locales, including British and American English as separate voices.

The context window is 32K tokens. That's the spec I'd worry about, since the two sibling models below get 128K.

LFM3-Omni-2B vs LFM3-VL-2B vs d1-Omni-2B

All three are from the same family and were built for different jobs.

	LFM3-Omni-2B	LFM3-VL-2B	d1-Omni-2B
Params	2.17B	1.92B	2.17B
Input	text, image, video, audio	text, image, video	text/JSON state, image, video, audio
Output	text + 24 kHz speech	text	typed answers with probabilities
Context	32K	128K	128K
Reasoning	no (`enable_thinking` unsupported)	yes, `<think>` block	single forward pass
License	LFM Open v1.0	LFM Open v1.0	LFM Open v1.0

Sources: Omni card, VL card, d1-Omni card.

d1-Omni-2B is a decision model built on top of LFM3-Omni-2B, and its card says plainly that there are "no generated tokens or speech". It's useful for classifying a camera feed, but you can't hold a conversation with it.

The comparison with LFM3-VL is less flattering. Both cards publish the same four vision benchmarks:

Benchmark	LFM3-Omni-2B	LFM3-VL-2B
MMStar	55.67	74.4
OCRBench	806 / 1000	86.3
DocVQA	92.47	96.7 (val)
RealWorldQA	66.54	79.3

The cards don't say whether the two models were evaluated the same way, and only VL reasons before answering, so treat these as rough numbers. The gap is still big enough that for screenshots, PDFs and charts I'd stick with LFM3-VL-2B and its 128K context. Pick Omni when the input or output is a voice.

LFM3-Omni-2B vs Qwen2.5-Omni, Gemma 4 and Phi-4 MM

Liquid compares Omni with Qwen2.5-Omni 3B, Gemma 4 E2B and E4B, and Phi-4 MM, all bigger in total parameters. These are Liquid's own measurements from the base card:

Benchmark	LFM3-Omni 2B	Qwen2.5-Omni 3B	Gemma 4 E2B	Gemma 4 E4B	Phi-4 MM
Daily-Omni	70.09	58.81	50.63	54.14	48.87
English ASR WER ↓	6.36	6.30	8.26	7.82	5.14
English TTS UTMOSv2 ↑	3.80	3.42	—	—	—
VoiceBench ↑	64.73	66.37	63.28	72.90	64.97
Tool calling (internal) ↑	52.20	44.30	55.60	72.40	—

The audio-plus-video results are strong for its size, and ASR is close to Qwen2.5-Omni 3B. On the vision benchmarks it roughly ties Qwen2.5-Omni 3B too, so the gap to LFM3-VL is a specialist-vs-generalist thing. VoiceBench and tool calling are where it falls short: Gemma 4 E4B beats it by about 8 points on VoiceBench and 20 on Liquid's internal tool-calling test, and even the smaller Gemma 4 E2B edges it on tool calling. Those two scores are the ones that matter for a voice assistant. Most voice tasks are some version of "set a timer", and that is a tool call.

Which quant to download: file sizes and RAM

Liquid doesn't publish RAM figures per quant, so file size is the best estimate available. You need the main model plus an mmproj file. The multimodal parts live in that mmproj file, and the repo's commit history shows the speech codec decoder is in there as well ("Quantize the codec decoder in mmproj"). Both lists below come from the file listing:

Quant	Model	mmproj (same quant)	Total on disk
Q4_0	1.05 GB	271 MB	~1.3 GB
Q4_K_M	1.1 GB	292 MB	~1.4 GB
Q8_0	1.85 GB	507 MB	~2.4 GB
BF16 / F16	3.47 GB	950 MB	~4.4 GB

Add the KV cache and audio buffers on top of that. Liquid's blog says the hybrid LFM3 backbone needs only 1.6 GB of KV cache at 128K context for the text model, and Omni stops at 32K. On paper, an 8 GB laptop handles Q8_0 without trouble, though that's my estimate and I haven't measured it.

Someone on the repo has already asked whether the Q4 file uses QAD (quantization-aware distillation), as the text model's Q4_0 does. Nobody has answered yet. Until Liquid says so, I'd assume it doesn't and go with Q8_0 if you can fit it.

How to run LFM3-Omni-2B GGUF with llama.cpp

Support arrived in llama.cpp b11960 (v0.8.0), released October 28. That release also added a POST /tts endpoint and a /v1/realtime endpoint to the server (release notes). The commands below are copied from the model card. They use the llama serve / llama cli front-end, plus the separate llama-tts binary for speech. If your build is older than b11960, update first. Older builds don't support the model at all.

Start the web UI and the OpenAI-compatible API. -hf also downloads the projector:

llama serve -hf LiquidAI/LFM3-Omni-2B-GGUF:Q4_K_M --reasoning off --temp 0 --port 8080

Keep --reasoning off. It's a non-reasoning model, and the card says enable_thinking=True isn't supported.

Speech-to-text:

llama cli -hf LiquidAI/LFM3-Omni-2B-GGUF:Q4_K_M --audio speech.wav -sys "Perform ASR in English." -p "<__media__>" --temp 0

Image input:

llama cli -hf LiquidAI/LFM3-Omni-2B-GGUF:Q4_K_M --image photo.png -p "Describe this image." --temp 0

Video input works with --video file.mp4. It needs ffmpeg in your PATH, and the base card says the model samples at 2 fps by default, between 4 and 384 frames. Long clips use up the 32K window fast.

Text-to-speech, the feature d1-Omni didn't have:

llama-tts -m LFM3-Omni-2B-Q4_K_M.gguf -mm mmproj-LFM3-Omni-2B-Q8_0.gguf -p "Hello world" -o out.wav

--tts-voice accepts female (the default) or male, and --tts-lang defaults to en. Liquid recommends audio temperature 0.4 and repetition penalty 1.2. The card says both values are already stored in the GGUF.

Realtime voice, the reason I'd download this

PR #31269 was merged on October 28. It adds voice chat with streaming audio in and out, plus live transcription, to the server's /v1/realtime endpoint. The GGUF card advertises tool calls over the same endpoint. You choose the reply type with output_modalities: ["text"], ["audio"], or ["audio", "text"] for interleaved voice chat. Leave it unset and the model decides. The PR includes examples/realtime_client.py to test with. It was smoke-tested on Mac and CUDA with F32, Q8_0 and Q4_0. The PR doesn't give latency numbers, so I'm not repeating the time-to-first-audio claims going around.

Ollama, LM Studio or llama.cpp: which ones make it speak

The GGUF card lists a lot of apps, but speech output is only available in a few of them:

llama.cpp v0.8.0+: image, audio and video input, plus speech output via llama-tts, /tts and /v1/realtime
Llama.app (macOS, Windows): image, audio and video input
Ollama v0.40.12+ (macOS): image and audio input
LM Studio (llama.cpp engine 2.65.1+): image input only
SGLang: text output only, according to the base card
Transformers >=5.20.2: everything, in BF16

Only llama.cpp and Transformers document speech output. Everywhere else you get a vision-language model with a microphone, at best.

The license: free until $10M revenue

The license is the LFM Open License v1.0. It's free for commercial use until your company reaches $10M in annual revenue. Past that point you need to contact Liquid for a paid license. The threshold still applies to fine-tunes and other derivatives. Qualifying nonprofits are exempt for non-commercial and research use. That's fine for hobby projects and startups, but a bigger company can't ship it without talking to Liquid's sales team first.

My take

This is the first 2B model I'd test as a fully local voice loop: ASR, a language model and TTS in one roughly 1.4 GB download, served over a WebSocket by a tool I already use. The 32K context, the drop in vision quality compared with LFM3-VL, and a tool-calling score 20 points behind Gemma 4 E4B are what you give up. For a kitchen-counter assistant that reads timers and the weather, I think it's enough. For an agent that has to remember a long conversation and pick the right tool reliably, I doubt it.

Would you use a 2B omni model as your local voice assistant, or is 2B still too small to trust with tool calls? If you've already tested /v1/realtime, tell me what latency you're getting.

Sources

GitHub Actions Down Again? How to Mirror Your Repos to Codeberg Without Actions

Alan West — Sat, 31 Oct 2026 19:00:00 +0000

On October 30 at 17:50 UTC, GitHub started investigating degraded performance for Actions and Webhooks. Ten minutes later Pages was on the list too. By 18:06 they were reporting delayed workflows, delayed Pages deployments, delayed webhook events, and errors in code search and live updates. The incident was marked resolved at 19:23.

That's about 90 minutes on the status page. In the Hacker News thread, one commenter pointed out that the same incident happened 11 days earlier, and another counted "several Actions outages in the past two weeks."

The same day, Tangled published The federated code forge, arguing that relying on someone else for your uptime "hasn't played out well." I don't think the timing was planned. It still works as an ad.

My take: don't move everything off GitHub because of one bad Friday afternoon. Spend an hour this week mirroring your repos to Codeberg, a self-hosted Forgejo or Tangled, so the next outage costs you 10 minutes instead of a lost evening. Below: a status check you can alias, four ways to mirror, the popular setup that fails during an outage, and a CI fallback.

Step 0: check if GitHub is down before you debug your own pipeline

I've seen people (fine, I've been one of them) rerun a stuck workflow four times, roll back a commit and blame a Dependabot bump before checking whether GitHub itself is broken. GitHub's status page has a public JSON API, so make the check a shell alias:

alias ghdown='curl -s https://www.githubstatus.com/api/v2/components.json \
  | jq -r ".components[] | select(.status != \"operational\") | \"\(.name): \(.status)\""'

If that prints Actions: degraded_performance, close the laptop. To list active incidents, use https://www.githubstatus.com/api/v2/incidents/unresolved.json. The full endpoint list also covers summary, scheduled maintenance and incident history.

One caveat from the HN thread: people noticed the 30-day uptime bar staying green during acknowledged incidents, because partial degradation isn't counted as downtime. One commenter mentioned that a third-party status page had to be built to track Actions accurately. So a green bar on the status page tells you very little.

The trap: mirroring GitHub with a GitHub Action

The most common mirror setup I see is a workflow that runs git push --mirror to Codeberg on every push. It works fine until Actions goes down, and then the mirror stops updating at exactly the moment you need it.

Your mirror has to be updated by something that doesn't depend on GitHub's job queue. That leaves two options: your own machine, or a forge that pushes or pulls on its own schedule.

Option 1: one `git push`, two forges

This is the cheapest setup and needs no infrastructure. Git lets one remote have several push URLs:

# keep fetching from GitHub, but push everywhere
git remote set-url --add --push origin git@github.com:you/project.git
git remote set-url --add --push origin git@codeberg.org:you/project.git
git remote set-url --add --push origin git@tangled.org:you.tngl.sh/project

git remote -v
# origin  git@github.com:you/project.git (fetch)
# origin  git@github.com:you/project.git (push)
# origin  git@codeberg.org:you/project.git (push)
# origin  git@tangled.org:you.tngl.sh/project (push)

The first --add --push replaces the implicit push URL, which is why GitHub has to be listed explicitly. From then on, every git push goes to all three. You need to create the empty repos on Codeberg and Tangled first.

The weakness is that it only mirrors what you push from that clone. Merges done through the GitHub UI won't show up until someone pulls and pushes again. For a solo project that's fine. For a team, use option 3.

Option 2: Codeberg, which only takes pushed mirrors

Codeberg runs Forgejo, and Forgejo supports pull mirrors. Codeberg.org doesn't allow them, though. Their FAQ says that "mirrors that pull content from other code hosting services were problematic for Codeberg" and suggests manual mirrors with multiple remotes and git push --mirror instead (FAQ). That's option 1 again, and I think it's a reasonable rule for a nonprofit that pays for its own disks.

If the Codeberg copy is a backup and nothing more, turn off issues and PRs in the repo settings so nobody files bugs in the wrong place.

Option 3: self-hosted Forgejo pull mirror, then fan out

If you have a $5 VPS or a homelab box, this is the setup I'd pick, because it's the only one here that catches merges done in the GitHub UI. On your own Forgejo instance, create the repo with New Migration and check This repository will be a mirror. Forgejo then pulls from GitHub on a schedule, including changes made through the GitHub web UI.

You can then fan out from there: Settings > Repository > Mirror Settings > Add Push Mirror pushes to Codeberg, Tangled or GitLab. For GitLab, the Forgejo docs say to use oauth2 as the username and a token with the write_repository scope. SSH push mirrors generate an Ed25519 key that you add as a deploy key on the target.

Two warnings from those docs: push mirrors are forced and overwrite the remote, and LFS over SSH isn't implemented, so an SSH push mirror won't carry your LFS objects.

Option 4: Tangled, the federated forge on ATProto

Tangled is built on the AT Protocol, the same protocol Bluesky runs on. Repos live on "knots," which you can host yourself or leave on tangled.org. CI runs on "spindles." The October 30 release added knot2, a Rust rewrite of the knot server, and moved issues, PRs, comments, reactions and labels onto the knot as collaborative objects, each one "just a chain of Git objects in the repo itself." That matters for mirroring: if your knot holds the issues too, your backup carries the issue and PR discussion along with the commits. The blog's pitch is "Whatever you choose, you can still talk to everyone else."

Pushing to it is plain SSH. Add your key under Settings > Keys, then:

Host tangled.org
  Hostname tangled.org
  User git
  IdentityFile ~/.ssh/id_ed25519
  AddressFamily inet

For a backup, the gaps count for more than the features:

Private repos aren't available yet. A co-founder said on HN they're rolling out "in the following couple weeks," and another team member said they have a working demo. Until they ship, Tangled only works for public code.
HTTPS push and clone came up because people want knots behind Cloudflare. A team member replied that HTTPS push already works but isn't documented yet, so expect to figure it out yourself.
On Windows, one commenter couldn't clone a repo with a colon in a filename. That's a Windows limit, not a Tangled bug, but it'll bite you the same way.
Self-hosted knot operators have to upgrade to v1.20.0 for the new release.

Most of that thread is an argument about the protocol. One camp says ATProto "heavily lends itself to centralization." The other camp says relays are cheap and that ForgeFed, the ActivityPub approach Forgejo was working on, has been "in limbo forever." I lean toward Tangled here, but for a reason other than the protocol. A federated forge that ships stacked PRs today is more useful than a theoretically better protocol that hasn't shipped. Still, I wouldn't make a forge without private repos my only backup.

The CI fallback: Forgejo Actions, Woodpecker or Tangled spindles

A mirror with no CI is a read-only archive. You don't need to port your whole pipeline, just enough to run tests and cut a release by hand.

	Where it runs	Config	Notes
Forgejo Actions	Your runner, or Codeberg's limited hosted Actions	`.forgejo/workflows/*.yml`	Designed to feel familiar to GitHub Actions users, though not compatible; disabled by default per repo on Codeberg
Woodpecker CI	Codeberg's hosted instance (request access) or self-hosted	`.woodpecker.yml`	What Codeberg's docs recommend for hosted CI
Tangled spindles	Self-hosted runner, or third-party CI via tack	`.tangled/workflows/*.yml`	Nixery engine, deps from Nixpkgs

A minimal spindle workflow looks like this. The pipeline docs list push, pull_request and manual as events, and nixery as the only engine for now:

when:
  - event: ["push", "pull_request"]
    branch: ["main"]

engine: "nixery"

dependencies:
  nixpkgs:
    - go

steps:
  - name: test
    command: "go test ./..."

The useful part of the Forgejo runner is that it connects outbound to the forge, so a box behind NAT works. Codeberg's docs say it "does not need a public IP address." An old laptop in a closet is enough to unblock a hotfix.

The one-hour checklist

Add the ghdown alias, or a bookmark to https://www.githubstatus.com/api/v2/summary.json.
Create empty repos on Codeberg and/or Tangled.
Add them as extra push URLs on origin, or set up a pull mirror on your own Forgejo.
Make sure the mirror doesn't depend on GitHub Actions.
Copy your test job to one fallback CI and run it once, so you know it works before you need it.
Write down which secrets the release job needs and where they'd live on the backup forge.

I'm not leaving GitHub. It's still where people find your project, and it will probably stay that way. I just want "GitHub is down" to mean I push somewhere else for 90 minutes and keep working.

So: do you keep a mirror of your repos anywhere besides GitHub, or are you all in? And if you've tried Tangled's ATProto setup, is it federation or a nicer-looking single point of failure?

Sources

Is AI Making You a Worse Developer? Anthropic's Data Says Yes. Here's the Fix

Alan West — Sat, 31 Oct 2026 17:00:02 +0000

Is AI making developers worse? In the best controlled study I've found, yes. Anthropic had 52 mostly junior engineers learn Trio, a Python async library. The ones who used an AI assistant scored 17 points lower on the follow-up quiz than the ones who wrote the code by hand, and the gap was widest on debugging questions, which is the part of the job you get paged for at 3 a.m.

This week Hacker News had three threads on this going at once: SREs losing incident skills, Cisco handing a 27-year-old unlimited tokens to rewrite legacy code, and a lot of developers admitting they're just tired. Read next to the study, they're the same problem.

SigNoz on SREs losing incident skills

SigNoz's newsletter ran a piece called "AI isn't replacing SREs, it's deskilling them". According to the piece, AI now handles alert grouping, runbook execution, log pattern detection and auto-remediation for the easy failures, like restarting a crashed pod. Humans keep the leftovers: the novel, cascading, nobody-has-seen-this-before outages.

The author asks: "When AI handles 95% of your incident response, do you get worse at handling the 5% that actually matters?"

None of this is new. Lisanne Bainbridge described it in 1983 in "Ironies of Automation": the more you automate, the more the human matters during the rare failure, and the less practice that human has had. The article lists what this looks like on an on-call rotation:

You stop reading raw logs because the AI summarizes them.
You stop forming hypotheses because the AI suggests a root cause.
You stop building a mental model of the architecture because the AI maps dependencies for you.

Each of those is a productivity win on its own. Stack them up and you get an engineer who can't function when the summary is wrong.

The HN thread (601 points, 452 comments) mostly agreed, then argued about whether anyone will pay to fix it. digitallogic: "In the moment, getting the broken thing back up and running is seen as far more important than the learning opportunity." sshine got the whole article down to one line: "Atrophy happens when you trade understanding for productivity."

Cisco gives one engineer unlimited AI tokens to rewrite legacy code

The same week, Fortune reported that Cisco president Jeetu Patel handed Padmanabhan "Paddy" Krishnamurthy, 27, unlimited AI tokens to refactor Cisco's legacy code. Krishnamurthy pitched it as a job for a two-person team and has four weeks to prove the idea. The end goal is 98% of Cisco's legacy code refactored within 24 months.

"I've given him unlimited tokens because he's going to refactor code," Patel said. "So I'm like, you can go, you can go nuts."

I have nothing against the guy. He co-founded a startup Cisco acquired, so he has shipped real things. My problem is the framing. Executives now treat tokens as the scarce resource, and on a rewrite like this they aren't. The scarce resource is people who understand what the old code actually does, including the bugs customers depend on without knowing it.

The HN thread on that one went straight there. cromka: "some of the bugs have become features without users even knowing it." raizer88 had the punchline: "Followup question: did anyone read the automated test suite? Silence. The software rewrite is shelved."

So in one week we got engineers losing the ability to debug their systems, and a company betting it can rewrite its legacy code faster than anyone can read it.

What the research says about AI deskilling

Software isn't the only field with data on this:

Field	Study	What happened
Software	Anthropic RCT, Jan 2026, 52 mostly junior engineers learning Trio	AI group ~50% on the quiz vs ~67% hand-coding. Biggest gap on debugging. Time saved: ~2 min, not statistically significant
Medicine	Budzyń et al., Lancet Gastroenterology & Hepatology, 4 Polish centres	Adenoma detection in non-AI colonoscopies fell from 28.4% to 22.4% after doctors got used to AI assistance
Aviation	Behrend & Lafargue, IASS 2019	Air France eye-tracking study: hand-flying with the flight director on doesn't build the basic skills that flying with it off does, and long-haul pilots are most exposed to skill erosion. The SigNoz piece makes the same comparison with the FAA and manual flying time

The Anthropic one is worth reading in full. The authors are open about its limits (small sample, quiz taken right after a 35-minute coding task), and they say agentic tools like Claude Code could hit skill development harder than the sidebar chat assistant they tested.

The most useful part is the breakdown by how people used the AI. The groups are tiny (two to seven people each), so treat this as a hint. Participants who delegated everything scored around 39%. The "iterative AI debugging" group, the ones who kept pasting errors back in until something worked, scored about 24% and were also the slowest at roughly 31 minutes. The two people who generated code and then asked follow-up questions to understand it scored about 86%.

The way you use the assistant seems to matter more than whether you use one. The worst pattern in that study, on both speed and learning, was "paste the stack trace, apply the patch, repeat".

Developers are also exhausted

The third thread, "Ask HN: Are you tired too in this AI era?" (144 points, 139 comments), started with the poster describing having to "read enormous amounts of generated text." thunfischtoast: "I feel my brain atrophying. I forget how to do things." Gigachad, on PRs nobody understood: "I just don't have time to review 4000 lines of code."

This worries me more than the study. Tired engineers rubber-stamp, and rubber-stamping builds no mental model. The 3 a.m. outage then lands on someone who has approved a lot of diffs and understood very few of them.

5 ways to keep AI from deskilling you

I'm not giving up the tools. They're too good at the boring 80%. But I've started following a few rules, and they cost almost nothing.

1. Debug by hand for a few hours a week

Pick a block each week (I use Friday afternoons) where any bug you touch gets debugged with no assistant: logs, git bisect, a debugger, strace if it comes to that. On-call teams can copy the SigNoz suggestion of "deliberate inefficiency": send some incidents the AI could resolve to a human as practice. Airlines push pilots to hand-fly for the same reason.

2. Write your hypothesis before you paste the alert

Two lines in the incident channel: what you think broke, and what would prove you wrong. Then ask the model. If it agrees, your model of the system holds up. If it disagrees, you get to find out which of you is wrong, and that's the part where you learn something.

3. Make the agent explain before it fixes

Claude Code has a built-in setting for this:

/output-style learning

Learning mode adds Insight blocks explaining its choices and leaves TODO(human) markers for the parts with real design decisions. /output-style explanatory gives you the explanations without the homework. (The Anthropic study authors point to these same two modes.) To make it the default across projects, set it in ~/.claude/settings.json:

{
  "outputStyle": "Explanatory"
}

The value is case-sensitive, per the docs. "explanatory" silently falls back to Default. Whatever tool you use, put a rule like this in your project instructions:

Before proposing any fix for a bug or incident:
1. State the root cause in one paragraph.
2. Name the evidence (log line, metric, trace) that supports it.
3. Say what would make this diagnosis wrong.
Do not edit files until I reply "go".

4. Write the postmortem yourself

No AI drafts. Rebuilding the timeline by hand forces you to understand why the system failed, and that's how the mental model gets built. Use the AI afterwards to check you didn't miss anything.

5. Read the tests on any AI rewrite

If you're on a Cisco-style refactor, that raizer88 comment is your checklist. If nobody has read the test suite, nobody knows what "done" means.

Rusty seniors, juniors who never learn

I don't think AI is coming for most developer jobs this year. What I see happening is slower than that and harder to spot. Juniors are losing the hands-on incidents where people used to build intuition, which the SigNoz piece calls "never-skilling." The seniors are getting rusty at the one part of the job the AI still can't do, which is noticing when the AI's answer is confidently wrong.

So be honest: could you still debug a production outage today without an AI assistant? When did you last try?

Sources

How to Stop Claude Code From Reading Your .env File (Deny Rules Aren't Enough)

Alan West — Sat, 31 Oct 2026 15:10:00 +0000

Claude Code doesn't ask before reading files in your project. Anthropic's own permissions table says it: read-only tools like file reads and Grep need "No" approval within the working directory. Your .env sits in the working directory. So unless you've changed something, the agent can open it, put your Stripe key into its context, and quote it back in a debug log without ever asking.

.gitignore does nothing here. It only keeps the file out of commits. The agent reads straight from disk.

There's a fresh reason to care. On October 30, Phorion published an advisory about a backdoored "Claude Code for VS Code" build on the Cursor Marketplace, versions 2.1.312 and 2.1.313. It added an attacker's SSH key to ~/.ssh/authorized_keys, opened a reverse tunnel, and beaconed home with up to 40 environment variable names matching KEY|TOKEN|SECRET|PASS|AWS|GCP. On Hacker News, Anthropic's Felix Rieseberg said "it wasn't a compromise of Anthropic's systems or employee laptops." I don't much care whose fault it was. Every file your tooling can read is one bad update away from leaving your machine.

Below is my setup. The deny rule most guides stop at is only the first step, because Bash can still read the file around it.

Block Claude Code from reading .env with permissions.deny

Put this in ~/.claude/settings.json so it applies to every project:

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(**/secrets/**)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)"
    ]
  }
}

The first two rules handle .env. The other three are cheap to add while you're in there.

The path syntax trips people up. The docs' own example uses Read(./.env), which matches "the .env file in the current directory". A bare Read(.env) follows gitignore semantics and matches any .env at or under the current directory, so apps/api/.env in your monorepo is covered too. Also, don't put Read(/secrets/**) in user settings. There, a leading / anchors to ~/.claude, so it would block ~/.claude/secrets/** and leave your project alone.

What these rules cover, per the docs:

the Read tool, plus a best-effort pass over Grep, Glob, @file mentions and the open-file context the IDE extension shares
Edit and Write on the same path (Write needs v2.1.228+)
Bash commands Claude Code recognizes as file commands: cat, head, tail, sed, tee, and redirections like < .env (input redirects are checked from v2.1.257, tee targets from v2.1.269)

If you still have a .claudeignore file lying around, the docs say flatly that "it has no effect". Move its entries into deny rules.

Run /status afterwards and check that User settings shows up under Setting sources.

What deny rules don't cover: Bash can still read your secrets

Most "just add a deny rule" posts skip this part. According to the permissions warning box, deny rules don't apply to:

a command that reads files without naming them, such as grep -r pattern . run from the directory that holds the file, or to arbitrary subprocesses that read or write files indirectly, like a Python or Node script that opens files itself.

So cat .env gets blocked, but grep -r DATABASE_URL . or node -e "require('dotenv').config(); console.log(process.env)" doesn't. Nobody has to be malicious for this to happen. An agent debugging a connection error will try exactly those commands.

Close the Bash hole with the sandbox

This has to be enforced by the OS. Claude Code's sandbox uses Seatbelt on macOS and bubblewrap on Linux and WSL2, and the docs say Read and Edit deny rules get "merged into the final sandbox configuration". With it on, the kernel stops grep -r and that Node one-liner, where before they slipped past a string matcher.

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "filesystem": {
      "denyRead": ["~/.ssh", "~/.aws"]
    }
  }
}

Why the two less obvious keys are in there:

By default, if the sandbox can't start, Claude Code "runs commands without sandboxing". That fails open. failIfUnavailable: true makes it exit instead.
When a sandboxed command fails, Claude may retry it with dangerouslyDisableSandbox, and in bypassPermissions mode that retry runs without a prompt. allowUnsandboxedCommands: false turns the retry off.

The sandbox has two limits. Its default read scope is "most of the machine, including credential files such as ~/.ssh and ~/.aws/credentials", so you have to list what you want hidden. And on native Windows, commands run unsandboxed, full stop. Use WSL2.

If you're on v2.1.257 or later, also set "blockReadsOutsideWorkingDirectories": true under permissions. It makes Read, Grep, Glob and LSP refuse paths outside your project in every mode, including bypassPermissions.

A PreToolUse hook as a tripwire

I still run a hook with the sandbox on. You get a clear message in the transcript, and it works on machines where you can't sandbox. Save this as .claude/hooks/block-secrets.sh and chmod +x it:

#!/usr/bin/env bash
cmd=$(jq -r '.tool_input.command // empty')
if printf '%s' "$cmd" | grep -Eq '\.env([^A-Za-z]|$)|secrets/|\.ssh/|id_(rsa|ed25519)|\.aws/credentials'; then
  echo "Blocked: this command touches a secrets file. Ask the user for the value instead." >&2
  exit 2
fi
exit 0

Wire it up in .claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/block-secrets.sh",
            "args": []
          }
        ]
      }
    ]
  }
}

Exit code 2 blocks the call and sends stderr back to Claude as the reason, per the hooks docs. The regex is deliberately greedy: it also catches process.env.FOO and .env.example. I'd rather get a false positive than explain a rotated key to my team. It doesn't match .envrc, so add that if you use direnv.

It's only a string match on the command text, though, so grep -r pattern . sails right through it. Anthropic says the same about its own if filters: use the permission system, "rather than a hook to enforce a hard allow or deny". I treat the hook as a readable error message and leave the blocking to the sandbox.

The same fix in Cursor and Codex

Cursor gives you a better default. Its ignore docs say it respects .gitignore plus a built-in list that includes .env*, and you can add paths with .cursorignore. The same page also says: "The terminal and MCP server tools used by Agent cannot block access to code governed by .cursorignore." So you're back to the same Bash hole, without a sandbox config to close it.

Codex handles it as a filesystem permission profile, enforced on sandboxed commands. From the permissions docs, in ~/.codex/config.toml:

default_permissions = "project-edit"

[permissions.project-edit]
extends = ":workspace"

[permissions.project-edit.filesystem.":workspace_roots"]
"**/*.env" = "deny"

Watch for two things. If sandbox_mode shows up in any active config layer, or you pass --sandbox, Codex falls back to the legacy sandbox settings and your profile doesn't apply. And on Linux, WSL and some Windows modes, glob matches are captured "when each sandboxed process starts", so a long-running dev server won't see a .env you create later as denied. For env vars, set shell_environment_policy.ignore_default_excludes = false so Codex strips variables containing KEY, SECRET or TOKEN from subprocesses.

Tool	Default on `.env`	Built-in file tools	Shell commands
Claude Code	Readable, no prompt	`permissions.deny`	Only with `sandbox.enabled`
Cursor	Ignored (`.env*` on default list)	`.cursorignore`	Not blocked, per docs
Codex	Readable under `:workspace`	Permission profile `deny`	Enforced in sandbox, glob snapshot caveat

What none of this fixes

The backdoored extension never went through Claude Code's permission system. It ran inside the editor with your user's full access. No deny rule stops that. What helps is a separate user account or container for agent work (a couple of HN commenters suggest exactly this), and not keeping production secrets in plaintext files at all. Inject them at runtime from a vault or op run, and keep .env for local throwaway values.

If you installed 2.1.312 or 2.1.313 in Cursor, run grep -n svc-telemetry ~/.ssh/authorized_keys and check ~/Library/LaunchAgents/com.apple.sysmond.plist on macOS. The label is just a comment and trivial to change, so Phorion also says to check the fingerprint: run ssh-keygen -lf ~/.ssh/authorized_keys and look for SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk.

My minimum setup: the deny block, the sandbox with failIfUnavailable, and the hook as a tripwire. It takes ten minutes.

So where do your secrets actually live while you code with an agent: .env, a vault, or "I'd rather not say"? And if you think the sandbox is overkill for local dev, tell me why in the comments.

Sources

Claude Code Extension Backdoor in Cursor: Uninstalling Won't Remove the SSH Key

Alan West — Sat, 31 Oct 2026 13:20:01 +0000

If you run Cursor on macOS or Windows and it pulled the Claude Code extension (anthropic.claude-code) 2.1.312 or 2.1.313 on October 29, your machine may now have a stranger's SSH key in ~/.ssh/authorized_keys and a reverse SSH tunnel that restarts at login. Uninstalling the Claude Code extension doesn't remove it. Updating to 2.1.314 doesn't remove it either.

The check takes about 5 minutes and uses the indicators Cursor, Phorion and Microsoft published. After that I cover what to rotate and how to stop your editor from installing whatever turns up in a marketplace overnight.

What happened with the Claude Code extension backdoor in Cursor

According to Cursor's security notice, tampered builds of Anthropic.claude-code versions 2.1.312 and 2.1.313 for Windows and macOS were served from the Cursor Extension Marketplace between about 2:27am and 1:35pm PT on October 29, 2026. Cursor says those builds "were not developed by Anthropic". StepSecurity reports that, by Cursor's count, "at most 5,000" of its users received the trojanized build.

Phorion published a teardown. Someone had prepended code to the minified extension.js, and it runs as soon as Node loads the file, before activate is even called. You didn't have to click anything or open a Claude panel; loading the extension was enough.

The part that bothers me most is the listing itself. It used the real extension ID, the one you'd tell a junior dev is safe to trust. Most of us have learned to look out for typosquats like anthropic-official-claude, and that habit was no help here.

Who is affected (and who isn't)

The early headlines went too far. DoublePulsar ran "Anthropic hacked to deliver remote access trojan", but Anthropic engineers said on Hacker News that their systems and laptops weren't compromised. They also made sure their next real update was 2.1.314, "in order to disambiguate" it from the tampered builds. Per StepSecurity and Microsoft:

Where you got the extension	2.1.312	2.1.313
Cursor Marketplace (Win/macOS)	malicious build served Oct 29	malicious
Open VSX (VSCodium, Windsurf, etc.)	clean	not found
Microsoft VS Code Marketplace	not affected	never published

So plain VS Code and VSCodium users can relax, mostly. Cursor users on macOS or Windows who had the editor running that day should check. The implant also contains Linux persistence logic, so Linux Cursor users should run the checks too. They take about a minute.

I don't fully buy Anthropic's "not our systems" line as the end of the story, though. The extension said "Anthropic" on it. As one HN commenter put it, "the malware has their branding and their name on it." Cursor's own docs say extension searches and downloads go through its proxy at marketplace.cursorapi.com, and Anthropic's Felix Rieseberg wrote on HN that a malicious actor "used access to Cursor's marketplace" to ship the build under the real ID. Cursor's notice says it audited access and rotated keys, but not how the attacker got in. Until someone explains that, I think both companies own part of this.

Step 1: list your extensions and versions

cursor --list-extensions --show-versions | grep -i claude
code   --list-extensions --show-versions | grep -i claude
codium --list-extensions --show-versions | grep -i claude

A clean result here doesn't settle anything. If Cursor has already updated you to 2.1.314, the 2.1.313 folder is probably gone, but the persistence it dropped outside the extension folder is still there. Look on disk too:

ls -d ~/.cursor/extensions/anthropic.claude-code-* 2>/dev/null
find ~/.cursor/extensions -path '*claude-code*' -name extension.js \
  -exec shasum -a 256 {} \;

The backdoored extension.js hashes to ecb58cb29078d9646ad1dcdbe51526f2d9cfea06be5fb2ab183e8ecc3ab6bf15. Cursor's notice also lists VSIX hashes for each version and platform.

Step 2: check for the SSH key and persistence (macOS / Linux)

If you only run one set of checks, run these:

# 1. The planted login key
grep -n 'svc-telemetry' ~/.ssh/authorized_keys
ssh-keygen -lf ~/.ssh/authorized_keys | grep '0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk'

# 2. Dropped scripts and keys
ls -la ~/.config/.smt ~/.config/.smtk 2>/dev/null
ls -la /tmp/.stk_* "$TMPDIR"/.stk_* 2>/dev/null

# 3. macOS LaunchAgent pretending to be Apple
ls -la ~/Library/LaunchAgents/com.apple.sysmond.plist 2>/dev/null
launchctl list | grep sysmond

# 4. Linux cron entry
crontab -l 2>/dev/null | grep '\.smt'

# 5. Live tunnel
ps -eo pid,args | grep -E '134\.209\.82\.225|:0:localhost:22' | grep -v grep

Run the fingerprint check even if the grep finds nothing. Phorion points out that the malware looks for the string svc-telemetry and not the key itself, so a key with an edited comment would slip past a plain grep.

Step 2 (Windows)

Select-String -Path "$HOME\.ssh\authorized_keys","C:\ProgramData\ssh\administrators_authorized_keys" -Pattern 'svc-telemetry' -ErrorAction SilentlyContinue
Get-ScheduledTask -TaskName SysMon -ErrorAction SilentlyContinue
Test-Path "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup\sysmon.cmd"
Test-Path "$env:USERPROFILE\.config\smt.cmd"
Get-ChildItem $env:TEMP -Filter '.stk_*' -Force

Network indicators

If you have firewall, DNS or EDR logs, search them for:

134.209.82.225 on TCP 22 (reverse SSH as user tunnel, with -R *:0:localhost:22)
http://134.209.82.225:8099/beacon (HTTP POST)
SSH logins from 127.0.0.1 or ::1 using the svc-telemetry key. The operator comes back in through the tunnel, so the login looks local.

Microsoft's post includes Defender XDR hunting queries if your company runs that.

How bad is it if you find something?

The payload isn't very good, which is lucky. Phorion found that on macOS it runs systemsetup -getremotelogin without admin rights, gets an error, and so never turns Remote Login on. On Windows the OpenSSH install goes through a helper hardcoded to /bin/sh, which probably fails. Cursor says the attacker's server is now offline.

That said, if Remote Login was already enabled on your Mac, or sshd was already running on your Linux box, the tunnel pointed straight at it and the attacker had a working SSH path into your account for as long as it stayed up.

The beacon also sent your hostname, username, git email, public IP, and up to 40 environment variable names matching KEY|TOKEN|SECRET|PASS|AWS|GCP. Only the names went out, not the values, but that still gives the attacker a list of which machines hold AWS keys and which ones are worth logging into.

Clean up, then rotate

Cursor provides remediate-macos.sh (run as your user, not root) and remediate-windows.ps1 (run as Administrator) on the notice page. If you'd rather do it by hand:

Kill the ssh/autossh processes and their retry loop.
Unload and delete com.apple.sysmond.plist, remove the @reboot cron line, or delete the SysMon task and sysmon.cmd. Then delete ~/.config/.smt and .smtk.
Remove only the svc-telemetry line from authorized_keys, and delete the .stk_* files.
Check that Remote Login / sshd is in the state you expect.

Phorion warns that a bug in the malware's cron check can wipe your existing user cron jobs on repeat runs, so compare crontab -l against what you remember having.

If you found any artifact, rotate everything that user account could reach. Start with anything an env var name like AWS_SECRET_ACCESS_KEY or GITHUB_TOKEN pointed to, then:

your SSH keys (generate new ones and remove the old public keys from GitHub, GitLab and your servers)
git tokens, gh auth sessions, and npm/PyPI publish tokens
cloud credentials in ~/.aws, ~/.config/gcloud and ~/.azure
Anthropic, OpenAI and other API keys sitting in .env files

Do the rotation from a different machine. If you're a company with EDR, Microsoft and Cursor both suggest isolating the host and considering a rebuild. I'd rebuild any machine where you can't rule out an inbound login.

Pin extensions and stop auto-updating them

Auto-update is how a build like this reaches thousands of laptops without anyone clicking anything, and it's easy to switch off.

In VS Code, VSCodium or Cursor settings.json:

{
  "extensions.autoUpdate": false,
  "extensions.autoCheckUpdates": false
}

Cursor also has an install cooldown. Per Cursor's extensions docs, the per-user setting is extensions.installCooldownHours, and team admins can enforce "Marketplace Install Cooldown (hours)" fleet-wide under Team settings → Security & automation. The same page has an "Allowed extensions" list and "Require Extension Signature Verification". The team default is 0, meaning off. I'd set it to 72. An 11-hour exposure window means even a one-day delay would have skipped this entirely.

To pin a known-good version explicitly:

cursor --install-extension anthropic.claude-code@2.1.314

Yes, you'll lag a few days behind on features, and that's fine with me.

So, do you let your editor auto-update extensions, or did this just change your mind? And who do you think owns this one, Cursor for running the marketplace or Anthropic for the name on the box? Tell me in the comments.

Sources

Gemini 4 Carbon vs Claude Opus 5.5: #1 Overall, but Opus Still Wins at Coding

Alan West — Fri, 30 Oct 2026 21:24:18 +0000

Gemini 4 Carbon is the new #1 on the Artificial Analysis Intelligence Index v5 with 59 points. Claude Opus 5.5 has 58. On coding, which is what most of us actually pay these models for, Opus still wins: 62 to 59 on the Coding Agent Index and 56% to 51% on FrontierCode. And you can't call Carbon on the public API yet.

The headline is true. It also tells you almost nothing if you're picking a model for your editor or your agent loop. I went through the published numbers for Gemini 4 Carbon vs Claude Opus 5.5 vs GPT-6.1 (per-benchmark scores, price per million tokens, cost per task, speed, context window) to see where each one wins. I didn't run anything myself. Every number below comes from Artificial Analysis or the vendors' pricing pages.

Gemini 4 Carbon vs Opus 5.5 vs GPT-6.1 Sol: the full scoreboard

First, "GPT-6.1" isn't one model. OpenAI has GPT-6.1 Sol (released September 29) and the cheaper GPT-6.1 Terra. Sol scores higher on the Index (55), so that's what I'm comparing. OpenAI's highest scorer is still the older GPT-6 Astra at 57.

	Gemini 4 Carbon (high)	Claude Opus 5.5 (max)	GPT-6.1 Sol (max)
Intelligence Index v5	59	58	55
Coding Agent Index	59 (Antigravity CLI)	62 (Claude Code)	n/a
FrontierCode v1.1	51%	56%	n/a
AA-Omniscience v1.1	54	48	n/a
Hallucination rate	11%	50%	n/a
Price in/out per 1M tokens	$4 / $20	$4 / $20	$2 / $10
Cost per Index task	$7.76	$10.04	$1.27
Output speed	82.5 t/s	96.6 t/s	81.1 t/s
Context window	1M	1M	1M
Can you use it today?	selected users only	yes	yes

Sources: the Carbon launch write-up, the Index v5 announcement, and the AA model pages for Carbon, Opus 5.5 and GPT-6.1 Sol. The n/a cells are Sol numbers I couldn't find in any of them.

Look at the list prices first. Carbon and Opus 5.5 are both $4 input and $20 output per million tokens, and both get a 95% cache discount down to $0.20. Calling Carbon "cheaper" only works for two reasons. One is a 50% launch discount that Google hasn't put an end date on. The other is token count.

Where Gemini 4 Carbon wins: fewer hallucinations

On AA-Omniscience v1.1 Carbon scores 54 to Opus 5.5's 48. Its hallucination rate is 11%. Opus 5.5 (max) and GPT-6 Astra (max) both sit at 50%. If you're building something that answers questions from its own knowledge (support bots, research assistants, anything where a confident wrong answer costs you), that gap is far bigger than the one-point gap on the Index.

One caveat: that 11% is up from 4% on Gemini 4 Argon. Google traded some caution for accuracy. And the Hacker News thread has people saying Argon made things up anyway: invented paragraphs in project summaries, a fake espresso machine. A benchmark hallucination rate and your production hallucination rate aren't the same number.

Carbon also uses fewer tokens. AA measured 123k output tokens per Index task, against 173k for Opus 5.5 at max effort, which is 29% fewer. That's where the ~23% cost-per-task advantage ($7.76 vs $10.04) comes from. The per-token price is identical, so the saving is all in how much each model writes.

It's #1 on 4 of the 9 Index evaluations: HLE-Diamond, Terminal-Bench-Science, AA-Omniscience and AutomationBench-AA. Three of those sit in the Science and General categories; AutomationBench-AA is the only Knowledge Work one.

Coding: Opus 5.5 is still ahead

One of the key results in AA's own write-up is literally titled "Behind only Claude Opus 5.5 on coding agents." The details:

Coding Agent Index: Carbon in Antigravity CLI scores 59. Claude Code with Opus 5.5 (max) scores 62.
FrontierCode v1.1: Carbon 51%, Opus 5.5 56%.
Terminal-Bench 4.0: Carbon 64%, which AA says is second place.

Three points on a composite isn't a blowout. But the Coding Agent Index scores the model inside its agent harness, which is closer to how you'll actually use it, and Opus is ahead there. One HN commenter put it bluntly: "Carbon scoring below Opus 5.5 on coding highlights how magnificent Opus 5.5 is as a coding agent."

So Carbon took the overall #1 by winning science and knowledge, while Opus is ahead on the Coding Agent Index and FrontierCode. In Index v5 the categories are weighted equally: Knowledge Work 25%, Coding 25%, Science 25%, General 25%. Terminal-Bench-Science alone is 15% of the total. If you never ask a model to do lab-style science in a terminal, 15% of that "59" isn't measuring anything you'll use.

GPT-6.1 Sol is the one that should worry Google

Everyone's arguing about first and second place, and meanwhile GPT-6.1 Sol scores 55 for $1.27 per Index task. That's about 6x cheaper than Carbon and about 8x cheaper than Opus 5.5 at max effort, for a model 3-4 points behind.

On CritPt v2 (hard subset), Sol scores 69%. Opus 5.5 scores 61%. On Terminal-Bench-Science, Sol gets 58% and Opus gets 59%, which is close to a tie.

There's a catch if you work with big contexts. OpenAI's pricing page charges more above 272K input tokens. Sol goes from $2/$10 to $4/$15, and Terra goes from $1/$5 to $2/$7.50. Anthropic bills Opus 5.5 at standard rates for the whole 1M window. A 900k-token request costs the same per token as a 9k one.

Long context: the Index stopped measuring it

All three advertise roughly 1M tokens. What bothers me is that Index v5 removed AA-LCR, the long-context reasoning benchmark, along with GDPval-AA and SciCode. So the #1 ranking contains zero direct evidence about how any of these models reasons over 500k tokens of your codebase.

What you can compare is cost. Opus 5.5 has flat pricing across the full window. Sol charges double for input above 272K. For Carbon, AA lists only the $4/$20 headline, the cache discount and the launch discount, and you can't call it publicly yet anyway.

Speed matters for long-context work too. AA lists Opus 5.5 at 96.6 tokens/s, Carbon at 82.5 and Sol at 81.1. Time to first token is ugly across the board at these reasoning settings: 103.54s for Carbon, 277.18s for Sol, and 644.22s for Opus 5.5 at max. Nobody is running max effort interactively.

Which model I'd pick for coding, pipelines and Q&A

Coding agents, refactors, repo-wide changes: Claude Opus 5.5 in Claude Code. It leads the Coding Agent Index (62 vs 59) and FrontierCode, and you can use it today.
High-volume pipelines, CI bots, eval loops: GPT-6.1 Sol. 55 points for $1.27 a task. Keep prompts under 272K or the price jumps.
Factual Q&A, research, anything where hallucinations hurt: Gemini 4 Carbon, once you can actually get access. An 11% vs 50% hallucination rate is the biggest real gap in this whole comparison.
Long context on a budget: Opus 5.5 for predictable billing up to 1M, but test it on your own data, because the index no longer measures this.

Before you switch anything, check two settings.

Effort. Opus 5.5 scores 35 at low effort and 58 at max. At low effort it costs $0.98 per task. GPT-6.1 Sol's low-to-max spread is 20 points. The "same model" can be a different product depending on one parameter, so compare at the effort level you actually run.
Whether you're caching. Opus 5.5 and Carbon both discount cached input by 95%, down to $0.20 per 1M tokens. If your agent re-sends the same repo context every turn and you aren't caching, you're paying for it again on every turn.

About that #1

The thread's other big argument is about trust. AA now says 60% of the Index comes from private test sets or held-out answers. One camp calls that unverifiable. The other says it's the only defense against benchmaxxing. I'm in the second camp, but private tests also mean you can't check how much the weighting decides the ranking. A one-point lead under a reweighting that happened in the same week as the launch deserves some skepticism.

My take: Carbon earned the headline by being the most careful model on knowledge questions. It hasn't earned your coding workflow, and you can't even buy it on the API yet.

Would a #1 ranking get you to switch away from your current model, or does your coding workflow keep you where you are? If you've had early Carbon access, tell me whether that 11% hallucination number matches what you're seeing.

Sources

How to Run LiquidAI d1-Omni-2B Locally (It Hears Audio but Can't Talk Back)

Alan West — Fri, 30 Oct 2026 16:40:01 +0000

If you came here hoping to run LiquidAI d1-Omni-2B locally as a small voice assistant, I'll save you the download first: it can't talk back, and it can't write back either. It listens to audio and returns typed answers with probabilities attached, and that's all you get out of it.

Hugging Face files d1-Omni-2B under audio-text-to-text, and that label sets the wrong expectations. Liquid calls it a "decision model". You give it a state (text, JSON, an image, a video, or an audio clip) and a set of named questions, and it answers all of them in one forward pass with zero generated tokens. The card says plainly that it "writes no transcript or speech", and the docs say it is not a chat model.

I think that's a good design, for reasons I'll get to below. But it changes what "running it locally" means, so here's what the 2B adds over the 600M, how much RAM it needs, and what works today in transformers, llama.cpp, Ollama, MLX and ONNX (as of late October 2026). All benchmark and speed numbers below are Liquid's own. I haven't run it myself.

What d1-Omni-2B actually does

You ask typed questions and get typed answers:

noul: yes/no, returns P(yes)
choice: one of several named options, with probabilities
score: an ordinal scale of 2 to 10 levels ("Agitated", "Neutral", "Calm")
in transformers, not yet in llama.cpp: multiple choice, extraction of text/number/date spans, number estimates with intervals, and bounding boxes

That fits call routing ("billing, technical or fraud?"), voicemail triage, sound event detection, or a cheap check at the front of a pipeline before a bigger model gets involved. Questions can even be spoken: the instructions field takes an audio clip. For text- or image-only work, Liquid's card itself tells you to use d1-2B instead, which beats the Omni on most rows.

d1-Omni-2B vs d1-omni-600M: what 3x the parameters buys you

The 600M came out with the Open d1 release on October 7, 2026, billed as Liquid's "first experimental checkpoint". According to OrcaRouter's repo write-up, the 2B repo was created on October 24. The 2B sits on a different base model, so treat it as a separate model rather than a bigger 600M:

	d1-omni-600M	d1-Omni-2B
Parameters	587M	2.17B
Base	LFM2.5-Encoder-350M	LFM3-Omni-2B
Context	16,384 tokens	128K tokens
Audio input	one 16 kHz mono clip, up to 30 s	clips + spoken questions
Images + audio in one request	no (`ValueError`)	yes
Speech languages	trained on English requests	12 (the 16 text languages minus Hindi, Thai, Vietnamese, Indonesian)
Decision Index v0.3	18.3	49.0
Average (public decision + image benchmarks)	42.8	67.7
Min transformers	5.15	5.19

The jump is large. Liquid says the 2B beats the 600M on every benchmark it reports, and beats d1-3B on the decision board and on 16 of 18 image benchmarks with about 70% of the parameters. VisualWebBench goes from 14.9 to 88.6. The 600M card reports no audio benchmarks at all, so there's no audio comparison to make between the two.

Audio scores: written vs. spoken input

The 2B card does publish audio scores, and they're worth a careful look. Each task is scored twice, once with the input written as text and once with the same input read aloud. The gap between the two columns is what the speech path costs you:

Test	Written	Heard
SLURP (assistant commands, real speakers)	87.4	81.7
Speech-MASSIVE (12 languages)	85.2	63.4
FLEURS (spoken language ID, 43 languages)	92.4	92.5
ESC-50 (sound events)	n/a	84.5
Spoken short states	42.0	22.8
Belebele (passages, 8 languages)	83.6	41.8

Short English commands and sound classification hold up. Long passages and non-English speech fall apart: Belebele loses half its score once you speak it. The card admits that "long spoken passages lose much of their accuracy, most of all outside Latin-script languages." If you're building multilingual voicemail triage, run your own eval before you trust it.

How much RAM and VRAM d1-Omni-2B needs

Liquid publishes no memory requirements, so here's the arithmetic plus the file sizes they do publish. At 2 bytes per parameter, 2.17B is about 4.3 GB of weights, which matches the single 4.33 GB BF16 safetensors file. Being a hybrid (13 short-convolution layers, 5 sliding-window, only 6 global attention), it should keep a smaller KV cache than a pure transformer at long context. And since it never decodes, you only pay for the prefill.

Build	Size on disk	Where it runs
Safetensors BF16	4.33 GB	transformers (CUDA, MPS, CPU in fp32)
GGUF BF16 / F16	3.47 GB	llama.cpp
GGUF Q8_0	1.85 GB	llama.cpp
MLX 8-bit	2.71 GB	Apple Silicon
ONNX q4	2.45 GB	CPU
ONNX q4f16	2.20 GB	GPU / WebGPU
ONNX fp32	8.32 GB	reference

Watch the CPU path in transformers: the sample code loads in float32 on CPU, so budget for roughly double the BF16 footprint, around 8.7 GB by my math. The GGUF sizes are the language model only; llama.cpp also pulls an mmproj file for audio and images (0.33 GB at Q8_0, 0.61 GB at BF16). On an 8 GB laptop, use the Q8_0 GGUF or ONNX q4.

Runtime status: transformers, llama.cpp, Ollama, MLX

transformers

Full support, including every question type. It needs remote code:

pip install "transformers>=5.19" torch torchvision pillow

import torch
from transformers import AutoModel

device = "cuda" if torch.cuda.is_available() else "mps" if torch.backends.mps.is_available() else "cpu"
dtype = torch.float32 if device == "cpu" else torch.bfloat16
model = AutoModel.from_pretrained("LiquidAI/d1-Omni-2B", trust_remote_code=True, dtype=dtype).to(device)

Then call model.system_one(state, questions, media=...). WAV files need to be 16-bit PCM and get resampled to 16 kHz.

llama.cpp

It works from build b11960 (v0.8.0) using the official GGUF, but only for noul, choice and score. Extraction, estimates, boxes and multi-select aren't supported there yet. On a laptop, this is what I'd run:

llama-server -hf LiquidAI/d1-Omni-2B-GGUF:Q8_0 -b 8192 -ub 8192

Don't drop the batch flags. Each question's full state and media has to fit in a single batch. An image can use at most half of -ub, so 8192 gives it the full 4096-token budget. Then POST audio to the custom endpoint (this is the card's audio example):

curl -sL -o jfk.wav https://github.com/ggml-org/whisper.cpp/raw/master/samples/jfk.wav

curl http://127.0.0.1:8080/v1/systemone -H "Content-Type: application/json" -d @- <<JSON
{
  "state": "Recording from a public event.",
  "files": ["data:audio/wav;base64,$(base64 < jfk.wav | tr -d '\n')"],
  "questions": {
    "kind": {"type": "choice", "instructions": "What kind of utterance is this?",
             "criteria": {"request": "A request to do something",
                          "question": "A question asking for information",
                          "speech": "A speech to an audience"}},
    "calm": {"type": "score", "instructions": "How calm is the speaker?",
             "criteria": ["Agitated", "Neutral", "Calm"]}
  }
}
JSON

Spoken questions work here too: put an input_audio part in a question's instructions.

Ollama

There's an official d1-omni library entry with a 2b tag at 4.4 GB. That's roughly the BF16 checkpoint, so don't expect a small quant. It serves the same /v1/systemone endpoint on port 11434, and the CLI gets an --ask flag. The page's own example:

curl http://localhost:11434/v1/systemone \
  -H "Content-Type: application/json" \
  -d '{
    "model": "d1-omni:2b",
    "state": "Hello World",
    "questions": {
      "says_hello": {
        "type": "noul",
        "instructions": "Does the state text contain a greeting?",
        "criteria": {
          "true": "The state text contains a greeting.",
          "false": "The state text does not contain a greeting."
        }
      }
    }
  }'

There's a catch. When I checked, the readme on that page still described the 600M (587M parameters, English speech only, 30-second clips, no audio and images together), and Liquid's d1-Omni-2B docs page only covers transformers and llama.cpp. Compare the 2B tag against transformers on a few of your own clips before you rely on it.

MLX

Official builds exist (fp16, 8-bit) and run through mlx_vlm, but the card itself says "Support for d1 in MLX-VLM is in progress". The examples may need an mlx-vlm release that doesn't exist yet. On a Mac I'd stick with transformers on MPS for now.

ONNX

The ONNX repo is the one I'd keep an eye on. It has CPU q4/q8 bundles and a WebGPU path via onnxruntime-web/webgpu, so routing audio in the browser looks doable.

Speed: fast on GPUs, and no CPU numbers yet

Liquid's bf16 numbers after model.compile(), for a 10-second audio clip: 12.4 ms on an H100 PCIe, 8.2 ms on an MI325X, 33.3 ms on an Apple M5 Pro. A single question on the M5 Pro takes 21.1 ms. Nothing gets decoded, which is why the numbers are that low.

Liquid doesn't publish any CPU or Raspberry Pi number for this model. I'd ignore any headline that says it "runs on CPU" until someone posts timings. It will run, since the ONNX CPU builds exist, but nobody has said how fast.

License: free until you hit $10M revenue

The weights ship under the LFM Open License v1.0. Commercial use is free under $10 million USD annual revenue, counted across your whole corporate group. Above that, you need a separate license. The threshold also applies to your downstream customers, and violating any term terminates the license immediately. That's fine for hobby projects and startups. If you ship it in an enterprise product, talk to a lawyer before it goes out. The Open d1 blog's "without restrictions" line is more generous than the actual license text.

My take

Skipping generation is the right call for this job. When I'm routing a call I want {"team": "billing", "confidence": 0.94} back in 20 ms, with a probability I can put a threshold on; a 300-token explanation is just latency. The 600M was a research preview. The 2B is the first d1-Omni I'd consider putting in a real pipeline, as long as the audio is short, mostly English, and you've calibrated thresholds on your own recordings, which the card also tells you to do.

Is 2B the sweet spot for an on-device voice model, or would you rather run the 600M on a Pi and accept the accuracy hit? And if you've run d1-omni:2b in Ollama, do its probabilities match what transformers gives you for the same clip? Tell me in the comments.

Sources

Cursor Agent SDK vs Claude Agent SDK: Every Model Is Billed Through Cursor

Alan West — Fri, 30 Oct 2026 15:10:02 +0000

The npm package for Cursor's new Agent SDK isn't @cursor/anything. According to the docs, you install it with:

npm install --global @grok/agent-sdk

That package name breaks the usual framing of the Cursor Agent SDK vs Claude Agent SDK question, which goes "editor company with a model-agnostic harness vs model company pushing its own model." SpaceX closed its $60B acquisition of Cursor on August 14 and folded it into SpaceXAI, and Cursor's own pricing page now lists Grok 4.x as a "Cursor model". So both of these SDKs come from a company that trains models. And whichever model you pick in Cursor's SDK, Claude and GPT included, the inference runs through Cursor and so does the bill.

I went through the docs, changelogs and the HN thread (141 points, 132 comments) for Cursor's Agent SDK, Anthropic's Claude Agent SDK and OpenAI's Agents SDK. I haven't run any of them, so everything below is what the vendors published, with links.

What Cursor actually shipped

Cursor announced the Agent SDK on October 20. The changelog marks 0.3.0 (2026-10-23) as the GA release. It's the framework Cursor uses internally for Bugbot, Security Reviewer and Rollouts.

An agent is a folder of Markdown and TypeScript. Prompts live in .md (or .ts) files, you write the tools, and Cursor's harness runs the model loop. The CLI needs Node 22.13 or newer:

agent-sdk login
agent-sdk init ./my-bot
agent-sdk dev        # local playground
agent-sdk validate --dir .
agent-sdk deploy     # Cursor-managed hosting

The CLI also covers evals, logs, deployment secrets, Slack setup and webhook replay for GitHub, GitLab, Bitbucket and PagerDuty. Subagents are defined in the project itself. If you don't want Cursor hosting it, the docs say you can run it on your own infrastructure. One team at Cursor built its internal kb-reviewer PR bot "in about a day."

There's some naming mess. The announcement's code sample imports defineAgent from @cursor/agent-sdk. The docs install @grok/agent-sdk and note it used to be @cursor/bdk. On top of that there's a separate, older @cursor/sdk (April 2026) for calling Cursor's agent from your own code, and the Agent SDK docs say it runs on that same Cursor SDK harness. Pin your versions.

Cursor Agent SDK vs Claude Agent SDK vs OpenAI Agents SDK: the table

	Cursor Agent SDK	Claude Agent SDK	OpenAI Agents SDK
Install	`npm i -g @grok/agent-sdk`	`npm install @anthropic-ai/claude-agent-sdk` / `pip install claude-agent-sdk`	`pip install openai-agents` / `npm install @openai/agents zod`
Languages	TypeScript (+ Markdown prompts)	TypeScript, Python	Python, TypeScript
Runtime minimum	Node 22.13	Node 18.14 / Python 3.10	Python 3.10 / Node 22
Models	Cursor's catalog: Composer 2.5, Grok 4.x, Claude, GPT, Gemini, DeepSeek, GLM, Kimi	Claude only	OpenAI by default; others via Chat Completions, LiteLLM (beta), Any-LLM (beta)
Where inference goes	Through Cursor	Anthropic API, Bedrock, Google Cloud's Agent Platform, Microsoft Foundry, Claude Platform on AWS	Wherever you point it
MCP	Yes	Yes	Yes
Built-in coding tools	Cursor's harness	Read/Edit/Bash/Glob/Grep/WebSearch etc.	You bring them (plus sandbox agents)
Hosting	Cursor-managed or self-hosted	Self-host; Managed Agents if you want Anthropic to run it	Self-host
Sandboxing	`local.sandbox`, off by default	Permissions + hooks; container isolation is on you	Sandbox agents: Unix-local, Docker, hosted
Pricing	Token-based, same pools as the IDE	API token pricing	Whatever your model provider charges
License	Proprietary (Cursor Terms of Service)	Anthropic Commercial Terms; bundles the closed Claude Code binary	MIT

Every row is sourced in the list at the end. A few of them need more room than a table cell.

"Model-agnostic" here means agnostic within Cursor

Model choice is Cursor's main selling point. On the Cursor TypeScript SDK the docs say it plainly: "All inference goes through Cursor's hosted models in both modes." You can switch from composer-2.5 to a Claude or GPT model by changing one field, but the bill always comes from Cursor.

Under the current plans, third-party models are billed at API list price on Premium ($30/mo) and up. On Teams and Enterprise there's also a Cursor Token Rate of $0.25 per million tokens on eligible third-party models. SDK runs "follow the same pricing, request pools, and Privacy Mode rules as runs from the IDE." The Agent SDK docs don't list a separate price for hosted deployments, so you can't budget hosted agents from the docs alone yet.

So you can swap models all day, but leaving Cursor means a rewrite. The lock-in is the Cursor account, and picking a different model in the config does nothing about it.

Claude Agent SDK: one model family, five ways to pay

The Claude Agent SDK gives you "the same tools, agent loop, and context management that power Claude Code" in Python and TypeScript. Under the hood it spawns a claude CLI subprocess per session. It runs Claude models only, but you can pay for them through Anthropic's API, Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform or Microsoft Foundry:

export CLAUDE_CODE_USE_BEDROCK=1   # or CLAUDE_CODE_USE_VERTEX=1, CLAUDE_CODE_USE_FOUNDRY=1

So you depend on one model family but not on one vendor account. For a company that already has an AWS or Azure commit, that's a lot easier to get through procurement than another SaaS bill.

The hosting docs are refreshingly concrete. Start at 1 GiB RAM, 5 GiB disk and 1 CPU per agent. A minimal container costs "roughly $0.05 per hour," and token cost "typically dominates container infrastructure cost by an order of magnitude or more."

The part people argue about is subscriptions. The docs say: "Unless previously approved, Anthropic does not allow third party developers to offer claude.ai login or rate limits for their products." Plan on API billing. A long stretch of the HN thread was people disagreeing about whether claude -p and the SDK draw from Max limits, which tells you how unclear that line is in practice.

Does Claude work better in Claude's own harness?

This was the best exchange on HN. One commenter argued "there's reason to believe that Claude itself works better with Claude Code than with other harnesses," and another replied that labs generally tune models alongside a specific harness. If that's true, a model-agnostic harness is always running someone else's model a bit off-tune.

I think it's true in part. Cursor's argument works the same way, just for Composer and Grok: those are the models its harness is tuned for. With Claude in Cursor's harness, you get Cursor's tool definitions and prompts, not Anthropic's. Neither vendor publishes a cross-harness benchmark, so take any "better" claim as marketing until one shows up.

OpenAI's SDK is the only one with nothing closed underneath

The OpenAI Agents SDK is MIT-licensed and the most provider-agnostic of the three. The caveats are in its own docs. LiteLLM support is "best-effort, beta." Some providers "don't have support for structured outputs." Tracing uploads fail with a 401 if you don't have an OpenAI key. It also ships a much thinner coding harness. You get sandbox agents with Unix-local and Docker clients, but not a ready-made Claude Code or Cursor agent.

What I'd pick

For a PR bot or code reviewer you want shipped this week, I'd pick the Cursor Agent SDK. agent-sdk deploy, PR triggers and evals out of the box beat wiring all that up yourself. Accept that you're a Cursor customer for as long as it runs.
For an agent inside your own product, especially a multi-tenant one, I'd pick the Claude Agent SDK. It has the best-documented production story of the three, and your inference bill can sit with your cloud provider.
If exit cost is what you care about most, go with the OpenAI Agents SDK and write the coding tools yourself.

A checklist for whichever you pick

Put your tools behind MCP servers. All three SDKs speak MCP, so your tools are the part you can move to another SDK. Prompts in Markdown move easily too. Harness-specific hooks don't.
Running Cursor agents locally? Set local.sandbox in defineAgent. It's off by default, which means shell commands auto-approve and inherit the host's credentials. With it on, shell commands run without network access and writes outside the session workspace are refused.
Running the Claude SDK for multiple tenants? Pass settingSources: [], set CLAUDE_CODE_DISABLE_AUTO_MEMORY=1, and give each tenant its own cwd and CLAUDE_CONFIG_DIR. Otherwise one tenant's CLAUDE.md can leak into another's session.
Set maxTurns. Claude's docs say outright that there's no top-level session timeout.

So: would you build your agent on an editor company's SDK or a model company's, now that Cursor is technically both? I think the harness matters less than whose invoice it's on, and I'd like to hear from anyone who has shipped on one of these and disagrees.

Sources

Cursor: Agent SDK announcement, Agent SDK docs, CLI reference, changelog, TypeScript SDK docs, Cursor SDK post, models and pricing
Anthropic: Agent SDK overview, quickstart, hosting
OpenAI: Agents SDK (Python), models, sandbox agents, openai-agents-js
Discussion: Hacker News thread; acquisition: The Next Web (deal terms), Yahoo Finance (close)

How to Run Tencent WeVisOne-VL-4B Locally on 8 GB VRAM (Ollama Drops the Masks)

Alan West — Thu, 29 Oct 2026 19:00:03 +0000

Tencent's WeVisOne-VL-4B picked up 5,986 Hugging Face downloads last month, and I suspect a lot of those people expected another small chat-about-your-image model. It's a perception model instead: boxes, points, counts, text locations, segmentation masks and alpha mattes, all from one 4B checkpoint built on Qwen3-VL. You can run WeVisOne-VL-4B locally on an 8 GB GPU with a Q4_K_M GGUF in llama.cpp, and the Hub offers a one-line Ollama pull too. You just lose the masks when you do.

I went through the model card, the GitHub README, the config and the GGUF repos. This post covers what the model is, Tencent's numbers against Qwen3-VL-8B (and the baseline they left out), VRAM per format, and the two ways to run it.

What WeVisOne-VL-4B actually is

The model card says it comes from WeChat Vision at Tencent and is built on Qwen3-VL. The config.json confirms it: Qwen3VLForConditionalGeneration, 36 text layers, hidden size 2560, a 24-layer ViT with patch size 16. That's the Qwen3-VL-4B layout with a 152,680-token vocabulary.

The extra tokens are the trick. Coordinates are emitted as <0> to <1000> (normalized boxes and points), and every predicted box in dense tasks is followed by an <OBJ> token (ID 152678). A separate 9.6M-parameter pixel decoder, shipped as mask_decoder.pt, reads those <OBJ> positions plus multi-level ViT features and produces masks and stride-1 alpha mattes, so there's no SAM in the loop.

The task list from the GitHub repo: detection, referring, point, count_box / count_point, ocr / ocr_grounding, segmentation, matting.

Other facts worth knowing before you download:

License: Apache-2.0 for Tencent-authored code; third-party components keep their own licenses.
Context: max_position_embeddings is 262144, same as the Qwen3-VL base. Tencent's evals cap images at 1,960 visual tokens, so context isn't the constraint here.
Single-turn, single image. The pixel decoder rejects video grids, and the model returns structured output without chain-of-thought.
It answers None when the thing you asked for isn't in the image, which matters more than it sounds (see the benchmarks).
There's also a 2B sibling. Paper is arXiv:2610.31329, submitted 22 Oct 2026.

WeVisOne-VL-4B vs Qwen3-VL benchmarks, and who's missing

All numbers below are from the GitHub README. Tencent compares against Qwen3-VL-8B, Qwen3.5-9B, Rex-Omni-3B, LocateAnything-3B and a few specialists.

Task (metric)	Qwen3-VL-8B	Qwen3.5-9B	Rex-Omni-3B	LocateAnything-3B	WeVisOne-VL-4B
LVIS detection (F1)	42.9	43.7	46.9	50.7	55.3
Dense200 detection (F1)	13.8	18.0	58.3	58.7	71.3
RefCOCOg test (F1)	74.9	74.6	74.3	77.6	81.8
WeRef rejection rate	18.3	70.7	43.3	73.0	96.4
PixMo-Count acc	n/a	80.4	71.9	82.8	89.6
TotalText OCR (F1)	35.4	n/a	40.6	43.3	52.0
SROIE OCR (F1)	43.3	n/a	44.8	40.3	68.1

On matting (MAD ×10³, lower is better), WeVisOne-VL-4B scores 9.8 on Tencent's WeRefMat referring benchmark against 22.4 for a Qwen3.5-9B + SAM2-Matting pipeline. On ReasonSeg val it gets 71.2 gIoU vs 65.0 for a fine-tuned LISA-13B.

The rejection numbers are the ones I care about. Qwen3-VL-8B on the WeRef set rejects absent targets 18.3% of the time, which means it draws a box around something that isn't there most of the time. At 96.4% you can put the detector in a pipeline; at 18.3% you end up babysitting it. One caveat: WeRef-Bench and WeRefMat are Tencent's own benchmarks.

The 2B sibling is closer than you'd expect: 53.3 on LVIS, 92.9% WeRef rejection, 88.1 on PixMo-Count. If the 4B doesn't fit your card at bf16, the 2B through the official package is the one to try before you give up on masks.

I do have complaints about the comparison. Qwen3-VL-4B isn't in the tables. This model is a 4B built on Qwen3-VL, and Tencent compares it with the 8B. I'd like to know how much of the gain comes from the fine-tuning and how much from the base, and the one baseline that would tell us is missing.

There's no Gemma and no general VLM benchmark either: no DocVQA, no OCRBench, no MMMU, no chart QA. That fits what the model is for, but it leaves the "vs Qwen VL and Gemma" question unanswered for general image chat, and nobody has published those numbers yet.

People are already questioning the baseline selection. Discussion #3 on the model page asks how the baselines were selected, pointing out that the GroundingPI paper reports additional baselines and higher scores on some overlapping benchmarks, and how the model compares with frontier proprietary models. No reply at the time of writing.

How much VRAM it needs: bf16 vs Q8_0 vs Q4_K_M

Tencent publishes no VRAM figures. The table below is estimated from file sizes. These are weight sizes only; activations and KV cache come on top.

Format	Weights	Vision projector	Total on disk	8 GB card?
f16 GGUF	8.84 GB	0.84 GB (f16 mmproj)	~9.7 GB	No
Q8_0 GGUF	4.70 GB	0.45 GB (Q8_0 mmproj)	~5.2 GB	Yes
Q4_K_M GGUF	2.72 GB	0.45 GB	~3.2 GB	Easily

Sizes are the actual file sizes in mradermacher/WeVisOne-VL-4B-GGUF; the repo's README table rounds them up (2.8 GB for Q4_K_M, 0.6 GB for the Q8_0 mmproj). The Hub lists the original checkpoint at 5B params in BF16, so the official bf16 path is roughly 10 GB of weights. That doesn't fit on an 8 GB card without offloading.

There is one measured data point, from the PALLER-NOVUS GGUF repo: in a 20-query pilot on an RTX 2060 6 GB (context 4096, 1,024 to 1,960 image tokens), 4B Q4_K_M peaked at 4.38 GiB of whole-device VRAM at 4.17 s per request. The 4B F16 GGUF had to spill onto the CPU on that card and took about 60 s per query. My guess is that 12 GB is the realistic floor for the Tencent package at bf16, but nobody has published a measured number yet.

Run it with the official package (the only way to get masks)

The Tencent package is what loads mask_decoder.pt. Install it from the repo:

git clone https://github.com/Tencent/WeVisOne-VL.git && cd WeVisOne-VL
conda create -n wevisone-vl python=3.10 -y && conda activate wevisone-vl
pip install -r requirements.txt && pip install -v -e .

from PIL import Image
from wevisone_vl import WeVisOneVL

from wevisone_vl.visualization import save_result

model = WeVisOneVL("tencent/WeVisOne-VL-4B", backend="transformers")  # or backend="vllm"

image = Image.open("demo/examples/images/seabreeze.jpg").convert("RGB")
result = model.predict(image, task="matting", query="person")
save_result("outputs/matting", image, result)

That's the README example. Swap task for detection (with a list of categories as query), ocr, count_box and so on. The README also lists options for device ("auto", "cuda:0", "npu:0", "cpu"), dtype, min_pixels / max_pixels and the usual decoding arguments like max_new_tokens and temperature. If you're short on memory, lower max_pixels before anything else; fewer visual tokens means less activation memory. There's a Gradio demo too:

CUDA_VISIBLE_DEVICES=0 python demo/app.py --model tencent/WeVisOne-VL-4B

Add --backend vllm to run it on vLLM instead of transformers.

The Hub's "Use this model" menu also offers a plain vllm serve "tencent/WeVisOne-VL-4B" and an SGLang launch command. Since the architecture is stock qwen3_vl, those serve the language model only: you get coordinate tokens back, parse them yourself, and never see a mask.

The Hub's transformers snippet for the model asks "What animal is on the candy?" That's the generic image-text-to-text example, so don't judge the model by free-form chat; it was trained for structured outputs.

GGUF in Ollama and llama.cpp: boxes yes, masks no

There are three community GGUF repos for the 4B so far: mradermacher, prithivMLmods and PALLER-NOVUS, which ships 2B and 4B in one repo. The Hub's "Use this model" menu on the mradermacher repo gives:

llama-server -hf mradermacher/WeVisOne-VL-4B-GGUF:Q4_K_M
ollama run hf.co/mradermacher/WeVisOne-VL-4B-GGUF:Q4_K_M

The problem is that a GGUF is the language model plus an mmproj vision projector. The pixel decoder is a separate PyTorch file, and neither llama.cpp nor Ollama knows what to do with an <OBJ> token. So on an 8 GB card you should get detection, referring boxes, pointing, counting and OCR grounding as coordinate text, but not segmentation or matting. PALLER-NOVUS says the same: putting mask_decoder.pt next to a GGUF doesn't give you pixel output. Their Q4_K_M runs did return structured boxes on a pinned, patched llama.cpp build (they say the patch carries changes for another model and adds no WeVisOne capabilities, but stock upstream is untested), launched with --special so the coordinate tokens survive decoding. I haven't seen anyone confirm that Ollama's hf.co pull picks up the separate mmproj for this architecture, so test image input there before you build on it. There are no imatrix quants yet either; mradermacher only has static ones so far.

Is it the vision model to run on an 8 GB card?

For grounding work, I think yes. If your local pipeline is GroundingDINO for boxes plus SAM for masks, or a general VLM you keep asking for coordinates, this is the first small model I'd test as a replacement, mostly because of the rejection rate. Q4_K_M plus its projector at ~3.2 GB leaves plenty of room.

For "read this screenshot and tell me what the error says", I wouldn't switch. The OCR benchmarks here measure finding and transcribing text regions with boxes, not answering questions about a document. Stay on whatever general Qwen3-VL build you already use until someone posts DocVQA or OCRBench numbers for this one.

And if you want masks on 8 GB, you're waiting on a quantized path for the official package, or on someone wiring the pixel decoder into llama.cpp.

Which small vision model do you actually use for OCR or screenshots locally right now, and would you trust a 4B model's boxes without a human checking them?

Sources

tencent/WeVisOne-VL-4B model card and config.json
Tencent/WeVisOne-VL on GitHub (benchmark tables, install, tasks)
WeVisOne-VL paper, arXiv:2610.31329
mradermacher/WeVisOne-VL-4B-GGUF
prithivMLmods/tencent-WeVisOne-VL-4B-GGUF
PALLER-NOVUS/WeVisOne-VL-GGUF (RTX 2060 pilot in BENCHMARKS.md)
Discussion #3: Questions on Baseline Selection

Raspberry Pi Zero 3W Specs Leak: Pi 4 Chip, Release Date and Why It Won't Be $15

Alan West — Thu, 29 Oct 2026 17:40:03 +0000

The Raspberry Pi Zero 3W now has a device tree, and it says the board runs on the BCM2711, the same quad Cortex-A72 chip as the Pi 4. I don't see a way it costs $15 like the Zero 2W, and the reason is the LPDDR4 that chip needs, which Raspberry Pi says has gone up sevenfold in a year.

I went through the new .dts files to see what they actually confirm about Zero 3W specs and what's still guesswork (clock, RAM, price, release date). I also pulled published Pi 4 benchmarks to get a rough idea of how fast it could run a small LLM, and whether you should just buy a Zero 2W now.

Where the Raspberry Pi Zero 3W leak came from

Phoronix covered it too, but bret.dk wrote the detailed breakdown on 27 October 2026. Two device tree source files written by Marta Momotko were merged into Raspberry Pi's own kernel tree, the rpi-6.18.y branch of raspberrypi/linux, through PR #7711 on 25 October 2026. They aren't in mainline Linux, and Raspberry Pi hasn't announced either board. The links below point at the original commits on the martamomotko/linux fork.

Zero 3W: bcm2711-rpi-zero-3-w.dts, commit 1afad193
Pi 4 Model A: bcm2711-rpi-4-a.dts, commit c17dd5f6

The Zero 3W file is very direct about what it describes:

compatible = "raspberrypi,model-zero-3-w", "brcm,bcm2711";
model = "Raspberry Pi Zero 3 W";

Zero 3W specs: confirmed vs. guesswork

A device tree describes how the board is wired. It doesn't cover clocks, RAM or price, so I've split what's in the file from what isn't.

	Zero 2W (shipping)	Zero 3W (device tree)	Status
SoC	RP3A0, 4x Cortex-A53 @ 1GHz	BCM2711, 4x Cortex-A72	In the DTS
Clock speed	1GHz	?	Not in DTS
RAM	512MB LPDDR2	?	Device trees don't describe RAM
Wi-Fi/BT	Yes	Yes, includes `bcm283x-rpi-wifi-bt.dtsi`	In the DTS
Storage	microSD	EMMC2 with `bus-width = <8>`, comment says "eMMC/SD card"	In the DTS, final form unknown
Bootloader	On SD	SPI flash lines, so an EEPROM bootloader like the Pi 4	In the DTS
HDMI	1x mini	1x (second controller disabled)	In the DTS
PCIe	No	`&pcie0` enabled	In the DTS; whether it's exposed is unknown
Camera	2-lane CSI	4-lane CSI config	In the DTS
Power button	No	`gpio-keys` on GPIO 46 → `KEY_POWER`	In the DTS
Price	$15	?	Pure speculation

The 8-bit bus width caught my eye. microSD only uses 4 data lines, so an 8-bit bus points to eMMC. Bret thinks it's a leftover and expects microSD on the final board. That could be right, but I'd keep an eye out for an eMMC SKU, because a Zero with soldered storage would make sense for industrial buyers.

The Pi 4 Model A file is the boring sibling. It has a disabled Ethernet controller, one HDMI, no analogue audio or composite, microSD only, and antenna-switching lines (ANT_CTRL1/ANT_CTRL2, overlay params ant1, ant2, noant) that look a lot like the CM4's internal/external antenna option.

Raspberry Pi Zero 3W release date

No date has been announced. A device tree merged into Raspberry Pi's kernel means bring-up work is happening, but that doesn't tell you when boards will ship. Anyone quoting a month is guessing. The Zero 2W launched about five years ago and the last Model A was the 3A+ in 2018, so a refresh is overdue.

The $15 Zero 3W problem: LPDDR4 prices

The Zero 2W still costs $15 and hasn't gone up during the RAM crunch. Raspberry Pi's own April 2026 pricing post explains why. The LPDDR2 used in the Zero, Zero 2W and Pi 3 comes from stock the company already holds. The LPDDR4 used in the Pi 4 and Pi 5 has seen "a seven-fold increase over the last year".

That same post put another $25 on the Pi 4 4GB, $50 on the 8GB, and launched a 3GB Pi 4 at $83.75.

The BCM2711 uses LPDDR4, so the Zero 3W lands on the memory whose price went up sevenfold instead of the LPDDR2 Raspberry Pi already has in a warehouse. I'd bet on a 512MB or 1GB base model at a price that makes people angry in the comments. On the HN thread, one commenter points out that an Orange Pi Zero used to cost less than $10 and now sells for a tad over $30.

Can the Zero 3W run an LLM? Pi 4 numbers are the ceiling

There are no Zero 3W benchmarks because there's no Zero 3W yet. But it uses the same SoC as the Pi 4, and a small, passively cooled board almost certainly won't beat a Pi 4. So published Pi 4 numbers are a reasonable upper bound.

The most useful dataset I found is SimeonOnSecurity's Ollama runs on a 2GB Pi 4B. The runs used five prompts, a 140-token output cap, and cold loads:

Model (Pi 4, 2GB)	Generation tok/s	Notes
LFM2.5-230M	12.8	383MB peak RSS
LFM2.5-350M	8.6	516MB peak RSS
qwen2.5:0.5b	8.0	5/5 prompts
MiniCPM5-1B (no reasoning)	5.9	883MB peak RSS
granite4:350m	4.6	stable, no swap
gemma3:1b	4.0	heavy swapping, board rebooted
qwen3.5:0.8b	n/a	didn't finish, board rebooted

For comparison, the Adafruit guide measured gemma3:1b at 9.99 tok/s on an 8GB Pi 5, and SimeonOnSecurity got 11.2 tok/s on its 8GB Pi 5. That's the same model that swapped a 2GB Pi 4 into a reboot at 4.0 tok/s.

On the Zero 2W, the pi-llm project got llama.cpp working with SmolLM2-135M at Q4_K_M. It managed 9.5 to 10.9 tok/s generation, needed a mandatory 2GB swapfile, and took about 24 hours to compile on the board. The README warns that larger models may not run at all.

What I take from those numbers:

RAM matters more than the A72 cores. Gemma 3 1B was already swapping and rebooting a 2GB Pi 4. If the Zero 3W ships with 512MB or 1GB, 1B-class models will be painful or won't load.
Models from 230M to 500M are where it'll work. LFM2.5-230M at 12.8 tok/s, or LFM2.5-350M and Qwen2.5-0.5B at around 8 tok/s, on Pi 4 silicon is fine for intent parsing, short summaries or a voice-assistant command layer. I wouldn't chat with it.
Over the Zero 2W, you mostly gain model size. The Zero 2W gets about 10 tok/s from a 135M model; Pi 4 silicon with enough RAM should get similar speed from a model about 3x bigger. That's worth having, since the pi-llm README admits its 135M model's responses "can be repetitive or incoherent".

If you want a 1B model on a Pi today, buy a Pi 5. Boring answer, but that's what the numbers say.

Buy a Zero 2W now or wait for the Zero 3W?

My take:

Buy the Zero 2W now if your project is GPIO, sensors, a Pi-hole, a USB gadget, or anything that already runs fine on it. It costs $15, it's in stock, and the price is protected by LPDDR2 stock. A Zero 3W probably won't help a temperature logger.
Wait if you're hitting the 512MB wall, need PCIe or 4-lane CSI, or want a small on-device model. Expect to pay more.
Skip both if you want local LLMs. Get a Pi 5 with at least 4GB. HN commenters also bring up Rockchip boards like the Radxa Zero 3W, though one owner there says its Cortex-A55 cores are only slightly better than the Zero 2W's A53s.

If you already have a Zero 2W and want to try a tiny model, don't compile on the board. Build on a faster ARM64 machine or cross-compile, copy the binary over, and add swap first. On a Bookworm-based Raspberry Pi OS image that still uses dphys-swapfile:

sudo dphys-swapfile swapoff
sudo sed -i 's/^CONF_SWAPSIZE=.*/CONF_SWAPSIZE=2048/' /etc/dphys-swapfile
sudo dphys-swapfile setup && sudo dphys-swapfile swapon
free -h

Then run a model in the SmolLM2-135M class with -t 4, and watch vcgencmd get_throttled while it generates. On a Zero, thermals will start to matter before model quality does.

So what's it for?

I like the idea of a Pi 4 chip in a Zero footprint, and it's overdue. With LPDDR4 at current prices, though, I doubt it'll be the cheap hacking board people on HN want. My guess is a small, pricier board for camera rigs, PCIe experiments and edge projects that have outgrown 512MB.

What would you build with a Zero 3W that the Zero 2W was too slow for? And at what price do you skip it for a Pi 5 or an ESP32? Tell me in the comments. I especially want to hear from people running models on a Zero 2W today.

Sources

How to Run an Offline AI Assistant With No Internet (Even on a Raspberry Pi)

Alan West — Thu, 29 Oct 2026 16:30:03 +0000

Survival LLM, the offline AI assistant Hacker News spent this week arguing about, got 14 of 22 blackout and first-aid questions right on a 16 GB machine. The other eight missed the main point of the official guidance, and these were emergency questions.

It's free, MIT-licensed, and bundles a local model with an offline emergency library so you can ask questions with no internet. I like the idea. I also think the library is the half that matters and the model is mostly a search box on top of it. Below I go through what Survival LLM ships and what hardware it wants, then how to build the same kind of offline kit on Linux with Ollama or llama.cpp plus Kiwix, including on a Raspberry Pi, which Survival LLM doesn't support.

What Survival LLM actually ships

The app is small (212 MB on Mac, 25 MB on Windows). On first run it checks how much memory you have, picks a model and downloads it. These are the published tiers from the project page:

Your machine	Model	Emergency test score	Model download
Mac, 128 GB+	NVIDIA Nemotron 3.5 Super	21 / 22	80 GB
Mac, 32–96 GB	Qwen3.8 27B	21 / 22	18 GB
Windows PC, 32 GB+	NVIDIA Nemotron 3.5 Lightning	19 / 22	25 GB
Mac or PC, 16–31 GB	IBM Granite 4.2 8B	14 / 22	6 GB

The score counts answers that got the main point of official guidance right on 22 blind-graded questions. The page notes the tests ran against an earlier build of the library.

The library is the interesting part. The full version is a 9 GB download (19 GB installed) of plain-text, searchable copies of:

about 930,000 of Wikipedia's most-read articles
WikiMed, MedlinePlus, UK Medicines A to Z and WikEM (emergency medicine)
Ready.gov (FEMA) guides, CDC travelers' health, and U.S. military medicine and survival manuals
wikiHow, iFixit, Appropedia
Stack Exchange Q&A on home repair, cooking, gardening, outdoors and ham radio

There's also a 1.3 GB "smaller library" (3 GB installed) that drops Wikipedia and iFixit. For disk space, plan on the model size plus 5 GB, and about 27 GB of temporary space while the full library installs. You can add your own PDFs, ebooks and notes, and each answer shows its sources. Version 0.3.4 (Oct 27, 2026) added a reasoning budget setting: Off, 1,000, 4,000, 16,000 tokens, or no limit.

Platform support is Apple Silicon on macOS 14+ or 64-bit Windows 10/11. There's no Linux build, which got the expected grumbling in the HN thread.

Power: about 100 W per answer, 100 to 300 answers per charge

The project publishes this, which I appreciate. On a MacBook Pro it draws about 100 W while answering, for 5 to 40 seconds per question, which works out to roughly 100 to 300 answers on a full battery.

At 20 questions a day that's 5 to 15 days per charge, and recharging is the hard part when the grid is down. One HN commenter asked whether you'd really run your generator for a local model. Plain Kiwix, by comparison, is a web server reading compressed files, and it sips power next to a GPU doing inference.

Why the LLM shouldn't be the only thing on the drive

The HN thread splits in two. One side treats the LLM as search: it finds the article when you don't know the keyword. The other asks what it adds over a plain index, which is smaller and faster and can't invent anything. I think both sides have a point. One commenter asked how to build a bow drill and got an answer that was partly wrong about how the bow works. Another, running Qwen 27B on a 32 GB M1 (about 19 to 23 GB used), noticed that answers the model pulled from its own memory came with no sources, and that it ran a real search once told to "look that up".

So my rule is to use the model to find the page, then read the page. The library has to be something you can browse without the model running. Kiwix gives you that, and it's what I'd build around.

Build your own offline AI kit on Linux: Ollama plus Kiwix

You need two pieces. For the model runtime, Ollama is the easy path, and llama.cpp is there if you want fewer layers between you and the GGUF file. For the library, use Kiwix ZIM files served by kiwix-serve. Most of what Survival LLM bundles (Wikipedia, WikiMed, iFixit, Appropedia) is available as ZIM files: compressed, searchable archives, with or without images.

Sizes from the Kiwix mirror as of this month:

ZIM file	Size
`wikipedia_en_all_maxi_2026-08.zim` (full, with images)	119 GB
`wikipedia_en_all_nopic_2026-06.zim` (full, no images)	49 GB
`wikipedia_en_all_mini_2026-09.zim` (intros only)	13 GB
`wikipedia_en_top_maxi_2026-09.zim` (top articles)	6.5 GB
`wikipedia_en_medicine_maxi_2026-10.zim`	1.7 GB
`mdwiki_en_all_maxi_2025-11.zim` (WikiMed)	2.1 GB
`ifixit_en_all_2025-12.zim`	3.3 GB
`zimgit-post-disaster_en_2024-05.zim`	615 MB
`appropedia_en_all_maxi_2026-02.zim`	555 MB
`zimgit-water_en_2024-08.zim`	20 MB

Disk and RAM by tier, from Raspberry Pi 5 to a 32 GB laptop

Model sizes are from the Ollama library pages for Granite 4.2 and Gemma 4. Gemma 4 12B was the model HN commenters suggested for modest hardware.

Tier	Model (Ollama tag, size)	Library	Total disk
Raspberry Pi 5, 16 GB	`granite4.2:3b`, 2.2 GB	top_maxi + WikiMed + iFixit + post-disaster + Appropedia	~15 GB
Old laptop, 16 GB	`granite4.2:8b`, 5.3 GB	full nopic Wikipedia + same extras	~61 GB
Mini PC or laptop, 32 GB	`gemma4:26b`, 16–19 GB	full maxi Wikipedia + same extras	~145 GB

The 16 GB row uses the same Granite 8B that Survival LLM picks for that tier, so expect roughly the same 14/22 accuracy. That's another reason to keep the articles one click away.

On the Pi, be realistic. One Pi 5 benchmark under Ollama measured qwen2.5:3b at 5.2 tokens/s and llama3.2:3b at 4.69 tokens/s, both Q4_K_M. Those same authors set OLLAMA_LOAD_TIMEOUT=60m0s because some models load that slowly. Another write-up works out a theoretical ceiling of about 8.6 tokens/s for Llama 3.2 3B at Q4_K_M from the Pi 5's 17.1 GB/s memory bandwidth. It also notes that inference pins all four cores at 100%, so get the active cooler. Either way, on a Pi the model is the slow extra and Kiwix is the product.

Setup commands (do all of this while you still have internet)

Install Ollama and pull a model:

curl -fsSL https://ollama.com/install.sh | sh
ollama pull granite4.2:8b
ollama run granite4.2:8b

Or with llama.cpp, using the commands from its current README:

curl -LsSf https://llama.app/install.sh | sh
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF   # swap in the GGUF repo you want

llama serve gives you an OpenAI-compatible API and a built-in web UI. Run it once while you're online so the weights are already on disk.

Then the library. Install kiwix-tools from your distro (Debian and Ubuntu package it), download your ZIMs, and serve them:

sudo apt install kiwix-tools
mkdir -p ~/zim && cd ~/zim
wget https://download.kiwix.org/zim/wikipedia/wikipedia_en_all_nopic_2026-06.zim
wget https://download.kiwix.org/zim/ifixit/ifixit_en_all_2025-12.zim
kiwix-serve -p 8080 ~/zim/*.zim

Open http://localhost:8080 and you have searchable offline Wikipedia and iFixit. Any phone on the same Wi-Fi can reach it too, which is the main thing a Pi tier gets you.

If you'd rather not wire it up yourself, Project NOMAD (Apache 2.0) bundles Kiwix, Ollama, OpenStreetMap offline maps and Kolibri in a Docker install on Ubuntu or Debian. It recommends 32 GB RAM and a 1 TB SSD, though, so it's not the "old laptop" route.

The pre-outage checklist

Pull the model and run it once with the network cable unplugged. If it tries to fetch something, find out now.
Check the ZIM files open in kiwix-serve before you go offline.
Put the whole thing on a second drive, and keep a cheap USB stick with just the Kiwix files.
Print the few pages you'd need in the first hour: CPR, water purification, your own medications. Several HN commenters made this point, and they're right: paper doesn't need a charger.

I'd install Survival LLM on a Mac without thinking twice. Just remember the 14/22 at the 16 GB tier, and treat the library as the source of truth.

If the internet went down for a month, what would you want on your offline drive besides a model and Wikipedia? One HN commenter said the default library feels "more like a tool for city dwellers" because it skips hunting and field dressing. What's missing from yours?

Sources

Survival LLM project page
Hacker News discussion
Kiwix ZIM downloads and kiwix-tools
kiwix-serve man page
Ollama: Granite 4.2, Gemma 4
llama.cpp README
Project NOMAD
Raspberry Pi 5 LLM numbers: Stratosphere research notes, localaimaster.com

DEV Community: Alan West

How to Run Mage-VL-Cowork Locally: Microsoft's 4B Agent Beats Sonnet 4.5

What Mage-VL-Cowork is (and how it differs from Phi vision)

Mage-VL-Cowork specs: 4B or 4.7B parameters?

OSWorld-Verified: where 66.0% actually sits

How much VRAM Mage-VL-Cowork needs

Which runtimes load it today: SGLang, Transformers, vLLM, llama.cpp, Ollama, MLX

Transformers

SGLang

vLLM

llama.cpp

Ollama and LM Studio

MLX on Apple Silicon

The part nobody reads: Microsoft's sandbox rules

Sources

How to Run LFM3-Omni-2B GGUF Locally (Only llama.cpp Makes It Talk Back)

What LFM3-Omni-2B actually is

LFM3-Omni-2B vs LFM3-VL-2B vs d1-Omni-2B

LFM3-Omni-2B vs Qwen2.5-Omni, Gemma 4 and Phi-4 MM

Which quant to download: file sizes and RAM

How to run LFM3-Omni-2B GGUF with llama.cpp

Realtime voice, the reason I'd download this

Ollama, LM Studio or llama.cpp: which ones make it speak

The license: free until $10M revenue

My take

Sources

GitHub Actions Down Again? How to Mirror Your Repos to Codeberg Without Actions

Step 0: check if GitHub is down before you debug your own pipeline

The trap: mirroring GitHub with a GitHub Action

Option 1: one git push, two forges

Option 2: Codeberg, which only takes pushed mirrors

Option 3: self-hosted Forgejo pull mirror, then fan out

Option 4: Tangled, the federated forge on ATProto

The CI fallback: Forgejo Actions, Woodpecker or Tangled spindles

The one-hour checklist

Sources

Is AI Making You a Worse Developer? Anthropic's Data Says Yes. Here's the Fix

SigNoz on SREs losing incident skills

Cisco gives one engineer unlimited AI tokens to rewrite legacy code

What the research says about AI deskilling

Developers are also exhausted

5 ways to keep AI from deskilling you

1. Debug by hand for a few hours a week

2. Write your hypothesis before you paste the alert

3. Make the agent explain before it fixes

4. Write the postmortem yourself

5. Read the tests on any AI rewrite

Rusty seniors, juniors who never learn

Sources

How to Stop Claude Code From Reading Your .env File (Deny Rules Aren't Enough)

Block Claude Code from reading .env with permissions.deny

What deny rules don't cover: Bash can still read your secrets

Close the Bash hole with the sandbox

A PreToolUse hook as a tripwire

The same fix in Cursor and Codex

What none of this fixes

Sources

Claude Code Extension Backdoor in Cursor: Uninstalling Won't Remove the SSH Key

What happened with the Claude Code extension backdoor in Cursor

Who is affected (and who isn't)

Step 1: list your extensions and versions

Step 2: check for the SSH key and persistence (macOS / Linux)

Step 2 (Windows)

Network indicators

How bad is it if you find something?

Clean up, then rotate

Pin extensions and stop auto-updating them

Sources

Gemini 4 Carbon vs Claude Opus 5.5: #1 Overall, but Opus Still Wins at Coding

Gemini 4 Carbon vs Opus 5.5 vs GPT-6.1 Sol: the full scoreboard

Where Gemini 4 Carbon wins: fewer hallucinations

Coding: Opus 5.5 is still ahead

GPT-6.1 Sol is the one that should worry Google

Long context: the Index stopped measuring it

Which model I'd pick for coding, pipelines and Q&A

About that #1

Sources

How to Run LiquidAI d1-Omni-2B Locally (It Hears Audio but Can't Talk Back)

What d1-Omni-2B actually does

d1-Omni-2B vs d1-omni-600M: what 3x the parameters buys you

Option 1: one `git push`, two forges