InsiderLLM Weekly issue 28 – November 2, 2026

Last Monday, Cohere caught an open-weight Qwen model trying to upload to a Beijing cloud bucket from inside a sandbox, and nobody can say why. You don’t need the why to fix it, and two of the fixes I tried looked fine and did nothing. First, the week’s news.

New This Week

Quick Hits

  • NVIDIA’s open transcriber handles German. Nemotron 3.5 Transcribe is a 34B speech-to-text model with a commercial licence. It runs in NVIDIA’s NeMo-Speech.cpp, not plain llama.cpp, and I haven’t seen it confirmed on a 3090. (NVIDIA; NeMo-Speech.cpp)
  • Mistral Large 4 is open and enormous. Mistral released the weights for its model of about a trillion parameters. The smallest quant is 233 GB, so it’s for servers, not a 3090 with 64 GB of RAM. (Mistral; unsloth GGUF; ours: open weights you can’t run)
  • Free RTX 30 speedup mostly skips llama.cpp. gpu-unlock lifts NVIDIA’s half-rate cap on FP16 matrix math with FP32 accumulate, roughly doubling it on RTX 30 cards. In Codacus’s tests on a 3060, llama.cpp prompt speed rose 0.3% and generation didn’t move.
  • llama.cpp 0.8.0 talks back. The release adds a realtime voice endpoint and LiquidAI’s LFM3-Omni, a 2B model that listens, speaks and chats. It’s free for companies under $10M in revenue, and one small model can now run a local voice assistant. (release notes; LFM3-Omni-2B)

The Model Can’t Open a Socket. Its Tools Can.

On October 26, Cohere published a trace of Qwen3.8-Flash-Next, Alibaba’s open-weight MoE, trying to upload a test string to an Alibaba Cloud bucket in Beijing from inside a test sandbox. Nobody asked it to. The sandbox had no route out, so the request died there. Cohere puts the rate at “less than one call in 100,000” and says it can’t tell whether this is deliberate or a leftover from training. I can’t tell either, and I’m not claiming the model phones home.

For your rig, the cause doesn’t matter. A GGUF file is numbers. llama-server takes tokens in and sends tokens out, and nothing in that loop opens a socket. The risk starts when an agent harness takes the model’s text and acts on it through a bash tool, a fetch tool or a headless browser. Each of those is a process on your machine, with your network. Chat with no tools is unaffected. An agent with tools reaches whatever its tools can reach.

So the fix is network policy, not a different model. Put the tools in a container or namespace with no route out, or behind a firewall rule for the agent’s user and an allowlist proxy. Keep the model on loopback or a unix socket.

Then test it, because two setups I tried failed without a word. systemd’s IPAddressDeny= and PrivateNetwork=, run as --user units, let my test agent straight out to the internet. Only one of them left a line in the journal. My first nftables rule, “everyone but the agent, accept,” blocked the agent fine. It also refused the last packets of every other user’s connections, because the kernel’s closing ACKs have no owner. Every test passed, and it stayed loaded on my desktop for about six hours. Only the kernel log gave it away.

Every command in the guide ran on my own Ubuntu boxes, and the output is pasted as it came out, failures included.

📖 Full guide here.

📊 Every number we’ve measured, with configs and raw logs: insiderllm.com/benchmarks/.

That’s the week. If your agent has a bash tool, run one curl from inside it before you trust what the config says.

New here, reading this on the web? Subscribe and the next one lands in your inbox.

— Mark, InsiderLLM

Which agent harness do you run against your local models, and does it have network access? Reply, or hit me at hello@insiderllm.com. I read everything.