Laya krijgt snelle C++-runtime; Focus-llama probeert KV-context tijdens decode weg te snijden

Laya heeft nu een zelfstandige C++-implementatie met CUDA-kernels en een Jev-compatibele HTTP-endpoint; de gepubliceerde metingen maken het lokale pad concreter, al zijn ze nog niet onafhankelijk gereproduceerd. Daarnaast probeert een llama.cpp-fork context tijdens generatie daadwerkelijk te verkleinen, maar de maker meldt zelf dat de vereiste CUDA-kernelwinst er nog niet is. Een kleine agentproef herinnert er tegelijk aan dat minder tokens niet automatisch minder productiefouten betekenen.

Laya.cpp zet het open beslismodel op een veel smaller runtimepad

laya.cpp implementeert Laya zonder Python of PyTorch, op basis van ggml met eigen CUDA-kernels, native tokenisatie en uitvoerformattering. De release ondersteunt de Engelse, meertalige en typed-decisions-checkpoints, biedt een HTTP-server met Jev-compatibele endpoint en staat onder MIT-licentie. De auteur rapporteert op een RTX PRO 6000 Blackwell bij BF16 366 beslissingen per seconde voor batchgrootte 1, tegenover 149 voor de vergeleken Python-route; laden en JSON-transport tellen niet mee. Aankondiging, code en volledige meettabel

Dit is een concrete vervolgstap na de middagupdate van vrijdag, waarin Laya als 421M-parameter beslismodel met een Python-georiënteerde release aan bod kwam. Voor routing, rubric scoring of vaste ja/nee- en keuzevragen is een zelfstandige binary interessant: minder runtime-afhankelijkheden en een endpoint dat bestaande Jev-gerichte clients kan uitproberen zonder hun requestvorm te herschrijven.

De snelheid is geen algemene Laya-benchmark. Ze komt van de maker, op één krachtige kaart en een vaste corpus van 250 vragen; de vergelijking sluit transport en laden uit. Ook zegt een endpoint niets over de juistheid van de beslissing of calibratie van de confidence. Test dus eerst eigen labels, foutkosten en batchpatroon — vooral wanneer een foute ‘snelle’ beslissing een actie in gang zet.

Focus-llama maakt contextselectie experimenteel in llama-server

De nieuwe fork focus-llama bouwt een paper over Declarative Attention in llama.cpp in. Een client levert contextblokken aan; na een tag van het model kan de server andere KV-bereiken uit de actieve request verwijderen. Er is ook een modus met een tweede sequence die het origineel bewaart. Dat is interessant voor lange prompts waarin het model maar een klein deel van de aangeleverde context nodig denkt te hebben. Project, ontwerpnotities en beperkingen

De belangrijke nuance staat al in de aankondiging: stock llama-server kan zonder deze wijzigingen geen KV-ranges midden in generatie aanpassen, maar enkel maskeren bespaart op CUDA bij single-token decode nog geen leeswerk. De fork bevat daarom servermechaniek voor verwijderen, niet automatisch een bewezen versnelde kernelroute. De aangehaalde papercijfers — 0,71× decode-tijd voor Gemma en 0,77× voor Qwen ten opzichte van vanilla — komen uit de vLLM-implementatie van de paper; de fork-auteur heeft zelf nog geen snelheids- of kwaliteitsbenchmark gepubliceerd.

Dat maakt dit nu vooral relevant voor runtimebouwers die KV-compactie, attention-kernels of contextprotocollen onderzoeken. Het is nog geen optie om blind in een lokale agentstack te zetten: het model kan relevante blokken verkeerd uitsluiten en de auteur noemt zelf geen eigen accuracy-evaluatie. Meet dus zowel taakuitkomst als latency bij dezelfde contextindeling.

OpenCode en PI: minder tokens, maar een minder zichtbare fout

Een gebruiker draaide hetzelfde lokale model — KAT-Coder-V2.5-Dev-APEX via llama.cpp op een Intel Arc Pro B70 plus RTX 5070 — tegen drie kleine webprojecten, en wisselde alleen de agent tussen OpenCode en PI. PI gebruikte in totaal volgens de post circa 80,8k tokens en elf minuten, tegen OpenCode 97,9k en twaalf minuten. Maar PI leverde bij één project een pagina af waarvan drag-and-delete niet werkte zonder consolefout; OpenCode produceerde twee directe syntaxfouten. Opzet, bronbestanden en resultaten

Dat sluit concreet aan op de eerdere observatie dat de harness de uitkomst mede vormt: hier verschuift niet alleen tijd en tokenverbruik, maar ook het soort defect. Een zichtbare syntaxfout is vaak snel te herstellen; ontbrekende interactie kan juist ongemerkt door een oppervlakkige review komen. Voor lokale agents is dat een reden om browser- of integratietests mee te nemen in de vergelijking, niet alleen wall-clock en tokens.

De test is nadrukkelijk te klein voor een winnaar: drie projecten, één uitvoering elk, en volgens reacties zijn de standaardtools van beide harnesses mogelijk niet gelijk. Samplingvariantie, systeemprompts en toolrechten kunnen de uitslag domineren. Zie dit als bruikbaar testformat voor een eigen repository, niet als bewijs dat PI of OpenCode structureel beter is.

Adtech rond ChatGPT vraagt om controle van browser- en accountgrenzen

Een HN-verwijzing stelt dat ChatGPT via een adtech-collector informatie over andere websites kan koppelen. In de bewaarde discussie wordt het beschreven mechanisme als reguliere advertentietechniek aangeduid, maar de toepassing bij een AI-chatproduct als nieuw; een reactie wijst bovendien op verschillende browserbeschermingen tegen zulke tracking. HN-post en discussie

Voor gebruikers die chatgesprekken, browsen en werkaccounts scherp willen scheiden, is de praktische les niet dat elke ChatGPT-sessie alomvattend webgedrag ziet — dat volgt niet uit de beschikbare context. Wel is het verstandig om cookiebeleid, extensies, browserprofielen en de ingelogde accountcontext te controleren, en gevoelige AI-werkstromen niet gedachteloos in hetzelfde profiel als advertentie-intensief browsen te doen.

De oorspronkelijke onderbouwing achter de HN-link zit niet volledig in de beschikbare oogst. Ook de reacties zijn geen onafhankelijk bewijs van werking of reikwijdte. Beschouw dit daarom als een privacycontrolepunt, niet als een vastgesteld technisch incident.

Verder nog

• Een open Jev-achtige Qwen-finetune: een ontwikkelaar publiceert Qwen3.5-4B-Hmm, een LoRA-finetune voor getypeerde beslissingen, plus synthetische dataset en Jev-compatibele API. De auteur meldt een stijging van 0,596 naar 0,709 op een eigen typed-decisions-meting na circa twee uur trainen op een gehuurde RTX 3090. Dat is vooral een reproduceerbaar experiment in post-training; de score is geen onafhankelijke vergelijking met Jev of Laya. Code, model en aankondiging
• Hemmingway-1 richt een 27B-model op creatief schrijven: een klein Zwitsers/Zuid-Afrikaans lab zegt open gewichten van een op Qwen3.8-27B gebaseerd model voor fictie, dialoog en journaling te publiceren. De geclaimde vergelijking met gesloten modellen en 40× lagere kosten komt van de makers zelf; verifieer licentie, talen en kwaliteit op eigen teksten. Aankondiging en link naar de gewichten
• Prompting is geen stabiele interface: een essay en HN-discussie over Prompts Aren't Real benadrukken dat tekstinstructies in productie uitgebreide tests nodig hebben en dat gebruikers slechts een kleine, gelukkige steekproef van gedrag zien. Geen nieuwe techniek, wel een bruikbare ontwerpwaarschuwing: zet kritieke agentregels om in controles, schema’s en tests, niet uitsluitend in steeds langere prompts. Essay en HN-discussie