Edition 2026-09-17 latest · digest built 2026-09-17T12:11:31+00:00

Sandboxing Claude Code, DIY Inference Infra, and a Forgotten Open-Source Architecture

Today's actionable haul centers on agent safety tooling for Claude Code (a proper sandbox and a reliability skill pack), plus a cluster of self-hosting wins: GLM's own inference stack, an open autotuner beating fixed heuristics by up to 97%, and a disk-streaming trick for running MoE models that don't fit in VRAM. A RAG post also flags a subtle multi-query retrieval failure mode worth checking against your own pipeline.

Agent safety and reliability

Two solid Claude Code releases stood out: an Apache-2.0 sandbox (claude-sandbox) that lets you run --dangerously-skip-permissions without exposing SSH keys or your network, and wbox-mcp, which boxes computer-use MCP agents inside a nested Wayland compositor so they stop hijacking your actual mouse and keyboard. Pair those with a shared "starter pack" of seven Claude Skills targeting specific agentic failure modes (false-positive completion claims, generic output, etc.) for a meaningfully safer and more reliable agent setup with almost no cost to adopt.

Self-hosting and inference infra

Zhipu's writeup on how GLM built its own inference infrastructure is a rare official deep-dive worth reading if you run open-weight models at any scale. An open-source autotuner reports 56-97% more throughput than fixed tuning heuristics across three GPU types for vLLM-style serving, and Colibri proposes disk-streaming MoE experts from NVMe to run models well beyond your VRAM budget, trading speed for reach. A resurfaced arXiv paper on a non-autoregressive, JSON-schema-constrained prediction architecture (open weights, dataset, and pypi package, published over a year ago) is getting new attention as a lab appears to have converged on the same idea independently.

RAG hygiene

A carefully measured RAG post found multi-query retrieval quietly cost 3 of 210 known-answer questions in a hybrid dense+BM25+reranker pipeline, reproduced twice to rule out noise, with the root cause not the obvious one (query expansion diluting rather than helping precision). Worth spot-checking if your stack uses multi-query expansion by default.

Today's findings

  1. #1 claude-sandbox: an Apache-2.0 sandbox for coding agentstool

    Run Claude Code (or Codex) with full autonomy without handing it your SSH keys and cloud credentials.

    claude-sandbox · Apache-2.0
    Full autonomy, but only inside the sandbox
    bounded capability
    Claude Code / Codex with --dangerously-skip-permissions
    scope Sandboxed run
    limit No SSH keys
    limit No cloud creds
    monitor PR review
    Review the PR the agent produces instead of watching every command.

    Why it matters: Most teams either babysit every tool call or run --dangerously-skip-permissions on a bare machine and hope for the best; this closes that gap with a real sandbox instead of a manual review bottleneck.

    How to apply: Drop it in front of any long-running agentic Claude Code/Codex session that needs --dangerously-skip-permissions; review the PR it produces instead of watching every command.

    claudeagentssandboxingsecurity

    Read more: I built claude-sandbox, a free, open-source (Apache 2.0) sandbox for coding agents using claude.

  2. #2 A 7-skill starter pack for fixing common Claude Code agentic quirkstool

    Seven narrow, composable Claude Skills (like "verify before done") that trigger only when needed instead of one bloated system prompt.

    Claude Code · Skills
    Swap one bloated prompt for narrow skills that load only when needed
    Monolithic prompt
    • Every rule in one system prompt
    • Always loaded, needed or not
    • Not aimed at any one failure
    Narrow skills
    • One skill per failure mode
    • Loads only when triggered
    • Composable, e.g. "verify before done"
    Write skills for the failures your team actually hits
    Aimed at agents that report success just because no tool threw an error.

    Why it matters: Directly targets the recurring failure where Claude reports success just because a tool didn't throw an error — a common source of silently broken agentic runs.

    How to apply: Adopt the skill-splitting pattern for your own Claude Code setup: replace monolithic instructions with targeted skills for specific failure modes your team actually hits.

    claudeskillsagents

    Read more: I built a "Starter Pack" of 7 custom Claude Skills to fix common agentic quirks and improve output quality. Here is my setup.

  3. #3 wbox-mcp isolates computer-use MCP agents in a nested compositortool

    An open-source MCP server that runs GUI-automation agents inside their own sandboxed Wayland session instead of taking over your real desktop.

    Why it matters: Every computer-use MCP server currently hijacks your actual mouse/keyboard, blocking you from doing anything else while an agent works — a real adoption blocker for agentic GUI automation.

    How to apply: Swap it in for any Claude/agent GUI-automation workflow on Linux where you need to keep working while the agent drives an app.

    mcpagentssandboxing

    Read more: I was tired of Claude hijacking my entire desktop for GUI automation — so I built wbox-mcp

  4. #4 Multi-query retrieval quietly cost 3/210 answers in a reproduced RAG benchmarktechnique

    A carefully controlled hybrid-retrieval eval found multi-query expansion measurably hurt recall on a subset of questions, twice.

    RAG · retrieval eval
    Multi-query expansion wasn't a free win: it lost answers
    −3
    correct answers lost out of 210 with multi-query expansion on
    A measured regression, not the gain people assume
    210
    questions in a frozen known-answer eval set
    the drop in recall happened on both runs
    Test with and without expansion on a frozen eval set before you keep it on by default.

    Why it matters: Multi-query expansion is a common "free win" pattern in RAG stacks; this is a rare case where someone actually measured a regression with a frozen eval set instead of assuming it helps.

    How to apply: If your RAG pipeline uses multi-query expansion, run a frozen known-answer eval set with and without it before trusting the default; check the root-cause discussion before you add it to yours.

    ragretrievalevaluation

    Read more: Multi-query retrieval cost us 3 questions out of 210, twice. We went looking for why and the obvious answer was wrong.

  5. #5 GLM published how it built its own inference infrastructuretool

    Zhipu's official engineering writeup on the custom inference stack behind GLM, straight from the source.

    Why it matters: Rare official-source detail (vs. the usual secondhand speculation) on how a major open-weight model provider actually serves at scale — directly useful if you self-host open models.

    How to apply: Read it before your next round of serving-infra decisions for open-weight models; compare against your current vLLM/llama.cpp setup for ideas worth borrowing.

    inferenceopen-sourcelocal-llm

    Read more: GLM Built Its Own Inference Infrastructure · Toward Recursive Self-Improvement: How GLM Built Its Own Inference Infrastructure

  6. #6 Open-source LLM autotuner beats fixed tuning heuristics by 56-97%tool

    A GitHub project auto-tunes serving configs and reports 56-97% more throughput than a fixed heuristic across three different GPUs.

    Why it matters: Serving config tuning (batch size, parallelism, etc.) is usually manual trial-and-error; an automated tuner with measured gains this large is a direct cost/throughput win for anyone self-hosting.

    How to apply: Try it against your current vLLM deployment's fixed config and compare throughput before rolling your own tuning heuristic.

    inferenceperformanceopen-source

    Read more: I built an open-source LLM autotuner: 56–97% more throughput than a fixed tuning heuristic across three GPUs

  7. #7 Colibri streams MoE experts from disk to run oversized models locallyrepo

    An open project that keeps a MoE model's dense layers resident and streams only the needed experts from NVMe/RAM/VRAM per token.

    Colibri · MoE expert streaming
    Dense layers stay put, and only the experts each token needs are streamed in
    HOT
    VRAM Dense layers + active experts
    WARM
    System RAM Staged experts
    COLD
    NVMe disk Full expert pool
    Runs MoE models too big for your GPU if you accept slower inference. It's an early project, so test it first.

    Why it matters: Lets you run models well beyond your GPU's VRAM by accepting a speed tradeoff, which is a different lever than quantization for fitting large local models on modest hardware.

    How to apply: Worth a spike if you're blocked on VRAM for a large MoE model and can tolerate slower inference; unverified/early-stage so test before relying on it.

    moelocal-llmquantization

    Read more: Colibri: an interesting disk-streaming MoE inference project. Does this approach have legs?

  8. #8 A non-autoregressive, JSON-schema-constrained prediction architecture, open-sourced over a year agopaper

    An arXiv paper with open weights, dataset, and a pypi package describing fast non-autoregressive structured-output prediction, now getting attention as a frontier lab appears to reinvent it.

    Why it matters: A fully open (paper + weights + dataset + package) alternative for fast structured/JSON-constrained generation that predates similar closed-lab announcements — worth evaluating before assuming you need a closed API for this.

    How to apply: If you need low-latency structured output generation (classification, schema-constrained decisions), pull the huggingface model and pypi package and benchmark against your current approach.

    paperopen-sourcearchitecture

    Read more: I literally build the jev architecture one year back and made it open-sourced · I literally built the Jev architecture one year back and completely open-sourced it with model, dataset and paper

  9. #9 KaozKit: sandboxed on-device LLM agents in JS for Apple Silicontool

    An MIT-licensed Swift library that runs JavaScript-defined LLM agents fully on-device via MLX, Apple Intelligence, or Ollama, with no cloud dependency.

    New tool · Apple Silicon
    Write a sandboxed local agent in about 10 lines of JS. No cloud needed.
    KaozKit
    tool MIT · on-device
    Swift library that runs agents written in JavaScript
    MLXApple IntelligenceOllama
    runSwift package · agents in JS
    No local LLM server to set up. Try it on a small job, like checking files and folders.

    Why it matters: Gives Mac-based teams a lightweight, sandboxed way to write local agents in ~10 lines of JS without standing up a full local-LLM serving stack.

    How to apply: Prototype a simple local automation (e.g. file/folder auditing) with it if you're on Apple Silicon and want zero-config on-device agents without cloud calls.

    agentslocal-llmollama

    Read more: KaozKit: sandboxed LLM agents in JS, fully on-device on Apple Silicon (MLX / Apple Intelligence / Ollama), MIT

  10. #10 Power-limiting an RTX 2080 Ti barely costs speed on a 27B local modeltip

    A power-limit sweep found 95% of max token throughput at 190W and peak efficiency at 167W (67% of default TDP) running Qwen3.6-27B.

    Why it matters: Cheap, reversible tweak for anyone running local inference boxes 24/7 — meaningfully lower power/heat for negligible throughput loss.

    How to apply: If you run a dedicated local-LLM inference box, sweep nvidia-smi power limits against your own model/quant to find your efficiency knee before leaving cards at default TDP.

    local-llmhardwaregguf

    Read more: RTX 2080 Ti power-limit sweep: Qwen3.6-27B delivers 95% of maximum speed at 190 W, peak efficiency 167 W (67% of default)

Looking for topic trends and crawl volume over time? See Trends.