La classifica Niklaus Harness testa Kimi Code, Hermes, Pi, Claude Code e Codex oltre le classifiche di marca

Joël Niklaus ha confrontato nove harness per agenti di coding in 28.849 prove, mettendo in discussione l’idea che la scelta di un modello risolva la questione delle prestazioni. La classifica Niklaus harness valuta il software che dirige il lavoro di un modello, mantenendo sotto controllo il modello sottostante e le impostazioni di ragionamento. I risultati iniziali collocano diversi strumenti noti in una fascia di accuratezza simile, mentre differenze di efficienza e ripetibilità rendono più complessa l’identificazione di un vincitore.

Il confronto include Kimi Code, Hermes Agent, Pi, Claude Code, Codex, OpenCode, mini-swe-agent, Qwen Code e OpenClaw. Un harness è il software che gestisce istruzioni, strumenti e ciclo di esecuzione di un modello AI. In questo caso, è quel software circostante a diventare la variabile in esame.

La tensione centrale riguarda la reputazione di un prodotto e il comportamento di una specifica configurazione testata. Questi risultati non dimostrano che Claude Code o Codex offrano prestazioni universalmente migliori con il loro modello predefinito. Esaminano ciò che accade quando harness differenti eseguono modelli open selezionati in condizioni controllate: una questione più circoscritta, ma con conseguenze pratiche per gli sviluppatori.

Cosa confronta realmente la classifica Niklaus Harness

L’esperimento isola il software dell’agente circostante invece di trattare ogni prodotto di coding come un pacchetto inseparabile.

Nella descrizione del rilascio, Niklaus afferma che il confronto mantiene fissi modello, provider e sforzo di ragionamento, modificando invece l’harness. Ogni attività riceve tre tentativi. La valutazione iniziale copre GLM-5.3-Flash, DeepSeek-V4.1-Flash e Flint, utilizzando Terminal-Bench 2.1 e DeepSWE.

Questo design è rilevante perché i normali confronti tra prodotti spesso modificano simultaneamente diverse variabili. Uno sviluppatore che cambia assistente di coding può cambiare insieme modello, istruzioni, strumenti disponibili, autorizzazioni e comportamento di esecuzione. Diventa quindi difficile attribuire una differenza di prestazioni.

La descrizione del rilascio riporta mini-swe-agent con un tasso medio di risoluzione del 51,4% sui tre modelli, rispetto al 27,3% di OpenClaw. Niklaus afferma inoltre che altri quattro harness sono statisticamente alla pari con il risultato migliore. Queste cifre descrivono il rilascio iniziale, non una classifica permanente.

I risultati specifici per modello complicano quella media complessiva. Secondo Niklaus, mini-swe-agent guida su GLM-5.3-Flash, Hermes Agent su DeepSeek-V4.1-Flash e Kimi Code su Flint. L’ordinamento dipende quindi dal modello che uno sviluppatore intende eseguire.

L’implicazione immediata è limitata ma rilevante. Un harness che funziona bene con un modello non estrae automaticamente le stesse prestazioni relative da un altro. Un punteggio complessivo può aiutare a identificare candidati, nascondendo però l’abbinamento che conta per una distribuzione concreta.

Terminal-Bench valuta agenti che svolgono attività in ambienti terminali, nei quali il software esegue comandi e interagisce con i file. DeepSWE fornisce una valutazione distinta di ingegneria del software. L’uso di entrambi amplia il confronto, anche se la combinazione dei risultati non rende le raccolte di attività rappresentative di ogni flusso di lavoro di sviluppo.

L’esperimento richiede inoltre che alle sue conclusioni sia associata una data. Al momento della verifica per questo articolo, l’applicazione live mostrava la versione v0.1.2. La descrizione attuale fa riferimento alla verifica di provider equivalenti, anziché limitarsi a ripetere la formulazione del rilascio iniziale sui provider fissi.

Questa distinzione merita attenzione perché un benchmark può evolvere dopo il suo primo annuncio. Nuove versioni degli harness, prove aggiuntive o controlli rivisti possono modificare il significato di uno screenshot. I dati di lancio restano prove della configurazione di lancio, anche quando la classifica corrente presenta un ordinamento differente.

Per i lettori che incontrano la discussione Reddit originale, la correzione essenziale riguarda quindi l’ambito. Si tratta di un confronto fra combinazioni selezionate di harness e modello. Non è un test completo di ogni funzionalità, esperienza di abbonamento o configurazione predefinita associata ai nomi dei prodotti elencati.

I fornitori di agenti di coding affrontano la pressione di spiegare l’intera configurazione

I risultati esercitano pressione sulle affermazioni che attribuiscono interamente le prestazioni di un agente al suo modello sottostante.

Per gli sviluppatori di harness, il confronto rende più visibili le scelte di implementazione. Istruzioni, interfacce degli strumenti, comportamento dei tentativi ripetuti e decisioni di arresto modellano tutti il lavoro svolto da un modello. Un modello forte può comunque incontrare attriti causati dal software responsabile della sua direzione.

Per i fornitori di modelli, lo stesso esperimento introduce un problema di attribuzione. Un risultato deludente all’interno di un particolare agente non identifica il modello come unica causa. Al contrario, un buon risultato non dimostra che ogni applicazione che utilizza quegli stessi pesi lo riprodurrà.

Per gli acquirenti enterprise, questo modifica ciò che una valutazione significativa deve descrivere. Indicare un modello e un assistente è insufficiente quando le scelte di configurazione influenzano gli esiti. Gli acquirenti hanno bisogno di informazioni sufficienti per comprendere la combinazione testata e riprodurre il comportamento rilevante per il proprio lavoro.

Un’ipotetica attività di manutenzione rende concreta la distinzione. Un agente potrebbe dover ispezionare un repository, identificare un test non riuscito, modificare una funzione e verificare il cambiamento. Ogni fase dipende da come l’harness espone le informazioni e gestisce la sequenza delle azioni.

Se l’agente si ferma dopo la modifica senza eseguire il test pertinente, una patch plausibile resta non verificata. Se continua a emettere comandi improduttivi, il completamento diventa più lento e più dispendioso in termini di risorse. Sono differenze operative, anche quando il modello sottostante rimane invariato.

Questo non dimostra quale implementazione abbia causato un particolare risultato in classifica. Per determinarlo occorre ispezionare i registri di esecuzione e testare un intervento. Spiega perché il confronto controllato pone una domanda utile alla quale una semplice classifica di modelli non può rispondere.

I risultati di lancio delimitano inoltre il consueto dibattito Claude Code vs Codex. Questi nomi di prodotto rappresentano spesso esperienze complete costruite attorno a particolari famiglie di modelli. Testare i loro harness con modelli open selezionati pone una domanda diversa dal confronto fra quelle esperienze complete.

Una posizione bassa in questo esperimento non dimostrerebbe che il servizio predefinito di un prodotto abbia prestazioni scarse. Una posizione alta non dimostrerebbe superiorità nella revisione del codice, nella collaborazione interattiva o nei flussi di lavoro specifici di un’organizzazione. Tali affermazioni richiedono valutazioni che misurino direttamente queste attività.

Il risultato del benchmark Kimi Code presenta lo stesso limite. Il suo vantaggio riportato con Flint giustifica l’approfondimento di quell’abbinamento nelle condizioni testate. Non dimostra un vantaggio generale su modelli o repository non correlati.

Per i fornitori, la risposta costruttiva consiste nel pubblicare le configurazioni e spiegare i cambiamenti che influenzano gli esiti. Gli acquirenti possono così distinguere un aggiornamento del modello da un miglioramento dell’harness. Questo rende le dichiarazioni sulle prestazioni più facili da valutare e gli insuccessi più semplici da indagare.

La pressione è particolarmente rilevante per i team che eseguono modelli open tramite software per agenti intercambiabili. La loro decisione d’acquisto include il livello di esecuzione. Hanno bisogno di prove su ciò che quel livello apporta, invece di affidarsi interamente a un nome di prodotto riconoscibile.

Un’accuratezza simile può nascondere comportamenti operativi differenti

Un risultato di accuratezza ravvicinato lascia spazio a differenze significative nell’uso delle risorse, nella latenza e nella coerenza.

La classifica attuale separa diverse misurazioni invece di presentare l’accuratezza come una risposta completa. Il suo metodo di valutazione descrive la misurazione esterna dell’uso del modello e distingue il tempo di elaborazione del modello dal tempo impiegato nell’esecuzione dell’agente. Queste distinzioni aiutano a spiegare perché tassi di risoluzione simili possano produrre esperienze operative diverse.

La classifica traccia inoltre l’accuratezza rispetto al costo e identifica una frontiera di Pareto, ovvero l’insieme delle opzioni che nessun concorrente supera su entrambe le misure visualizzate. Questo offre ai lettori un modo per esaminare vantaggi concorrenti senza presumere che la massima accuratezza debba sempre essere preferibile.

Questa impostazione è importante quando un’organizzazione ha un carico di lavoro fisso e risorse limitate. Un piccolo vantaggio di accuratezza può essere prezioso per un’attività difficile che richiede supervisione minima. Lo stesso vantaggio può risultare meno attraente se richiede un tempo di esecuzione sostanzialmente maggiore nell’ambito della manutenzione ordinaria.

Anche un risultato di efficienza necessita di interpretazione. Una spesa inferiore non significa necessariamente che un agente ragioni in modo più efficace. Potrebbe riflettere meno tentativi, una terminazione anticipata, output più brevi o un diverso schema di utilizzo degli strumenti. Il registro di esecuzione aiuta a distinguere la moderazione produttiva dall’insuccesso prematuro.

Allo stesso modo, un’esecuzione più lunga non dimostra uno spreco. Un agente potrebbe dedicare uno sforzo aggiuntivo al controllo di una patch o al recupero da un approccio fallito. La domanda rilevante è se quel lavoro aggiuntivo migliori un risultato che il team valorizza realmente.

Per questo riportare l’uso delle risorse per tentativo e per esito positivo risponde a domande diverse. Un tentativo economico fallito resta un fallimento. Un tentativo riuscito più impegnativo può comunque essere la scelta migliore quando il recupero umano altrimenti dominerebbe il flusso di lavoro.

Si tratta di considerazioni di valutazione, non di spiegazioni dimostrate per ogni harness presente nella classifica. Un grafico può rivelare uno schema meritevole di indagine. Non può, da solo, identificare l’istruzione o il comportamento degli strumenti responsabile di quello schema.

Il meccanismo è semplice in linea di principio. Un agente riceve informazioni, sceglie un’azione, osserva il risultato e decide cosa fare successivamente. L’harness controlla parti importanti di quel ciclo, compresi gli strumenti disponibili e il modo in cui le loro risposte raggiungono il modello.

Si consideri un repository ipotetico con una build non riuscita causata da un problema di ambiente. Un agente che modifica ripetutamente il codice dell’applicazione può consumare risorse senza affrontarne la causa. Un’altra configurazione potrebbe riconoscere il problema di ambiente e reindirizzare la propria indagine.

La differenza riguarderebbe l’esecuzione dell’attività anziché la conoscenza grezza del modello. Dimostrare questa spiegazione richiederebbe di collegare il comportamento osservato al risultato. Senza tale ispezione, affermare che un particolare harness sia “più intelligente” va oltre le prove disponibili.

La classifica Niklaus harness supporta quindi un confronto più specifico di quanto suggerisca un’unica etichetta di vincitore. Gli sviluppatori possono chiedersi quali combinazioni raggiungano un’accuratezza accettabile usando risorse in un modo che il loro carico di lavoro può sostenere. La risposta può differire tra sviluppo interattivo e operatività non supervisionata.

Cambia anche il modo di leggere un titolo sul benchmark Kimi Code. Un vantaggio specifico per modello è un segnale utile per ulteriori valutazioni. Resta incompleto senza informazioni sui tentativi falliti, sulla durata dell’esecuzione e sul comportamento che ha prodotto il punteggio.

Per la stessa ragione, i confronti Claude Code vs Codex dovrebbero preservare il contesto testato. I nomi offrono orientamento, ma è la configurazione a determinare ciò che il risultato descrive realmente.

Il successo ripetibile è un risultato diverso dal successo occasionale

Un agente che risolve un compito in modo intermittente presenta una proposta di deployment diversa da uno che lo risolve con costanza.

Niklaus ha poi evidenziato l'affidabilità nei tentativi ripetuti. Secondo la sua analisi dell'affidabilità, mini-swe-agent ha risolto in media il 51,4% dei compiti per tentativo. Ha risolto il 68,6% almeno una volta su tre tentativi, ma il 33,0% a ogni tentativo.

Queste misurazioni descrivono questioni operative diverse. La media cattura le prestazioni tra i vari tentativi. Il successo almeno una volta indica se opportunità ripetute producono infine una soluzione. Il successo ogni volta misura la coerenza nei tentativi osservati.

La distinzione diventa importante quando qualcuno osserva l'agente al lavoro. Uno sviluppatore può esaminare un tentativo fallito, modificare un'istruzione o decidere che valga la pena eseguire un altro tentativo. La supervisione umana può rendere utile un successo intermittente, anche se il tempo impiegato per supervisionare resta parte del flusso di lavoro.

Un processo non supervisionato affronta un vincolo diverso. Non può presumere che esista un tentativo alternativo riuscito, a meno che il sistema circostante non esegua davvero delle alternative e non ne riconosca la qualità. I tentativi ripetuti richiedono un metodo di selezione, un budget di esecuzione e un modo per gestire i fallimenti irrisolti.

Questo rende un punteggio di successo occasionale un sostituto inadeguato di una misurazione della coerenza. Può mostrare che una configurazione ha accesso a una soluzione in determinate condizioni. Non dimostra che la configurazione fornirà quella soluzione in modo affidabile su richiesta.

Niklaus riferisce che cinque harness hanno risolto tra il 32,0% e il 33,3% dei compiti a ogni tentativo nel confronto citato. Descrive questi risultati come troppo ravvicinati per poter decretare un vincitore. Ciò supporta la scelta di evitare affermazioni precise sul vincitore all'interno del gruppo di testa.

Anche alle cifre sull'affidabilità vanno associati dei limiti. Tre tentativi forniscono evidenza sulla ripetibilità all'interno di quell'esperimento. Non stabiliscono un tasso di fallimento in produzione tra repository, dipendenze, autorizzazioni e istruzioni degli utenti in evoluzione.

Nemmeno un fallimento su un benchmark si traduce automaticamente in un'azione dannosa in produzione. Il valutatore misura se il compito soddisfa i suoi criteri di successo. Le conseguenze operative dipendono da ciò a cui l'agente può accedere e dalle approvazioni o verifiche che circondano il suo lavoro.

Per i responsabili dell'ingegneria, l'implicazione è separare la capacità dalla consegna affidabile. Una configurazione può essere abbastanza capace da produrre talvolta una patch corretta, pur restando inadatta a un flusso di lavoro non supervisionato. Quel divario richiede verifiche aggiuntive, non un'etichetta di marketing più forte.

Un ipotetico aggiornamento di dipendenza illustra la differenza. Un agente potrebbe aggiornare con successo il pacchetto e superare i test durante una prima esecuzione, quindi non rilevare una modifica correlata alla configurazione durante un'altra. Il successo occasionale dimostra meno sulla prontezza per un uso non supervisionato di quanto potrebbe suggerire la percentuale in evidenza.

Un team che valuta quel flusso di lavoro si preoccuperebbe del completamento riproducibile e di una gestione chiara dei fallimenti. Si preoccuperebbe anche che la modifica risultante sia comprensibile per un revisore. Queste dimensioni restano distinte dal fatto che il verificatore del benchmark accetti lo stato finale.

La visione del leaderboard sui tentativi ripetuti porta questa distinzione nel confronto pubblico. Incoraggia i lettori a chiedersi cosa accada quando l'agente deve lavorare di nuovo, invece di trattare una singola traiettoria riuscita come una descrizione completa del prodotto.

Le versioni dei benchmark e i record pubblici limitano le affermazioni sul vincitore

I risultati pubblicati sono prove ispezionabili, ma restano delimitati dalle versioni dei benchmark, dalle configurazioni e dalla completezza della verifica.

Terminal-Bench stesso offre un esempio chiaro del motivo per cui le etichette di versione sono importanti. La sua revisione 2.1 ha corretto problemi in 28 degli 89 compiti dell'edizione precedente. I manutentori hanno riportato cambiamenti nei punteggi rappresentativi di agenti e modelli dopo tali correzioni.

Questa storia rende la versione di un benchmark parte integrante dell'affermazione. Un punteggio di Terminal-Bench 2.0 non può essere semplicemente considerato intercambiabile con uno della 2.1. I compiti e le condizioni di valutazione sono cambiati, anche quando la metrica visualizzata mantiene lo stesso nome.

Lo stesso principio si applica all'harness. Un risultato appartiene alla versione del software e alle impostazioni testate. Se un aggiornamento modifica istruzioni, esecuzione degli strumenti o comportamento di terminazione, il punteggio precedente descrive l'implementazione precedente.

Ciò crea una difficoltà per le discussioni pubbliche in rapida evoluzione. Un grafico può circolare dopo che la classifica è cambiata, mentre i commenti continuano a trattarlo come attuale. I lettori hanno bisogno della configurazione originale e della data di misurazione per stabilire cosa l'immagine dimostri ancora.

I record pubblici delle esecuzioni del progetto offrono un percorso per verificare questi dettagli. La disponibilità dei record è un vantaggio in termini di trasparenza. La loro pubblicazione non significa che ogni risultato abbia già ricevuto una riproduzione indipendente o una revisione manuale completa.

Una riproduzione indipendente richiederebbe l'esecuzione delle configurazioni specificate e la verifica della persistenza dei modelli rilevanti. La lettura dei record può supportare un audit dei calcoli riportati o dei singoli comportamenti. Queste attività forniscono tipi di prova differenti.

La questione causale resta particolarmente impegnativa. Una differenza di punteggio può identificare un'associazione tra configurazione e risultato in condizioni controllate. Spiegare la differenza richiede l'esame dei fallimenti e la verifica che una modifica proposta li alteri.

Per esempio, un sospetto problema di timeout dovrebbe essere testato modificando il timeout e preservando le altre condizioni rilevanti. Un sospetto problema di perdita di informazioni richiede di ispezionare quali informazioni siano scomparse e se preservarle migliori i risultati. Nessuna delle due spiegazioni deriva automaticamente da una posizione bassa in classifica.

La familiarità con il benchmark introduce un'altra preoccupazione che vale la pena indagare senza presumere scorrettezze. Un sistema ottimizzato rispetto a compiti pubblici può migliorare su quella distribuzione di compiti senza migliorare in egual misura altrove. Le prove su compiti non familiari aiuterebbero a stabilire quanto ampiamente il miglioramento si trasferisca.

La copertura dei compiti presenta una limitazione separata. La manutenzione dei repository include convenzioni organizzative, richieste ambigue e aspettative di revisione umana che un benchmark fisso non può catturare completamente. Un benchmark può comunque essere utile, lasciando irrisolte tali questioni di deployment.

La risposta pratica consiste nel mantenere le prove proporzionate alla decisione. Un risultato pubblico può giustificare una shortlist o una prova mirata. Sostituire il flusso di sviluppo di un team richiede prove aggiuntive provenienti da attività simili alle responsabilità effettive di quel team.

Mantenere insieme configurazioni, esempi di fallimento e decisioni di revisione rende questi confronti più facili da riesaminare. Una base di conoscenza ricercabile può aiutare a preservare questa cronologia di valutazione accanto ai documenti tecnici utilizzati durante i test.

Il divario nella verifica non cancella il valore dell'esperimento. Definisce ciò che i risultati supportano attualmente e quale lavoro aggiuntivo li rafforzerebbe. È una lettura più utile che accettare letteralmente ogni posizione in classifica o liquidare del tutto il confronto.

I prossimi test dovrebbero monitorare aggiornamenti, riproduzione e lavoro non supervisionato

Le prove di follow-up più solide collegheranno i cambiamenti di versione a miglioramenti riproducibili su attività che vadano oltre il confronto iniziale.

Il primo segnale da osservare è l'aggiornamento delle prestazioni dell'harness con una chiara cronologia delle versioni. Quando uno sviluppatore modifica il software di esecuzione, una riesecuzione comparabile può mostrare se cambiano accuratezza, efficienza o coerenza. Preservare la configurazione precedente rende significativo il confronto.

Un miglioramento tra misurazioni ripetute rafforzerebbe l'ipotesi che l'ingegneria dell'harness influenzi materialmente i risultati. Un risultato che scompare in riesecuzioni comparabili indebolirebbe la fiducia nel miglioramento dichiarato. Entrambi gli esiti forniscono più informazioni di un badge del vincitore aggiornato.

Ciò offre anche ai fornitori un modo costruttivo per rispondere. Possono identificare un modello di fallimento, spiegare la modifica di implementazione rilevante e pubblicare prove del risultato. I lettori possono quindi valutare un'affermazione ingegneristica concreta invece di dedurre la qualità dalla reputazione di un prodotto.

Il secondo segnale è la riproduzione indipendente con controlli corrispondenti. Un valutatore separato dovrebbe documentare il modello, le condizioni del fornitore, le impostazioni di ragionamento, la versione dei compiti e la versione dell'harness. Le differenze devono restare visibili anziché essere assorbite in un punteggio apparentemente identico.

Se i risultati indipendenti preservano l'ordinamento generale o i modelli specifici per modello, aumenta la fiducia nel confronto. Se i risultati divergono, ciò indica condizioni che richiedono un esame più approfondito. Il comportamento del fornitore, le impostazioni di esecuzione e i dettagli di misurazione diventano questioni di ricerca anziché spiegazioni comode.

La riproduzione non richiede che ogni numero corrisponda esattamente. La questione rilevante è se la conclusione resista a ragionevoli misurazioni ripetute. Risultati ravvicinati dovrebbero restare ravvicinati, salvo che prove aggiuntive giustifichino di distinguerli.

Il terzo segnale è la prestazione su attività non familiari con criteri espliciti di successo non supervisionato. Ciò significa verificare se l'agente completa il compito richiesto, verifica il risultato e gestisce il fallimento in modo appropriato. L'intervento umano dovrebbe essere registrato perché modifica il significato di “completamento autonomo”.

Miglioramenti costanti su quel lavoro rafforzerebbero l'importanza pratica dei risultati del leaderboard. Guadagni confinati a compiti di benchmark familiari ne restringerebbero la rilevanza. La distinzione conta più per il deployment di un altro piccolo movimento in una media complessiva.

Per i team che scelgono software ora, le prove supportano il confronto al livello dell'abbinamento effettivo. Kimi Code, Hermes Agent, Pi, Claude Code, Codex e mini-swe-agent meritano una valutazione nelle configurazioni che un team intende utilizzare. I loro nomi da soli non possono determinare il risultato.

Il harness leaderboard di Niklaus offre un punto di partenza pubblico per tale valutazione, con risultati di lancio, tentativi ripetuti e record accessibili. Il suo contributo duraturo dipenderà dal fatto che tali misurazioni aiutino a spiegare e migliorare il comportamento degli agenti.

Prima di cambiare il vostro flusso di lavoro di coding, confrontate un abbinamento selezionato con la configurazione di cui già vi fidate, usando attività di manutenzione rappresentative. Registrate la configurazione esatta, le prove di completamento, lo sforzo del revisore e i fallimenti che richiedono intervento. Includete compiti in cui una patch plausibile non sia sufficiente senza un passaggio di verifica riuscito. Riesaminate il confronto dopo un aggiornamento significativo dell'harness, preservando i risultati precedenti affinché i cambiamenti restino comprensibili. Considerate la classifica pubblica come una prova per quella decisione, lasciando però al vostro flusso di lavoro l'ultima parola. La domanda che vale la pena porre è concreta: quale combinazione testata fornisce un lavoro che il vostro team può verificare, ripetere e accettare con la supervisione che potete realmente garantire?