Il pricing flat-rate per l’AI aveva senso finché la maggior parte dei prodotti si comportava come una chat: una persona faceva una domanda, il modello rispondeva e la sessione finiva. Il calcolo agentico rompe questo ritmo. Una sola richiesta può avviare un agente cloud, aprire più strumenti, dividersi in rami paralleli, aspettare un’approvazione, riprendere più tardi e continuare a consumare token anche quando l’utente ha già chiuso la scheda. Non è più un caso limite teorico. Il 22 aprile 2026 OpenAI ha presentato i workspace agents in ChatGPT e ha detto che resteranno gratuiti fino al 6 maggio 2026 prima del passaggio a un modello basato sui crediti. Il 20 aprile 2026, aggiornato il 21 aprile, GitHub ha spiegato che i workflow agentici hanno cambiato la domanda di calcolo di Copilot, ha sospeso le nuove iscrizioni individuali, irrigidito i limiti di utilizzo e lasciato Opus 4.7 solo in Pro+.
Per chi compra o costruisce sistemi AI, il segnale è molto più grande di un semplice “i prezzi sono cambiati”. Il calcolo agentico ha trasformato il pricing in una decisione architetturale. Il workflow che progetti oggi determina quale piano sembra conveniente, quale piano sembra rotto e quale team verrà incolpato quando i costi saliranno.
Cosa è cambiato questa settimana
L’annuncio di OpenAI conta perché descrive la nuova normalità senza giri di parole. I workspace agents sono alimentati da Codex, girano nel cloud, possono continuare a lavorare quando l’utente è assente e agire attraverso strumenti e Slack con approvazioni quando servono. Questo profilo di costo è molto diverso da un seat che risponde soprattutto a prompt interattivi. OpenAI ha anche fissato una data precisa: i workspace agents restano gratuiti in research preview fino al 6 maggio 2026, poi passano a un pricing basato sui crediti. È un vendor che sta dicendo chiaramente: questo workload va misurato.
La spiegazione di GitHub è stata ancora più diretta. Nel post del 20 aprile, aggiornato il 21 aprile, GitHub ha scritto che i workflow agentici hanno cambiato in modo sostanziale la domanda di calcolo di Copilot, che le sessioni lunghe e parallele consumano più risorse di quanto prevedesse la struttura originaria del piano e che ormai capita spesso che una manciata di richieste costi più del prezzo del piano. GitHub ha reagito mettendo in pausa le nuove iscrizioni a Pro, Pro+ e Student, stringendo i limiti, mostrando gli avvisi di utilizzo in VS Code e Copilot CLI e mantenendo Opus 4.7 solo su Pro+.
Se metti insieme questi due annunci, emerge uno schema chiaro: i vendor stanno passando da “seat più ipotesi generose” a “seat più governance del workload”. È lo stesso spostamento che avevamo già descritto in La rinascita delle API: perché le API accessibili agli agenti sono il nuovo fossato competitivo. Quando i prodotti AI iniziano a fare lavoro reale attraverso sistemi diversi, il driver di costo non è più il numero di prompt. È l’orchestrazione.
Un terzo segnale è arrivato dalla confusione, non dalla chiarezza di policy. Simon Willison ha documentato il 22 aprile 2026 la confusione sul pricing di Claude Code, quando un testo pubblico ha suggerito per poco tempo un accesso più ristretto prima di essere revertato. Non lo tratterei come policy stabile. Lo leggerei come prova che il mercato sta ancora cercando un modo credibile per confezionare i workload agentici. Se i vendor stessi stanno testando il linguaggio in pubblico, i buyer hanno bisogno di un modello più solido di “illimitato finché non si scopre il contrario”.
Perché il pricing flat-rate si rompe con i workload agentici
Il pricing flat-rate vive di prevedibilità. Un vendor SaaS può offrire un prezzo per seat se la maggior parte degli utenti consuma risorse dentro una banda relativamente stretta. Il calcolo agentico distrugge quella banda.
Una sessione chat normale è più o meno lineare. Un utente fa una domanda, il modello produce una risposta e il costo scala con dimensione del prompt, dimensione della risposta e un po’ di tool use. Un run di agente è diverso. Può:
- rileggere il contesto più volte
- chiamare sistemi esterni
- generare codice ed eseguirlo
- aprire rami paralleli
- aspettare un’approvazione umana
- riprendere più tardi con nuove finestre di contesto
- ritentare automaticamente gli step che falliscono
Questo significa che la variabile costosa non è più “quanti messaggi ha inviato l’utente?”, ma la forma del workload.
Ecco il framework che usiamo quando i team chiedono perché un run di agente sembri economico e quello successivo assurdo:
- Durata di esecuzione: per quanto tempo l’agente può restare attivo prima di successo, timeout o pausa di approvazione?
- Ampiezza degli strumenti: quanti sistemi può leggere o modificare durante un run?
- Fattore di branching: quanti percorsi paralleli può aprire prima di ricondursi a una risposta sola?
- Costo di refresh del contesto: quanto spesso deve ricaricare file grandi, thread o documentazione?
- Posizione dei gate umani: l’approvazione avviene prima degli step costosi o dopo?
I piani flat-rate nascondono queste variabili finché un power user non le fa emergere. I sistemi basati sul consumo le mostrano prima. È fastidioso, ma è anche più onesto.
Le nuove indicazioni di GitHub lo dimostrano in silenzio. Quando GitHub suggerisce di ridurre i workflow paralleli e usare il plan mode in modo più disciplinato vicino ai limiti, sta ammettendo che le scelte di design degli agenti cambiano le unit economics. Lo stesso modello, nello stesso piano, può essere economico o rovinoso a seconda che segua un percorso disciplinato o sei rami speculativi.
Per questo il calcolo agentico va trattato più come cloud workload engineering che come semplice seat management SaaS. Il problema non è che i vendor siano diventati avidi. Il problema è che il calcolo autonomo è volatile.
L’economia dei workload agentici è un problema di design, non solo di finanza
La maggior parte dei team nota questo cambiamento prima come problema di pricing: il piano cambia, compare un cap o la fattura diventa strana. Il modo migliore di leggerlo è come problema di workflow design.
Nel nostro lavoro con i clienti, i team che controllano meglio la spesa non sono quasi mai quelli con il modello più economico. Sono quelli con la topologia di run più chiara. Decidono quali step richiedono davvero autonomia, quali possono restare interattivi e dove una persona deve approvare prima che l’agente si apra a ventaglio. È questa la differenza tra automazione utile e teatro costoso.
Un sintetizzatore di ticket di supporto o un assistente CRM leggero può ancora vivere bene dentro una logica flat-rate, perché il lavoro è breve, ripetitivo e delimitato. È il tipo di use case dietro molti progetti di business automation. Un agente di ricerca, di migrazione del codice o di vendor risk assomiglia invece di più a un job di calcolo elastico. Può scorrere documentazione, valutare opzioni, generare artefatti e iterare su più revisioni. Questo lo avvicina di più all’implementazione di agenti AI o al custom development, dove guardrail e design del run contano quanto la scelta del modello.
Ecco anche perché tanti team scambiano problemi di qualità per problemi di modello. Se un agente brucia i limiti o produce output incoerente, il problema può essere la disciplina del branching, non la capacità grezza del modello. Abbiamo visto un segnale simile in Codex 0.123 Alpha Sprint: 5 versioni, un segnale: la velocità di rilascio conta, ma la policy operativa conta ancora di più. Un modello migliore non salva un workflow progettato male.
Un esperimento mentale utile è confrontare tre modi di risolvere lo stesso task:
- Copilot interattivo: la persona guida ogni step, il modello assiste.
- Agente guidato: il modello esegue step delimitati, la persona approva i cambi di fase.
- Sciame di agenti autonomi: più rami esplorano in parallelo e poi convergono.
Il primo modo tende a essere più pesante sul lavoro umano ma stabile nei costi. L’ultimo può essere impressionante in velocità, ma solo se il task ha abbastanza upside da giustificare il burst. La maggior parte dei team dovrebbe stare nel mezzo. L’autonomia guidata è di solito il punto con il rapporto migliore tra costo e output.
È proprio in questo strato intermedio che la governance diventa product design. Checkpoint di approvazione, model routing, retention della memoria, scope degli strumenti e retry behavior non sono semplici impostazioni admin. Sono controlli di pricing.
Un framework pratico di pricing e governance per i team
Se il calcolo agentico ha rotto il flat-rate, cosa viene dopo? In pratica stanno emergendo tre modelli.
1. Il flat-rate funziona ancora per copiloti delimitati.
Se gli utenti restano soprattutto in sessioni brevi, usano una sola superficie e non avviano catene lunghe di strumenti, un prezzo per seat può ancora funzionare. Pensiamo a drafting, riassunti o supporto rapido nell’IDE. Il prodotto è assistenza interattiva, non lavoro delegato.
2. I crediti funzionano meglio per i run autonomi bursty.
Quando il prodotto può continuare nel cloud, usare più strumenti o operare in Slack mentre l’utente è assente, il metering diventa sensato. Il passaggio di OpenAI ai crediti dal 6 maggio è l’esempio pubblico più chiaro della settimana. Un pool di crediti è più facile da difendere se alcuni run sono cinquanta volte più pesanti di altri.
3. Il pricing ibrido è probabilmente la destinazione enterprise.
Il modello più solido sarà probabilmente un abbonamento base per seat, governance, analytics e collaborazione, più usage o crediti per il calcolo autonomo sopra una certa soglia. Ai buyer piace poco perché sembra meno semplice. Ai vendor piace perché riflette meglio il costo reale. Probabilmente entrambe le parti dovranno conviverci.
Per chi opera il sistema, il punto non è discutere di filosofia. È mappare le classi di workload alle classi di pricing:
- lavoro interattivo leggero → seat flat-rate
- automazione di workflow delimitata → seat più soft cap
- agenti lunghi di ricerca o coding → crediti o budget espliciti
- workflow multi-agente paralleli → burst budget governati con approvazioni
Questa mappatura è più facile se ragioni già in termini di system design. La nostra precedente analisi Hermes Agent vs OpenClaw diceva qualcosa di simile da un’altra angolazione: quando introduci orchestrazione, stai prendendo decisioni infrastrutturali anche se non le chiami così.
Alcune mosse di design riducono la spesa senza distruggere la qualità:
- ridurre i rami paralleli prima di tagliare la qualità del modello
- instradare retrieval, formattazione e trasformazioni low risk verso modelli più economici
- imporre un’approvazione prima delle azioni esterne costose
- mettere in cache il contesto condiviso invece di ricaricarlo in ogni ramo
- definire condizioni di stop esplicite per evitare loop con guadagno marginale
- registrare la forma dei run, non solo la spesa totale
Quest’ultimo punto conta molto. Se tracci solo la fattura, impari troppo tardi. Se tracci numero di rami, durata, chiamate agli strumenti e attese di approvazione, puoi vedere quali workflow sono economicamente rotti prima che finance presenti il reclamo.
Cosa dovrebbero chiedere i buyer ai vendor prima di scegliere un piano
La maggior parte delle pagine di pricing AI continua a specificare poco la parte che conta davvero: quale comportamento degli agenti il piano tollera realmente. Quindi bisogna chiedere in modo esplicito.
Primo: che cosa conta come unità di utilizzo? Token, tool call, minuti di sessione, moltiplicatori di modello o una miscela? Se la risposta è vaga, anche il budget sarà vago.
Secondo: come gestisce il prodotto il parallelismo? GitHub ora avverte esplicitamente che i workflow paralleli aumentano il consumo di token. Se il tuo team dipende da pattern di fan-out e merge, devi sapere se è un bonus per power user o una penalità nascosta.
Terzo: cosa succede durante le attese di approvazione? Alcuni sistemi tengono di fatto caldo un contesto costoso mentre aspettano. Altri checkpointano in modo molto più efficiente. Questa differenza può contare più del prezzo di listino.
Quarto: qual è la modalità degradata? Quando gli utenti si avvicinano ai cap, perdono la scelta del modello, la concorrenza, l’accesso agli strumenti o il prodotto intero? I nuovi avvisi di GitHub in VS Code e Copilot CLI sono un buon passo perché permettono di reagire prima dell’impatto.
Quinto: le analytics sono abbastanza buone per governare il sistema? Il pitch di OpenAI sui workspace agents include visibilità enterprise e analytics. Non è solo una funzione admin. Senza visibilità a livello di run, non puoi ottimizzare costo o fiducia.
Sesto: il linguaggio di pricing può cambiare in corsa? La confusione di Claude Code del 22 aprile ricorda che bisogna distinguere fra policy ufficiale, test, revert e interpretazione della community. Se il tuo operating model dipende da un’ipotesi sull’uso agentico incluso, fattela mettere per iscritto.
La lezione più ampia è semplice: non comprare una piattaforma di agenti come se fosse un abbonamento chat. Comprala come un motore di workflow con costi burst dipendenti dal modello. L’astrazione sbagliata porta al piano sbagliato, poi al rollout sbagliato e infine al postmortem sbagliato.
FAQ
Il pricing flat-rate è morto per i prodotti AI?
No. Il pricing flat-rate funziona ancora per copiloti interattivi leggeri con sessioni brevi, uso limitato di strumenti e comportamento prevedibile.
Cosa rende il calcolo agentico più costoso della chat?
Durate lunghe, refresh ripetuti del contesto, tool call e rami paralleli rendono il calcolo agentico molto più variabile della chat classica.
I team dovrebbero scegliere crediti o abbonamenti per gli agenti AI?
Gli abbonamenti servono per un valore seat prevedibile; i crediti per lavoro autonomo bursty. La maggior parte dei team enterprise finirà per combinare entrambi.
Come si riduce la spesa degli agenti senza rovinare la qualità?
Riduci prima il parallelismo inutile, metti approvazioni prima delle azioni costose e instrada gli step semplici verso modelli più economici prima di fare downgrade dell’intero workflow.
Perché il pricing ora sembra una questione di system design?
Perché logica di approvazione, retry, memoria, accesso agli strumenti e concorrenza plasmano direttamente quanta potenza di calcolo consuma un agente.
Conclusione: compra il workflow, non solo il prezzo in vetrina
Il punto delle notizie di pricing di questa settimana non è che i vendor abbiano improvvisamente scoperto la monetizzazione. Il punto è che il calcolo agentico ha cambiato ciò che stanno vendendo. Un chat seat può essere prezzato in modo ampio. Un workflow delegato no. Quando il software può lavorare per minuti o ore attraverso più strumenti, pricing, governance e architettura collassano nella stessa decisione.
Per questo i team vincenti non si limiteranno a negoziare contratti migliori. Progetteranno workload migliori. Se vuoi capire quali task AI devono stare su seat flat-rate, quali richiedono budget a crediti e dove posizionare le approvazioni nel flusso, Context Studios può aiutarti a progettare il workflow prima di pagare troppo per il piano sbagliato.