Claude Opus 4.5 vs Claude Sonnet 4.5: quando pagare di più per correggere i problemi di codice e quando non serve

La decisione non è quale modello sembri migliore, ma quale problema risolva al minor costo totale

Confrontare Claude Opus 4.5 e Claude Sonnet 4.5 per la manutenzione software richiede di delimitare la domanda. Il prezzo per token, una dimostrazione isolata o un risultato di benchmark non rispondono da soli a quale opzione convenga a un team. L'unità decisionale deve essere il problema correttamente risolto e accettato: una modifica che riproduce il contesto del difetto, supera i test mirati e di regressione, non estende indebitamente l'ambito e richiede una revisione umana ragionevole.

In questo confronto, un sovrapprezzo per Opus 4.5 sarebbe giustificato solo se si traducesse in un risultato operativo misurabile. Potrebbe trattarsi di un tasso più alto di risoluzioni complete, meno regressioni, meno iterazioni da parte di un ingegnere o un tempo inferiore per ottenere una patch accettabile. Se Sonnet 4.5 raggiunge le stesse soglie di accettazione a un costo minore, pagare di più non apporta necessariamente valore per quel tipo di ticket.

L'analisi deve separare il costo dell'inferenza dal costo del lavoro. Un modello economico che genera patch incomplete, costringe a eseguire il debug della propria diagnosi o produce modifiche fuori ambito può risultare più costoso dopo aver sommato tentativi ripetuti, esecuzione degli strumenti e revisione. Al contrario, un modello con una tariffa più alta non deve ricevere merito per una patch apparentemente plausibile che non supera una batteria di test rappresentativa.

Questo articolo non dichiara un vincitore assoluto. Propone una prova locale che consenta a responsabili di ingegneria, team di piattaforma IA e acquirenti di decidere sulla base delle proprie evidenze. È inoltre compatibile con l'indice dei confronti, con le schede di Claude Opus 4.5 e Claude Sonnet 4.5 e con le informazioni di Anthropic sui modelli e sui relativi canali di accesso.

Prepara un corpus congelato e riproducibile prima di eseguire i modelli

La prova inizia dal corpus, non dal prompt. Ogni problema deve essere associato a un repository, a un commit di base immutabile, a un ambiente di esecuzione e a una definizione verificabile del difetto. Conserva il ticket originale, ma redigi una versione del compito che elimini le informazioni successive al momento che si vuole simulare, come il collegamento alla correzione già nota o commenti che rivelano la soluzione.

Per ogni caso, crea una riproduzione minima che fallisca sul commit di base e una batteria che consenta di verificare la correzione. La valutazione deve distinguere una modifica cosmetica da una correzione funzionale. Una pratica solida consiste nel definire test che avrebbero dovuto fallire prima della correzione e test che già passavano e devono continuare a passare. Questo approccio coincide con la logica di validazione impiegata per distinguere risoluzione e regressione in SWE-bench Verified, anche se i risultati di un corpus interno non devono essere mescolati a quelli di quel benchmark.

SWE-bench è un utile riferimento metodologico, non un sostituto del corpus locale. Il lavoro originale descrive un insieme di problemi estratti da repository Python reali; ciò aiuta a comprendere le esigenze di un compito di modifica del repository. Tuttavia, la distribuzione di linguaggi, dipendenze, anzianità dei problemi e regole di valutazione può differire da quella del team. Un risultato interno deve essere pubblicato come risultato interno.

Escludi i ticket senza una riproduzione ragionevolmente stabile, le modifiche che dipendono da servizi esterni non controllati, le vulnerabilità che richiedono una procedura specifica di divulgazione e i compiti il cui criterio di accettazione sia puramente soggettivo. Registrare queste esclusioni evita che il campione finale sembri più rappresentativo di quanto non sia.

Mantieni condizioni equivalenti, ma non presumere che equivalente significhi identico

Registra l'identificatore esatto di ogni modello, la data e l'ora di esecuzione, il canale di accesso, la regione o l'endpoint, il fornitore dell'infrastruttura, la configurazione del contesto e gli strumenti concessi. Per Opus 4.5, la documentazione di Anthropic identifica il modello API claude-opus-4-5-20251101. La documentazione sul ciclo di vita dei modelli va consultata all'inizio di ogni campagna per confermare che entrambi gli identificatori siano ancora attivi e per prevedere eventuali ritiri.

L'annuncio di Sonnet 4.5 documenta il suo accesso tramite API e il prezzo di lancio per input e output. Questo dato non basta per calcolare un costo definitivo: la fatturazione può dipendere dal canale, dall'uso della cache, dalla regione, dagli strumenti e dalle condizioni commerciali in vigore. In Amazon Bedrock, per esempio, la documentazione del fornitore descrive differenze tra endpoint globali e regionali, oltre a condizioni specifiche di disponibilità. Non confrontare un'esecuzione regionale di un modello con un'esecuzione globale dell'altro senza dichiarare la differenza.

Usa lo stesso prompt di sistema, la stessa descrizione del compito, lo stesso formato della risposta, la stessa directory di lavoro, gli stessi permessi di lettura e scrittura, comandi autorizzati, accesso di rete e limite di iterazioni. Se un modello dispone di una modalità o capacità che l'altro non possiede nel canale scelto, non trattarla come una prova strettamente equivalente. Puoi misurarla come scenario operativo separato, ma devi etichettarla come tale.

Devono essere fissate anche la politica di ritentativi e le soglie. Un ritentativo dopo un errore transitorio dell'infrastruttura può essere ragionevole; molteplici riavvii perché il primo risultato era scarso cambiano l'intervento disponibile. La regola deve applicarsi a entrambi i modelli e tutti i tentativi fatturabili devono essere conteggiati.

Separa i ticket per difficoltà e per meccanismo di guasto

Una media globale può nascondere l'informazione che determina davvero l'acquisto. Classifica i casi prima di eseguire i modelli. Un primo strato può riunire correzioni localizzate: una validazione errata, una condizione limite o una trasformazione di dati circoscritta a uno o pochi file. Sono compiti in cui un modello più economico può raggiungere rapidamente la soglia di accettazione.

Un secondo strato deve includere difetti che richiedono di tracciare dipendenze tra moduli. Per esempio, una modifica di un'interfaccia interna che rompe serializzazione, validazione e consumatori remoti, oppure un difetto in cui il sintomo compare in un livello diverso dalla causa. Qui è ragionevole indagare se una maggiore capacità di pianificazione o esplorazione riduca le iterazioni, ma il risultato deve essere misurato e non dedotto dalla categoria del modello.

Il terzo strato corrisponde a problemi ambigui o difficili da riprodurre. Possono coinvolgere concorrenza, stato condiviso, configurazioni particolari o requisiti incompleti. L'obiettivo non è premiare una spiegazione lunga: è verificare se il modello formula ipotesi verificabili, ottiene evidenze con gli strumenti consentiti e limita la modifica alla causa meglio supportata.

Etichetta inoltre linguaggio, dimensione del repository, superficie modificata, tipo di test e presenza di dipendenze esterne. Queste etichette consentono di capire se una differenza deriva dalla difficoltà reale oppure da una concentrazione casuale di ticket in un linguaggio o modulo.

Definisci il successo completo prima di vedere i risultati

Il criterio di successo deve combinare validazione automatica e revisione umana. Classifica come successo completo soltanto una patch che superi i test mirati, mantenga i test di regressione pertinenti e rispetti la rubrica relativa all'ambito. Se il repository dispone di test estesi praticabili entro il budget, eseguili; altrimenti dichiara quale copertura è rimasta esclusa e perché.

La revisione umana deve essere in cieco rispetto al modello. Fornisci ai revisori il diff, la diagnosi prodotta, i risultati dei test e il ticket, ma non il nome del modello né il costo. Richiedi una decisione definita: accettare, accettare con modifiche minori, rifiutare per correzione incompleta, rifiutare per regressione, rifiutare per ambito eccessivo o un'altra categoria specificata in precedenza.

È opportuno conservare la categoria di successo parziale, senza però usarla per gonfiare il tasso di risoluzione. Una patch che individua correttamente il componente interessato ma fallisce una condizione limite può essere utile per valutare la qualità della diagnosi. Non equivale a un problema risolto. Analogamente, una correzione corretta che modifica file estranei senza giustificazione può richiedere un intervento tale da non poter essere conteggiata come successo completo.

Le istruzioni di revisione devono vietare l'accettazione di modifiche che disattivino test, riducano asserzioni o introducano eccezioni generiche soltanto per far scomparire un errore. Devono inoltre indicare che un nuovo test, da solo, non dimostra che l'implementazione sia corretta.

Misura costi, intervento e tempo end-to-end

La metrica principale può essere espressa come costo totale del lotto diviso per il numero di successi completi accettati. Nel numeratore includi input, output, cache e qualsiasi voce fatturabile applicabile al canale. Aggiungi ritentativi, chiamate fallite, utilizzo degli strumenti quando ha un costo e tempo umano di revisione o correzione, se l'obiettivo è decidere il costo operativo e non soltanto il costo API.

Riporta anche il tasso di successo completo, il tasso di successo parziale, le regressioni rilevate, il numero di interventi umani e la latenza end-to-end. La latenza non equivale necessariamente al tempo del modello: un agente può attendere strumenti, ripetere test o bloccare risorse di integrazione continua. Registra separatamente, quando possibile, il tempo di inferenza, quello degli strumenti e quello umano.

Per valutare la diagnosi, usa una rubrica semplice: identificazione dei sintomi, ipotesi causale, evidenze raccolte, spiegazione della modifica e limiti noti. Una diagnosi può essere utile anche in caso di fallimento, ma deve essere valutata senza confondere la qualità narrativa con la correttezza. Il punteggio deve avere esempi di riferimento e, se ci sono più revisori, una regola per risolvere i disaccordi.

Riporta distribuzioni e risultati per strato, non soltanto medie. Un numero ridotto di problemi complessi può dominare il costo medio. Ripeti inoltre una parte o l'intero lotto: la variabilità tra esecuzioni può cambiare la conclusione se la differenza tra i modelli è piccola.

Interpreta il sovrapprezzo di Opus 4.5 tramite soglie, non tramite il prestigio del modello

Opus 4.5 giustificherebbe un sovrapprezzo in uno specifico strato se il suo miglioramento nelle risoluzioni complete compensasse i costi aggiuntivi e la revisione evitata. Ciò potrebbe verificarsi per problemi con relazioni tra moduli, diagnosi ambigue o cicli di test costosi, ma è un'ipotesi che l'esperimento deve confermare. Il confronto deve mostrare quanti casi aggiuntivi vengono accettati dalla revisione e quale costo umano non è più necessario.

Sonnet 4.5 raggiunge la soglia operativa quando soddisfa il tasso di accettazione, il limite di regressioni, la scadenza e il costo definiti dal team. Nelle correzioni localizzate, la decisione può favorirlo anche se Opus ottiene un punteggio medio maggiore, qualora la differenza non riduca un costo rilevante. Nei compiti più difficili, il risultato può essere misto: Sonnet per triage e correzioni circoscritte, Opus per una coda definita di problemi che supera un criterio di complessità.

Non trasformare la segmentazione in una regola basata soltanto sull'intuizione. Una politica iniziale può usare segnali quali il numero di moduli interessati, l'assenza di una riproduzione chiara o la necessità di analizzare tracce estese. Successivamente va validata rispetto ai risultati. Se tali segnali non predicono un miglioramento sufficiente con Opus, aggiungono complessità senza migliorare la decisione.

Gli annunci e le schede tecniche del fornitore possono fornire informazioni su disponibilità, configurazione e valutazioni interne. Non sostituiscono questa prova, perché strumenti, repository, prompt, budget e definizione di successo potrebbero non coincidere con quelli del tuo team.

Applica un'analisi di sensibilità e dichiara i limiti

Ripeti il confronto con budget di iterazione diversi, limiti di contesto e permessi degli strumenti ristretti. Un risultato che dipende da un budget molto alto potrebbe non essere applicabile a un'operazione con limiti rigidi. Allo stesso modo, un vantaggio osservato con accesso di rete o con uno strumento proprietario non deve essere attribuito soltanto al modello.

Non aggregare i risultati di SWE-bench Verified, Terminal-Bench o altre valutazioni al risultato interno. È lecito presentarli come contesto metodologico se si identifica la differenza di corpus e harness, ma non come righe confrontabili della stessa tabella. Cambiare test, politica degli strumenti o definizione di accettazione cambia il compito misurato.

Questa prova non dimostra nemmeno la sicurezza del codice, l'autorizzazione al deployment, la capacità di manutenzione continua né le prestazioni in tutti i linguaggi. Una patch accettata in un ambiente isolato può introdurre rischi non coperti dall'insieme di test. La decisione di produzione deve mantenere controlli di revisione, integrazione continua e gestione delle modifiche.

Infine, documenta i casi persi: ticket esclusi, errori dell'infrastruttura, revisioni senza consenso e test instabili. Nasconderli può far apparire la conclusione più solida di quanto sia realmente. La trasparenza è particolarmente importante se la differenza di costo o accettazione tra i due modelli è ridotta.

Modello finale per prendere una decisione ripetibile

Prima di scegliere, definisci per iscritto l'obiettivo: per esempio, ridurre il costo per correzione accettata di problemi di manutenzione senza superare un limite di regressioni né di tempo di revisione. Quindi esegui entrambi i modelli sullo stesso lotto congelato e pubblica parametri sufficienti per ripetere il calcolo internamente.

La conclusione deve assumere una forma condizionale. Per esempio: Sonnet 4.5 è l'opzione predefinita per lo strato localizzato perché raggiunge la soglia di accettazione con un costo totale inferiore; Opus 4.5 è riservato allo strato intermodulare se la ripetizione conferma una riduzione sufficiente dei rifiuti o dell'intervento umano. Se la differenza non persiste dopo aver ripetuto il lotto, la conclusione responsabile è che non vi sono evidenze sufficienti per pagare un sovrapprezzo in quell'ambiente.

Rivedi la decisione quando cambiano gli identificatori dei modelli, i prezzi applicabili, il canale, gli strumenti disponibili o la composizione della coda dei problemi. Una valutazione riproducibile non è un acquisto una tantum: è un controllo periodico su una decisione che dipende da sistemi e condizioni in evoluzione.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.