Che cos’è un harness per agenti di programmazione?

Un agente di programmazione è costituito da un modello di linguaggio accoppiato a un harness, ovvero l’insieme di prompt di sistema, strumenti (come ricerca file o esecuzione di comandi Bash) e meccanismi di gestione del contesto che permettono al modello di operare all’interno di un repository di codice.

Negli ultimi mesi sono stati lanciati quotidianamente nuovi harness – ad esempio Claude Code, OpenCode o mini‑SWE‑agent – e le classifiche pubbliche li mescolano liberamente, suggerendo che la scelta del harness possa fare la differenza.

Obiettivo dello studio

Due ricercatori dell’Università di Shandong, Liu e Han, hanno voluto misurare quanto il harness incida realmente sui risultati, mantenendo costante il modello di base. Il titolo del loro lavoro è esplicito: “What does a harness buy? Mostly tokens.”

Metodologia e modelli testati

Gli autori hanno valutato cinque modelli di intelligenza artificiale con tre harness diversi nella loro versione “spedita”:

Claude Code

OpenCode

mini‑SWE‑agent (offre solo lo strumento Bash e non gestisce il contesto)

I modelli analizzati sono stati:

Qwen 3.6

Qwen 3.8

Deepseek‑V4‑Flash

GLM‑5.3‑Flash

HY4‑Preview

Claude Opus 5 è stato usato solo come riferimento in combinazione con Claude Code.

Per la valutazione sono stati impiegati i 45 task più difficili della suite SWE‑bench Verified, più un pool aggiuntivo di 447 task più semplici, per un totale di 492 esercizi.

Procedura di esecuzione

Tutte le prove sono state condotte offline. In una fase preliminare con accesso al web, il 71 % delle richieste dei modelli Deepseek e Qwen ha recuperato la correzione corretta direttamente da GitHub anziché risolvere il problema autonomamente; i modelli Claude quasi mai hanno adottato questa strategia. Per evitare contaminazioni, gli autori hanno escluso questi risultati e hanno disabilitato l’accesso al web per le esecuzioni successive.

Risultati principali: poco impatto sul tasso di successo

Su 447 task, Claude Code (harness più “pesante”) e mini‑SWE‑agent (harness più “leggero”) differiscono di meno di due punti percentuali per entrambi i modelli testati, rientrando in un intervallo di cinque punti considerato statisticamente equivalente.

Gli stessi harness consumano da due a tre volte più token rispetto all’opzione più snella, ma i tassi di passaggio rimangono entro l’incertezza di misura. L’unica eccezione è OpenCode, che presenta un deficit statisticamente significativo sul grande pool di task.

Confronto con la variabilità di un semplice rerun

Quando gli stessi setup sono eseguiti due volte (rerun), la differenza di risultati può arrivare fino a sei punti su SWE‑bench Verified. Lo scambio di harness produce variazioni analoghe: la differenza media è di due‑cinque task risolti, mentre un semplice rerun può modificare il conteggio di fino a tre task.

Le “flip rates” – la percentuale di task il cui risultato cambia – confermano questo fenomeno: tra due rerun la mediana dei cambiamenti è del 13 %; tra due harness diversi è anch’essa del 13 %; passando a un modello diverso la percentuale sale al 22 %.

Analisi dei costi: il ruolo del prompt di sistema

Con lo stesso modello, gli stessi task e la stessa tariffa per token, il costo di una singola esecuzione può variare fino a tre volte a seconda dell’harness impiegato. La differenza non è data dalla quantità di output generato dagli strumenti, ma dal prompt di sistema e dalle descrizioni degli strumenti, che vengono reinviati ad ogni passo.

Le dimensioni medie dei prompt di sistema sono:

Claude Code: circa 16 600 token

OpenCode: circa 7 000 token

mini‑SWE‑agent: meno di 1 000 token

Claude Code, oltre al prompt più grande, mantiene nella cronologia anche l’output di ragionamento del modello, aumentando ulteriormente il consumo di token.

Esempi di costi per modello

Con GLM‑5.3‑Flash, una singola prova in Claude Code costa 1,81 yuan, contro 0,56 yuan in OpenCode. Con Deepseek‑V4‑Flash, invece, Claude Code e mini‑SWE‑agent raggiungono costi quasi equivalenti a causa del maggior numero di passi richiesti da quest’ultimo.

OpenCode: l’unica anomalia rilevata

OpenCode è l’unico harness che mostra un deficit misurabile. Su 447 task è inferiore di fino a nove punti rispetto agli altri due harness. Circa la metà di questo divario è attribuita a un limite di output:

Se il modello supera il limite a metà di un ragionamento, Claude Code lo invita a continuare, mentre OpenCode termina l’operazione, provocando il fallimento.

L’aggiunta di un prompt di continuazione in stile Claude Code a OpenCode non ha risolto il problema, poiché l’overflow non si verifica più spesso su una nuova esecuzione.

Il resto del divario rimane inspiegato, ma è stato osservato che, sotto OpenCode, i modelli tendono a interrompersi più rapidamente. Inoltre, OpenCode impone limiti di tempo più stringenti rispetto a Claude Code, un fattore non controllato dallo studio.

Altri fattori di performance

mini‑SWE‑agent, privo di gestione del contesto, incappa più spesso nel superamento della finestra di contesto, soprattutto su task dove anche gli altri harness falliscono.

OpenCode tenta di scaricare un file binario al primo utilizzo del tool di ricerca e si blocca quando è offline, limitando ulteriormente la sua efficacia.

Il ruolo del “thinking”

Un caso in cui la scelta dell’harness influisce realmente è la modalità “thinking”. Quando questa è disattivata, mini‑SWE‑agent con Qwen 3.6 perde undici punti, mentre Claude Code e OpenCode rimangono entro il rumore. Anche HY4‑Preview perde undici punti in Claude Code senza “thinking”. Ciò suggerisce che la dipendenza dal ragionamento varia a seconda della combinazione modello‑harness.

Conclusioni e raccomandazioni

Lo studio, basato quasi esclusivamente su SWE‑bench, ha effettuato un piccolo cross‑check su Terminal‑Bench 2.1, confermando lo stesso schema: i diversi harness non migliorano significativamente il tasso di successo, ma aumentano i costi.

Gli autori sintetizzano il risultato con la frase: un harness compra “meno modi per perdere un task, ma una bolletta più alta, non un tasso di passaggio più alto”.

Raccomandano di pubblicare sempre un rerun della stessa configurazione insieme a ogni confronto di harness, così da distinguere la reale differenza dal semplice rumore statistico.

I dati grezzi e gli script di analisi sono disponibili su GitHub.