Haiku 5.5 verlaagt agentkosten; llama.cpp cachet MoE-experts op de GPU

Claude Haiku 5.5 is uit met lagere tokenprijzen en een regelbare effortstand, gericht op compacte, veelvuldige agentstappen. Voor lokale inference is de interessantere stap dat llama.cpp nu een gemergede GPU-cache heeft voor MoE-experts in host-RAM — een daadwerkelijke implementatie waar gisteren nog vooral een prefetch-ontwerp lag.

Tegelijk rolt OpenAI GPT-6 uit in ChatGPT met een ‘Intelligent UI’, en claimt vLLM forse winst voor DeepSeek-V4.1-Flash. Beide zijn providerberichten: meet ze in de eigen workflow voordat je er een capaciteits- of productbeslissing aan ophangt.

Haiku 5.5 mikt op goedkope, begrensde agentstappen

Anthropic heeft Claude Haiku 5.5 uitgebracht. Het model krijgt een instelbare effortstand en is volgens de aanbieder bedoeld voor onder meer classificatie, samenvatten, compactie, databasevragen en subagenttaken. Dat onderscheid is nuttig: Anthropic positioneert Haiku nadrukkelijk niet als vervanger voor Sonnet of Opus bij complexe, langdurige codingtaken.

De prijs voor prompts tot 100K tokens is volgens de aankondiging $0,10 per miljoen inputtokens en $0,50 outputtokens; boven 100K stijgt dat naar respectievelijk $0,50 en $2,50. Cache reads kosten $0,01 respectievelijk $0,05 per miljoen tokens. Anthropic verlaagt tegelijk de cache-readprijs van Sonnet 5.5 van $0,20 naar $0,10 per miljoen tokens. Dat kan relevant zijn voor agentpaden met veel hergebruikte context, maar de aangekondigde kostenreducties en benchmarks blijven leveranciersmetingen.

De praktische vraag is dus niet of Haiku een grote agent kan vervangen, maar welke stappen echt smal en controleerbaar zijn: triage, extractie, samenvatting, reranking of een beperkte subtaak. Test daarbij fouttype, latency, contextgrens en escalatie naar een sterker model; een lagere tokenprijs is geen besparing als herstelwerk toeneemt. Anthropics aankondiging met prijzen en evaluatietabel · HN-discussie

llama.cpp brengt GPU-cache voor MoE-experts uit host-RAM

In llama.cpp is een pull request gemerged dat een LRU-cache van MoE-experts op de GPU toevoegt voor modellen waarvan experts in host-RAM staan. Matrixvermenigvuldiging voor een host-residente expert kan daarmee vanuit de GPU-cache lopen; alleen cachemisses worden geüpload. De beschreven route is voor één device en batches tot 32 tokens.

Dit is een concrete stap sinds de namiddagupdate van gisteren, waarin een Strata-gebruiker nog analyseerde hoeveel expertmisses kosten en waarom prefetch in diens proef niet op tijd kwam. Nu is er dus een cache-implementatie in een veelgebruikte runtime, niet enkel een simulatie van mogelijke winst.

De beschikbare meting is smal: met Qwen3.8 Flash Next UD-IQ3_XXS, een RTX 5060 Ti met 16 GB en 62 GB RAM steeg decode volgens de PR van 14,95 naar 19,26 tok/s bij een cache van 8.000 MiB; prefill bleef rond 89 tok/s. De eerder overwogen expert-prefetch zit niet in deze wijziging omdat prefill in die proef in cuBLAS afbrak. Zie dit daarom als een testbare feature, niet als een algemene snelheidsbelofte: cachegrootte, expertpatroon, PCIe, quant en context bepalen de uitkomst. Gemergede PR met configuratie en meting · Reddit-signaal

vLLM claimt grote DeepSeek-winst, maar op één workload

Het vLLM-project meldt dat DeepSeek-V4.1-Flash drie weken na de eerste dag op de AgentX-test van SemiAnalysis 1,9× sneller draait bij lage concurrency en bij 150 tokens per seconde per gebruiker 5,3× zoveel throughput haalt. De technische verklaring noemt bounded replay voor sliding-window-KV, CUDA graphs, DeepSeek-kernels en diverse vLLM-fusies. Volgens de thread daalt time-to-first-token rond 100K throughput bijna 70%.

Dat is interessant voor operators die precies deze model- en servingcombinatie draaien, omdat het niet alleen een nieuwe kernel maar een verzameling cache-, attention- en schedulingpaden betreft. Maar het blijft een bericht van het project zelf, op één benchmarkprofiel. Doorvoer bij concurrency is niet hetzelfde als de latency van één gebruikersrequest; bovendien zegt de post niets over andere GPU’s, prompts, contextlengtes, quants of outputkwaliteit.

Neem dit daarom als aanleiding om vLLM-versie, kernelpad en metrics op een stagingserver te vergelijken. Meet TTFT, inter-token-latency, cache-hitratio, geheugenmarge en per-request latency naast aggregate throughput. vLLM-thread met technische uitsplitsing

GPT-6 komt in ChatGPT; UI is het nieuwe deel van de uitrol

OpenAI meldt dat GPT-6 samen met een Intelligent UI naar ChatGPT voor iedereen uitrolt. Volgens de officiële post moet die interface snelle, interactieve en visuelere antwoorden bieden, met taakgerichte interactieve hulpmiddelen.

Dit is een andere gebeurtenis dan de einde-dagupdate van maandag 5 oktober, die de door een medewerker gemelde versnelling voor Astra en Sol behandelde: het nieuwe feit is de ChatGPT-uitrol van GPT-6 met een gewijzigde productinterface. De opslag bevat geen leesbare oorspronkelijke OpenAI-pagina en dus ook geen volledige specificatie, modelkaart, regioverdeling of vergelijkbare meetopzet.

Behandel de uitrol daarom als productstatus, niet als bewijs van betere betrouwbaarheid of geschiktheid voor werk. Wie ChatGPT voor inhoudelijk werk inzet, doet er goed aan feitelijke claims en tussenstappen te blijven controleren — ook wanneer de interface de uitkomst overtuigender presenteert. OpenAI’s aankondiging op X · HN-discussie

Wis geheimen niet blind: een wipe kan extra kopieën maken

Een technisch essay over zeroization laat met gecompileerde C-voorbeelden zien waarom een memset() op een lokale variabele geen betrouwbare manier is om een geheim te verwijderen. De compiler kan de write wegoptimaliseren als de waarde daarna niet meer wordt gelezen. Een volatile of apart gecompileerde wipe dwingt wel stores af, maar kan juist een waarde die alleen in een register stond eerst naar de stack laten kopiëren — terwijl de registerkopie blijft bestaan.

Een tweede voorbeeld laat zien dat een compiler een extra spillkopie kan maken om een waarde na een wipe-call nog voor een vergelijking beschikbaar te houden. De aangewezen buffer wordt dan gewist, maar die extra stackkopie niet. Dat is geen aangetoonde compilerbug; het programmeermodel belooft de bedoelde securityvolgorde niet.

De praktische les is genuanceerd: buffers die al in geheugen bestaan, zoals een key schedule of wachtwoordbuffer, blijven zinvol om te wissen. Maar voeg niet automatisch een wipe toe aan iedere kleine lokale variabele. Inspecteer de geoptimaliseerde build die je werkelijk levert, inclusief LTO en hardening; denk ook aan registers bij contextswitches, crashdumps, hibernatie en VM-snapshots. Artikel met assemblervoorbeelden · Lobsters-discussie

Verder nog

• Rex schaalt volgens maker naar 10.000 actieve terminals: Mitchell Hashimoto meldt voor de server achter Rex 10.000 gelijktijdig actieve terminals bij 3,8 GB geheugen, met als doel 100.000. Dat is een concrete ontwikkeling sinds de ochtendupdate van gisteren, waarin Rex alleen als vroege OSC-7501-implementatie langskwam. De cijfers zijn eigen metingen; test zelf sessiegedrag, netwerk, authenticatie en herstel bij de gewenste schaal. Aankondiging
• Rex is nog beperkt beschikbaar: dezelfde maker schrijft dat ongeveer 500 van circa 40.000 geïnteresseerden zijn uitgenodigd en dat uitnodigingen gefaseerd verlopen. Dat plaatst de schaalclaim in een vroege testfase; het is geen algemeen beschikbare serverrelease. Statusbericht