Benchmark degli agenti di codice: l’impatto del runtime

Quattro sessioni di agenti di codice hanno ricevuto lo stesso repository e lo stesso incarico generale. Ogni sessione ha prodotto una modifica e superato i test mirati. La durata end-to-end variava comunque da 6:04 a 13:57.

Codex con Luna Max è stata l’esecuzione osservata più breve. DSH con Qwen 3.8 27B è stata la più breve tra quelle locali. Entrambe le configurazioni OpenCode hanno richiesto più tempo, anche se OpenCode Qwen dichiarava il volume totale di token più basso.

La conclusione principale non è quindi una classifica universale dei modelli. Un agente di codice comprende anche istruzioni di sistema, skill, memoria, gestione del contesto, cache, strumenti, gate utente, politica di revisione e verifica finale.

Che cosa misura il benchmark

Le quattro sessioni partivano dallo stesso repository e dallo stesso incarico astratto, ma non erano obbligate a scegliere lo stesso difetto. Le esecuzioni Luna sono arrivate nella stessa area delle flashcard con ambiti diversi. Le due esecuzioni Qwen hanno selezionato altri difetti.

Il test confronta quindi profili runtime completi, non quattro modelli in una condizione controllata con lo stesso patch. Una sessione può durare di più per la generazione, per un maggior numero di azioni degli strumenti, per una revisione indipendente o per compattazione e continuazione del contesto.

Durata e volume di token dichiarato

• Codex · Luna Max: 363,696 secondi, 2,031 milioni di token, 11/11 test mirati.
• DSH · Qwen 3.8 27B: 483,641 secondi, 1,984 milioni di token, 57 chiamate agli strumenti, 14/14 test.
• OpenCode · Luna Max: 773,632 secondi, 2,683 milioni di token, 67 chiamate, 11/11 test.
• OpenCode · Qwen 100K: 836,954 secondi, 1,687 milioni di token, 39 chiamate, 17/17 test.

OpenCode Luna ha richiesto 2,13 volte il tempo di Codex Luna. OpenCode Qwen ha richiesto 1,73 volte il tempo di DSH Qwen. Allo stesso tempo, OpenCode Qwen è stata la sessione più lunga pur dichiarando meno token. Un volume inferiore non è quindi automaticamente un punteggio di velocità o qualità.

Anche gli schemi dei token differiscono. Codex include il reasoning nell’output. OpenCode lo espone separatamente e combina input nuovo e letture cache nel totale del prompt. DSH fornisce totali di prompt e output. I valori normalizzati descrivono un carico di lavoro, non direttamente fattura, energia o limite di abbonamento.

Cache, orchestrazione e revisione

In entrambe le sessioni OpenCode, oltre il 91 per cento del volume lato prompt proveniva dalle letture cache. OpenCode Luna dichiarava 220.630 token di input nuovo e 2.451.456 token di cache; OpenCode Qwen rispettivamente 145.146 e 1.514.973.

DSH Qwen ha usato 36 turni assistente e 57 chiamate agli strumenti. OpenCode Luna ha usato 32 turni e 67 chiamate; OpenCode Qwen 31 turni e 39 chiamate. L’export Codex non esponeva contatori direttamente comparabili, quindi è omesso da questa vista invece di ricevere uno zero fuorviante.

OpenCode Luna ha attivato brainstorming, scrittura del piano, sviluppo guidato dai test, code review e verifica prima del completamento. Il reviewer ha rappresentato circa 299 secondi, cioè il 38,6 per cento della sessione. Questo processo può essere utile per una modifica grande o rischiosa. Per un piccolo fix, il suo costo fisso è diventato una parte sostanziale del tempo totale.

Codex Luna usava le linee guida di Karpathy e una memoria di lavoro precedente. Questi input possono aver favorito una modifica più piccola, ipotesi esplicite e verifica diretta, ma una singola esecuzione non consente di misurarne l’effetto indipendente. Serve un braccio sperimentale skill attive contro skill disattivate.

Quale runtime per quale attività?

• Per un piccolo fix cloud ben delimitato, Codex Luna Max è stato il percorso osservato più breve.
• Per l’esecuzione locale di Qwen, DSH Qwen è stato il runtime più veloce nel test.
• OpenCode resta utile quando portabilità dei provider, pianificazione visibile e un’interfaccia indipendente dal modello contano più del tempo minimo.
• Per un refactoring ampio o una modifica ad alto rischio di regressione, una catena esplicita di pianificazione e revisione può giustificare il sovraccosto.
• Per micro-attività, un profilo più leggero dovrebbe evitare costi di processo fissi, salvo che il rischio richieda gate aggiuntivi.

Limiti e prossimo benchmark

Ogni condizione è stata eseguita una sola volta. Gli agenti non hanno implementato lo stesso patch, gli export dei token usano semantiche diverse e Qwen funzionava localmente mentre Luna usava il cloud. Il numero di test non è una classifica di qualità perché gli ambiti erano differenti.

Un test successivo più solido dovrebbe imporre un solo difetto, un unico test di accettazione, gli stessi strumenti, le stesse istruzioni di sistema e limiti uguali di contesto e timeout. Ogni condizione dovrebbe essere ripetuta almeno tre volte. Per Qwen vanno registrati hardware, quantizzazione, limite di contesto, formato della KV cache e throughput di generazione. Timestamp per ogni fase separerebbero finalmente latenza del modello, strumenti e revisione.

Evidenze e fonti dei marchi

Le misure sono state ricostruite da quattro export conservati: `lunamax-session.jsonl`, `session.jsonl`, `session-ses_fdda.md` e `session-ses_fdd8.md`.

• Organizzazione GitHub ufficiale di OpenAI
• Logo ufficiale DeepSeek nel repository DeepSeek-VL
• Organizzazione GitHub ufficiale di Qwen
• Repository ufficiale di OpenCode