MCP Goes Stateless, Agents Get Deterministic Orchestration, and Claude Code Gets a Lot Cheaper

Today's findings

1. #1 MCP 2026-07-28: the protocol core goes statelesstool

   MCP's next spec, finalizing July 28, drops session IDs and the init handshake and deprecates Roots/Sampling/Logging from core.

   MCP spec update · cuts over 2026-07-28

   MCP core drops session state

   Stateful core

   • Mcp-Session-Id
   • init handshake
   • Roots/Sampling/Logging built-in

   → Breaking migration

   Stateless core

   • Mcp-Method/Mcp-Name headers
   • server/discover
   • Roots/Sampling/Logging as extension

   Existing session-based auth/logging needs rework before 7/28

   Why it matters: If your team runs or builds MCP servers, this is a breaking migration, not a routine update — stateless core means servers become easier to scale behind ordinary load balancers, but existing session-based auth/logging assumptions will need rework, and OAuth 2.1/OIDC hardening is bundled in.

   How to apply: Audit any custom MCP servers for reliance on Mcp-Session-Id or the initialize/initialized handshake; plan the switch to Mcp-Method/Mcp-Name headers and server/discover before the 7/28 cutover, and check whether you use Roots/Sampling/Logging since those move to an extension.

   mcpprotocolagents

   Read more: MCP 2026-07-28 looks like a real migration, not a routine spec bump

2. #2 Treat multi-agent orchestration as a distributed-systems problem, not an agent-framework problemtechnique

   Stop trying to make the LLM deterministic — make the orchestration around it deterministic instead: typed task graphs, durable queues, stateless workers.

   Multi-agent reliability

   Orchestration is a distributed-systems problem, not a framework problem

   In-process agent framework

   • Planner calls workers directly
   • Failure detection left to you
   • State lives in-process, dies on crash

   vs

   Distributed orchestration

   • Typed task contract: what, not how
   • Durable per-type queues
   • Externalized state, TTL + atomic completion

   Make the plumbing deterministic — not the LLM

   Two years running multi-agents in production, distilled

   Why it matters: This is a hard-won lesson from two years of running a multi-agent system in production: partial failure, retries, and coordination are the actual reliability problems, and in-process agent frameworks leave failure detection and recovery to you.

   How to apply: Have your planner emit a typed task contract (what, not how) rather than calling workers directly; put tasks on durable per-type queues so a dead worker just leaves its task waiting; externalize aggregator state with a TTL and atomic completion so it survives crashes and scales across replicas.

   agentsorchestrationreliability

   Read more: The hard part of multi-agent systems isn't the agents — it's what happens when one dies mid-task · Treating LLM agent orchestration as a distributed-systems problem — durable execution vs. agent frameworks · We stopped trying to make our agents deterministic and made the orchestration deterministic instead · We stopped trying to make our agents deterministic and made the orchestration deterministic instead

3. #3 Open-source profiler shows exactly where your Claude Code tokens gotool

   A free local tool reads your own Claude Code session logs and surfaces re-read files, failed-command re-billing, and cache savings.

   Token Waste, Quantified

   One profiler run found $201 burned on retries

   $201

   re-billed from failed calls

   across 60 sessions

   455

   failed tool calls re-billed

   118x

   same 5,649-line doc re-read

   60

   sessions analyzed

   Local profiler reads your own Claude Code JSONL logs to surface this

   Why it matters: The author found a 5,649-line progress doc re-read 118 times and $201 of retry re-billing from 455 failed tool calls in just 60 sessions — the kind of waste that's invisible until you look at raw per-request token logs.

   How to apply: Point the profiler at your own `~/.claude/projects/` JSONL logs to find your worst offenders; the fix pattern shown (split long docs into a short 'current state' head plus archived history below a marker) is directly reusable for any CLAUDE.md or progress doc.

   claude-codecostobservability

   Read more: I profiled 3 months of my Claude Code transcripts. One markdown file was read 118 times, a dead MCP server taxed every request, and caching silently saved me $15k

4. #4 Route Claude Code sub-tasks to the cheapest capable model automaticallytool

   A plugin makes the main Claude Code model act as a router, sending mechanical sub-tasks down a ladder to shell commands, then Haiku, then Sonnet, before ever using the top-tier model.

   Cost-aware routing

   Claude Code tries the cheapest option first, escalating only when needed

   1

   Shell cmd

   grep/jq/git

   2

   Haiku

   locate/extract

   Most mechanical sub-tasks stop here

   3

   Sonnet

   edits

   4

   Top-tier

   planning

   Top-tier model reserved for actual judgment calls, not busywork

   Why it matters: Most calls in an agent session aren't reasoning — they're locating files, extracting fields, or mechanical edits — and running that on a top-tier model is the bulk of a wasted bill.

   How to apply: Adopt the ladder pattern directly: try a deterministic shell command first (grep/jq/git), fall back to a small model for locate/extract tasks, and reserve your best model for actual planning and judgment calls.

   claude-codecostagents

   Read more: Frugal: routing Claude Code sub-tasks to the cheapest capable model, enforced with hooks and measured per run

5. #5 Provider failover chains can silently triple your per-task costtip

   A 'reliable' primary→secondary→tertiary LLM failover chain replayed full context through all three providers on hard tickets, tripling cost per resolved ticket while uptime dashboards looked fine.

   Why it matters: Uptime and cost-per-task are different metrics, and a fallback chain built for reliability can quietly wreck margins on exactly the highest-value cases without tripping any alert.

   How to apply: If you run multi-provider failover, add cost-per-resolved-task tracking broken out by whether a request hit the fallback chain, and cap how many providers a single request can cascade through before failing loudly instead of expensively.

   agentscostreliability

   Read more: Failover between LLM providers saved our uptime and quietly tripled our cost per task. Here's how we caught it.

6. #6 SymbolPeek: an MCP server that gives agents symbol-level code access instead of whole filestool

   Open-source (MIT) MCP server lets Claude Code/Codex answer 'where is this function defined' without reading a 2,000-line file.

   Why it matters: Directly reduces token spend and context pollution on large TypeScript/JS codebases, the same class of waste the Claude Code profiler above independently surfaced.

   How to apply: Add it as an MCP server alongside your existing filesystem tools for large repos; it's most valuable exactly where agents currently do full-file reads to answer symbol-level questions.

   mcpcodingtokens

   Read more: I built an MCP server that lets AI read symbols instead of entire files

7. #7 Kwaipilot open-sources KAT-Coder-V2.5-Dev, a 35B-A3B coding MoErepo

   Open-weight release of the coding-focused MoE behind KAT-Coder-V2.5, 35B total / 3B active parameters.

   architecture

   KAT-Coder-V2.5-Dev: sparse coding MoE, open-weight

   router

   top-3 gate

   35B total params3B active per token

   weighted

   merge

   35B

   total params

   3B

   active per token

   ~8.6%

   of weights fire

   Why it matters: A capable open-weight coding model in the 3B-active tier is runnable on modest local hardware via llama.cpp, giving teams a self-hostable alternative for coding-agent workloads.

   How to apply: Pull the weights from Hugging Face and benchmark against your current local coding model (e.g. Qwen3.6-35B-A3B) on your own repo tasks before adopting.

   open-weightscodingmoe

   Read more: Kwaipilot/KAT-Coder-V2.5-Dev · Hugging Face

8. #8 Offload MoE experts to system RAM with llama.cpp's --n-cpu-moe on consumer GPUstip

   A two-site local LLM cluster build shows Qwen3.6-35B-A3B (Q4_K_M) running via llama.cpp with `--n-cpu-moe 12` after vLLM + gpt-oss-20b repeatedly OOM'd on a 24GB card.

   Local LLM Memory Trick

   Split MoE Experts Between GPU and RAM

   HOT

   24GB GPU VRAM Active experts + KV cache

   COLD

   System RAM 12 offloaded MoE experts

   llama.cpp --n-cpu-moe 12 kept Qwen3.6-35B-A3B (Q4_K_M) off the OOM path where vLLM + gpt-oss-20b failed

   Why it matters: Concrete, reusable fix for the common 'MoE model almost fits but not quite' problem on 16-24GB consumer GPUs — offloading select MoE experts to CPU RAM instead of falling back to heavier quantization or a smaller model.

   How to apply: If a MoE model OOMs on your GPU, try llama.cpp with `--n-cpu-moe <n>` to push some experts to system RAM before downsizing the quant or the model.

   llama.cpplocal-llmquantization

   Read more: Built a two-site local LLM cluster from second-hand hardware, meshed with self-hosted Headscale

9. #9 Fully local RAG over proprietary manuals, built by a non-programmer, with a documented eval harnesstechnique

   An industrial engineer with no prior coding background built a production-bound, fully local RAG system (hybrid + contextual retrieval + reranking, Qwen3 generation) gated behind an eval harness, now saturated at 56/56 on their retrieval eval.

   Why it matters: It's a real production RAG build for data that legally can't leave the building, with a documented list of what didn't work — a useful reality check against RAG tutorials that stop at 'index loaded'.

   How to apply: Borrow the structure directly: hybrid retrieval + contextual retrieval + reranking as the retrieval stack, and build an eval set early so you know when retrieval is actually saturated versus when synthesis is the bottleneck.

   raglocal-llmollama

   Read more: I’m an industrial commissioning engineer with no coding background. I built a fully local RAG system over our machine manuals and it’s going into production. Full write-up — including everything that didn’t work.

10. #10 NeuTTS-2E: open-source on-device TTS with 7 controllable emotionsrepo

    125M-active-parameter open-source TTS model with controllable emotion, designed to run on-device.

    Why it matters: Small enough to run locally without a TTS API dependency, useful for voice features where sending user text to a third-party TTS service is undesirable.

    How to apply: Evaluate for local voice-agent or accessibility features where latency and data locality matter more than studio-grade quality.

    ttsopen-sourcelocal-llm

    Read more: We built NeuTTS-2E, an open-source on-device TTS model with 7 controllable emotions

11. #11 Gigatoken: a Rust BPE tokenizer claiming up to 989x HuggingFace Tokenizers throughputrepo

    New Rust BPE tokenizer benchmarked at 24.53 GB/s encoding speed.

    Why it matters: Tokenization is a real bottleneck in large-scale data pipelines and RAG ingestion; a drop-in faster tokenizer can meaningfully cut preprocessing time for large corpora.

    How to apply: Benchmark it against your current tokenizer on your actual ingestion pipeline before swapping — verify vocab/BPE-merge compatibility with your target model first.

    tokenizationperformanceopen-source

    Read more: Meet Gigatoken: A Rust BPE Tokenizer that Encodes Text at 24.53 GB/s, up to 989x Faster than HuggingFace Tokenizers

12. #12 SkewAdam: tiered optimizer cuts MoE training memory by 97%paper

    A tiered-optimizer approach reportedly fits a 6.7B MoE's optimizer state on a 40GB GPU, a 97% memory cut versus standard Adam.

    Why it matters: Optimizer state (not weights) is often the real memory bottleneck when fine-tuning MoE models locally; a technique that shrinks it that much could make MoE fine-tuning feasible on a single workstation GPU.

    How to apply: If your team fine-tunes MoE models locally and is VRAM-constrained, check the repo/paper for implementation details and whether it integrates with your existing training stack before committing.

    fine-tuningmoequantization

    Read more: SkewAdam: A tiered optimizer that cuts MoE state memory by 97% (fits a 6.7B MoE on a 40GB GPU) [R]