Nella maggior parte delle API LLM, ogni chiamata viene fatturata a token. Non per risultato, non per qualità dell’output, non per problema risolto: per token. È come pagare un programmatore a numero di caratteri digitati.

Rupert Goodwins su The Register lo dice senza riserve: il billing a token non è un’unità di misura provvisoria in attesa di qualcosa di meglio. È un sistema costruito per crescere. E crescerà.

Billing a token AI: un metro che non misura il valore

Il token è la granularità con cui i modelli linguistici elaborano il testo: un’unità computazionale interna, non una misura di lavoro produttivo. Usarlo come base di fatturazione è come misurare la qualità del codice in linee prodotte.

La differenza è che nessuno ci ha costruito un’industria da trilioni sopra. Con i token, sì.

Goodwins usa un paragone brutale: fatturare a token ha persino meno senso che pagare i programmatori a battitura. Il punto è semplice: la metrica non misura lavoro utile, risultato o qualità. Misura consumo.

Non c’è un modo “efficiente” di consumare token che un vendor non possa erodere dall’interno. Un modello verboso consuma di più. Un’implementazione inefficiente consuma di più. Entrambi aumentano la fattura. Nessuno dei due garantisce un risultato migliore.

Perché il consumo di token cresce senza che tu lo veda

I vendor hanno un incentivo strutturale a venderti più capacità e più ragionamento nel tempo. La competizione può spingere i prezzi unitari verso il basso, ma non cambia il fatto che il metro resta nelle loro mani: modelli più verbosi, reasoning chain più lunghe, prompt di sistema opachi. Ogni “ottimizzazione” che introducono può aumentare silenziosamente il consumo, restando contrattualmente invisibile.

Il caso più trasparente è quello dei modelli a ragionamento esteso. OpenAI espone il conteggio nel campo completion_tokens_details.reasoning_tokens, dove puoi vedere quanti token ha consumato il ragionamento, ma non ispezionare la catena completa che li ha prodotti. Paghi per un processo che puoi quantificare, non verificare fino in fondo.

Anthropic con extended thinking restituisce blocchi di thinking nella risposta o loro sintesi: visibilità maggiore, ma i token di thinking sono comunque fatturati come output token e, su problemi complessi, possono aumentare sensibilmente il costo della chiamata. In entrambi i casi, il vendor controlla quanto “pensiero” il modello consuma per default.

Cosa significa per i team che usano LLM in produzione

Il costo per task può crescere anche senza un tuo errore: basta che cambi il modello, il reasoning budget, il prompt di sistema o il comportamento predefinito del provider. Il lock-in che segue è tecnico e culturale insieme: i team si abituano agli strumenti di un singolo provider fino al punto in cui ogni migrazione diventa un progetto, non una sostituzione di endpoint.

Le metriche di ROI che usi oggi sono fragili: spesso assumono stabile proprio l’unità che il vendor può modificare più facilmente.

Trattare i costi token come una variabile instabile, mai come un dato fisso nei calcoli di unit economics, è l’unica posizione difendibile.

In pratica significa tre cose. Prima: imposta budget alert per chiamata API come faresti per qualsiasi altra risorsa cloud, non aspettare la fattura di fine mese. Seconda: misura il consumo su campioni rappresentativi di traffico reale ogni settimana, non solo durante l’integrazione iniziale quando i costi sono artificialmente bassi. Terza: considera un’astrazione leggera sopra il provider, non per eleganza architetturale, ma perché il giorno in cui vorrai migrare, quell’astrazione è l’unica cosa che rende il costo sopportabile. LiteLLM, gateway HTTP generici, o anche solo una funzione di wrapping: l’obiettivo non è la portabilità oggi, è non essere completamente ostaggio domani.

Ma il punto non è solo ottimizzare prompt, alert e wrapper. Quelli sono cerotti operativi. Il problema vero è che l’unità di misura del mercato AI non è stata scelta da chi compra valore, ma da chi vende consumo.

Il take di TechMonk: tre scenari per il mercato AI

Il problema non è che il billing a token sia ingiusto. È che nessuno sa quale dei tre scenari che seguono si materializzerà: in tutti e tre paghi comunque.

Scenario 1 — La competizione sui prezzi ci salva, ma solo per ora

Google taglia i prezzi di Gemini, OpenAI segue, Anthropic si adegua. I token si deflazionano non per un cambiamento strutturale, ma perché i provider più grandi usano il prezzo come arma per acquisire quota di mercato tra i developer.

È una dinamica già vista nel cloud: prezzi aggressivi nella fase di acquisizione, poi ottimizzazione dei margini quando workload, dati e competenze sono ormai dentro la piattaforma.

Questa deflazione è una tregua, non una struttura stabile. Dura finché qualcuno deve ancora guadagnare market share. Quando il mercato si consolida a tre o quattro provider con posizioni dominanti, la pressione al ribasso sparisce, e quella storia l’abbiamo già letta.

Scenario 2 — Il lock-in cognitivo è il costo reale

Goodwins parla di lock-in tecnico. C’è un lock-in più insidioso che non appare in nessuna fattura: quello cognitivo. I team ridisegnano i workflow intorno all’output di un modello specifico: tono delle risposte, formato strutturato, lunghezza degli snippet, gestione degli errori, aspettative implicite nei prompt.

Quando il vendor cambia il modello, quei workflow si rompono.

Il costo non è nell’API bill: sono giorni di reingegnerizzazione, review dei prompt, regressioni nei test. Non compare in nessuna metrica di unit economics, non c’è in nessun contratto. Ed è il motivo per cui migrare provider non costa sprint: costa mesi, esattamente come uscire da un’architettura mainframe.

Scenario 3 — Serve governance, non solo competizione

Oggi mancano standard aperti e adottati su larga scala per misurare il valore effettivo prodotto dai modelli. Chi avrebbe interesse ad averli, i developer, non ha potere di mercato sufficiente. Chi ha potere di mercato non ha incentivo a cedere il controllo del metro di misura.

Uno standard minimo potrebbe essere banale: costo per task riuscito, token nascosti separati da token visibili, variazione del consumo medio tra versioni dello stesso modello, changelog obbligatorio quando un upgrade modifica il profilo di spesa.

Non è un fallimento del mercato nel senso classico: è una failure di governance. Il parallelo non è perfetto, ma la logica è simile a quella dei mercati regolati: quando chi compra non può misurare bene ciò che paga, la competizione da sola non basta sempre a correggere l’asimmetria.

Conclusione

La domanda non è se il consumo di token diventerà una leva economica: lo è già. La domanda interessante è chi avrà abbastanza potere di mercato da imporre metriche alternative: hyperscaler, grandi enterprise, governi, piattaforme con volumi enormi.

Oggi quella lista è cortissima. I developer non ci sono.