Il prezzo di listino mente: perché i costi AI si sono disaccoppiati dal pricing a maggio 2026

Anthropic non ha aumentato il prezzo di Opus 4.7. Il listino indica ancora 5 dollari per milione di token in input e 25 dollari per milione di token in output, esattamente come per Opus 4.6. Eppure i team che eseguono workload di produzione su Opus 4.7 questa settimana stanno pagando il 27% in più per lo stesso lavoro.

Qualcosa è cambiato nel modo in cui funziona il pricing dell'AI. È cambiato in modo silenzioso, attraverso tre mosse separate di vendor annunciate a pochi giorni di distanza, ognuna con un meccanismo diverso. Lo spostamento è abbastanza grande da rompere la maggior parte dei budget AI enterprise redatti per il 2026, e abbastanza sottile da non emergere leggendo le pagine di pricing.

Questo articolo spiega cosa è successo davvero, perché il prezzo di listino è diventato un proxy debole del costo reale e cosa determina se il vostro team vedrà una variazione del 5% o del 90% nei prossimi 60 giorni.

Tre vendor, tre meccanismi, una sola direzione

OpenAI: l'aumento esplicito

GPT-5.5 è stato lanciato con una variazione di prezzo chiara e visibile. I token in input sono passati da 2,50 dollari per milione a 5,00 dollari per milione. I token in output da 15 dollari per milione a 30 dollari per milione. Un aumento da manuale del 2x, annunciato apertamente.

OpenRouter ha condotto un'analisi su una coorte di switcher, cioè utenti il cui modello primario era GPT-5.4 prima del lancio e che sono passati a GPT-5.5 immediatamente dopo. Stessi utenti, stessi workflow, versione del modello diversa. Il risultato: gli aumenti di costo reali sono andati dal 49% al 92%, a seconda della lunghezza del prompt.

Perché non l'intero 100%? Perché GPT-5.5 è meno verboso sui prompt lunghi. Per prompt sopra i 10K token il modello produce dal 19% al 34% in meno di completion token rispetto a GPT-5.4 per lo stesso compito. Questo compensa parzialmente il prezzo per token raddoppiato. Per prompt più corti il compenso scompare, ed è per questo che il colpo peggiore è sui prompt sotto i 2K token, dove il costo reale è aumentato del 92%.

Il messaggio è diretto: OpenAI ha raddoppiato il prezzo e la vostra bolletta è salita di un valore compreso tra metà e quasi il doppio. Il meccanismo è visibile. La magnitudine no.

Anthropic: l'aumento invisibile

Anthropic ha seguito una strada diversa. Il prezzo di listino di Opus 4.7 è identico a quello di Opus 4.6. Nessun annuncio di variazione di prezzo, perché non c'è nessuna variazione di prezzo da annunciare.

Opus 4.7 viene invece rilasciato con un nuovo tokenizer. Il nuovo tokenizer produce dal 32% al 45% di token nativi in più per lo stesso testo, a seconda della dimensione del prompt. Anthropic ha dichiarato un intervallo di inflazione tra 1,0x e 1,35x nella documentazione ufficiale. La misurazione di OpenRouter su una coorte di switcher ha confermato l'estremo superiore di quell'intervallo nella pratica.

L'impatto reale sul costo: dal 12% al 27% in più per task sui prompt sopra i 2K token. C'è un'eccezione notevole. I prompt sotto i 2K token costano in realtà l'1,6% in meno, perché Opus 4.7 è significativamente più conciso sulle query brevi (62% in meno di completion token alla mediana).

C'è anche una mitigazione nascosta. Il prompt caching, fatturato con uno sconto del 90%, assorbe una larga parte dell'inflazione di token se la struttura del prompt è abbastanza stabile da centrare la cache. Sui prompt da 128K token in su, il 93% dei token aggiuntivi finisce in cache. Sui prompt nell'intervallo 10K-25K, solo il 9%. Questo non è un dettaglio implementativo minore. È la differenza tra un aumento di costo del 33% e uno del 5%, sullo stesso modello, con lo stesso volume.

Il prezzo di listino non si è mosso. La bolletta sì. E quanto la bolletta si sia mossa dipende quasi interamente da come sono strutturati i vostri prompt.

GitHub Copilot: il cambio strutturale

GitHub ha annunciato che dal 1° giugno 2026 Copilot passerà dalla fatturazione basata su request a quella basata su usage. I prezzi dei piani restano gli stessi: Copilot Pro a 10 dollari al mese, Pro+ a 39, Business a 19 per utente. Ciò che cambia è cosa quei prezzi comprano.

Oggi ogni interazione con Copilot consuma un'unità premium request, con un moltiplicatore di modello in cima. Dal 1° giugno ogni interazione consumerà token, prezzati alla tariffa API del modello sottostante, convertiti in GitHub AI Credits.

Per gli sviluppatori che usano principalmente il code completion inline e Next Edit Suggestions, l'impatto sarà modesto. Quelle funzionalità restano incluse nei piani base. Per gli sviluppatori che si affidano a Copilot Chat, sessioni di coding agentico, finestre di contesto ampie o code review, la curva di costo cambia in modo sostanziale. I moltiplicatori per chi tiene piani annuali sulla fatturazione request-based saliranno bruscamente: Opus 4.7, ad esempio, passa da un moltiplicatore di 7,5x a 27x.

GitHub ha inoltre sospeso le nuove iscrizioni ai piani Copilot Pro, Pro+ e Student a partire dal 20 aprile 2026. La motivazione ufficiale è proteggere l'esperienza dei clienti esistenti. La motivazione implicita è che la domanda sta superando ciò che GitHub può servire profittevolmente alle attuali tariffe flat.

Tre vendor. Tre meccanismi (variazione di prezzo, cambio di tokenizer, cambio di modello di billing). Una direzione.

Vendor	Meccanismo	Variazione prezzo di listino	Impatto reale sul costo	Cosa guida il gap
OpenAI (GPT-5.5)	Aumento di prezzo esplicito	+100% (input e output)	da +49% a +92%	Completion meno verbose sui prompt lunghi (da -19% a -34% sopra i 10K)
Anthropic (Opus 4.7)	Nuovo tokenizer	0%	da +12% a +27% sopra i 2K; -1,6% sotto i 2K	32-45% di token nativi in più per lo stesso testo; la cache assorbe dal 9% al 93% a seconda della dimensione del prompt
GitHub (Copilot)	Cambio del modello di billing	0% sui piani	Fino a 3-4x per gli utenti agentici dal 1° giugno	Passaggio da request-based a token-based; moltiplicatori fino a 27x per alcuni modelli

Perché questo conta più di quanto sembri

Per gran parte degli ultimi tre anni, i costi AI nei budget enterprise sono stati un arrotondamento. I team di procurement trattavano le API dei modelli più o meno come trattano lo storage S3: una tariffa per unità da una pagina di pricing pubblica, moltiplicata per un volume stimato, più una contingency.

Quell'approccio ha smesso di funzionare. Per produrre una stima credibile dei costi AI oggi servono tre input, non uno:

1. Il prezzo di listino del modello. Questo conta ancora, ma ora è necessario, non sufficiente.
2. Il comportamento del tokenizer della specifica versione del modello. Vendor diversi producono conteggi di token diversi per lo stesso testo. Versioni diverse dello stesso modello possono produrre conteggi che differiscono dal 30% al 45%. L'unità sul listino non è più un'unità stabile.
3. Il vostro pattern di utilizzo reale: distribuzione delle lunghezze dei prompt, distribuzione delle lunghezze delle completion, tasso di cache hit, tasso di retry. Sono questi a determinare a quale segmento della struttura di pricing del vendor siete realmente esposti.

Solo l'intersezione di questi tre dà una vera cifra di costo per task. Senza tutti e tre non state facendo budget. State tirando a indovinare.

L'implicazione strutturale per chi guida un'organizzazione tecnica: la voce "AI" nel vostro budget 2026 sta diventando la riga più volatile dell'intero stack tecnologico. Una volatilità del 50%-90% in 48 ore non ha precedenti nell'infrastruttura commodity enterprise. AWS in dieci anni non ha mai avuto questo profilo di rischio. Nemmeno il mercato dei database, quello delle CDN o quello dell'osservabilità.

Questa volatilità non sparirà. È la conseguenza naturale di un mercato in cui supply di compute, capacità dei modelli di frontiera e modelli di business dei provider stanno evolvendo simultaneamente. I vendor che stanno cambiando il pricing questo mese non hanno finito. Cambieranno di nuovo, e i prossimi vendor useranno meccanismi che non abbiamo ancora visto.

Cosa controlla davvero il costo in produzione

Gli stessi dati di OpenRouter che mostrano gli aumenti di costo a livello macro mostrano anche una grande dispersione all'interno di quegli aumenti. Due organizzazioni che usano Opus 4.7 con lo stesso volume possono vedere un impatto reale del +5% o del +27%. La differenza non è quale contratto hanno firmato. È come hanno costruito il sistema attorno al modello. Quattro leve fanno la maggior parte del lavoro.

Leva	Cosa controlla	Meccanismo	Impatto stimato
Struttura del contesto consapevole della cache	Assorbimento dell'inflazione del tokenizer	Prefisso del prompt stabile che centra la cache (sconto del 90%)	9% di assorbimento sui prompt 10K-25K; 93% sopra i 128K
Model routing	Esposizione alle variazioni di pricing di un singolo vendor	Layer di routing che indirizza i task tra tier di modello	Buffer contro eventi di volatilità del 50%-90%; valore opzionale tra vendor
Disciplina della lunghezza dei prompt	Consumo di token per task	Comprimere il contesto irrilevante; evitare il pad-for-safety	La fascia 2K-10K è la più penalizzata (+27% a +69%)
Controllo della completion	Volume di token in output	Schemi stretti, condizioni di stop precise, design di output conciso	Amplifica le riduzioni di completion guidate dal vendor

Struttura del contesto consapevole della cache. Il prompt caching di Anthropic, fatturato con sconto del 90%, assorbe una larga parte dell'inflazione del tokenizer quando i prompt sono strutturati in layer stabili e cacheable. I dati Anthropic mostrano il gradiente in modo chiaro: il 9% dei token extra assorbiti sui prompt da 10K-25K, il 77% su 50K-128K, il 93% sopra i 128K. La variabile che controlla il tasso di cache hit è se l'assemblaggio dei prompt produce lo stesso prefisso tra le richieste. Prompt assemblati ad-hoc ad ogni richiesta perdono interamente questo beneficio. Prompt assemblati con un layer strutturale fisso (system instructions, contesto fisso, poi input variabile alla fine) lo catturano.

Model routing. Un workflow cablato su un singolo modello è completamente esposto alle variazioni di pricing di quel modello. Un workflow con un layer di routing che indirizza i task semplici verso modelli più piccoli e riserva i modelli di frontiera ai task complessi ha un buffer naturale. Il layer di routing crea anche valore opzionale: quando un vendor cambia il pricing in modo sfavorevole, potete spostare il carico su alternative senza riscrivere il codice applicativo. Non è una leva ipotetica. Con OpenAI, Anthropic e GitHub che hanno cambiato i termini nella stessa settimana, le organizzazioni con layer di routing hanno riconfigurato il traffico. Quelle senza hanno aperto change request.

Disciplina della lunghezza dei prompt. Entrambe le analisi di OpenRouter mostrano la fascia 2K-10K come una delle più penalizzate. GPT-5.5 è il 69% più costoso in quel range. Opus 4.7 è il 27% più costoso. Molti team di engineering tendono istintivamente a imbottire i prompt con contesto "per sicurezza", gonfiando il conteggio di token per task senza beneficio proporzionale. Una costruzione disciplinata dei prompt (comprimere il contesto irrilevante, dividere contesti lunghi su più chiamate quando il caching si applica, rimuovere il contesto morto che non conta più) ha un ritorno economico diretto.

Controllo della completion. GPT-5.5 produce dal 19% al 34% in meno di completion token sopra i 10K. Opus 4.7 produce il 62% in meno sotto i 2K. Sono cambiamenti guidati dal vendor, ma i workflow possono amplificarli. Schemi di output stretti, condizioni di stop precise e task progettati per richiedere risposte concise riducono tutti la lunghezza della completion. I team che guidano il modello verso output brevi e strutturati pagano meno, indipendentemente dal prezzo nominale del modello.

Tutte e quattro le leve sono proprietà del sistema attorno al modello, non del modello stesso. Non sono prompt engineering. Il prompt engineering ottimizza una singola chiamata. Queste ottimizzano l'architettura in cui le chiamate avvengono.

La conversazione con il CFO è cambiata

Sei mesi fa il CTO che difendeva il budget AI con il CFO entrava con la pagina di pricing del vendor. Quella conversazione funzionava, perché la pagina di pricing era un proxy ragionevole di ciò che l'azienda avrebbe pagato davvero.

Oggi quella pagina di pricing è incompleta. Tra 60 giorni, dopo la transizione di Copilot del 1° giugno, sarà esplicitamente sbagliata per uno degli strumenti AI enterprise più comuni.

La conversazione che un CTO deve essere pronto ad avere ora è diversa. Non è "quanto costa il modello". È "quanto costa per noi un task rappresentativo, e perché". La risposta a questa seconda domanda dipende quasi interamente dall'architettura, non dalla scelta del modello.

Le organizzazioni che sanno rispondere alla seconda domanda sono in posizione forte. Possono fare budget con fiducia, negoziare con i vendor da una posizione di misura piuttosto che di speranza, e assorbire le variazioni di pricing senza disruption operativa. Le organizzazioni che non sanno rispondere sono esposte a ogni decisione di vendor presa nel prossimo anno, e ce ne saranno molte.

Lo spostamento è strutturale, non ciclico

Sarebbe rassicurante leggere le variazioni di pricing di questa settimana come una stretta temporanea. Vendor capacity-constrained che alzano i prezzi finché la supply non recupera. Quella lettura è sbagliata, o quantomeno incompleta.

Lo spostamento più profondo è che l'infrastruttura AI sta passando da un modello di pricing in stile commodity (tariffe per unità prevedibili, unità prevedibili) a un modello di pricing in stile structured product (le tariffe dipendono dal tokenizer, dal modello di billing, dal piano e dal pattern di utilizzo). I structured product richiedono procurement strutturato. Premiano la sofisticazione e puniscono il consumo ingenuo.

Non è un problema da aspettare. È una proprietà del mercato che è qui per restare, e favorisce le organizzazioni che hanno investito nel layer architetturale attorno al modello: i vincoli, il routing, la strategia di caching, i feedback loop che misurano in continuo il costo reale per task.

In FairMind chiamiamo questo layer la harness. Costruirla non è più opzionale. È la parte dello stack AI che determina se la prossima variazione di pricing vi costerà il 5% o il 50%.

Scopri di più sulla Harness Engineering.

---

Fonti

• OpenRouter, "Opus 4.7's New Tokenizer: What It Actually Costs" (27 aprile 2026): https://openrouter.ai/announcements/opus-47-tokenizer-analysis
• OpenRouter, "GPT-5.5 Price Increase: What It Actually Costs": https://openrouter.ai/announcements/gpt55-cost-analysis
• GitHub Blog, "GitHub Copilot is moving to usage-based billing": https://github.blog/news-insights/company-news/github-copilot-is-moving-to-usage-based-billing/
• GitHub Docs, "Models and pricing for GitHub Copilot": https://docs.github.com/en/copilot/reference/copilot-billing/models-and-pricing