GPT-6.1 Sol su WordPress: guida al cambio

Cosa ha annunciato OpenAI il 29 settembre

Al DevDay del 29 settembre 2026 OpenAI ha presentato GPT-6.1 Sol, un aggiornamento di GPT-6 Sol uscito appena una settimana prima, il 22 settembre. I dati che servono per decidere sono pochi:

• Nome nell’API: gpt-6.1-sol, disponibile da subito per gli sviluppatori.
• Prezzo standard: 2 dollari per milione di token in input, 0,10 per l’input in cache (sconto del 95%), 10 per l’output.
• Rapporto con Astra: un quinto dei prezzi standard di Astra per input e output, secondo OpenAI.
• Rapporto con GPT-6 Sol: stesso prezzo. Il listino di GPT-6 Sol era già 2 e 10 dollari, dopo il dimezzamento annunciato il 22 settembre.
• ChatGPT: disponibile in ChatGPT Work e Codex per i piani Plus, Pro, Business, Enterprise ed Edu, non ancora in Chat.

Da qui escono due situazioni diverse. Chi oggi usa GPT-6 Sol riceve un modello più capace allo stesso prezzo: il motivo per cambiare è la qualità, non il costo. Chi usa Astra ha davanti un risparmio dell’80% sui token, e il motivo per cambiare è il costo, con un rischio sulla qualità da misurare. La procedura è la stessa, ma cambia la domanda a cui il test deve rispondere.

Vicino ad Astra non vuol dire uguale

I benchmark pubblicati da OpenAI dicono dove il divario si è chiuso e dove resta. Li riporto perché aiutano a capire quali automazioni spostare per prime:

• Programmazione (DeepSWE v1.1): GPT-6.1 Sol eguaglia Astra a circa un quinto del costo.
• Flussi di lavoro aziendali (AutomationBench, 47 strumenti fra vendite, marketing, assistenza e finanza): supera GPT-6 Sol di 4,8 punti con ragionamento medio.
• Uso del computer (OSWorld 2.0): resta a 2,1 punti da Astra al massimo sforzo di ragionamento, a circa un settimo del costo per attività.
• Ricerca scientifica (Terminal-Bench Science): Astra resta il migliore con il 68,1%, e OpenAI stessa lo indica per i compiti più difficili.
• Accuratezza fattuale: con ragionamento molto alto, 4,1% di risposte con almeno un errore, contro il 4,5% di GPT-6 Sol e il 4,0% di Astra.

Due avvertenze che OpenAI scrive nella stessa pagina. I test di accuratezza usano conversazioni in cui gli utenti avevano già segnalato un errore, quindi prompt scelti apposta per essere difficili e “non rappresentativi dell’uso tipico”. E le valutazioni girano nell’ambiente di ricerca di OpenAI, con prompt di sistema e strumenti diversi da quelli di ChatGPT in produzione, e a maggior ragione dai tuoi.

La mia lettura: per le automazioni tipiche di una PMI su WordPress, cioè testi descrittivi, classificazione di richieste, estrazione di dati da email o PDF, riassunti, il candidato naturale è GPT-6.1 Sol. Astra resta giustificato dove un errore costa più della differenza di prezzo, oppure dove il tuo test dimostra che Sol sbaglia più spesso sui tuoi dati.

Passo 1: l’inventario delle chiamate

Prima di cambiare modello bisogna sapere dove è scritto. Su un sito con qualche anno di lavoro sopra, il nome del modello di solito compare in tre o quattro posti diversi: un plugin su misura, uno snippet in functions.php, un mu-plugin, le impostazioni di un plugin commerciale, un nodo di n8n. Se ne cambi uno solo, ti ritrovi con due modelli in produzione senza saperlo.

Dalla root di WordPress, via SSH, questo comando elenca ogni occorrenza di un nome di modello GPT nel codice:

grep -rhoE "gpt-[0-9][0-9a-z.-]*" \
  wp-content/plugins wp-content/themes wp-content/mu-plugins \
  --include="*.php" --include="*.js" --include="*.json" \
  | sort | uniq -c | sort -rn

Il codice non basta, perché molti plugin salvano il modello nelle opzioni del database. Con WP-CLI:

wp db search 'gpt-' --all-tables-with-prefix --stats

Per n8n e Make si esportano i workflow in JSON e si cerca la stessa stringa. Il risultato va in una tabella con cinque colonne: dove sta la chiamata, cosa fa, modello attuale, volume mensile stimato, chi si accorge se sbaglia. L’ultima colonna è quella che decide l’ordine della migrazione: prima i compiti dove un errore lo vede subito una persona, per ultimi quelli dove l’output finisce dritto al cliente.

Passo 2: misurare il costo reale, non quello stimato

La stima all’inizio dell’articolo usa numeri tondi. Nella realtà i token variano molto da una chiamata all’altra, i modelli con ragionamento consumano token di ragionamento che si pagano come output, e una parte dell’input può arrivare dalla cache a 0,10 dollari invece di 2, mentre la scrittura in cache ha una tariffa sua. Senza misurare, il confronto fra modelli è un confronto fra ipotesi.

La Responses API restituisce in ogni risposta un oggetto usage con input_tokens, output_tokens e il dettaglio input_tokens_details. Nella guida al prompt caching OpenAI precisa che ogni token di input si paga a una di tre tariffe: normale, in cache (cached_tokens) o di scrittura in cache (cache_write_tokens). Per il costo effettivo servono tutti e tre. Se le tue chiamate passano da una funzione unica, basta registrarli lì.

Questo è lo scheletro che uso: una sola funzione per tutte le chiamate AI del sito, con la chiave API in wp-config.php e il consumo scritto nel log di PHP, che non è raggiungibile dal web.

<?php
/**
 * Chiamata unica alla Responses API di OpenAI.
 * La chiave sta in wp-config.php: define( 'OPENAI_API_KEY', '...' );
 *
 * @param string $task   Nome del compito, es. 'scheda-prodotto'.
 * @param string $input  Testo da inviare al modello.
 * @param string $key    Identificativo stabile dell'elemento (es. ID prodotto).
 * @return string|WP_Error Testo della risposta o errore.
 */
function lr_ai_call( $task, $input, $key ) {
	if ( ! defined( 'OPENAI_API_KEY' ) || ! defined( 'LR_AI_MODEL' ) ) {
		return new WP_Error( 'lr_ai_config', 'OPENAI_API_KEY o LR_AI_MODEL mancanti in wp-config.php' );
	}

	$model = lr_ai_model( $task, $key );

	$response = wp_remote_post(
		'https://api.openai.com/v1/responses',
		array(
			'timeout' => 60,
			'headers' => array(
				'Authorization' => 'Bearer ' . OPENAI_API_KEY,
				'Content-Type'  => 'application/json',
			),
			'body'    => wp_json_encode(
				array(
					'model'     => $model,
					'input'     => $input,
					'reasoning' => array( 'effort' => 'medium' ),
				)
			),
		)
	);

	if ( is_wp_error( $response ) ) {
		return $response;
	}

	$code = wp_remote_retrieve_response_code( $response );
	$data = json_decode( wp_remote_retrieve_body( $response ), true );

	if ( 200 !== $code || ! is_array( $data ) ) {
		return new WP_Error( 'lr_ai_http', 'Risposta API ' . $code, array( 'model' => $model ) );
	}

	// Una riga per chiamata nel log PHP: modello, compito e token consumati.
	$usage = isset( $data['usage'] ) ? $data['usage'] : array();
	error_log(
		'LR_AI_USAGE ' . wp_json_encode(
			array(
				'task'   => $task,
				'model'  => $model,
				'in'     => isset( $usage['input_tokens'] ) ? (int) $usage['input_tokens'] : 0,
				'cached' => isset( $usage['input_tokens_details']['cached_tokens'] ) ? (int) $usage['input_tokens_details']['cached_tokens'] : 0,
				'write'  => isset( $usage['input_tokens_details']['cache_write_tokens'] ) ? (int) $usage['input_tokens_details']['cache_write_tokens'] : 0,
				'out'    => isset( $usage['output_tokens'] ) ? (int) $usage['output_tokens'] : 0,
			)
		)
	);

	return isset( $data['output_text'] ) ? (string) $data['output_text'] : lr_ai_extract_text( $data );
}

Una nota sull’ultima riga. Il campo output_text è una comodità degli SDK ufficiali e non è garantito nel JSON grezzo della risposta HTTP, dove il testo sta dentro l’array output. La funzione lr_ai_extract_text() deve quindi scorrere output, prendere gli elementi di tipo message e concatenare i blocchi di tipo output_text. Eccola:

<?php
/**
 * Estrae il testo dalla risposta grezza della Responses API.
 *
 * @param array $data Risposta JSON decodificata.
 * @return string Testo concatenato dei blocchi output_text.
 */
function lr_ai_extract_text( $data ) {
	$text = '';
	foreach ( (array) ( $data['output'] ?? array() ) as $item ) {
		if ( 'message' !== ( $item['type'] ?? '' ) ) {
			continue;
		}
		foreach ( (array) ( $item['content'] ?? array() ) as $block ) {
			if ( 'output_text' === ( $block['type'] ?? '' ) ) {
				$text .= (string) ( $block['text'] ?? '' );
			}
		}
	}
	return $text;
}

Dopo una settimana di log si ricava il costo per compito con un grep LR_AI_USAGE sul file di log e una somma per modello. È il numero da mettere accanto a quello del test: quanto costa davvero ogni scheda prodotto, ogni ticket, ogni riassunto. Se usi un system prompt lungo e sempre uguale, guarda anche la quota di cached e di write sul totale di input. Per come funziona la cache con GPT-6, e perché l’ordine delle parti del prompt cambia la bolletta, ho scritto una guida a parte sul prompt caching di GPT-6 per WordPress.

Passo 3: un set di prova con i tuoi dati

I benchmark di OpenAI rispondono alla domanda “il modello è capace?”. A te serve la risposta a un’altra: “sui miei casi, sbaglia più o meno di quello che uso oggi?”. Si risponde con un set di prova piccolo, costruito una volta e riusato a ogni nuovo modello. Il metodo completo l’ho descritto in come costruire un test privato dei modelli con dati reali. Qui la versione minima per questa migrazione.

1. Scegli da 30 a 50 casi veri per ogni compito, presi dai log o dagli archivi: prodotti con schede difficili, email ambigue, PDF con tabelle. Almeno un terzo devono essere casi dove il modello attuale ha già sbagliato o dove una persona ha dovuto correggere.
2. Scrivi i criteri di promozione prima di guardare i risultati. Per una scheda prodotto: nessun dato tecnico inventato, misure identiche alla fonte, lunghezza entro il limite, JSON valido se l’output è strutturato. Scriverli dopo vuol dire adattarli a quello che hai visto.
3. Fai girare i due modelli con lo stesso prompt e lo stesso livello di ragionamento. Se confronti Sol con ragionamento alto e Astra con ragionamento basso, stai misurando il ragionamento, non il modello.
4. Valuta alla cieca, se puoi. Chi giudica non deve sapere quale output viene da quale modello. Basta un foglio con le risposte in ordine casuale e una colonna “promosso/bocciato”.
5. Somma costo e bocciature. Per ogni modello: percentuale di casi promossi, costo medio per caso preso dal campo usage, tempo medio di risposta.

La regola di decisione conviene fissarla anche lei in anticipo. La mia: se GPT-6.1 Sol boccia al massimo un caso in più su 50 rispetto al modello attuale, e nessuno di quei casi è un errore grave (un prezzo sbagliato, un dato personale al posto sbagliato, un’azione non richiesta), si passa alla fase successiva. Se boccia di più, quel compito resta dov’è e si riprova al prossimo modello.

Passo 4: il modello in un solo punto, fuori dal codice

Nell’inventario del passo 1 il nome del modello quasi sempre compare scritto a mano dentro le funzioni. È la causa per cui una migrazione diventa un lavoro di giorni: ogni cambio è un deploy, e tornare indietro è un altro deploy. Conviene spostarlo in wp-config.php, con la possibilità di mandare solo una parte del traffico al modello nuovo.

// In wp-config.php
define( 'LR_AI_MODEL', 'gpt-6-astra' );        // modello attuale: copia il nome esatto dal tuo codice
define( 'LR_AI_MODEL_CANARY', 'gpt-6.1-sol' ); // modello in prova
define( 'LR_AI_CANARY_PCT', 10 );             // percentuale di traffico al modello in prova

<?php
/**
 * Sceglie il modello per una chiamata.
 * Lo stesso elemento finisce sempre sullo stesso modello:
 * così un prodotto non alterna due stili di scheda a ogni rigenerazione.
 *
 * @param string $task Nome del compito.
 * @param string $key  Identificativo stabile dell'elemento.
 * @return string Nome del modello.
 */
function lr_ai_model( $task, $key ) {
	$model = LR_AI_MODEL; // lr_ai_call() ha già verificato che sia definita.

	if ( ! defined( 'LR_AI_MODEL_CANARY' ) || ! defined( 'LR_AI_CANARY_PCT' ) ) {
		return $model;
	}

	// Numero stabile fra 0 e 99 ricavato da compito + elemento.
	$bucket = hexdec( substr( md5( $task . '|' . $key ), 0, 8 ) ) % 100;

	$chosen = ( $bucket < (int) LR_AI_CANARY_PCT ) ? LR_AI_MODEL_CANARY : $model;

	// Filtro per escludere dal canary i compiti che non vuoi toccare.
	return apply_filters( 'lr_ai_model', $chosen, $task, $model );
}

Due dettagli che contano. La scelta è deterministica: l’hash di compito ed elemento decide, quindi il prodotto 1234 va sempre sullo stesso modello e i confronti restano puliti. Un rand() avrebbe mischiato i risultati a ogni rigenerazione. E il filtro lr_ai_model permette di tenere fuori dal canary un compito specifico, per esempio le risposte automatiche ai clienti, con un add_filter che restituisce $model quando $task è quello da proteggere.

Tornare indietro, a questo punto, è una riga: LR_AI_CANARY_PCT a 0. Non serve un deploy, non serve toccare un plugin.

Sul fallback: se il modello in prova fallisce, ripeti con LR_AI_MODEL solo per errori di rete e codici 5xx, non per i 4xx, che di solito indicano una richiesta sbagliata. E conta i fallback nel log: un modello in prova che ne ha bisogno spesso non è pronto.

Passo 5: il canary in produzione

Il set di prova dice se il modello regge sui casi scelti da te. La produzione porta i casi che non avevi previsto. Per questo il passaggio successivo è mandare il 10% del traffico reale a GPT-6.1 Sol per una settimana, lasciando il resto sul modello attuale.

Durante quella settimana guardo quattro numeri, separati per modello:

• Tasso di correzione umana: quante schede, risposte o riassunti una persona ha dovuto modificare prima di pubblicarli. Se hai un flusso con approvazione, è il numero più affidabile.
• Output strutturati non validi: JSON che non si decodifica, campi mancanti, valori fuori dallo schema. Si contano nel codice che riceve la risposta.
• Fallback e ripetizioni: quante chiamate sono state ripetute o dirottate sul modello attuale.
• Costo per compito: la somma dei token dal log del passo 2, per modello e per compito.

Se dopo sette giorni i primi tre numeri sono in linea con il modello attuale, la quota sale al 50% per un’altra settimana, poi al 100%. Se uno dei tre peggiora, si torna a zero e si guarda quali casi hanno fatto la differenza: quasi sempre sono una categoria precisa (le schede con varianti, le email in tedesco, i PDF scansionati) che si può tenere sul modello vecchio con il filtro, spostando tutto il resto.

Con 3.000 chiamate al mese, il 10% per una settimana sono circa 70 casi: pochi, ma bastano a far emergere gli errori sistematici. Per un sito con 200 chiamate al mese il canary al 10% non dà numeri leggibili in tempi ragionevoli: meglio saltarlo, allargare il set di prova a 80-100 casi e passare direttamente, con il ritorno indietro a portata di mano.

Gli agenti con permessi: qui il modello conta meno delle regole

Fin qui ho parlato di compiti dove il modello produce testo e una persona o il codice lo controlla. Con gli agenti che agiscono, cioè che modificano ordini, inviano email, aggiornano prodotti o chiamano altri servizi, la scelta del modello è solo una parte del rischio.

OpenAI pubblica, nella stessa pagina di GPT-6.1 Sol, alcuni test sul comportamento degli agenti. Uno misura quante volte un agente non avvisa l’utente quando lo strumento di ricerca è guasto, e risponde invece con quello che ritiene plausibile. Con ragionamento al massimo, GPT-6.1 Sol lo fa nel 2,1% dei casi, Astra nell’1,5%, GPT-6 Sol nel 4,9%, GPT-6 Luna nel 28,7%. Anche qui sono compiti scelti per far emergere gli errori. Il dato su Luna però è da tenere a mente per chi usa il modello più economico dentro agenti con strumenti: su quel test, più di un caso su quattro finisce con la risposta che il modello ritiene più plausibile al posto di un errore dichiarato.

C’è poi un fatto di contorno. Secondo quanto riportato da TechCrunch, che cita il Wall Street Journal, OpenAI ha rinunciato a rilasciare GPT-6.1 Astra dopo che nei test interni il modello aveva mostrato più inganno e la tendenza a procedere senza chiedere il permesso all’utente. Non è una notizia confermata da OpenAI nei suoi annunci, e la riporto come tale.

La conseguenza pratica non cambia con il modello. Un agente che può spendere soldi, scrivere al cliente o cancellare dati deve avere un’approvazione umana sui passaggi irreversibili e un budget massimo scritto nel codice, non nel prompt. Ne ho parlato nella guida sugli agenti AI con pagamenti, budget e approvazione. Nella migrazione a GPT-6.1 Sol, questi agenti vanno spostati per ultimi, e con le stesse regole di prima.

La mia take: il modello economico diventa la scelta predefinita

Fino a qualche mese fa, per molte PMI la scelta sensata era usare il modello di punta ovunque e non pensarci: i volumi erano piccoli e la differenza di costo non valeva il tempo di un test. Con GPT-6.1 Sol a un quinto di Astra e prestazioni vicine, il ragionamento si rovescia. Il modello di fascia media diventa quello predefinito, e il modello di punta va giustificato compito per compito, con un test che dimostri che serve. È la stessa logica che avevo proposto nel confronto fra modelli di punta e modelli medi per le automazioni WordPress, e adesso il divario di prezzo la rende difficile da ignorare.

La seconda cosa che questa uscita mostra è il ritmo. GPT-6 Sol è uscito il 22 settembre, GPT-6.1 Sol il 29. Due versioni dello stesso modello in sette giorni. Chi ha il nome del modello sparso in cinque file e nessun set di prova rifà ogni volta lo stesso lavoro da zero, oppure non migra mai e paga di più. Chi ha fatto i passi 2, 3 e 4 una volta, alla prossima uscita cambia una costante, lancia il test e guarda due numeri. L’investimento che resta è l’infrastruttura che rende economica anche la prossima migrazione.

Vale anche al contrario. Un set di prova e un modello configurabile sono anche il piano B se un giorno vuoi o devi cambiare fornitore, un tema che ho trattato nella guida sul lock-in dei modelli AI e il piano B nei contratti. Il codice dei passi 2 e 4 funziona con qualsiasi API compatibile con la Responses API, cambiando endpoint e chiave.

Se hai dieci minuti: la checklist

1. Cerca il nome del modello in codice, database e workflow, e fai la tabella con volume e impatto dell’errore.
2. Porta tutte le chiamate in una funzione unica che registra input_tokens, cached_tokens, cache_write_tokens e output_tokens.
3. Costruisci un set di prova da 30-50 casi reali per compito, con i criteri scritti prima.
4. Confronta i due modelli con lo stesso prompt e lo stesso livello di ragionamento, alla cieca.
5. Sposta il nome del modello in wp-config.php con quota di canary e filtro per compito.
6. Manda il 10% del traffico a GPT-6.1 Sol per una settimana e controlla correzioni, JSON non validi, fallback e costo.
7. Sposta per ultimi gli agenti con permessi, con approvazione umana e budget nel codice.

Fonti

• OpenAI: Introducing GPT-6.1 Sol (29 settembre 2026)
• OpenAI: Introducing GPT-6 Sol and Luna (22 settembre 2026)
• OpenAI: DevDay 2026 Recap
• OpenAI API: Prompt caching
• OpenAI API: Reasoning models e parametro reasoning.effort
• OpenAI API Reference: Responses
• TechCrunch: OpenAI launches GPT-6.1 Sol (29 settembre 2026)