Typed Decision Heads Take Over Agent Loops, Plus Half-Price Browser Agents and Code-Aware MCP

Today's findings

1. #1 Typed Decision Models Replace JSON-Generating LLM Calls in Agent Loopstechnique

   Use classifier-style decision models like Jev, GLiNER2.5-Decide, and GLM-5.3-Flash to return typed choices and probabilities for tool routing, safety, and escalation instead of free-text JSON.

   AGENT TOOL ROUTING

   Who picks the tool: a chat call or a decision head?

   vs

   LLM + generated JSON

   Typed decision head

   Output

   Free text; can be malformed

   Typed label, always valid

   Confidence

   Buried in prose

   Probability per choice

   Cost

   Full generative call

   Small classifier pass

   Latency

   Token-by-token

   Single forward pass

   Open-ended reasoning

   Handles novel cases

   Fixed label set

   LLM + generated JSON wins the row Typed decision head wins the row

   Decide with the head, act with the LLM — confidence below threshold escalates to a human.

   Why it matters: Agent loops waste tokens and fail on malformed JSON when every routing decision is a generative call; typed decision heads are faster, cheaper, and easier to validate.

   How to apply: Wrap tool selection, safety checks, and escalation in a decision endpoint that returns a label plus confidence; expose only the chosen tool schema to the LLM and use confidence thresholds for human fallback.

   agentsroutingstructured-outputlocal

   Read more: GLiNER2.5-Decide vs Jev: typed decisions without asking an LLM for JSON · I spent some time understanding Jev, TypeSafe's decision-only model. Here's what I learned · The JEV feature missing from most LLM speed-vs-accuracy comparisons · Unofficial Jev plugin for coding agents: best practices, an API reference, and 150+ community projects. Evals included. · GLM-5.3-Flash works as a Jev-like decision model with the same accuracy and speed · TensorSharp Jev requests can now combine documents, images, video, and audio · If Jev picks the tool, how does the LLM ask for another one?

2. #2 Browser Agents Cut Token Cost with Element Tables and Playwrighttechnique

   PawBrowse and FreeComputerUse show that giving agents structured DOM/element tables and local Playwright execution can roughly halve browser-automation cost versus screenshot-per-action loops.

   Why it matters: Screenshot-driven browser agents are slow and token-hungry; structured page representations and local execution make agentic browsing practical for CI and internal tools.

   How to apply: Extract an element table or accessibility tree for planning, let the model choose actions, then execute them locally with Playwright; reserve model calls for planning and failed-step repair.

   agentsbrowser-automationtokensplaywright

   Read more: PawBrowse - I made my agent's browser automation ~2x faster by giving it an element table instead of screenshots (open source, reproducible benchmark) · FreeComputerUse, a local-first browser automation agent that tries to make "computer use" dramatically cheaper in tokens.

3. #3 Benzi MCP Adds Code Intelligence to Claude Codetool

   Benzi is a free MCP server that indexes code with tree-sitter and gives Claude Code symbol-level intelligence to reduce token use and speed up navigation.

   BENZI MCP

   Query a symbol index instead of dumping raw files into context

   Without Benzi

   vs

   With Benzi

   Index the code once, edit with symbol-level precision — fewer tokens, faster navigation

   Free MCP server that adds code intelligence to Claude Code

   Why it matters: Codebase-aware MCP tools can cut the context Claude Code needs for refactors and bug fixes, directly reducing cost and latency.

   How to apply: Add the Benzi MCP server to Claude Code, then use it for symbol lookup, reference finding, and impact analysis before asking the agent to edit.

   mcpclaudecode-intelligencetokens

   Read more: Benzi - FREE code intelligience MCP that makes claude code 2x faster and cheaper

4. #4 Tauon Optimizer Beats Muon on GPT-Minipaper

   A new optimizer called Tauon reports lower loss and about 8.5% faster step time than Muon on GPT-Mini.

   Why it matters: Training efficiency gains compound for teams fine-tuning or pretraining small models, and Tauon is a drop-in candidate to benchmark against Muon and AdamW.

   How to apply: Add Tauon to your training harness and run an A/B against your current optimizer on a representative small model, tracking loss, step time, and stability.

   trainingoptimizerspaper

   Read more: Tauon: A new optimizer outperforming Muon on GPT-Mini (lower loss, ~8.5% faster step time) [P]

5. #5 InkDoc Converts PDFs to RAG-Ready Markdown Locallytool

   InkDoc is a local desktop app that turns PDFs, Office files, and URLs into clean Markdown with tables preserved for RAG ingestion.

   InkDoc · local RAG preprocessing

   From parse-breaking PDFs to RAG-ready Markdown

   Raw PDFs, Office, URLs

   • Scrambled tables
   • Lost structure
   • Manual cleanup

   → Runs fully local — documents stay private

   InkDoc output

   • Clean Markdown
   • Tables intact
   • RAG-ready

   RAG quality often dies at document parsing; InkDoc removes that step.

   Why it matters: RAG quality often dies at document parsing; a local, private converter that keeps tables intact removes a painful preprocessing step.

   How to apply: Drop source documents into InkDoc, review the Markdown output, then feed it into your local or Claude-based RAG pipeline instead of raw PDFs.

   raglocalmarkdownpdf

   Read more: Drag a PDF in , get RAG-ready Markdown out: free , local ,and the tables actually survive

6. #6 Splash Fork Speeds Local Inference on M5 Maxtool

   A fork of Inco's Splash engine optimized for M5 Max reports about 1.5x higher throughput and 1.25x faster single-request performance.

   Tool · Local LLM

   Splash fork tuned for M5 Max

   1.5×

   higher throughput vs upstream Splash

   1.25× faster single requests

   1.25×

   faster single-request runs

   M5 Max

   same Mac, no new hardware

   GGUF / MLX

   benchmarks your usual models

   A tuned engine, not new silicon — making larger local models usable on a Mac dev setup.

   Why it matters: Mac-based local inference is a common dev setup, and a tuned engine can make larger models usable without new hardware.

   How to apply: Run the fork on an M5 Max, benchmark your usual GGUF/MLX models, and compare tokens per second against the upstream Splash build.

   local-llmmacinferenceperformance

   Read more: Splash fork optimised for M5 Max: ~1.5× faster (1.25× single request) · Splash fork optimised for M5 Max: ~1.5× faster (1.25× single request)

7. #7 Qwen3.8-27B FP8 Runs 262K Context on Mixed 48GB VRAMtechnique

   A vLLM pipeline-parallel recipe runs Qwen3.8-27B block-FP8 across a 5090 and 4070 Ti Super with 262K context, MTP, and fp8 KV cache.

   Why it matters: It is a concrete local long-context agentic setup that uses mixed consumer GPUs instead of a uniform expensive rig.

   How to apply: Replicate the layer split in vLLM 0.30.0, enable block-FP8, MTP K=3, and fp8 KV; tune pipeline ranks to your VRAM balance.

   local-llmvllmquantizationlong-context

   Read more: Qwen3.8-27B FP8 dual GPUs

8. #8 Gate Stochastic Agent Evals in CI Without False Alarmstechnique

   MLOps teams are handling noisy agent eval scores by averaging multiple runs, requiring reproducible drops, and using confidence intervals before blocking CI.

   Why it matters: Agent evals are stochastic, so naive threshold gating either blocks good changes or lets regressions through.

   How to apply: Run each eval N times, compare distributions rather than single scores, and only fail CI when a drop reproduces across runs or exceeds a confidence bound.

   evalsciagentsmlops

   Read more: How are you gating stochastic LLM/agent evals in CI?

9. #9 LLM Router Evals Can Leak Task Identitytechnique

   A learned router scored 0.84 AUC, but shuffling labels within each task still scored 0.838, showing it learned task recognition rather than difficulty.

   measured

   Shuffling labels barely moved the score

   1

   Real labels

   0.84

   2

   Shuffled within task

   0.838

   3

   Random guess

   0.50

   Router eval AUC (higher = better)A near-tie with shuffled labels means the router learned task identity, not difficulty

   Why it matters: Routing and model-selection evals can look strong while actually measuring task leakage, leading to bad production routing decisions.

   How to apply: Test routers with within-task label shuffling and held-out tasks; if shuffled labels preserve AUC, your router is not learning difficulty.

   routingevalsmlops

   Read more: A learned LLM router scored 0.84 AUC. Shuffling the labels within each task still scored 0.838

10. #10 Chat Template Changes LLM Self-Referential Voicepaper

    An arXiv paper shows that the chat template itself switches how a language model refers to itself, affecting behavior and evaluation.

    Why it matters: Prompt and template formatting are not neutral; they can change model identity, tone, and benchmark results.

    How to apply: Audit your chat templates and test self-referential prompts across templates before drawing conclusions from evals or shipping system prompts.

    promptingtemplatespaper

    Read more: "As a Language Model": Chat Template Switches LLM Self-Referential Voice

11. #11 Pin CUDA and ROCm Versions for Older Local GPUstip

    A reference table lists the last CUDA and ROCm versions that support older cheap-VRAM cards like P40, P100, V100, M40, and MI50.

    Why it matters: Used GPUs are popular for local LLM rigs, but newer toolkits drop support and break builds without obvious errors.

    How to apply: Check the table before buying or upgrading, then pin the matching CUDA/ROCm toolkit and driver versions in your local inference environment.

    local-llmcudarocmhardware

    Read more: Running a P40, P100, V100, M40 or MI50? Here's the last CUDA/ROCm version that supports each older GPU architecture, so you know what to pin

12. #12 Profile Prompt Preprocessing Before Blaming VRAMtip

    Naive Python prompt preprocessing, string manipulation, and token chunking can cause OOM and throughput flatlines in local LLM stacks.

    Why it matters: Teams often blame quantization or context length when the real bottleneck is inefficient data preparation before inference.

    How to apply: Profile the pipeline before the model call, move tokenization and chunking to efficient batched code, and measure preprocessing time separately from inference.

    local-llmperformanceprofiling

    Read more: The silent bottlenec