Firecracker Sandboxing Goes Open Source, Plus Cohere in llama.cpp and Token-Lean Coding Agents

Today's findings

1. #1 Perplexity Open-Sources SPACE Firecracker Orchestrator for Agent Sandboxingrepo

   SPACE gives teams a ready-made Firecracker orchestration layer for running untrusted agent workloads in isolated microVMs.

   Agent sandboxing

   Full-power agent code, hardware-isolated

   bounded capability

   Untrusted agent code

   scope Firecracker microVM

   limit Secrets outside guest

   monitor All jobs via SPACE

   Perplexity's SPACE routes agent jobs into isolated Firecracker microVMs — a real sandbox boundary, not prompt-level guar

   Why it matters: Agent code often needs shell, network, and filesystem access; a real sandbox boundary is more actionable than prompt-level guardrails.

   How to apply: Evaluate SPACE for CI or internal agent runners: define VM images, route agent jobs through the orchestrator, and keep secrets outside the guest.

   agentssandboxingsecurityfirecracker

   Read more: Perplexity open sources firecracker orchestrator for agent sandboxing

2. #2 llama.cpp Adds Cohere Model Supporttool

   Cohere’s models can now be run through llama.cpp, widening the local inference path for teams already standardized on GGUF-style tooling.

   Local inference

   llama.cpp Adds Cohere Model Support

   Cohere models in llama.cpp

   model Now supported

   Cohere weights → GGUF artifacts → llama.cppJust shipped

   runUpdate llama.cpp, pull the Cohere GGUF weights, and benchmark quality and throughput against your current local stack.

   Widens the local path for GGUF-standardized teams — less vendor-API dependence, offline eval reuses existing infrastruct

   Why it matters: It reduces dependence on vendor APIs for Cohere-compatible workloads and lets local/offline evaluation reuse existing llama.cpp infrastructure.

   How to apply: Update llama.cpp, pull the supported Cohere weights/GGUF artifacts, and benchmark quality and throughput against your current local stack.

   llama.cpplocal-llmcohereinference

   Read more: llama.cpp support for Cohere models

3. #3 Agentic GraphRAG Connects Retrieval Context with Agent Memoryrepo

   The open-source Agentic GraphRAG project combines hybrid GraphRAG context layers with persistent agent memory in one graph-backed system.

   AGENT STACKS

   Bolted-on vs. one shared graph

   Ad-hoc stack

   • RAG and memory glued together ad hoc
   • Context and history live in separate stores
   • Provenance blurs across steps

   vs

   Shared graph

   • GraphRAG context + agent memory in one graph
   • Retrieval and provenance on the same model
   • Continuity for long-running tasks

   One graph model can improve retrieval, provenance, and task continuity.

   Open-source Agentic GraphRAG backs retrieval context and agent memory with a single graph.

   Why it matters: Most agent stacks bolt RAG and memory together ad hoc; a shared graph model can improve retrieval, provenance, and long-running task continuity.

   How to apply: Clone the repo, map your existing document store and memory schema into its graph, then test multi-step coding or research tasks against a plain RAG baseline.

   raggraphragagentsmemory

   Read more: Agentic GraphRAG: an open source project combining the context layer and agent memory · Context layer + agent memory: we're connecting both in a graph · Context layer + agent memory: we're connecting both in a graph · RAG context and agent memory belong together. Here's what we're building.

4. #4 Tau Open-Source Coding Agent Targets Token-Efficient Task Pathsrepo

   Tau is an open-source coding agent built to minimize token usage while exposing the execution path it takes through a task.

   Why it matters: Token burn is a practical blocker for agentic coding; better path visibility also makes failures easier to debug than opaque retry loops.

   How to apply: Run Tau on a small repo with a known task, compare token counts and diffs against your current agent, and inspect its path logs for unnecessary tool calls.

   coding-agentstokensopen-sourcetooling

   Read more: I built an open-source AI coding agent that minimizes your token usage and executes your tasks directly along an optimal path, with better visibility

5. #5 Trace CLI Gives Coding Agents Progressive Repository Investigationtool

   Trace lets agents request function maps, diffs, and specific symbols instead of loading whole files into context.

   Why it matters: Repository-wide context loading is a common source of token waste and distraction; evidence-driven inspection keeps agents focused on relevant code.

   How to apply: Install Trace, add its map/diff/symbol commands to your agent’s toolset, and require it to cite inspected symbols before editing.

   coding-agentscontextclitokens

   Read more: I built an open-source tool to change how AI coding agents investigate codebases

6. #6 amicu Brings Terraform-Style Workflows to Local and Cloud LLM Deploymentstool

   amicu is an open-source CLI that describes model, hardware, and runtime in HCL, then plans, applies, and destroys LLM deployments.

   Terrafor-style LLM ops

   Infrastructure-as-code for LLM deployments

   1

   Declare

   model · hardware · runtime

   2

   Plan

   preview the diff

   review before anything changes — drift stops here

   3

   Apply

   provision local or cloud

   4

   Destroy

   clean teardown

   Version-controlled HCL carries a local experiment to cloud GPUs without hand-built setup drift.

   Why it matters: Reproducible deployment definitions make it easier to move local experiments to cloud GPUs without hand-built setup drift.

   How to apply: Write an HCL resource for one model/runtime pair, run plan/apply in a test environment, and keep the config in version control alongside app code.

   deploymentlocal-llmterraforminfrastructure

   Read more: amicu: Terraform for your own LLMs, locally or on cloud GPUs

7. #7 KiviDB Offers Redis-Compatible Memory Database and Vector Cacherepo

   KiviDB is a faster Redis-compatible memory database with vector-cache support, aimed at low-latency retrieval and agent memory workloads.

   Why it matters: Teams often need a lightweight vector/memory layer that fits existing Redis-style operations without standing up a separate vector database.

   How to apply: Benchmark KiviDB against your current Redis or vector store for embedding lookup and session memory, then test compatibility with your client libraries.

   vector-databaseredismemoryrag

   Read more: Show HN: KiviDB, a faster Redis-compatible memory database and vector cache

8. #8 Open-Source Harness Rejects Bad Local Model Output with Gatestool

   A bring-your-own-local-model harness adds validation gates that reject bad output and steer generation before it reaches downstream code.

   Why it matters: Local models can hallucinate or drift; explicit rejection and steering gates are a practical reliability layer beyond prompt tweaks.

   How to apply: Point the harness at your Ollama or llama.cpp endpoint, define acceptance checks for structured outputs, and log rejected generations to tune gates.

   local-llmguardrailsvalidationharness

   Read more: Open Source harness (with flaws) that rejects bad output, and has gates to steer output

9. #9 Mutation-Test Agent-Written Tests by Breaking Code on Purposetip

   If an agent writes its own tests, delete a line or flip a boolean and rerun the suite; tests that still pass are likely theater.

   Why it matters: Agent-generated tests can be optimized to pass rather than verify behavior, giving false confidence in autonomous coding loops.

   How to apply: Add a local script that mutates a few critical lines, runs the test suite, and flags surviving mutants for human review before merging agent work.

   testingcoding-agentsqualitymutation-testing

   Read more: My agent's tests were green. Then I deleted the line they were testing.

10. #10 Use a Control Plane, Not a Super-Agent, for Multi-Machine Coding Agentstip

    A lightweight control plane should queue work while per-machine daemons run agent CLIs and pause for human approvals.

    Why it matters: Once several coding agents run across machines, visibility and permission boundaries matter more than adding another orchestration model.

    How to apply: Separate queueing from execution, keep approvals outside agent reach, and log each run’s machine, command, and diff for audit.

    agentsorchestrationsecuritycoding-agents

    Read more: What I learned building a control plane for coding agents (Claude Code, Codex, Pi, Kimi) running on multiple machines

11. #11 Wan 2.2 I2V on 12GB: Watch System RAM, Not Just VRAMtip

    Measured Wan 2.2 image-to-video runs used only 8–9GB of VRAM on a 12GB card, but shared GPU memory and system RAM were the real bottlenecks.

    Wan 2.2 · image-to-video

    The 12GB card wasn't the wall

    Real bottlenecks: shared GPU memory + system RAM — monitor both mid-render and size DDR5 before upgrading.

    Why it matters: Local video generation planning often over-indexes on VRAM; host memory and dynamic loading can decide whether a render completes smoothly.

    How to apply: Use dynamic VRAM loading, monitor shared GPU memory and system RAM during renders, and size DDR5 capacity before upgrading the GPU.

    video-generationwanvramcomfyui

    Read more: Wan 2.2 I2V on a 12GB card only used 8–9GB of VRAM. System RAM was the real bottleneck (measured, 3 renders)

12. #12 CPU BitNet/Bonsai Check: Verify Outputs and Try ik_llama.cpp -rtrtip

    A CPU comparison found bitnet.cpp main still producing wrong output, Bonsai 1.7B correct wherever it loaded, and ik_llama.cpp with -rtr usually fastest.

    CPU inference check

    One wrong, one fragile, one fast

    3 stacks tested

    bitnet.cpp — wrong output

    Bonsai 1.7B — correct when loaded

    ik_llama.cpp -rtr — usually fastest

    pass warn fail

    Silent bad output can beat any speed win — run reference prompts before standardizing.

    Why it matters: CPU inference is attractive for small local models, but silent correctness failures make benchmark-only adoption risky.

    How to apply: Run reference prompts against your CPU stack, prefer Bonsai 1.7B for correctness checks, and test ik_llama.cpp -rtr before standardizing on bitnet.cpp.

    cpu-inferencebitnetllama.cppbenchmarking

    Read more: I checked BitNet and Bonsai on CPU against references: bitnet.cpp main still gives wrong output, Bonsai 1.7B is correct wherever it loads, and ik_llama.cpp with -rtr is usually fastest