OpenAI DevDay 2026: il punto per gli sviluppatori

OpenAI DevDay 2026 non è stato il solito evento dedicato ai nuovi modelli. Nel recap del 29 settembre, OpenAI ha messo insieme un modello più economico, un runtime gestito per gli agenti, ambienti di sviluppo nel cloud e un agente consumer sempre attivo. Per chi sviluppa, la novità più importante è architetturale: sempre più elementi del ciclo operativo attorno al modello — sessioni, strumenti, ambienti ed esecuzione in background — vengono spostati dentro prodotti gestiti da OpenAI.

Il verdetto per gli sviluppatori

GPT-6.1 Sol è la novità API più concreta nell’immediato: OpenAI lo identifica come gpt-6.1-sol e ne indica il supporto per Responses API, tool calling, computer use e MCP. Agents API è invece una beta pubblica per costruire agenti gestiti in stile Codex. Codex Cloud trasforma la programmazione asincrona in un flusso di lavoro ospitato. Dots mostra la stessa direzione sul versante consumer, ma non sostituisce un’API per sviluppatori.

La strategia più sensata è partire dai test con Sol e Agents API, usare Codex Cloud quando l’esecuzione remota riduce il lavoro di coordinamento e considerare Dots un segnale di prodotto, non una superficie d’integrazione stabile.

Cosa è stato davvero lanciato e cosa è ancora in distribuzione

Il recap ufficiale di DevDay parla di oltre 20 lanci, ma i quattro più rilevanti per gli sviluppatori non hanno tutti lo stesso livello di disponibilità.

La documentazione del modello di OpenAI è il riferimento da consultare per l’accesso alle API, mentre l’annuncio di Agents API ne definisce lo stato di beta. Nessuna delle due pagine va interpretata come una promessa di quote o disponibilità regionale identiche per ogni account.

GPT-6.1 Sol cambia i costi dei cicli agentici

Nel suo annuncio su GPT-6.1 Sol, OpenAI descrive Sol come un’evoluzione di GPT-6 Sol, capace di avvicinarsi alle prestazioni di Astra nel coding e nel computer use a un costo operativo inferiore. Secondo RuntimeWire, le tariffe pubblicate da OpenAI sono di $2 per milione di token in input, $0.10 per milione di token in input memorizzati nella cache e $10 per milione di token in output. Il contesto ripetuto costa quindi molto meno quando l’applicazione può riutilizzare l’input in cache invece di inviarlo ogni volta da zero.

Questa struttura dei prezzi favorisce i flussi agentici con istruzioni lunghe, tracce degli strumenti o contesto di progetto ripetuto. Non significa però che ogni attività diventi economica: i cicli con molto output, i tentativi ripetuti, le azioni nel browser e i costi degli strumenti esterni possono incidere più del modello. La definizione di OpenAI, “vicino ad Astra”, è un’indicazione qualitativa, non un sostituto dei test sul proprio repository, sugli schemi degli strumenti e sul budget di errore.

Un primo test utile consiste nell’eseguire 20–50 attività rappresentative con Sol e con il modello attualmente usato in produzione, registrando completamenti riusciti, percentuale di correzione delle chiamate agli strumenti, latenza e token totali. In questo modo si vede se il prezzo più basso dei token regge anche dopo i costi reali dell’orchestrazione.

Agents API: dalle chiamate al modello all’esecuzione gestita

Agents API è l’annuncio più importante per gli sviluppatori perché non riguarda soltanto la scelta del modello. OpenAI lo descrive come un harness Codex gestito che si occupa di sessioni, orchestrazione, compattazione del contesto e recupero dagli errori, mentre agli sviluppatori spetta fornire strumenti e ambienti di esecuzione.

L’annuncio della beta pubblica e la copertura del lancio parlano di esecuzione del codice, modifica dei file, connessioni MCP, delega ad altri agenti e computer use tramite un browser ospitato da OpenAI. L’API punta quindi al runtime che circonda un agente, non a una semplice chiamata responses.create con un system prompt più lungo.

L’applicazione continua a essere responsabile di autenticazione, permessi di business, progettazione degli strumenti, policy di approvazione, osservabilità, allowlist dei domini, conferma delle azioni sensibili, audit log e casi di errore riproducibili. Il computer use ospitato può ridurre l’infrastruttura necessaria per il browser, ma non elimina nessuno di questi controlli.

“Ci sono novità sulle prestazioni di Sol 6.1 rispetto a Opus 5.5?” — u/Ashamed-Subject-8573, in una discussione su r/codex

La domanda fotografa bene la distanza tra il keynote e l’adozione in produzione. Agli sviluppatori interessano il comportamento del modello effettivamente servito, l’affidabilità degli strumenti e i costi sul proprio carico di lavoro, non soltanto il confronto presentato nei titoli. Agents API va quindi trattato come un runtime beta da valutare, non come la prova che ogni applicazione agentica debba passare allo stack gestito di OpenAI.

Codex Cloud porta il runtime dentro il prodotto

Codex Cloud estende gli agenti di coding oltre il terminale aperto sul computer dello sviluppatore. La copertura del lancio descrive ambienti riutilizzabili che includono repository, dipendenze, strumenti e impostazioni di accesso del progetto. Le attività possono essere eseguite da remoto su desktop, web o mobile, permettendo di riprendere il lavoro anche dopo aver chiuso il portatile.

L’impatto è soprattutto operativo:

1. Le attività lunghe diventano asincrone. Una code review, la correzione dei test o una migrazione possono proseguire senza mantenere aperta una sessione locale.
2. La configurazione dell’ambiente diventa condivisibile. I team possono definire uno spazio di lavoro approvato invece di reinstallare le dipendenze per ogni attività.
3. Il passaggio di consegne tra persone e agenti è più semplice. Lo sviluppatore può controllare le differenze, riprendere una sessione e decidere cosa unire al progetto.
4. La sicurezza diventa un tema di deployment. Accesso ai repository, segreti, traffico in uscita e identità cloud richiedono policy esplicite.

Il recap di DevDay di OpenAI e lo stesso elenco dei prodotti includono anche una vista degli agenti per Codex CLI, controlli vocali, code review desktop e Codex Security Cloud per i repository GitHub collegati. Nel complesso, Codex assomiglia sempre meno a un sistema di completamento automatico e sempre più a un livello remoto per le operazioni di engineering.

Codex Cloud non sostituisce automaticamente l’ambiente di sviluppo locale. I team devono comunque verificare il supporto ai repository, l’installazione delle dipendenze, l’accesso alla rete, la gestione dei segreti, la durata delle sessioni e la possibilità di recuperare uno spazio di lavoro riproducibile dopo un errore. Conviene iniziare da attività di manutenzione a basso rischio, prima di delegare migrazioni in produzione o modifiche critiche per il rilascio.

Dots è la dimostrazione consumer, non l’API per sviluppatori

Dots mostra la direzione verso cui OpenAI vuole portare i prodotti agentici: un assistente sempre attivo, con un computer nel cloud, applicazioni collegate, contesto persistente e attività in background. L’annuncio di Dots e la documentazione sui workspace descrivono servizi collegati e accesso controllato, mentre la copertura del lancio segnala percorsi tramite ChatGPT, Slack e Microsoft Teams nei piani e nei mercati idonei.

Per gli sviluppatori, Dots indica il passaggio dalla semplice interazione turno per turno alla delega, ma lascia aperte domande importanti su autonomia e privacy. La documentazione sui workspace di OpenAI conferma che l’accesso dipende dalle impostazioni del workspace e del piano; la copertura del lancio riporta percorsi tramite ChatGPT, Slack e Microsoft Teams nei mercati idonei. Dots non è il contratto per gli sviluppatori: prima di scegliere un agente ospitato, bisogna confrontare controllo, posizione dei dati, permessi degli strumenti, auditabilità e costi di uscita con Agents API.

Una sequenza pratica per l’adozione nei team di engineering

I quattro lanci si prestano a un ordine di valutazione piuttosto chiaro:

1. Misurate GPT-6.1 Sol su attività reali. Usate task dal repository, chiamate strutturate agli strumenti e contesto rappresentativo. Nel modello dei costi includete anche le ipotesi sull’input in cache.
2. Costruite un workflow ristretto con Agents API. Scegliete un’attività reversibile, come il triage delle issue, la diagnosi dei test o gli aggiornamenti della documentazione. Inserite blocchi di approvazione prima di ampliare i permessi.
3. Spostate selettivamente il coding asincrono su Codex Cloud. Testate prima un ambiente riutilizzabile con repository non sensibili, poi documentate i controlli su segreti e rete.
4. Usate Dots come segnale per la ricerca di prodotto. Monitoratene permessi, integrazioni e disponibilità, ma non fatene una dipendenza dell’architettura applicativa.
5. Mantenete un livello di portabilità. Conservate definizioni degli strumenti, prompt, casi di valutazione e logica di approvazione nel vostro repository, così da poter sostituire un’API in anteprima se limiti o comportamento dovessero cambiare.

Sol ha una voce dedicata nel catalogo dei modelli API e prezzi pubblicati; Agents API è esplicitamente in beta pubblica; Codex Cloud è un workflow ospitato con diversi aspetti operativi ancora da chiarire; Dots resta la base meno adatta per definire un contratto per sviluppatori.

FAQ

GPT-6.1 Sol è disponibile via API?

Sì. La pagina del modello per sviluppatori di OpenAI indica gpt-6.1-sol per l’uso via API, incluso il supporto a Responses API e alle funzionalità orientate agli strumenti. Accesso e limiti possono variare in base all’account e alla distribuzione.

Agents API è generalmente disponibile?

No. OpenAI ha annunciato Agents API come beta pubblica. Prima di usarla per azioni irreversibili in produzione, predisponete valutazione, logging e un percorso alternativo.

Dots è un’API che gli sviluppatori possono chiamare?

No. Dots è un prodotto agentico di OpenAI con una propria distribuzione e regole legate al piano. Agents API è la superficie per sviluppatori rilevante per costruire agenti gestiti.

Codex Cloud sostituisce un ambiente di sviluppo locale?

Non per impostazione predefinita. Aggiunge esecuzione remota e ambienti riutilizzabili, ma i team devono verificare accesso ai repository, dipendenze, segreti, policy di rete, persistenza e workflow di revisione.

Cosa devono verificare i team prima di spostare attività in produzione?

Bisogna verificare il modello effettivamente servito, il prezzo considerando retry e chiamate agli strumenti, la gestione dei dati, i confini dei permessi, il recupero dagli errori, l’osservabilità, la disponibilità regionale e un percorso di uscita nel caso in cui una funzionalità beta cambi.

Il compromesso che gli sviluppatori non devono ignorare

Il compromesso è chiaro: sessioni e browser gestiti riducono il lavoro infrastrutturale, mentre i runtime gestiti internamente offrono più controllo su dati, credenziali, debugging e cambiamenti del modello. Partite da Sol e Agents API, poi usate Codex Cloud solo dove il vantaggio operativo è evidente.