Il modello è un plugin, non una scommessa

Ogni poche settimane qualcuno riapre la stessa discussione: "C'è qualcuno che ha davvero sostituito Claude o GPT con un modello locale per il lavoro di tutti i giorni?". L'ultima è passata su Hacker News e ha raccolto decine di risposte da gente con rig seri sotto la scrivania. La conclusione, onesta, è che no: quasi nessuno ha rimpiazzato il cloud per il lavoro pesante.

Ma la domanda è sbagliata. E il motivo per cui è sbagliata è esattamente il motivo per cui in FairMind costruiamo quello che costruiamo.

Il dato che cambia la cornice

Partiamo dai numeri, perché qui è dove la maggior parte delle discussioni si ferma alla percezione.

Sui benchmark di coding il divario tra modelli aperti e frontier si è quasi chiuso. Nell'ultimo anno la distanza tra il primo e il decimo modello è scesa da quasi dodici punti a poco più di cinque, e in cima i primi due sono separati da meno di un punto. Il miglior open-weight su SWE-bench Verified viaggia ormai oltre l'80%, in linea con modelli proprietari di frontiera. Sul fronte costi il crollo è ancora più netto: un modello come DeepSeek V4 Flash gira a frazioni di centesimo per milione di token, con licenza permissiva e contesto da un milione di token, e in generale il costo per token degli open è da dieci a cento volte più basso delle API proprietarie.

Se la storia finisse qui, l'articolo sarebbe un altro pezzo entusiasta sul "momento degli open model". Non è così, e il punto interessante è proprio dove i numeri smettono di raccontare la verità.

C'è un meccanismo preciso dietro questo livellamento, e non è che i modelli siano diventati tutti ugualmente bravi. È che il benchmark è diventato un bersaglio. Quando una metrica come SWE-bench Verified diventa l'obiettivo pubblico su cui ogni laboratorio viene misurato, smette di misurare la capacità generale e inizia a misurare quanto ci si è ottimizzati sopra. È la legge di Goodhart applicata all'AI: quando una misura diventa un obiettivo, smette di essere una buona misura. I punteggi convergono perché tutti corrono verso lo stesso traguardo, non perché il territorio sotto i piedi sia diventato uniforme. Un gap che si chiude in cima alla classifica dice molto sulla classifica e poco sul lavoro reale.

SWE-bench Verified, il benchmark più citato, è un pavimento di capacità, non un soffitto di performance. Un punteggio alto dice che il modello sa risolvere task GitHub ben delimitati. Non dice nulla su come si comporta in una sessione che dura giorni, su una codebase proprietaria priva di test, o in un refactoring che tocca venti file. C'è di più: il benchmark RULER di NVIDIA mostra che i modelli usano in modo affidabile solo il 50-65% del contesto che dichiarano. La finestra da un milione di token sulla carta diventa molto meno nella pratica.

La distinzione che conta qui non è capacità contro incapacità, è capacità mediana contro affidabilità sulla coda. Due modelli possono risolvere lo stesso 80% di task standard e divergere completamente sul 20% difficile: il file legacy senza test, il requisito che si contraddice tre cartelle più in là, la dipendenza implicita che nessuna documentazione cattura. Lo sviluppo software enterprise vive esattamente su quella coda. Non paghi un ingegnere senior per il caso medio, lo paghi per i casi che fanno saltare il caso medio. Lo stesso vale per il modello: il valore di frontiera non è nel punteggio aggregato, è in cosa succede quando il task esce dai binari, ed è precisamente ciò che nessun benchmark a oggi sa misurare.

Il dato sul contesto effettivo aggrava il quadro proprio dove fa più male. Se un modello usa in modo affidabile solo metà della finestra che dichiara, il problema è marginale su uno script di duecento righe e diventa strutturale su una codebase brownfield che si misura in milioni di righe sparse su decine di repository. È il nostro terreno quotidiano, ed è il terreno dove la finestra di contesto sulla carta e la comprensione reale del progetto divergono di più. Riempire il contesto di token non significa dare contesto: è il lavoro di selezione, compressione e instradamento, cioè di harness, a determinare cosa il modello capisce davvero.

Cosa dice davvero la community

Il thread di Hacker News è utile non per la conclusione, ma per dove i practitioner mettono il dito.

Il commento più votato è un argomento di costo opportunità, non di qualità: rifaccio l'analisi ogni mese, ogni mese concludo che il tempo per far funzionare il locale non vale rispetto a un agente cloud già pronto. È un'osservazione economica, non tecnica.

Vale la pena prendere quell'argomento sul serio invece di liquidarlo, perché nel suo contesto è corretto. Per uno sviluppatore singolo il costo del locale è il proprio tempo, e il proprio tempo confrontato con un abbonamento da poche decine di euro al mese perde quasi sempre. Ma quel calcolo non si trasferisce all'azienda, e qui sta il punto che il thread non poteva vedere. Per un'organizzazione cambiano tre variabili insieme: la sovranità del dato, che in Europa non è una preferenza ma spesso un vincolo; l'economia di scala, dove il prezzo per sviluppatore di un modello in cloud si moltiplica per centinaia di seat mentre l'infrastruttura locale si ammortizza; e il controllo, cioè la possibilità di non dipendere da un listino che, come vedremo, può muoversi sotto i piedi senza preavviso. La conclusione "non vale" è giusta per il singolo e fuorviante per l'impresa.

Fig. 1 · Fonte: thread Hacker News — Chi ha provato il locale per il coding: come è andata

Ogni quadrato è un setup descritto nel thread. Campione: 14 casi, autoselezionati. "Usabile" significa "l'autore del commento lo usa", non un benchmark, e spesso vale solo per progetti personali o task ben definiti. Chi non ci riusciva, spesso non ha lasciato un setup strutturato: il conteggio è quindi ottimista.

Il segnale che conta davvero è un altro, ed emerge più volte: il collo di bottiglia non sono i modelli, sono gli harness alternativi. Gli strumenti che pilotano il modello locale sono ancora immaturi su gestione della coda, interruzione, sub-agent, gestione degli obiettivi. I modelli reggono. È l'impalcatura intorno a non reggere. E il pattern di chi lavora sul serio non è "locale puro" ma ibrido: modello di frontiera per i task difficili, modello aperto o in subscription per il volume e per il codice di servizio.

Conviene essere precisi su cosa manca, perché "harness immaturo" suona vago. Mancano le cose che non si vedono in una demo e si sentono in produzione: la coda che decide cosa l'agente fa prima e cosa dopo, l'interruzione pulita quando parte per la tangente, i sub-agenti a cui delegare un pezzo verificabile, la memoria di progetto che sopravvive alla singola sessione, la verifica automatica che blocca un output sbagliato prima che arrivi all'utente. Sono problemi di ingegneria dei sistemi, non di addestramento del modello, ed è per questo che non si risolvono aspettando la prossima release. E l'ibrido che ne emerge non è un compromesso al ribasso: è l'architettura matura. Instradare ogni task al modello giusto, frontier dove serve ragionamento e aperto dove serve volume, è una decisione di orchestrazione. Il modello mette la capacità; l'harness decide se quella capacità diventa un risultato.

Fig. 2 · Sintesi del thread (sosodev e altri) — La soglia hardware: dove la fascia media diventa il sweet spot

L'altezza dei blocchi indica la capacità sbloccata; il colore, la praticabilità su hardware locale. Il messaggio del thread: la fascia 27–35B è il punto di equilibrio reale; il frontier "in casa" richiede 128GB+ di memoria e, parole di chi ci ha provato, spesso comunque non basta.

In sintesi: chi ci ha provato non si è scontrato con un limite del modello. Si è scontrato con un limite dell'orchestrazione, e con un muro di hardware.

Fig. 3 · Throughput dichiarato nel thread — Velocità reale (tok/s), scala logaritmica

Solo i casi in cui un numero è stato riportato; molti commenti dicono solo "più veloce del cloud" o "molto più lento". Lo spread tra il rig multi-GPU e la macchina CPU è di circa 230×. La velocità non è un dettaglio: a 0,7 tok/s un task agentico multi-step diventa impraticabile.

La prova che non arriva da un forum

Un thread è aneddotica. Per uscire dall'aneddoto serve qualcosa di misurato, ed è appena arrivato.

A giugno 2026 Arena ha pubblicato la metodologia di Agent Arena, una valutazione di agenti costruita su milioni di interazioni reali. La parte rilevante per noi è concettuale prima ancora che numerica. Arena tratta l'agente per quello che è: non un modello, ma un sistema fatto di un modello-orchestratore più un harness con molti sottocomponenti e strumenti. E introduce una tecnica, il causal tracing, che randomizza la scelta dei componenti e stima il contributo causale di ciascuno separatamente. In altre parole: misura quanto pesa il modello e quanto pesa l'impalcatura, distintamente.

Vale la pena fermarsi sul metodo, perché è la differenza tra un'opinione e una misura. Una classifica normale osserva quali agenti vanno meglio e correla, ma un agente è modello più harness più mille scelte di configurazione, e la correlazione non sa dire a chi vada il merito. Il causal tracing rompe questo nodo randomizzando i componenti, lo stesso principio di un esperimento controllato: se cambi solo l'orchestratore e tieni fisso il resto, la differenza di risultato è attribuibile a quell'orchestratore e non a una coincidenza di setup. È l'unico modo onesto per rispondere alla domanda "quanto conta davvero il modello", e la risposta che emerge è netta: conta, ma è un fattore tra tanti, non il fattore.

E qui i nomi contano, perché la classifica agentica di Arena non misura quanto un modello è intelligente in astratto, ma quanto bene orchestra strumenti su task reali. Al 15 giugno 2026 ordina 27 modelli su quasi 752.000 sessioni. In cima c'è il frontier proprietario, come prevedibile. Ma scorrendo verso il basso i modelli aperti non stanno raggruppati in fondo: sono mescolati tra i proprietari.

Fig. 4 · Fonte: Agent Arena — Un segnale agentico, non il listino: task confermati dall'utente

Segnale "confirmed success" di Agent Arena: quanto spesso l'utente conferma esplicitamente che il task è risolto, uno dei segnali causali della metodologia. In teal i pesi aperti, in blu i proprietari. GLM 5.2 (Max), aperto, è terzo, davanti a quasi tutto il frontier. Ho scelto un segnale chiaro e direzionale invece del punteggio aggregato "net improvement", che non è ordinabile in modo lineare e renderebbe il grafico fuorviante. Dati: Agent Arena, 15 giu 2026; selezione nostra.

Tre letture valgono più di tutta la tabella. La prima la vedi nel grafico: su uno dei segnali agentici di Arena, quanto spesso l'utente conferma che il task è davvero risolto, GLM 5.2 (Max), pesi aperti con licenza MIT, è terzo assoluto, davanti a quasi tutto il frontier. La seconda non si vede in un singolo grafico ma è la più istruttiva: la classifica complessiva non è una scala di capacità. Lo stesso Claude Opus 4.8 è secondo nella variante che ragiona e undicesimo in quella che non ragiona, e ciò che lo fa sprofondare è un segnale di comportamento, l'allucinazione di strumenti, salita da sotto l'1% a quasi il 16%. Stesso cervello, comportamento diverso dentro il flusso. La terza: modelli aperti come DeepSeek V4 Flash, quasi gratuito, e GLM 5.1 consegnano un'orchestrazione vicina al frontier a una frazione del costo, mentre altri capaci come Gemma 4 31B pagano non per scarsa intelligenza ma per la stessa fragilità sugli strumenti.

Se cercavi una singola prova della tesi di questo articolo, è questa. Quando misuri gli agenti su come si comportano davvero, e non su quanto sono brillanti in astratto, la classifica si riorganizza intorno a proprietà che vivono nel modo in cui il modello viene condotto: affidabilità degli strumenti, capacità di farsi correggere, recupero dagli errori. Tutte cose che un harness migliore migliora, e che un modello da solo non garantisce.

I segnali che Arena misura, infatti, non parlano quasi mai di "intelligenza" del modello, ma di comportamento dentro un flusso di lavoro: la capacità di recepire una correzione dell'utente (steerability), il numero di tentativi per riprendersi da un errore di shell (bash recovery), la tendenza a invocare strumenti che non esistono (tool hallucination). Sono tutte proprietà che vivono nell'interazione tra modello e harness, non nel modello da solo.

Il punto da non lasciare sfuggire è che ognuno di questi segnali è migliorabile dall'esterno del modello. La steerability dipende da come l'harness reinietta la correzione nel contesto. Il recupero da un errore di shell dipende da quali strumenti di diagnosi e quali guardrail gli hai messo intorno. L'allucinazione di uno strumento si abbatte con un registro di strumenti validato e un controllo che rifiuta le chiamate inesistenti prima che diventino errori. Arena sta misurando proprietà che un buon strato di orchestrazione può spostare senza toccare un solo peso del modello. È la dimostrazione operativa di una cosa scomoda per chi vende modelli e comoda per chi costruisce sistemi: oggi il margine di miglioramento sta più nell'impalcatura che nel cervello.

Ancora più interessanti sono due modi di fallire che Arena ha battezzato. Il bluster: l'agente, messo sotto pressione da una correzione, suona deciso ma quasi mai tiene la posizione. E il bluffing: davanti a una richiesta composta da più parti, in una quota non banale di casi lascia un pezzo incompleto, e in una minoranza più insidiosa lo omette in silenzio presentando il risultato come completo. Nessuno di questi due problemi si risolve cambiando modello. Si risolvono con verifica, con controlli automatici, con un harness che non si fida della parola dell'agente.

Fig. 5 · Fonte: Agent Arena — Bluffing e Bluster: due fallimenti che nessun cambio di modello risolve

Due modi in cui un agente capace sotto-rende. Su richieste multi-parte, l'8% dei pezzi viene omesso in silenzio e presentato come completo (bluffing). Sotto correzione, l'agente "suona deciso" nel 26% dei casi ma quasi mai tiene la posizione (bluster). Nessuno dei due si cura cambiando modello: si cura con la verifica dentro l'harness. Dati: Agent Arena; elaborazione nostra.

C'è un altro dato di Arena che chiude il cerchio. Quando gli utenti delegano, nella maggioranza dei casi non chiedono un consiglio: affidano all'agente un intero deliverable, e in una quota minore lo lasciano lavorare in autonomia. Gli agenti, quindi, fanno già lavoro vero e non assistito. Ma nello stesso periodo gli utenti riprendono il controllo molto più spesso di quanto allarghino la delega, circa due volte e mezza tanto. Letto bene, questo non dice "gli agenti non sono pronti". Dice che servono due cose insieme: agenti capaci di prendersi un compito intero, e un piano di controllo che lasci all'umano riprendere le redini in qualunque momento. Quel piano di controllo è harness, per definizione.

E il lavoro reale è pesante in modo che il benchmark non cattura. Nella finestra osservata, gli agenti hanno scritto decine di milioni di righe di codice in una settimana, con bash come strumento dominante, una quota consistente di sessioni oltre le venticinque chiamate a strumento e una coda lunga che arriva a centinaia. Un terzo delle sessioni chiude con oltre 128k token di contesto. Questo non è "completare un task ben definito". Questo è guidare un sistema lungo, rumoroso, multi-step. È terreno da harness.

Fig. 6 · Fonte: Agent Arena — Cosa fanno davvero gli agenti: il coding è la quota maggiore

Intento primario su 160.480 task reali in 7 giorni (Agent Mode). Scrittura e debug del codice insieme valgono circa il 26%: il coding è la quota maggiore del lavoro agentico reale, ed è il terreno più esigente per l'harness. Dati: Agent Arena; elaborazione nostra.

Un'ultima nota da non perdere, e che si lega a qualcosa che abbiamo già raccontato su questo blog. Arena calcola il costo reale a posteriori, non quello di listino, e trova modelli più cari nella pratica di quanto il prezzo per token suggerisca, perché un orchestratore inefficiente fa più passi, più chiamate e induce più turni dell'utente per arrivare allo stesso risultato. Il prezzo per token è un'illusione contabile. Quello che conta è il prezzo per task risolto, e quel numero non lo decide il listino del modello: lo decide quanto bene l'harness conduce il modello al risultato senza sprecare passi. Un modello "economico" dentro un'orchestrazione scadente può costare più di un modello caro ben condotto.

---

È esattamente ciò che stiamo mettendo nelle mani dei nostri clienti: modelli open-weight, condotti dal nostro harness.

Richiedi l'accesso

---

Il modello migliore non è più un solo modello

La conferma più solida che il valore stia nello strato di orchestrazione, e non nel modello, non arriva da un forum ma da un paper. Perplexity, con un ricercatore di Harvard, ha pubblicato DRACO, un benchmark di ricerca profonda costruito su task reali e con penalità per le risposte sbagliate, così che non si possa gonfiare il punteggio scrivendo tanto e male. Il risultato che conta è uno: la loro pipeline di deep research basata su Opus 4.6 segna 70,5%, mentre lo stesso Opus 4.6 da solo, pur con web search e code execution, si ferma a 59,8%. Stesso modello base, oltre dieci punti di differenza, prodotti interamente dall'orchestrazione costruita attorno. Gli autori lo scrivono senza giri di parole: il distacco indica l'importanza dell'orchestrazione dell'agente al di là del modello base. E quando discutono quanto sia difficile confrontare sistemi diversi, parlano proprio di eterogeneità dell'harness, degli strumenti e degli stack di recupero che circondano il modello.

La stessa intuizione è già un prodotto. OpenRouter ha lanciato Fusion: invece di scegliere un modello, li fonde. Manda lo stesso prompt a un panel di modelli in parallelo, un giudice ne confronta le risposte segnando accordi, contraddizioni e punti ciechi, e un sintetizzatore ne scrive una sola. Sul medesimo benchmark, con un giudice diverso (quindi i numeri non sono confrontabili uno a uno con il paper), ogni panel fuso supera i modelli presi da soli: il migliore tocca 69,0%, sopra Fable da sola a 65,3%.

Fig. 7 · Fonte: OpenRouter / DRACO — Fondere i modelli batte sceglierne uno, e i modelli aperti reggono

DRACO, valutazione di OpenRouter (giudice Gemini 3.1 Pro, quindi non confrontabile uno a uno con il paper). Fondere batte ogni modello solo. Per il nostro tema conta il fondo della classifica: DeepSeek V4 Pro, a pesi aperti, da solo eguaglia Opus 4.8 e GPT-5.5; un panel in gran parte aperto arriva a un punto da Fable a metà costo, sintetizzato però da un modello di frontiera. Asse troncato a 50%. Dati: OpenRouter, 12 giu 2026; elaborazione nostra.

Ma per il nostro tema, modelli aperti che diventano utili, il dato interessante è in fondo alla classifica, non in cima. DeepSeek V4 Pro, a pesi aperti, da solo eguaglia GPT-5.5 e supera Opus 4.8. E un panel fatto in gran parte di modelli aperti ed economici, DeepSeek e Kimi accanto a un piccolo modello di Google, batte sia GPT-5.5 sia Opus 4.8 presi da soli e arriva a un punto da Fable, a metà del costo. L'orchestrazione non serve solo a spremere il frontier: serve a portare modelli aperti e a basso costo a un livello che da soli non toccherebbero.

Due precisazioni oneste, perché contano proprio per chi vuole andare verso l'aperto. La prima: gran parte del guadagno viene dal passo di sintesi, non dalla diversità dei modelli, e lo dimostra il caso limite, Opus 4.8 fuso con una copia di sé stesso, zero diversità, che sale comunque di 6,7 punti. La seconda, più scomoda: in quel panel economico a sintetizzare era comunque un modello di frontiera, Opus 4.8. Quindi un pipeline interamente aperto, panel e sintetizzatore, nessuno l'ha ancora dimostrato. Ed è esattamente la domanda su cui lavoriamo.

Qui si torna al punto di tutto l'articolo. Fusion è ricerca profonda, non coding: OpenRouter stessa dice che non sostituisce un modello di coding, ma diventa uno strumento che il modello chiama quando una decisione di architettura o una scelta di approccio vale qualche secondo in più. Il principio però è trasferibile, e la domanda che ci poniamo in FairMind è netta: la stessa orchestrazione di modelli aperti, che nella ricerca porta il low-cost a livello di frontiera, regge sui task di sviluppo? Requisitazione, analisi, documentazione, harness engineering sul codice. È ciò che stiamo sperimentando, orchestrando modelli aperti dentro il nostro harness invece di affidarci a un singolo modello di frontiera. La differenza con un Fusion generico è il punto: il nostro strato conosce la codebase, verifica contro i test, instrada su politiche che dipendono dal dominio. Fusion dimostra il principio nella sua forma più nuda; il valore vero è nell'harness che lo specializza. E per ora i segnali sono incoraggianti: in alcuni workflow un modello aperto, dentro il nostro harness, chiede una seconda opinione a un modello di frontiera sui passaggi implementativi più delicati, e nella maggioranza dei casi il frontier non corregge la scelta dell'aperto, la conferma.

L'obiezione più seria

A questo punto un lettore attento ha un'obiezione, ed è la più forte che si possa muovere a tutto il ragionamento. Se è vero che sul 20% difficile, l'orchestrazione lunga e ambigua, il modello di frontiera resta insostituibile, e se è vero che quel 20% è proprio dove si concentra il valore, allora il modello non è affatto un plugin: è ancora la leva che conta di più, e l'harness è contorno.

L'obiezione è seria e va concessa per metà. Sì, sui task duri il modello migliore vince, e nessuna impalcatura trasforma un modello mediocre in un ragionatore di frontiera. Ma la conclusione non segue, per due motivi. Il primo: la politica di escalation è essa stessa una funzione dell'harness, non del modello. Un sistema che sa instradare il 20% difficile al modello giusto e l'80% restante a un modello aperto sta estraendo il valore del frontier esattamente dove serve, e lo fa grazie all'orchestrazione. Il plugin esiste proprio perché qualcosa, sopra, decide come e quando sostituirlo.

Il secondo motivo è più sottile. Anche sul 20% difficile, ciò che fa fallire un modello capace raramente è la mancanza di intelligenza grezza. È il contesto sbagliato, la verifica assente, il passo non recuperato, esattamente i fallimenti che Arena misura e che l'harness corregge. Dare al miglior modello del mondo il contesto sbagliato produce un fallimento di frontiera. Il modello di frontiera è condizione necessaria per i task duri, non sufficiente, e tutto ciò che lo rende sufficiente vive nello strato sopra. Concedere che il frontier sia insostituibile sul 20% non indebolisce la tesi: la completa.

Perché non è successo prima

C'è una seconda obiezione che sento spesso, ed è legittima: se l'harness è davvero l'elemento differenziale, perché non è successo prima? Perché ne parliamo solo ora?

La risposta è che il vincolo dominante si è spostato. Per anni il collo di bottiglia era la capacità grezza del modello: un modello che non sapeva seguire un piano a più passi, chiamare uno strumento in modo affidabile o tenere insieme un contesto lungo non lasciava niente da orchestrare. Costruire un harness sofisticato sopra un modello del genere era come progettare una rete logistica raffinata per un magazzino vuoto. Solo quando i modelli hanno superato una certa soglia di capacità agentica, uso degli strumenti, aderenza alle istruzioni, coerenza sui contesti lunghi, il rendimento marginale si è spostato dallo strato del modello a quello dell'orchestrazione. Non è che l'harness sia diventato importante all'improvviso: è diventato il vincolo che lega, perché l'altro si è allentato.

Questo chiarisce anche cosa l'harness può e non può fare, ed è il punto da tenere fermo. L'harness non genera capacità: non puoi alzare da solo l'accuratezza con cui un modello scrive Java, quella la mette il modello e nessuna impalcatura la crea dal nulla. Quello che l'harness fa è estrarre il massimo valore possibile dalla capacità che c'è: dà il contesto giusto, instrada al modello adatto, verifica l'output, recupera dagli errori. La capacità fissa il soffitto; l'harness decide quanto di quel soffitto tocchi davvero. Sono complementari, non in competizione.

Resta una domanda onesta, ed è la più scomoda per chi, come noi, scommette sull'orchestrazione: se i modelli continuano a diventare più agentici, non finiranno per assorbire da soli le funzioni dell'harness, auto-verificandosi e auto-instradandosi? In parte sì, e va messo in conto. Ma due cose restano fuori dalla portata del singolo modello, per quanto bravo: il contesto e l'integrazione specifici di un'azienda, che nessun modello generalista conosce, e l'instradamento intelligente su una flotta eterogenea di modelli, che per definizione vive sopra il singolo modello. Anche in un mondo di modelli quasi perfetti, qualcosa deve decidere quale chiamare, con quali dati riservati e come provarne il risultato. Quel qualcosa è l'harness.

Perché il valore si sposta verso l'alto

C'è uno schema che si ripete ogni volta che uno strato tecnologico si standardizza, ed è utile riconoscerlo perché dice dove andrà il valore prima che ci arrivi il mercato. Quando un componente diventa abbondante e intercambiabile, la differenziazione non sparisce: migra verso l'alto, allo strato che orchestra quel componente. È successo con l'hardware quando il calcolo è diventato commodity e il valore è salito al software. Sta succedendo ora con i modelli.

Per anni il modello è stato lo strato scarso e differenziante: avere accesso al modello migliore era il vantaggio. Quel periodo si sta chiudendo, non perché i modelli smettano di migliorare, ma perché migliorano tutti insieme e la distanza tra il primo e il decimo si è ridotta a un margine che, sui task delimitati, non si sente. Quando il componente sotto si appiattisce, chi ha costruito la propria identità su "usiamo il modello X" resta con un vantaggio che evapora a ogni rilascio. Chi ha costruito sullo strato sopra, l'orchestrazione, il contesto, la verifica, accumula un vantaggio che ogni nuovo modello rende più forte, non più debole, perché gli mette in mano materiale migliore da orchestrare.

Questo non è l'argomento di parte di chi vende harness. È la previsione naturale di come si comporta una tecnologia che matura, e vale anche se a dirla fosse qualcun altro. La domanda strategica per chi compra non è "quale modello", è "quanto del mio valore dipende da una scelta che dovrò rifare tra sei mesi".

Cosa vediamo in FairMind

Qui smettiamo di citare gli altri e parliamo di quello che misuriamo noi, ogni giorno, su clienti brownfield con codebase legacy.

Il punto di partenza è una scelta di metodo: tutta la fase di progettazione, requisitazione funzionale e analisi tecnica, la facciamo in piattaforma con validazione umana. È qui che si risolve l'ambiguità, la parte in cui un modello di frontiera resterebbe insostituibile. Quando il lavoro arriva ai coding agent, il perimetro e il contesto sono già definiti, e dentro quel perimetro pulito i modelli aperti bastano per elaborare e implementare ciò che la piattaforma ha specificato. Non è l'open che fa da solo ciò che prima chiedeva il frontier: è l'harness che, a monte, gli toglie di mezzo l'ambiguità.

I numeri li condivideremo in un articolo a parte, ma la direzione è netta: negli ultimi dodici mesi l'autonomia degli agenti basati su modelli aperti è cresciuta in modo che definire impressionante è poco. Oggi implementiamo di fatto tutti i casi d'uso previsti in piattaforma con GLM 5.1, e da qualche giorno stiamo provando GLM 5.2 e M3 con grande soddisfazione. Anche nel caso più ostico, la generazione di documentazione a partire da codice esistente, un task che può durare ore, i nostri agenti restano sui binari con un livello di accuratezza molto alto e costi estremamente contenuti.

E qui una precisazione che conta, perché è il contrario di quello che molti si aspettano. In piattaforma non facciamo mai escalation automatica al modello di frontiera. È il cliente a scegliere se usare un modello aperto o uno di frontiera, e dal 18 giugno abbiamo aperto a un gruppo selezionato di clienti la possibilità di scegliere i modelli aperti, che vengono usati a tutto campo, sempre. L'unico punto in cui oggi ricorriamo davvero a un modello di frontiera è quella seconda opinione opzionale dentro i coding agent lato cliente: un controllo sui passaggi più complessi, non la spina dorsale del sistema.

La domanda giusta

Se il modello è diventato un componente intercambiabile, la domanda "posso sostituire Claude con un modello locale?" è mal posta. Le domande utili sono altre.

Il mio harness è abbastanza maturo da rendere la scelta del modello un plugin e non una scommessa? Il task è delimitato al punto da reggere un modello di fascia media, o è ambiguo e lungo al punto da richiedere il frontier? Qual è la mia politica di escalation, e chi la decide, l'ingegnere o il sistema? E infine, le ragioni per andare locale (sovranità del dato, costo, controllo) valgono il costo totale, energia, ore di configurazione, hardware, e non solo il prezzo per token?

Chi resta fermo alla prima domanda continuerà a rifare la stessa analisi ogni mese e a concludere ogni mese la stessa cosa. Chi passa alle altre quattro inizia a costruire qualcosa che dura più di un ciclo di rilascio dei modelli.

La scommessa

In FairMind la scommessa è esplicita: il livello del modello è una commodity in rapida convergenza, e lo trattiamo come tale, un plugin da sostituire in base al task e ai vincoli del cliente. Il fossato lo costruiamo dove il valore non evapora a ogni nuova release: nell'harness, nel context engineering, nella verifica automatica, nell'orchestrazione che trasforma un modello capace in un sistema affidabile.

I numeri sui benchmark continueranno a salire e a livellarsi. La distanza tra un modello e l'altro continuerà a stringersi. E ogni volta che succederà, chi ha investito nel modello giusto dovrà ricominciare, mentre chi ha investito nell'harness avrà solo un plugin in più da sostituire.

---

Vuoi far girare il tuo sviluppo su modelli open-weight, orchestrati da un harness che conosce la tua codebase?

Richiedi l'accesso

---

Fonti

• Hacker News — "Ask HN: Has anyone replaced Claude/GPT with a local model for daily coding?" — news.ycombinator.com
• Agent Arena — "Causal Evaluation of Agents in the Real World" (metodologia, giu 2026), con la leaderboard agentica — arena.ai/blog
• Perplexity & Harvard — "DRACO: a Cross-Domain Benchmark for Deep Research" (arXiv:2602.11685, feb 2026) — arxiv.org
• OpenRouter — "Surpassing Frontier Performance with Fusion", sul benchmark DRACO (12 giu 2026) — openrouter.ai/blog · Fusion
• SWE-bench Verified — leaderboard pubblico e analisi comparative open vs frontier (mid-2026) — swebench.com
• RULER (NVIDIA) — benchmark sul contesto effettivo — arxiv.org

I diagrammi Fig. 1–7 sono nostre elaborazioni dei dati: il thread di Hacker News per le Fig. 1–3, Agent Arena per le Fig. 4–6, OpenRouter / DRACO per la Fig. 7.