Open-Weight Agent Security Scoring Arrives, Plus SQLite Memory Layers and Diff Discipline

Today's findings

1. #1 Wolf Defender Jev: 151M Open-Weight Agent Security Decision Modeltool

   A 151M encoder model scores agent context and proposed actions for prompt injection, exfiltration, and alignment, with MIT weights.

   Agent security

   A tiny local gate for agent tool calls

   151M

   parameters — encoder-class decision model

   open weights · MIT license

   3

   threat classes scored: prompt injection, exfiltration, alignment

   local

   scores context + proposed action before each tool call

   0

   sensitive context tokens sent to a cloud API

   Treat verdicts as evidence, not authorization — test benign-action contamination before trusting scores.

   Why it matters: Agent security is usually a prompt-level afterthought; a small local decision model can gate tool calls without sending sensitive context to a cloud API.

   How to apply: Run the MIT-licensed model locally as a pre-tool-call classifier, but treat content verdicts as evidence—not authorization—and test label-redefinition and benign-action contamination before trusting scores.

   agentssecurityprompt-injectionencoders

   Read more: We built a 151M decision model for agent security. Here’s where it works and where it doesn’t. · A local injection detector’s content verdict is not an authorization verdict for the next tool call · A label-redefinition suffix moved our security classifier more than a length-matched neutral sentence · Adding a benign shell action changed our content-injection score from 0.00 to 0.96 · Document Review with Unsiloed and TypeSafe Jev

2. #2 Tencent Open-Sources Local SQLite Agent Memoryrepo

   A local long-term memory layer for agents runs on SQLite, cuts token use ~61%, and improves PersonaMem accuracy from 48% to 76%.

   Why it matters: Most agent memory stacks depend on cloud vector DBs or opaque embeddings; a traceable local SQLite layer is easier to audit, self-host, and debug.

   How to apply: Prototype it as the memory backend for a local or Claude-based agent, then verify that recalled facts link back to original conversation logs before replacing your vector store.

   agentsmemorysqlitelocal

   Read more: China just made AI memory startups sweat 💀 Tencent open-sourced Agent Memory and it runs 100% locally on SQLite

3. #3 Claude Code Drift Control: Plan First, Bound the Difftip

   Ask Claude Code for a plan, identify the smallest fix, and define file/API boundaries before letting it edit.

   AI drift control

   Let the agent edit — but only inside agreed limits

   bounded capability

   Claude Code edits

   scope File & API boundary

   limit Smallest fix only

   monitor Root cause + file list

   revoke Reject off-boundary diffs

   Unscoped requests invite unrelated refactors; agree the boundary first, then gate every diff.

   Why it matters: Small requests often trigger unrelated refactors and dependency changes; explicit scope control keeps AI-assisted changes reviewable and production-safe.

   How to apply: Add a pre-code planning step to your Claude Code workflow, require root-cause and file list, and reject diffs that touch files outside the agreed boundary.

   claude-codeagentscode-reviewworkflow

   Read more: Claude Code keeps changing things I didn't ask it to. Here's how I'd approach it. · How to avoid drifts?

4. #4 MMR Needs a Larger Candidate Pool Than Final Top-Ktip

   If Qdrant MMR returns near-duplicate chunks, check candidates_limit—it defaults to limit, so the reranker has no room to diversify.

   Why it matters: RAG agents can look broken when retrieval is actually constrained by a default parameter; fixing the candidate pool is cheaper than rewriting prompts.

   How to apply: Keep query, filters, diversity, and final limit fixed, then compare candidates_limit=5 vs a larger pool; only change the prompt after retrieval membership can actually change.

   ragretrievalqdrantmmr

   Read more: Why MMR can keep returning the same chunks to your agent

5. #5 Audit Approved Cache Hits to Fix Calibration Ratchettechnique

   Recalibrating a cache verifier only on rejected hits inflated error to 9.5–27.7%; auditing 5% of approved hits brought it back to ~1.5%.

   LLM cache calibration

   Learn from rejections, but audit the approvals

   vs

   Recalibrate on rejects only

   Audit 5% of approved hits

   Verifier error

   9.5–27.7%

   ~1.5%

   Learning data

   Rejected hits only

   Rejects + weighted approved sample

   Extra LLM calls

   Zero

   0.5% of traffic

   Recalibrate on rejects only wins the row Audit 5% of approved hits wins the row

   Without audits, approved hits drift silently as hit rate rises; a random 5% pass-through restores ~1.5% error for under

   Why it matters: LLM caches often learn only from misses, so approved hits silently drift wrong while hit rate rises; a small audit sample restores trustworthy thresholds.

   How to apply: Force a random 5% of approved cache hits through the LLM, weight by 1/p, and recalibrate on that labeled sample; the extra calls cost under 0.5% of traffic.

   cachingllmevaluationcalibration

   Read more: CacheVerifier: recalibrating on the labels we actually had made our cache 5 to 14x more wrong, and hit rate went up

6. #6 Agent 'Done' Is Six States, Not One Booleantip

   An agent saying done can mean intended, attempted, accepted, applied, correct, or effective—verify the real system state, not the tool's 200.

   AGENT RELIABILITY

   'Done' is six states, not one boolean

   1

   Intended

   model meant to act

   2

   Attempted

   tool call was made

   3

   Accepted

   API said 200

   as far as HTTP 200 gets you

   4

   Applied

   write actually landed

   5

   Correct

   hit the right target

   6

   Effective

   the intended effect occurred

   Don't trust the 200 — verify system state up through Effective before reporting done.

   Why it matters: Tool-call success is not task success; treating HTTP 200 as completion hides partial writes, wrong targets, and downstream side effects.

   How to apply: Instrument each tool call with explicit state checks: confirm the row/event/message exists, matches the user's intent, and has the expected effect before reporting completion.

   agentsreliabilitytool-callsverification

   Read more: Follow-up to my "200 OK isn't proof" thread: "done" turned out to be six states, not one

7. #7 DecisionLoop: Small Decision Model Instead of LLM for Agent Controlrepo

   A Python framework uses a small decision model for intent, tool selection, arguments, and control flow, reporting better tool-call accuracy and lower cost than a 12B LLM agent.

   Why it matters: Not every agent step needs a generative model; routing and tool selection can be cheaper, faster, and more deterministic with a dedicated decision model.

   How to apply: Try DecisionLoop on order-support or flight-desk workflows, benchmark it against your current LangChain agent, and keep the LLM for open-ended reasoning only.

   agentsdecision-modelspythonrouting

   Read more: Built a Python agent framework where a decision model chooses actions instead of an LLM - looking for feedback · Built a Python agent framework where a decision model chooses actions instead of an LLM - looking for feedback · Built a Python agent framework where a decision model chooses actions instead of an LLM - looking for feedback

8. #8 SonicBoom: C++/CUDA Runtime Beats llama.cpp on Consumer GPUrepo

   A native tensor runtime with no Python hit 51.65 tok/s decode on an RTX 3050 vs llama.cpp's 45.20 tok/s using the same GGUF.

   measured

   Same GGUF, same RTX 3050 — only the runtime changed

   1

   SonicBoom v0.0.1

   51.65 tok/s

   2

   llama.cpp

   45.20 tok/s

   Decode speed, tokens per secondC++/CUDA runtime, no Python: +14%

   Why it matters: Local inference speed is often limited by runtime overhead; a lean C ABI stack can squeeze more tokens from the same quantized model and hardware.

   How to apply: Benchmark SonicBoom v0.0.1 against your llama.cpp setup on the same GGUF and GPU, then check whether its C ABI fits your serving or desktop app.

   local-llminferencecudallama.cpp

   Read more: SonicBoom: 52 tok/s decode on a laptop RTX 3050 (llama.cpp: 45) with the same quantized kernels, the difference is a graph compiler. No Python.

9. #9 Vocabulary Pruning Shrinks Qwen 27B GGUF to 9.3 GBtechnique

   Pruning unused vocabulary from a Qwen 3.8 27B GGUF cut it to 9.3 GB, enabling 100k+ context on a single 16 GB RTX 5060 Ti.

   Vocabulary pruning

   A 27B GGUF, pruned to fit one 16 GB card

   Removing unused vocab frees VRAM for 100k+ context — without dropping to a worse quant.

   Why it matters: VRAM is the hard limit for local long-context work; vocabulary pruning is a practical way to fit larger models without dropping to a worse quant.

   How to apply: Use the ASCII-Condensed prune tools on your target GGUF, remove characters your workload never needs, and validate tokenizer behavior before deploying the smaller file.

   local-llmggufquantizationqwen

   Read more: Qwen 3.8 25B on 5060TI with 100k+ context

10. #10 Harness Studio: Open-Source Desktop Runner for Local HF Modelstool

    A free desktop app runs Hugging Face models locally as an alternative to LM Studio and Ollama, with feedback and contributors wanted.

    Local LLM tooling

    Harness Studio runs Hugging Face models in a free desktop app

    Harness Studio

    tool Open source

    Free desktop alternative to LM Studio & Ollama

    runInstall on a dev machine → load a GGUF or HF model → compare UX & API with your current runner

    A lightweight open option in a still-fragmented local-model tooling landscape.

    Why it matters: Local model tooling is still fragmented; a lightweight open-source desktop runner can simplify experimentation and reduce dependence on closed apps.

    How to apply: Install Harness Studio on a dev machine, load a GGUF or HF model, and compare its UX and API surface against your current Ollama/LM Studio setup.

    local-llmhuggingfacedesktopollama

    Read more: I released Harness Studio, an open-source alternative to LM Studio and Ollama. Looking for feedback and contributors. · I built Harness Studio — an open-source desktop app for running Hugging Face models locally. Looking for feedback and contributors.

11. #11 Flow-WLS: Training-Free Sampler Fixes High-Order DiT Collapsepaper

    A Savitzky-Golay regularized multistep solver eliminates high-order Runge oscillations in Flow Matching DiT models, enabling clean 10-step generations in 11s.

    Why it matters: High-order diffusion samplers often collapse into noise; a training-free solver can improve image/video generation quality without retraining or extra compute.

    How to apply: Test Flow-WLS in ComfyUI on Anima DiT or similar Flow Matching models, compare 10-step outputs against DPM-Solver++ orders 2–3, and watch for oversmoothing.

    diffusionsamplerscomfyuiflow-matching

    Read more: [Research & Release] Flow-WLS: Why high-order samplers fail on DiT/Flow Matching (and how a Savitzky-Golay regularized multistep solver achieves clean 10-step generations in 11s) · [Research & Release] Flow-WLS: Why high-order samplers fail on DiT/Flow Matching (and how a Savitzky-Golay regularized multistep solver achieves clean 10-step generations in 11s)

12. #12 ALHR: O(N log N) Attention Retains 97% Long-Context Accuracypaper

    A learnable hierarchical routing attention system reduces key usage, scales VRAM better with tokens, and reports 97% MQAR accuracy over long context.

    ALHR · efficient attention

    Standard attention hits a memory wall as context grows

    Illustrative quadratic key-memory growth vs context length; ALHR's routing flattens the curve.

    Why it matters: Long-context inference is memory-bound; a subquadratic attention variant that preserves accuracy could make larger contexts practical on local hardware.

    How to apply: Follow the MQAR results and request code/weights when available; if you train long-context models, prototype hierarchical key routing against your current attention baseline.

    attentionlong-contextefficiencyresearch

    Read more: [UPDATE] I Built a O(NlogN) attention system that retains 97% accuracy over long context (MQAR) [P] · [UPDATE] I Built a O(NlogN) attention system that retains 97% accuracy over long context (MQAR) · [UPDATE] I Built a O(NlogN) attention system that retains 97% accuracy over long context (MQAR) · [UPDATE] I Built a O(NlogN) attention system that retains 97% accuracy over long context (MQAR)