Post di annuncio pubblicato sul **blog ufficiale di Z.ai** (già Zhipu AI, laboratorio cinese) il **14 agosto 2026**, **senza firma individuale**, ~2.000 parole più note a piè di pagina. Annuncia **GLM-5.3**, successore di GLM-5.2, aprendo con una tesi metodologica: *« Scaling post-training is all we did for GLM-5.3. »* Stesso modello di base di GLM-5.2 — *« every gain comes from post-training »*. Tre annunci. **(A) Un modello di coding open-weights**: +50% dichiarato sul **Z.ai Code Bench**, un benchmark interno non pubblicato. **(B) Una capacità cyber presentata come "emergente"**, che il corpo del testo riconduce a una scelta di addestramento — *« As part of post-training, we introduced vulnerability discovery data and environments into the training mix. We expected this to make the model better at finding and reasoning about vulnerabilities »* — ciò che è arrivato come sorpresa è la velocità e il cambiamento di natura: il modello passa dall'identificazione di falle isolate a *« coherent plans for complete exploitation chains »*. I guadagni crescono con la posizione nella catena di exploitation: CyberGym 77,2 → **84,5%**, ExploitBench 24,4 → **54,4%** (×2,2), ExploitGym 29 → **105** task in 2h (×3,6), con il divario rispetto alla frontiera chiusa che resta ampio (181 e 247 task). Z.ai lo formula così: *« Capability is growing fastest exactly where we are furthest behind. »* Il post pubblica anche un **Z.ai Security Disclosure Ledger**: **2.436 vulnerabilità identificate in 269 progetti open source** — kernel, sistemi operativi, motori browser, infrastrutture, applicazioni web, protocolli di rete — la più vecchia introdotta nel **1981**, durata media prima della scoperta **26,6 anni**, di cui **53 divulgate** e **2.383 sotto embargo**. **(C) Un rilascio dei pesi** *« within two weeks of launch, once safety evaluation and hardening are complete »*. Il contributo metodologico più riutilizzabile: **sintesi di ambiente e verificatore**, quest'ultimo prodotto senza accesso alla soluzione di riferimento e ammesso solo dopo un tris di controlli negativi — **oracle**, **no-op**, **unsolved-state**. Tutte le valutazioni agentiche sono condotte **in Claude Code 2.1.207**.
#GLM-5.3#GLM-5.2#Z.ai
**Z.ai** (anciennement **Zhipu AI**) · laboratoire d'IA chinois · éditeur de la famille **GLM**. Billet **institutionnel et non signé** : aucun auteur nommé · aucun chercheur mis en avant · aucun lien vers un rapport technique ou une carte de modèle. Publié le **14 août 2026**. La page est une SPA React — le HTML servi est un `<div id="root">` vide · et le texte comme les scores ont dû être extraits du bundle `glm-5.3-BCnx8T5_.js` · où ils figurent en valeurs source.
Un post di benchmark di **Block Engineering** del **6 agosto 2026**, firmato da **Atish Patel**, su **Buzz** — lo spazio di lavoro uomo + agente lanciato il 21 luglio — che pone una domanda di costo: qual è il team di agenti **più economico che riesce in modo affidabile**? Tre risultati. **(A) Un risultato negativo, pubblicato per intero**: su **Terminal-Bench 2.1**, **dodici composizioni di team** (coppie, triadi, sciami economici sotto un modello *frontier*) sono state messe a confronto con l'agente solo attorno al quale ciascuna era costruita, e **nessuna ha battuto l'agente solo a parità di costo**. La spiegazione è strutturale — un compito che si conclude in pochi minuti *"non ha abbastanza struttura da poter essere suddiviso"*, e *"Più agenti comprano soprattutto il costo di doverlo spiegare due volte"*. **(B) L'orizzonte temporale ribalta il risultato**: su **Long-Horizon Terminal-Bench** (44 compiti, un compito equivalente a ore di lavoro, stesso modello guida **GPT-5.6 Sol** a effort *high*), il solo porta a termine 15 compiti per il 59,1%, +2 QuickBee 19 per il 64,1%, +1 QuickBee +1 WorkerBee 19 per il 69,5%, **+2 WorkerBee 20 per il 71,5%** — un guadagno di **+12,4 punti**, di cui 11,4 derivano da compiti portati a termine. *"Stessi posti, risultato opposto, perché il lavoro ha una forma diversa."* Queste esecuzioni sono girate a **3× il timeout**, solo incluso. **(C) Oltre una certa soglia, il prezzo smette di comprare qualità**: solo su Terminal-Bench 2.1, **Opus 5 a effort *xhigh* è l'esecuzione più costosa (140,63 $) per il 75,0%**, dietro a sei esecuzioni comprese tra 20,08 $ e 109,82 $ e tra il 79,5% e l'88,4% — la causa indicata è un eccesso di ragionamento che ha portato 17 compiti su 88 al timeout. Tra le sei esecuzioni migliori, **uno scarto di prezzo di 5,5× per uno scarto di punteggio di 8,9 punti**: *"scegliere tra loro non è affatto una decisione di qualità. È una decisione di budget."* Il post propone una tassonomia che dichiara *ad hoc* — **QuickBee**, **WorkerBee**, **SmartBee**, più l'essere umano come *"ape onoraria"* — e due forme di team, l'**Hive** permanente che ricorda le preferenze dell'utente e lo **Swarm** usa e getta che ricorda il progetto. Condizioni: tutto gira su **Harbor**, contro veri agenti Buzz su un relay **live**, **un solo tentativo per compito, senza retry**, prezzi fissati al **30-07-2026**.
#Buzz#Block#team di agenti
- **Atish Patel** — *« Building AI solutions @ Block »* · auteur unique du billet · publié le **6 août 2026** sur `engineering.block.xyz`.
Analisi SFEIR (voce dell'azienda, "una lettura da ingegneri") dell'accordo annunciato il **21 luglio 2026** tra **Mistral** e **Microsoft**: una **partnership industriale del valore di diversi miliardi di dollari**, strutturata in tre parti — (1) **compute in Europa** (capacità Azure riservata sul continente, datacenter in Francia, sistemi **NVIDIA Vera Rubin** di ultima generazione, per "colmare il deficit europeo di compute"); (2) **i modelli di Mistral negli strumenti di Microsoft** (**Mistral Medium 3.5** e **Mistral OCR 4** in **Microsoft Foundry**, accessibili in **Copilot Studio** per costruire agenti aziendali); (3) soprattutto **Azure Local fino alla modalità disconnessa** (cloud pubblico, cloud connesso supervisionato e **air-gapped** completamente isolato dalla rete esterna — per il segreto della difesa, la sanità, il settore bancario critico). **Fatto notevole, confermato da Brad Smith: nessuna nuova partecipazione azionaria** di Microsoft nel capitale di Mistral — una partnership massiccia **senza legame di capitale**. SFEIR — partner di Anthropic e Google Cloud, "senza alcun interesse a sopravvalutare il campione francese" — considera Mistral **"la migliore scommessa europea sul livello modello"** e propone una lettura in tre parti. **Cosa porta l'accordo a un CIO**: un modello europeo all'avanguardia, eseguibile in un ambiente disconnesso e controllato dal cliente (cifratura in memoria, chiavi gestite localmente), spunta caselle che pochissime offerte spuntano. **La tensione**: questa sovranità è dispiegata **sull'infrastruttura di un hyperscaler americano**; occorre distinguere quattro sovranità — **modello, esecuzione, infrastruttura, relazione commerciale** — di cui se ne possono "ottenere tre su quattro, ma occorre comunque sapere quale manca". L'unico elemento che rende la sovranità **realmente portabile** è la **natura open-weights** dei pesi di Mistral (la stessa logica di reversibilità descritta per **Kimi K3**). L'assenza di una partecipazione azionaria non è un dettaglio: preserva la governance di Mistral **e** riduce al minimo il rischio di un esame antitrust (FTC, Commissione Europea) — **arbitraggio regolatorio assunto**, non solo una scelta tecnica. **Il vero punto cieco**: la **leggibilità della strategia industriale di Mistral**, presente simultaneamente su quasi ogni fronte (B2C con Le Chat, B2B tramite la distribuzione Azure, modello open-weights **e** ambizione frontier, infrastruttura ad altissima intensità di capitale — 200 MW garantiti, un tetto di 1 GW entro il 2030 —, partnership con una manciata di grandi account, verticalizzazione Robostral/OCR, servizio a settori regolamentati): full-stack sovrano (lettura ottimistica) oppure la dispersione di un'azienda di tre anni valutata circa 20 miliardi di euro su business con modelli economici divergenti (lettura prudente). Per la leadership tecnica: **separare il modello dal canale**, **progettare per l'uscita** (Design to Exit — l'open-weights rende credibile la porta d'uscita), **instradare piuttosto che scommettere** (architettura multi-LLM sovrana, RAISE). Conclusione: **la sovranità è una proprietà architetturale, non un'etichetta** — va qualificata dipendenza per dipendenza; la leggibilità industriale mancante resta la vera questione aperta, risolta non dai comunicati stampa ma dai "compromessi dei prossimi dodici mesi".
Analisi del gabinetto di ingegneria SFEIR ("una lettura da ingegnere") sul lancio, il **16 luglio 2026**, di **Kimi K3** da parte del laboratorio cinese **Moonshot AI**: un modello **open-weights, di livello frontier**, il cui fornitore dichiara **circa 2.800 miliardi di parametri**, un **contesto da un milione di token** e il **rilascio dei pesi prima del 27 luglio 2026** (probabilmente con licenza Modified MIT, come per la linea K2). Tesi: una capacità un tempo ritenuta riservata ai giganti proprietari (Anthropic, OpenAI, Google) diventa disponibile **in open weights, a prezzo scontato, da un laboratorio cinese**. SFEIR — pur essendo **partner di Anthropic e Google Cloud**, e quindi "senza alcun interesse a sopravvalutare un modello cinese" — adotta una **riserva metodologica** cardinale: il giorno del lancio **non esiste alcuna tabella di benchmark ufficiale e completa**; le specifiche (2,8T, Kimi Delta Attention, +25% di efficienza di addestramento) e i punteggi sono **dichiarati dal fornitore** o tratti da **arene comunitarie**, "da trattare come affermazioni, non come fatti misurati." La nuova architettura (**Kimi Delta Attention**, attenzione lineare ibrida; decodifica dichiarata fino a **6,3 volte più veloce** a 1M di token) rompe con la cadenza K2 (K2 lug. 2025 → K2.7 Code giu. 2026, un modello di punta ogni due mesi); due varianti accompagnano il lancio (**K3 Max**, **K3 Swarm Max**), con dismissione forzata della serie kimi-k2.5/moonshot-v1 il **31 agosto 2026**. **La vera arma è il prezzo** (~3$/M in ingresso, 0,30$ in cache, 15$ in uscita secondo fonti secondarie): un modello open-weights di livello frontier a questo livello **trascina verso il basso l'intera curva prezzo-prestazioni** — la commodizzazione del livello modello, accelerata dall'open source. Ma la singolarità decisiva non è un punteggio: è la **reversibilità**. Un modello open-weights di livello frontier trasforma un'API consumata (dipendenza dal fornitore) in un'**opzione** (self-hosting, portabilità, uscita dal lock-in), al prezzo di un'infrastruttura pesante per ospitare 2,8T di parametri. Il punto di vista di SFEIR: **l'open-weights cambia la domanda, non solo la risposta** — non più "quale modello è il migliore/il più economico?" ma "quanta parte del mio sistema sono disposto a rendere dipendente da un fornitore che non controllo?". La postura corretta resta un **portafoglio instradato** (un modello per compito, un modello per vincolo), con Kimi K3 che aggiunge una **colonna "reversibilità"** alla griglia decisionale. La convinzione "AI Only" resta invariata: il modello è una commodity, il vantaggio duraturo risiede nell'ingegneria che lo circonda (Context Engineering, harness, governance dei costi, capacità di cambiare idea). Le cifre restano da validare "in autonomia" — sui propri repository, sui propri dati.
**Rapporto ricorrente di Mozilla**, *The state of open source AI*, **v1.0.1, luglio 2026**, introdotto da una lettera di **Raffi Krikorian** (CTO): sette sezioni, un sito interattivo e un rapporto scaricabile. Tesi enunciata nel titolo della Sezione 1: *« Il livello del modello si è commoditizzato. Il valore si sposta sull'harness sovrastante. »* **Stato delle capacità**: sull'*Artificial Analysis Intelligence Index v4.1*, il miglior modello chiuso ottiene **61** punti (Claude Opus 5) e il miglior modello open **57** (**Kimi K3**), quarto in classifica generale e davanti a tre dei più grandi laboratori chiusi; sull'*Epoch Capabilities Index*, lo scarto è di **6 punti** (K3 a 156 contro GPT-5.6 Sol a 162), descritto come *« all'incirca un ciclo di release »*, con intervalli di confidenza sovrapposti. **Frontiera a dente di sega**: l'open è in testa nel codice frontend (K3 a 1.679 Elo sulla LMArena Frontend Code Arena, sei domini su sette), contende il lavoro agentico da terminale (88,3 contro 88,8 su Terminal-Bench 2.1), e cede terreno sul lavoro professionale di conoscenza (Fable 5 supera K3 di 92 Elo su GDPval-AA v2). **Spostamento d'uso**: la quota di token OpenRouter instradati verso modelli open-weight è salita da un livello trascurabile a un terzo entro fine 2025, poi a una **maggioranza entro metà 2026**, con i sette modelli a maggior volume tutti open-weight — il rapporto stesso osserva che *« in numero di richieste, i fornitori chiusi statunitensi restano in testa »*, il vantaggio open essendo un vantaggio in volume di token concentrato nei carichi di lavoro di coding e agentici. **Il contrasto centrale**: *« L'open si spedisce facilmente. L'open si distribuisce con difficoltà. »* — il 79% degli sviluppatori che adottano l'IA usa modelli open contro il 71% per il chiuso, ma solo il **53%** dei team su modello open raggiunge la produzione **contro il 63%**, e lo scarto si allarga con la dimensione dell'organizzazione (chiuso 54% → 73%, open 53% → 57%), il che *« esclude una spiegazione basata sulle risorse »*. La mappa di maturità dello stack (48 componenti, 9 livelli) mostra due colonne costantemente fredde — la **standardizzazione** e la ***prontezza enterprise*** — identificate come il divario operativo. **Sezione 5**: *« L'harness agentico è un altro user agent »*, e *« Il modello sta divorando l'harness »* — su ogni modello in cui entrambi esistono, l'harness proprietario del laboratorio ora vince, con lo scarto di 21,8 punti compresso a circa 3. Da cui la formula: *« Un harness calibrato strettamente sui pesi di un laboratorio… degrada su qualsiasi altro modello, quindi più stretta è la calibrazione, meno intercambiabili sono i pesi sottostanti. Il lock-in arriva come effetto collaterale dell'ottimizzazione. »*
#Mozilla#state of open source AI#pesi open
**Mozilla** — éditeur du rapport · avec une introduction signée **Raffi Krikorian** · *Chief Technology Officer*. Publié en **juillet 2026** (v1.0.1). Données issues de sources tierces créditées (Artificial Analysis, Epoch AI, OpenRouter, LMArena) et d'une enquête propre menée avec **SlashData** (*Mozilla / SlashData 2026 developer survey*, n = 1 410 sur la question des freins).