Pi haalt MCP naar de kern, terwijl lokale AI nieuwe meet- en compatibiliteitspaden krijgt

Pi neemt MCP voortaan op in zijn kern en koppelt het aan een sandbox voor toolorkestratie. Voor lokale inference is er een concreet compatibiliteitspunt: GLM-5.3-Flash zit nu in mainline llama.cpp. Een uitgebreide, maar nog enkelvoudige M1-Max-proef laat bovendien zien dat snelheid, geheugen en contextlengte verschillende winnaars opleveren.

Pi draait MCP-koers om met Codemode als orkestratielaag

De makers van Pi hebben MCP van een eerder afgewezen extensie naar een kernfunctie verplaatst. De technische reden is niet alleen het protocol zelf: Pi wil MCP-tools via Codemode beschikbaar maken in een JavaScript-sandbox die toolcalls kan combineren, paralleliseren en sessiestaat in het transcript bewaart in plaats van op het filesystem.

Dat is relevant voor agents die veel kleine tools combineren. De makers willen tools liever als ontdekkbare interfaces met gestructureerde resultaten behandelen dan als grote lappen tekst in de context. Ze koppelen dezelfde laag ook aan deferred tool loading en aan Jev-achtige classificatie: in het voorbeeld haalt een script eerst issues op via Linear-MCP en laat het vervolgens commentaren classificeren zonder alle tussenresultaten in de modelcontext te zetten.

De grens blijft belangrijk. Pi zegt zelf dat MCP-servers en harnesses nog lastig samen te stellen zijn. In de HN-discussie wordt bovendien terecht opgemerkt dat clients resources en prompts niet uniform afhandelen; ook een sandbox maakt toolrechten niet vanzelf veilig. Wie deze route test, moet dus per MCP-server de toegestane acties, credentials, netwerktoegang en responsegrootte begrenzen — en niet aannemen dat Codemode een vervanging is voor OS- of netwerkisolatie. Technische toelichting van Pi · HN-discussie

Mainline llama.cpp krijgt GLM-5.3-Flash-conversie met MTP-pad

Een gemergede commit in llama.cpp voegt ondersteuning toe voor Glm5NextForConditionalGeneration, de architectuur van GLM-5.3-Flash. De converter registreert het model expliciet, schrijft de benodigde architectuurmetadata weg en bevat een pad voor het exporteren of overslaan van de MTP-lagen. Daarmee is dit meer dan een communityfork: de basisondersteuning staat nu in de hoofdcodebase.

Dat is een concrete lokale-compatibiliteitsstap na de einde-dagupdate van gisteren, die GLM-5.3 vanuit cyberrisico bekeek. Wie het open model lokaal wil proberen, krijgt nu een route om zelf GGUF-artefacten uit de originele gewichten te maken, inclusief de model-specifieke attention-, indexer- en MoE-metadata die de commit verwerkt.

Dit betekent nog niet dat elke bestaande quant direct werkt, of dat iedere backend het model meteen kan serveren. Een Reddit-discussie rond een eerdere pull request meldde juist naams- en compatibiliteitsfrictie tussen quants en mainline. Verifieer daarom conversie, chattemplate, toolcalls en tokenpariteit op de eigen versie; vooral MTP is een extra bewegend onderdeel. Gemergede commit · Reddit-signaal

M1-Max-test scheidt snelle decode van zuinige lange context

Een gebruiker vergelijkt Splash-M1, upstream MTPLX, een eigen M1-geoptimaliseerde MTPLX-fork, oMLX en TensorFold op een M1 Max met 64GB en Qwen3.8-27B. De test meet drie beurten met steeds langere synthetische logs en korte antwoorden; hij is dus vooral relevant voor documentanalyse en repositorycontext, niet als algemene coding-agentbenchmark.

De uitkomst is minder eenduidig dan een tok/s-score. Splash-M1 decodeerde in de proef het snelst tot 64K context en gebruikte bij 128K ongeveer 26,2GB, tegenover 43,5GB voor de eigen MTPLX-fork. Die fork verwerkte lange prompts en follow-ups juist sneller: de totale driereeks bij 128K duurde volgens de meting 24,9 minuten tegen 29,4 minuten voor Splash. Bij één 256K-run bleef dat patroon bestaan, maar met 51,8GB voor de fork tegenover 30,4GB voor Splash.

Dit is een inhoudelijke aanvulling op de namiddagupdate van zaterdag, waarin Splash-M1 vooral als kernelproject werd besproken: nu ligt er een vergelijking met een vast meerturnscenario en een zichtbare geheugenruil. Maar het blijft één apparaat, een synthetische workload en een benchmark van de auteur van een deelnemende fork. Gebruik het als receptenkaart voor een eigen A/B-test: meet koude prefill, cache-hits, geheugenplafond én de echte verdeling tussen invoer en uitvoer in je agenttaken. Volledige opzet, ruwe cijfers en beperkingen

LokalBot bundelt lokale notulenstapel in 6,8GB

LokalBot 0.9.2 is een open-source Mac-app voor lokale vergaderopname en notulen. Volgens de maker bestaat de vernieuwde standaardstapel uit Qwen3-ASR 1.7B voor transcriptie, Nemotron 3 voor speaker-diarization, Qwen3.5 4B voor samenvattingen, Harrier voor embeddings en LFM2.5 1.2B voor autocomplete — samen 6,8GB aan gewichten. Een read-only MCP-server en CLI kunnen die vergadercontext optioneel toegankelijk maken voor andere clients.

De auteur rapporteert op een M4 Max met 48GB dat een opname van 26 minuten warm in 33 seconden naar notulen ging. In een eigen vergelijking daalde de speakerfout op AMI van 43,4% naar 14,6% ten opzichte van de vorige pyannote-configuratie; autocomplete zou op p95 van 1,83 naar 0,49 seconde zijn gegaan. Interessant is ook de negatieve keuze: MiniCPM5-2B was kleiner en sneller voor notulen, maar herhaalde in één test een samenvatting en schreef actiepunten fout toe.

Dat maakt dit een praktische lokale bouwsteen voor wie op-device notulen wil, maar geen onafhankelijke kwaliteitsgarantie. De metingen zijn van de maker, de diarization-vergelijking zegt mede iets over diens eerdere configuratie, en de MCP-interface vergroot de gegevensgrens. Test daarom transcriptie en namen op eigen taal, microfoons en vergaderformaten; laat de MCP-server uit totdat je weet welke client precies welke notities kan lezen. Releasepost met modelkeuzes en cijfers

Backblaze ziet hogere kwartaal-AFR, maar niet één simpele schijvenranglijst

Backblaze publiceert zijn Q2 2026 Drive Stats over 354.415 datadragers. De totale annualized failure rate kwam uit op 1,73%, hoger dan in recente kwartalen; de lifetime-AFR is 1,41%. De vloot verschuift verder naar grote capaciteit: schijven van 20TB of meer vormen volgens Backblaze inmiddels meer dan een kwart van de dataset.

De cijfers zijn vooral nuttig als operationeel datapunt, niet als koopgids. Hoge uitschieters kwamen in het kwartaal onder meer voor bij een bijna zeven jaar oude 12TB-HGST en bij twee Seagate-modellen met lage aantallen: 22 respectievelijk 25 failures resulteerden daar in hoge AFR’s. In de HN-discussie wordt terecht gewaarschuwd dat modelvergelijkingen zonder correctie voor leeftijd misleidend kunnen zijn.

Het rapport kijkt ook vooruit naar SMR, dat meer capaciteit per platter kan geven maar bij kleine willekeurige herschrijvingen een andere workloadkarakteristiek heeft. Backblaze heeft nog geen SMR-schijven in deze vloot. Voor storageteams is de praktische conclusie dus: combineer deze openbare dataset met eigen workload-, rebuild- en foutdomeinmetingen; beoordeel hoge capaciteit niet los van schrijfpatroon, erasure coding en herstelgedrag. Q2-dataset en duiding · HN-discussie

Verder nog

• Oído wil ASR op een ESP32-S3 brengen: het open-sourceproject gebruikt volgens de makers een 13M-parameter int8 Conformer-CTC-model op een ESP32-S3 met 8MB PSRAM. De post claimt betere WER dan Whisper tiny.en op LibriSpeech en een eigen ruisopzet; dat zijn makersmetingen en geen onafhankelijke vergelijking. Wel een interessant embedded-signaal voor wie offline spraakherkenning zonder GPU of NPU wil onderzoeken. Aankondiging en repositorylink