Nieuwe agentstudie maakt harnesskeuzes meetbaar; Bonsai 2 krijgt eerste tegenwind

Een nieuwe empirische studie stelt dat de beste agentharness afhangt van model, taak en budget — geen universele standaard dus. Tegelijk leveren eerste gebruikersrapporten concreet tegenwicht tegen Bonsai 2’s compacte positionering. Voor coding agents is er bovendien een onbevestigd maar praktisch privacy-alarm rond ZCode.

Coding agents: planning en tools zijn geen standaardrecept

De paper An Empirical Study of Harness Design for Coding Agents vergelijkt keuzes rond planning, voorgedefinieerde tools en contextbeheer. De samengevatte conclusies: planning verhoogt bij zwakkere modellen de slagingskans, maar kost meer; bij sterkere modellen kan het vooral kosten drukken met een kleine daling in succes. Vaste tools helpen modellen die slecht met de shell omgaan, terwijl bash-only bij shell-vaardige modellen juist goedkoper en succesvoller kan zijn. Contextbeheer verlengt vooral trajecten onder een krap contextbudget, zonder het agentgedrag wezenlijk te veranderen.

Dat is nuttig voor wie een lokale of eigen coding-agent inricht: kies niet blind de loop van een bekende provider, maar meet taakuitkomst, kosten, looptijd en herstelwerk per model-harnesscombinatie. Het is een concrete verdieping na de ochtendupdate van gisteren, die al waarschuwde dat de harness de uitkomst mede bepaalt. De beschikbare HN-draad telt slechts twee inhoudelijke reacties; ook daar wordt opgemerkt dat sommige conclusies intuïtief klinken. De paper is dus een sterke aanleiding voor eigen evaluatie, geen bewezen universele configuratie. Paper · HN-discussie

Bonsai 2: eerste tests botsen met de compacte belofte

De ochtendupdate van vandaag beschreef Ternary Bonsai 2 27B als een nieuwe, circa 6GB grote afgeleide van Qwen3.8-27B. Nu is er een concrete nieuwe reden om de leveranciersclaim van 98,2% behouden ‘intelligence’ niet als algemene kwaliteitsuitspraak te lezen. Een Reddit-gebruiker wijst op cijfers uit Prisms eigen whitepaper: Bonsai 2 haalt volgens die weergave 52,8 op Terminal-Bench 2.1 en 60,8 op SWE-bench Verified, tegenover 69,7 en 80,6 voor de referentie. Dat is ruwweg driekwart op die twee agentische benchmarks, geen 98%.

Daarnaast meldt een andere gebruiker een lange redeneerlus bij een brede codeeropdracht. Dat is één niet-gestandaardiseerde ervaring en bewijst geen algemeen defect; reacties wijzen terecht op prompt, instellingen en het verschil tussen een compressiemodel en een volwaardig codingmodel. Maar samen zijn dit wel onafhankelijke praktijk- en documentatiesignalen ná de release: test niet alleen of de eigen runtime start, maar ook lange taken, toolgebruik en je eigen regressieset. Analyse van de whitepapercijfers · gebruikersrapport over loopgedrag

ZCode zou Git-geschiedenis uploaden; bewijs en reactie ontbreken hier

Een artikel dat op Hacker News circuleert stelt dat ZCode, de GLM-coding-agent, zonder duidelijke melding bestanden uit .git en de Git-geschiedenis naar de cloud uploadt. De beschikbare context bevat de aantijging en discussies erover, maar geen onafhankelijke technische reproductie, packet capture of reactie van ZCode/Z.ai. Ook de HN-draad bevat veel algemene meningen over gesloten harnesses en modelgedrag, geen bevestiging van de specifieke claim.

Behandel dit dus niet als vastgesteld incident. Het is wel een zinvolle onmiddellijke controle voor teams die zo’n agent gebruiken: inspecteer uitgaand verkeer, lees de privacy- en telemetrieinstellingen, en geef een agent niet zonder noodzaak toegang tot volledige repositories, .git, dotfiles en secrets. Dit is concreet relevanter nu agenten steeds vaker zelfstandig een werkmap doorzoeken; open source alleen vervangt die controle overigens niet. Oorspronkelijke claim · HN-discussie

OpenJev zet een vroege, lokale Jev-achtige server neer

OpenJev is een nieuw Apache-2.0-project dat met DiffusionGemma en een nog niet gemergde vLLM-pull request een API aanbiedt die zich op Jev richt. Volgens de maker vult het model in één denoisingstap een set getypeerde antwoordopties in; de server zou daardoor een Jev-compatibele route bieden met alleen een aangepaste base URL. Er is ook een Docker-image genoemd.

Dit verschilt inhoudelijk van Laya uit de middagupdate van vandaag: Laya is een nieuw getraind beslismodel, OpenJev is een serverlaag op een bestaand diffusionmodel. Interessant voor lokale routing of classificatie met strikt afgebakende antwoordopties, maar nog duidelijk experimenteel: de vLLM-wijziging is niet gemergd, de gehoste dienst kan volgens de maker overbelast raken, en de genoemde latency- en vergelijkingscijfers zijn niet onafhankelijk bevestigd. Gebruik het alleen na eigen tests op foutkosten en calibratie; een snel schemaresultaat is nog geen betrouwbare beslissing. Projectaankondiging

Opti 27B: kleinere Qwen-quant, maar geen open route

Een nieuw project presenteert Opti 27B, een 11,8GB-versie van Qwen3.8-27B op 3,47 bit per parameter. De auteur rapporteert vrijwel gelijke WikiText-2-perplexity aan FP16 en Q4_K_M, 42,3 tok/s op een RTX 3090 en ruimte voor een 16GB-kaart. De runtime is publiek te bouwen, maar vereist een gepatchte llama.cpp; de extra netwerkcomponent en trainingsmethode zijn niet gepubliceerd, er loopt volgens de auteur een patentaanvraag, en zowel runtime als model zijn niet-commercieel.

De interessante praktische grens is daarmee helder: dit kan een compacte evaluatieoptie zijn voor een 16GB-kaart, maar geen transparante, drop-in GGUF of open-sourcebouwsteen. De benchmarks en agenttest komen van de maker en de agenttest betreft één taak; vergelijk bovendien met reguliere quants op dezelfde hardware en contextlengte voordat je de 30%-besparing als gerealiseerde winst rekent. Aankondiging, methode en reproduceercommando

Verder nog

• Passkeys vragen om herstelpaden: een HN-discussie over passkey-ergonomie benadrukt dat QR/hybrid login een onbeheerd apparaat kan afvangen, maar alleen als diensten die route én recovery goed implementeren. Dat is geen nieuw protocol, wel een nuttige implementatiecheck voor productteams: test derde-partij-passwordmanagers, verlies van apparaten en backupcodes, niet uitsluitend de happy flow. Discussie
• Antirez’ compact SDF-CAD-experiment: antirez licht toe dat zijn recente 3D-demo in C met Sokol UI een eigen signed-distance-field-engine gebruikt voor onder meer fillets, vlakdetectie en extrusie; een mesh ontstaat pas bij export. Interessant als klein open experiment in directe geometrische modellering, maar er is nog geen repository, licentie of onafhankelijke technische evaluatie in de beschikbare context. Toelichting · oorspronkelijke demo