Harness o modello? Con lo stesso modello, l’harness del produttore non vince in media

Chi ha cucinato in una cucina non sua conosce la sensazione: i coltelli tagliano diverso, il forno scalda a modo suo, il sale non sta dove la mano lo cerca. Si dà per scontato che un cuoco renda meglio dove ha imparato. Per saperlo bisognerebbe farlo cucinare, con le stesse ricette, in due cucine, e assaggiare alla cieca.

Con gli agenti di programmazione è lo stesso. Chi produce un modello distribuisce anche il programma che lo fa lavorare, l’harness (claude-agent-sdk per Anthropic, l’SDK di openai-codex per OpenAI), e si dà per scontato che la coppia del produttore risolva più compiti di un harness neutrale. Harness or Model?, depositato su arXiv l’8 settembre 2026 (2609.11987) da Mohsen Arjmandi, della tedesca evolutionID GmbH, fa l’assaggio alla cieca: in media nessuno dei due vince.

Un assaggio a modello fisso

Il disegno tiene fermo il modello e cambia solo l’harness: claude-opus-4-8 lavora una volta dentro claude-agent-sdk e una volta dentro deepagents, l’harness neutrale costruito su LangGraph; gpt-5.5 fa lo stesso fra l’SDK di openai-codex e deepagents. Ogni esecuzione ha una sua macchina virtuale, lo stesso repository, lo stesso prompt e un tetto di 1.200 secondi; le patch le giudica a parte un correttore con test nascosti.

I compiti sono privati, perché quelli pubblici finiscono nei dati di addestramento: 179 ricavati da quattro codebase di produzione dell’organizzazione dell’autore e 77 problemi di LeetCode e AtCoder usciti dopo il limite di addestramento dei modelli in gara. L’esperimento principale ne usa 80, 61 di repository e 19 da gara, ciascuno ripetuto due volte per cella.

Il risultato medio

Su Opus 4.8 claude-agent-sdk risolve 1,25 punti in meno di deepagents; su GPT-5.5 l’SDK di openai-codex ne risolve 1,25 in più. Gli intervalli al 95% comprendono lo zero in tutti e due i casi.

«Nessun vantaggio dimostrato» non vuol dire «nessuna differenza»: l’intervallo di Opus va da 10 punti a favore di deepagents a 7,5 a favore di claude-agent-sdk, e l’autore scrive che i suoi numeri non stabiliscono un’equivalenza. Il metodo è quello che il libro descrive per misurare un harness: confronti appaiati, con la numerosità data dai compiti e non dalle ripetizioni.

Una media che somma due effetti opposti

Su Opus, nei 61 compiti di repository claude-agent-sdk resta indietro di 9,0 punti; nei 19 compiti da gara è avanti di 23,7. Pesati per il numero di compiti, i due effetti ricompongono la media:

$$\Delta = \tfrac{61}{80}\,(-9{,}0) + \tfrac{19}{80}\,(+23{,}7) \approx -1{,}25.$$

Un test di permutazione, che rimescola le etichette «repository» e «gara» fra i compiti, dà $p = 0{,}003$ per questa interazione. Su GPT-5.5 la divisione non dice niente. Ma è stata scelta dopo aver visto i risultati, e l’autore lo scrive già nell’abstract: è una traccia da verificare con una replica disegnata apposta. Una conseguenza regge comunque: un tasso di successo aggregato dipende da come è composto il banco di prova, e non è la grandezza su cui scegliere un harness.

Lo stesso punteggio, un altro lavoro

I due harness si separano nel modo di arrivarci. Allo scadere dei 1.200 secondi l’agente viene interrotto e il correttore giudica la patch che trova: delle 81 esecuzioni valutate fermate così (contando due celle laterali con gemini-3.5-flash e deepseek-v3.2), 22 avevano già una patch che passava i test. Il compito era risolto, l’agente non aveva finito, e i dati non dicono da quanto.

L’harness neutrale fa più chiamate a strumenti, impiega di più e su Opus tocca il tetto 32 volte contro una. Un banco di prova che giudica solo la patch dirà che i due harness si equivalgono; chi aspetta che l’agente finisca no. L’autore chiede di riportare sempre insieme tasso di successo, esiti delle esecuzioni e tempi.

Un errore nei propri conti

La versione di agosto, di cui questo paper è la revisione, stimava che l’harness neutrale costasse 2,6 volte tanto per compito risolto su Opus e 1,8 su GPT-5.5. Erano numeri sbagliati: il modulo dei consumi sommava ai token in ingresso quelli della cache, cosa giusta per l’API di Anthropic, che li conta a parte, e sbagliata per LangChain, che sotto deepagents li include già. Ricalcolati dai consumi registrati turno per turno, a prezzi di listino, i rapporti scendono a valori fra 1,3 e 1,6 su Opus e a 1,2 su GPT-5.5. Sul conto di OpenAI la stima coincide con la spesa addebitata a meno del 2–4%. Su quello di Anthropic no: 58 esecuzioni non hanno lasciato un registro dei consumi, e a seconda di come si attribuisce la spesa mancante il rapporto va da 0,7 a 2,3. Quale dei due harness costi di più in bolletta, su Opus, resta aperto.

Che cosa dicono gli altri due studi

Due studi usciti poco dopo guardano dentro l’harness, con modelli aperti e banchi pubblici. Fan e colleghi (17 settembre) variano tre componenti di un harness leggero su Nemotron-3 in tre taglie e su Mistral-Medium-3.5-128B: 176 configurazioni su SWE-Bench Verified e Terminal-Bench 2.1. Gestire il contesto (togliere i vecchi output, riassumere la cronologia) serve soprattutto quando la finestra è stretta, perché evita che l’esecuzione si fermi a contesto esaurito: senza gestione, su SWE-Bench, succede in media al 78,7% dei compiti con 32mila token e all’8,7% con 128mila. Al Nemotron più grande basta la sola bash, che guadagna 3,6 punti su SWE-Bench e costa il 53% in meno; Mistral, nella stessa prova, ne perde 23,2.

Hu e colleghi (26 settembre) mettono dieci modelli Qwen e DeepSeek in mini-SWE-agent, un harness minimo, e in OpenCode, uno da prodotto. Su SWE-bench Pro il vantaggio dell’harness complesso in generale si assottiglia al crescere del modello (con DeepSeek-V4-Pro, 34,3% contro 33,7%); su compiti più aperti, come generare un repository intero, sono invece i modelli più forti a sfruttarlo meglio. E su ProgramBench la compressione del contesto costa fra 3,9 e 4,9 punti, e i subagenti generici peggiorano il punteggio. Nessuno dei due studi pone la domanda di Arjmandi, ma tutti e tre arrivano allo stesso punto: l’effetto dell’harness non è un premio fisso, dipende dal modello, dal compito, dal budget e da che cosa si misura.

I conti da rifare

Il primo limite sta nella firma. L’autore è uno solo e i compiti di repository vengono dalla sua organizzazione: compiti, apparato e analisi escono dalla stessa mano. I compiti restano privati, e da fuori le esecuzioni non si possono rifare.

Il secondo è la divisione per tipo di compito, scelta a posteriori fra le diverse che i risultati per famiglia suggerivano; quante ne siano state guardate prima, scrive l’autore, non è più ricostruibile. E la correzione per i confronti multipli è cambiata dopo una revisione, portando il valore corretto dell’interazione da 0,10 a 0,013: il paper riporta entrambi.

Poi il campione. Gli 80 compiti comprendono tutti i 24 su cui le due coppie dei produttori, in un primo giro, erano in disaccordo: il 30% del campione, contro il 9,4% della raccolta. Le ripetizioni sono due, previste tre e ridotte per costo. La cella di codex aveva 4 GiB di memoria e le altre 8, e budget e strumenti cambiano da un prodotto all’altro: il confronto è fra harness come si usano, non a budget uguale. E la preregistrazione dichiarata ad agosto non c’è: c’è un piano con le ipotesi, datato nel repository prima delle esecuzioni, e un deposito privato su OSF la cui preregistrazione descrive un altro esperimento.

Infine il tetto di tempo. I documenti depositati su OSF a giugno contavano come fallita un’esecuzione interrotta; il paper giudica invece la patch presente all’interruzione, e lo dichiara. Con la regola di giugno, per deepagents su Opus 11 esecuzioni su 160 passerebbero da riuscite a fallite, circa sette punti; claude-agent-sdk ha avuto una sola esecuzione interrotta, e senza una patch valida. La differenza passerebbe così da −1,25 a circa +5,6 punti a favore dell’harness del produttore. Il conto è nostro e approssimato, non del paper. Vale anche il rovescio, che l’autore mette fra i limiti: con un tetto più alto i risultati dell’harness più lento potrebbero cambiare. «Nessuno vince» dipende anche da quanto si è disposti ad aspettare.

Che cosa c’è in gioco

L’harness del produttore lega a un fornitore; uno neutrale promette di cambiare modello senza riscrivere niente, a un prezzo che, scrive l’autore, nessuno aveva misurato su lavoro privato. Questo esperimento dice che in capacità quel prezzo, in media, non si vede, e che il costo visibile sta altrove: nel tempo, nei giri in più, nella spesa. L’harness si sceglie sul proprio miscuglio di compiti, sul comportamento che serve (un agente che finisce, non solo una patch giusta) e sulla spesa addebitata con le proprie tariffe. Il cuoco, nella cucina d’altri, cucina più o meno come a casa: ci mette di più e, a giudicare dai consumi registrati, spende anche di più.

Per approfondire

Il paper: Mohsen Arjmandi, Harness or Model? Isolating the Harness Effect in Agentic Coding with a Contamination-Controlled Private Suite, arXiv, 8 settembre 2026, arxiv.org/abs/2609.11987.

Run-Ze Fan, Zihao Zhang e colleghi, fra cui Hamed Zamani e Xiaoyang Wang, An Empirical Study of Harness Design for Coding Agents, arXiv, 17 settembre 2026, arxiv.org/abs/2609.20804; Haichuan Hu, Quanjun Zhang e colleghi, Beyond the Model: Demystifying Harness Effects in Software Engineering Agents, arXiv, 26 settembre 2026, arxiv.org/abs/2609.32459.

Nel Paithon Book: «Harness engineering: tutto ciò che non è il modello», sulla coppia di modello e harness e su come si misura un componente, e «Lavorare a turni: il passaggio di consegne», su compattare o ripartire da capo.