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).
Sintesi di Addy Osmani (Google, Chrome/Cloud) sul campo emergente dell'*harness engineering*: l'equazione `agent = model + harness`, il principio del *ratchet* ("ogni errore diventa una regola"), la rilettura "skill issue" di HumanLayer, le evidenze di Terminal Bench (Top 30 → Top 5 dal solo cambio di harness), l'architettura a livelli di Claude Code, la visione di Anthropic "gli harness non si riducono, si spostano", e l'Harness-as-a-Service (Claude Agent SDK, Codex SDK, OpenAI Agents SDK). Articolo cardine che consolida in una dottrina Trivedy, HumanLayer, Anthropic e Böckeler.
#harness engineering#agent harness#Addy Osmani
Addy Osmani (Software Engineer at Google, Cloud + Gemini)