LFM2.5 brengt 24B-MoE naar lokale agents; Ledger bevestigt hardware-implantaat

Liquid AI heeft LFM2.5-24B-A2B aangekondigd: een MoE-model met 24 miljard totale parameters, waarvan volgens de maker 2 miljard per token actief zijn, en een contextvenster van 131K tokens. Elders bevestigt Ledger dat in minstens één apparaat uit een specifieke resellerketen een ongeautoriseerd hardware-implantaat zat; wie zo’n wallet via die keten kocht, moet niet op alleen een softwarematige authenticiteitscheck vertrouwen.

Ook praktisch voor ontwikkelaars: de statusstandaard OSC 7501 krijgt ondersteuning in Kitty, Grok Build en — nog niet in een getagde versie — Codex. Lix 2.96 zet ondertussen een migratiepad uit voor remote Nix-stores.

LFM2.5-24B-A2B mikt op lokale meerstapsagents

Liquid AI kondigt LFM2.5-24B-A2B aan als grootste lid van zijn LFM2.5-familie. Het model heeft volgens de aankondiging 24B parameters in totaal, maar activeert er 2B per token; de context groeit naar 131K tokens. De maker positioneert het expliciet voor laptops en pc’s die meerstapswerk in bestaande agent-harnassen uitvoeren.

Dat is interessant voor lokaal gebruik omdat een MoE-opzet de rekenlast per token kan beperken zonder het totale model even klein te maken. Uit de beschikbare post blijkt echter niet welk geheugenbeslag, welke quantisatie, hardware of onafhankelijke taakscore daarbij hoort. Behandel de aankondiging dus als een nieuw model om op eigen prompts, toolcalls, contextlengte en foutgedrag te meten — niet als bewijs dat het op elke laptop bruikbaar of beter is dan een dicht model.

Liquid AI’s aankondiging op X

Ledger bevestigt implantaat in apparaten uit één resellerketen

Ledger zegt volgens BleepingComputer te hebben vastgesteld dat minstens één getroffen apparaat een ongeautoriseerd hardware-implantaat bevatte. De leverancier koppelt alle gemelde onverwachte wallet-leegloop aan apparaten die via de Zuidoost-Aziatische reseller CryptoBilis zijn verkocht, omschrijft de omvang als beperkt en onderzoekt nog hoe en wanneer de manipulatie plaatsvond.

Dat is een belangrijke reminder dat een secure element niet alle fysieke supply-chainmanipulatie dekt. Het artikel beschrijft onderzoek van Karpelès en Tibane Labs naar varianten in Ledger X-apparaten: de extra hardware zou schermuitvoer en knopdrukken hebben kunnen onderscheppen en via LTE versturen. Dat technische mechanisme is een bevinding van die onderzoekers, geen volledige technische bevestiging van Ledger. Ledger waarschuwt bovendien dat zijn Genuine Check een toegevoegd implantaat niet per se ziet wanneer het oorspronkelijke secure element intact blijft.

Voor bezitters is de actie concreet maar afgebakend: Ledger adviseert klanten die via deze reseller kochten een ongebruikt apparaat niet in te stellen; wie het al gebruikte, moet overwegen fondsen naar een nieuwe signer met nieuwe seed te verplaatsen. Het beschikbare materiaal wijst niet op andere resellers. Koop nieuwe hardware daarom via geautoriseerde kanalen, maar behandel vooral de eerste seed-invoer als een fysiek vertrouwensmoment, niet als iets dat één appcheck volledig kan bewijzen.

BleepingComputer: bevestiging, scope en onderzoek · HN-discussie

OSC 7501 krijgt eerste concrete interoperabiliteit

De terminalstatusspecificatie OSC 7501, die in de ochtendupdate van woensdag 7 oktober nog vooral een voorstel met proof-of-concepts was, krijgt nu drie concrete adopties. Volgens auteur Mitchell Hashimoto implementeert Kitty de code en toont die in de tabtitel; Grok Build heeft ondersteuning uitgebracht; Codex heeft ondersteuning gemerged, maar die zit nog niet in een getagde release.

Dat is precies het soort ontwikkeling dat de waarde van de specificatie kan vergroten: processen kunnen hun eigen toestand melden in plaats van terminals en agentinterfaces te laten raden uit schermtekst of processen. Voor integrators blijft het wel vroeg: één implementatie is al uit, maar voor Codex is er nog geen stabiele release genoemd en de post levert geen compatibiliteitstest tussen de betrokken tools. Reken dus pas op een portable workflow wanneer de versies en het gedrag in de eigen terminalstack zijn gecontroleerd.

Hashimoto over de nieuwe adopties

Pulse Local houdt budgetvragen en rekenwerk op de Mac

Pulse Local is een Mac-bèta voor Apple Silicon die budgetgegevens uit CSV importeert en vragen over uitgaven lokaal probeert te beantwoorden. Volgens de productpagina loopt de geldberekening door code tegen de ledger; modellen lezen de vraag en controleren de interpretatie nogmaals. Bij tegenstrijdige interpretaties meldt de app onzekerheid in plaats van een bedrag te gokken. Met die controle aan duurt een geldantwoord volgens de maker 12 tot 14 seconden.

De privacyruil is expliciet: geen account, geen bankkoppeling en geen synchronisatie; de data blijft op één machine. Dat maakt het een interessant patroon voor gevoelige consumentenworkflows, maar ook minder handig dan apps met directe banksynchronisatie. De app is voorlopig Engelstalig en vereist een recente Apple-Silicon-Mac.

De lokale route maakt importkwaliteit des te belangrijker. In één HN-test met een CSV van 150 regels koppelde de automatische import een Description-kolom verkeerd aan Merchant Name, waardoor 25 regels dreigden te worden overgeslagen; handmatig wijzigen loste het op en de maker beloofde de mapping aan te passen. Dat is één gebruikerservaring, geen algemene foutmeting, maar wel reden om na import totalen, kolommen en uitzonderingen te controleren voordat je op analyses vertrouwt.

Pulse Local: productpagina en beperkingen · HN-discussie

Lix 2.96 maakt ssh://-migratie en flakegedrag expliciet

De Nix-implementatie Lix 2.96 ‘Bingsu’ depreceert ssh://-store-URI’s; in 2.97 wil het project ze verwijderen. ssh-ng:// blijft bestaan en wordt nu als stabiel aangemerkt. Lix noemt strengere securitychecks als reden: de nieuwere route staat onder meer niet toe dat onbetrouwbare gebruikers ongesigneerde outputs naar remote stores kopiëren.

Voor Nix-beheerders is dat vooral een migratiesignaal. De oude URI’s werken in 2.96 nog zonder waarschuwing, maar teams met remote builders of scripts doen er goed aan hun configuratie vóór 2.97 op ssh-ng:// te testen. Volledige featurepariteit geldt volgens Lix alleen tussen recente Lix-versies; koppelingen met oudere Lix- of andere Nix-implementaties kunnen stil terugvallen op eerder gedrag.

Let ook op een compatibiliteitsbreuk rond flake.nix: buiten outputs zijn voortaan geen functiecalls toegestaan, maar let-blokken en stringinterpolatie in flake-inputs wel. Daardoor kunnen flakes die Lix accepteert niet per se door andere Nix-implementaties worden geëvalueerd. De release meldt daarnaast een eigen evaluatiewinst van 5–12% door mimalloc; dat is een projectmeting, geen algemene performancegarantie.

Lix 2.96: release notes en upgrade-instructies · Lobsters-discussie

Verder nog

• uv-build als distributie-afweging: een Gentoo-maintainer pleit ervoor om voor pure Python-pakketten geen uv-build als PEP 517-backend te kiezen, vooral wegens de Rust-toolchain, frequente releases en zwakkere portabiliteit op nicheplatforms. Een uv-maintainer werpt in de discussie tegen dat downstreams een compatibele backendversie minder vaak kunnen bijwerken. Dit is geen algemeen oordeel over uv of een aangetoonde fout, maar een bruikbare afweging voor projecten die source-based distributies willen ondersteunen. Gentoo-blog · Lobsters-discussie