Agents API: OpenAI conferma un bug di fatturazione
Dopo una segnalazione da 1.600 dollari, OpenAI conferma addebiti errati per i container. Distinguo il bug risolto dalla gestione delle sessioni nelle app.

Il 18 settembre 2026 un utente Reddit ha segnalato una fattura da 1.600 dollari per l’Agents API dopo aver lasciato inattive alcune sessioni ospitate. OpenAI ha riconosciuto addebiti eccessivi per i container quel giorno e ha dichiarato risolto l’incidente il 19 settembre. La mia conclusione è verificare gli addebiti inattesi prima di considerarli normali, assegnando comunque a ogni sessione una regola per il rilascio delle risorse. [1] [2]
Che cosa è successo alla fattura da 1.600 dollari segnalata?
La segnalazione ha ricevuto un aggiornamento sostanziale: l’autore ha scritto che OpenAI aveva riconosciuto un problema di fatturazione, aggiungendo poi il link all’incidente ufficiale. Questo cambia il modo in cui leggo l’avvertimento iniziale. È un motivo per indagare un addebito errato, non un esempio affidabile di quanto costino normalmente le sessioni inattive. [1] [2]
L’utente descriveva attività ricorrenti che duravano circa cinque minuti e costavano intorno a 0,20 dollari di utilizzo del modello dopo il passaggio a Luna. Aveva creato 138 sessioni e le conservava come archivio del lavoro precedente. Secondo il post, la spesa visualizzata era poi salita oltre 200 dollari e quindi a 1.600. Importi, tempi e dettagli del carico di lavoro restano quelli riferiti dall’autore. [2]
La pagina di stato di OpenAI conferma in modo indipendente l’incidente più ampio. Il 18 settembre l’azienda ha annunciato un’indagine su costi inaspettatamente alti per i container ospitati, dichiarando di preparare i rimborsi. Il 19 settembre ha comunicato un intervento per proteggere le nuove sessioni, poi ha dichiarato risolto l’incidente. L’avviso non conferma l’importo esatto della fattura di questo utente né l’avvenuto rimborso. [1]
Per chi sta valutando quali responsabilità assume l’Agents API, la distinzione conta. Una fattura errata può far sembrare insostenibile un servizio anche quando il prezzo previsto è diverso. Conserverei gli identificativi delle sessioni e i dati di fatturazione prima di decidere se riprogettare il carico di lavoro.
Quanto costa normalmente una sandbox ospitata?
OpenAI documenta due addebiti separati: l’utilizzo di token del modello e le tariffe del container della sandbox ospitata. Guardare soltanto il contatore dei token lascia quindi fuori una parte del costo del compito. La guida agli ambienti ospitati rimanda esplicitamente al listino standard dei container. [3]
Il 22 settembre 2026 ho verificato il listino, che riportava gli importi seguenti. La seconda colonna conserva l’unità di 20 minuti; nell’ultima ho diviso gli importi per 20, senza voler dire che ogni sessione venga fatturata al minuto. [4]
Tariffe pubblicate dei container, verificate il 22 settembre 2026. Gli equivalenti al minuto sono calcolati ed escludono i costi del modello e degli altri strumenti. [4]
| Memoria del container | Prezzo in USD per 20 minuti | Equivalente in USD al minuto |
|---|---|---|
| 1 GB | 0,03 $ | 0,0015 $ |
| 4 GB | 0,12 $ | 0,006 $ |
| 16 GB | 0,48 $ | 0,024 $ |
| 64 GB | 1,92 $ | 0,096 $ |
La nota specifica che le sessioni dei container che soddisfano i requisiti vengono fatturate al minuto, con un minimo di cinque minuti. La pagina dei prezzi non definisce i criteri di idoneità né precisa come venga conteggiato ogni periodo di inattività. Verificherei questi dettagli per il carico di lavoro effettivo prima di usare la tariffa equivalente in una stima. Il solo listino non permette di ricostruire la fattura segnalata su Reddit. [4]
È una questione diversa dai limiti di utilizzo di cinque ore negli abbonamenti Codex. La quota di un abbonamento regola l’utilizzo incluso; un’applicazione basata sull’API deve tenere conto delle risorse che crea. Confondere i due aspetti rende più difficile capire entrambi.
Completare un compito libera anche la sandbox?
Completare il compito e rilasciare le risorse della sandbox sono due passaggi separati. OpenAI spiega che le sandbox connesse ricevono segnali di keep-alive tra un turno e l’altro e possono scadere dopo un’ora senza attività né keep-alive. Quell’ora non garantisce quindi che ogni compito completato perda la propria sandbox esattamente 60 minuti dopo. [3]
L’azione documentata per liberare le risorse è eliminare la sessione quando non serve più. Una risposta 409 può indicare che la configurazione o l’esecuzione è ancora in fase di completamento; OpenAI consiglia di aspettare e riprovare, con un numero massimo di tentativi. L’eliminazione della sessione rimuove la risorsa dall’API, mentre il rilascio effettivo delle risorse può proseguire in modo asincrono. [3] [5]
L’annullamento ha un altro scopo: interrompe un turno attivo conservando la conversazione e il lavoro precedente. La guida alle sessioni avverte inoltre che una sessione inattiva non dimostra che il compito sia riuscito: l’applicazione deve esaminare l’esito del turno e il suo output. Registrerei separatamente se il lavoro è stato accettato e se le sue risorse sono state liberate. [7]
È il risvolto operativo della conservazione del contesto utile per gli agenti di programmazione. Le informazioni salvate e un ambiente di lavoro attivo rispondono a esigenze diverse. Per un’attività ricorrente, salverei in modo esplicito l’output accettato e la cronologia necessaria, poi deciderei se il turno successivo ha davvero bisogno dello stesso ambiente.
Che cosa cambierei in un’applicazione basata su agenti?
Farei in modo che l’applicazione tenesse traccia delle sessioni dalla creazione fino al rilascio delle risorse, comprese quelle dei compiti falliti. Ogni sessione avrebbe un responsabile e una scadenza di conservazione. Dopo il salvataggio degli output necessari, un worker dedicato chiederebbe l’eliminazione, registrerebbe la risposta e riproverebbe in caso di errori temporanei, entro un limite. Un controllo periodico separato individuerebbe le sessioni sfuggite al normale percorso di completamento.
Questa è la mia proposta per progettare l’applicazione, non una correzione che secondo OpenAI i clienti avrebbero dovuto applicare per evitare l’incidente di fatturazione. Serve a rendere verificabile l’utilizzo delle risorse. Se un addebito sembra sbagliato, voglio sapere quali sessioni esistevano, che cosa vi è stato eseguito e quando è stato richiesto il rilascio delle risorse.
Confronterei anche i registri dell’applicazione con i dati di fatturazione. OpenAI descrive come provvisori i conteggi dei token per sessioni e turni: possono mancare o cambiare man mano che arrivano i dati contabili e non costituiscono una fattura finale. Le indicazioni dell’azienda chiedono di includere il lavoro delegato, i nuovi tentativi e gli eventuali costi di strumenti o calcolo nella stima dell’intero compito. [6]
Infine, verificherei se il compito ha bisogno di una sandbox. L’opzione documentata environment.type: "none" può essere adatta al lavoro svolto tramite strumenti esterni, anche se si rinuncia a Bash, alle funzioni per applicare patch e ai file dell’ambiente di lavoro forniti dalla sandbox. La sceglierei per le attività che possono usare tutti gli strumenti necessari anche senza quell’ambiente. [8]
Per la prossima attività ricorrente, esaminerei insieme il risultato salvato e il registro del rilascio delle risorse. Entrambi fanno parte di un’esecuzione completata.





