Costo dei token nelle feature AI: gestirlo prima di perdere il margine

Il costo dei token è la bolletta variabile di inferenza che il prodotto paga ogni volta che un utente attiva una feature AI, ed è la voce che trasforma in silenzio un margine software dell'80% in uno del 50%. Una feature SaaS classica si costruisce una volta e si serve per sempre: il costo marginale del decimillesimo utente è quasi nullo. Una feature AI è l'opposto. Ogni chiamata rilancia il modello, consuma calcolo e attacca un costo reale a quella singola transazione. Se la budgetizzi come se fosse software, il margine si svuota senza che una sola riga del conto economico sembri sbagliata.

Non è un errore di arrotondamento. Il SaaS tradizionale si è assestato tra l'80% e il 90% di margine lordo nell'ultimo decennio. La fotografia di ICONIQ del gennaio 2026 mette il margine lordo medio dei prodotti AI al 52%, in salita dal 41% del 2024 ma ancora lontano dal tetto del software. Bessemer, nel suo State of AI, colloca le aziende LLM-native intorno al 65%. Martin Casado di a16z descrive il vecchio margine software del 70-80% come una gravità di mercato che l'AI rompe, perché l'inferenza è un costo variabile che cresce con ogni uso, non un costo fisso da ammortizzare su una base che si allarga.

Perché le feature AI si comportano come infrastruttura, non come software

Il modello mentale che fallisce è trattare una chiamata AI come una lettura da database. Una lettura da database al margine è di fatto gratis. Una chiamata al modello è a consumo, come l'elettricità. Nel 2026 il contatore segna più o meno così: Claude Sonnet 4.6 costa 3 dollari per milione di token in input e 15 per milione in output, Opus 4.8 costa 5 e 25, Haiku 4.5 costa 1 e 5. GPT-5.5 di OpenAI sta a 5 dollari in input e 30 in output. Sono numeri da centesimi a chiamata, invisibili in una demo, che poi si sommano fino a diventare il tuo costo del venduto più grande quando arrivano utenti veri. L'unità che conta non è il prezzo per token. È quanti token consuma un'azione utile, moltiplicato per quanto spesso i tuoi utenti più pesanti la ripetono.

Perché alzare il prezzo non risolve

Il riflesso è far pagare di più. Non funziona, perché il costo non è distribuito in modo uniforme. I dati di utilizzo del 2026 mostrano il 10% di utenti più attivi consumare quasi il 90% dell'inferenza. Un piano fisso da 29 dollari è redditizio su un utente occasionale e profondamente in perdita su un power user che tiene la feature accesa tutto il giorno. Quando GitHub Copilot ha spostato ogni piano a crediti a consumo a metà 2026, alcuni utenti pesanti hanno visto la bolletta salire da 29 dollari verso 750. Cursor ha tagliato la sua soglia di richieste allo stesso prezzo. Gli sviluppatori hanno chiamato il passaggio tokenpocalypse. Un prezzo fisso più alto perde comunque soldi sul decimo più pesante e taglia fuori il 90% che la feature la sfiora appena. Non puoi mettere una tariffa piatta su un costo che si comporta come una utenza.

Come budgetizzare una feature AI prima di spedirla

Il lavoro si fa prima del lancio, non dopo la prima fattura a sorpresa. Quattro mosse portano quasi tutto il risultato.

Misura il costo per azione, non per utente

Scegli la più piccola unità di valore che la feature produce: un thread riassunto, una bozza generata, una domanda risposta. Conta i token che consuma davvero da capo a fondo, incluso il system prompt, il contesto recuperato, la cronologia della conversazione e l'output. Moltiplica per le tariffe di input e output del modello. Ora hai un costo per azione difendibile. Una singola risposta fondata con 10.000 token di contesto e 700 di replica su Sonnet 4.6 costa circa 4 centesimi. È quel numero, non una vaga stima mensile, quello attorno a cui progetti prezzo e limiti.

Manda ogni compito al modello più economico che supera l'asticella

Lo scarto di prezzo tra un modello di frontiera e uno piccolo è di 5x o più. La maggior parte del traffico in produzione non ha bisogno del modello di frontiera. Classificazione, estrazione, riscritture brevi e decisioni di routing girano bene su modelli classe Haiku a un quinto del costo. Tieni il modello costoso per il ragionamento davvero difficile. Mandare tutto al modello top è il modo più comune in cui i team pagano troppo, e il routing tra modelli è di solito la leva più grande che hanno.

Metti in cache le parti che si ripetono

Quasi tutte le chiamate AI rispediscono lo stesso system prompt e lo stesso contesto a ogni turno. Il prompt caching evita di pagare a prezzo pieno quella ripetizione: Anthropic sconta l'input in cache fino al 90%, e OpenAI lo mette in cache in automatico con uno sconto del 50%. Il semantic caching va oltre, servendo domande quasi identiche da un archivio invece che dal modello, e i sistemi in produzione ne deviano comunemente dal 20% al 45% del traffico. Il batch, per tutto ciò che non deve essere in tempo reale, è un altro 50% in meno. Impilati, caching e routing tagliano regolarmente una bolletta di inferenza dal 47% all'80%.

Metti un tetto al caso peggiore

Ogni feature AI ha bisogno di un limite. Fissa un budget di token o richieste per utente, degrada con grazia quando lo raggiunge (un modello più piccolo, un contesto più corto, una coda) e rendi il tetto una decisione di prodotto, non un incidente scoperto in fattura. La regola a cui teniamo: non spedire mai una feature AI a un prezzo sotto il costo del suo utente peggiore, a meno che tu non abbia scelto di proposito di sussidiare quel livello e sappia esattamente per quanto te lo puoi permettere.

Come fare pricing attorno a un costo variabile

Una volta noto il costo per azione, il prezzo segue. La tariffa piatta regge solo quando l'utente peggiore sta comunque dentro il prezzo, cosa rara per qualsiasi cosa a consumo intenso. Il pricing a consumo allinea ricavo e costo ma aggiunge attrito e imprevedibilità per chi compra. La soluzione comune nel 2026 è ibrida: un abbonamento base che copre una soglia generosa di azioni, poi crediti a consumo oltre quella. Così l'utente occasionale resta su un piano semplice, il power user paga il carico che genera, e il margine è protetto a entrambi gli estremi. Qualunque modello scegli, il livello di billing deve misurare il consumo in modo accurato: è una decisione di sviluppo da prendere presto, non da innestare dopo sotto pressione.

Come si presenta nella pratica

Prendi un assistente di supporto dentro uno strumento B2B. Ogni risposta porta un system prompt da 4.000 token, 6.000 token di conoscenza recuperata e una replica da 700 token. Su Sonnet 4.6 sono circa 4 centesimi a risposta. Un power user che fa 30 domande al giorno su 20 giorni lavorativi genera 600 risposte, circa 24 dollari di inferenza in un mese. Su un piano da 29 dollari, quella singola feature consuma l'83% del ricavo prima di ogni altro costo. Un utente occasionale con 20 domande in tutto il mese costa 80 centesimi. Stessa feature, uno scarto di 30 volte.

Ora applica il budget. Metti in cache il prefisso statico da 9.500 token con lo sconto del 90% e pagano a prezzo pieno solo l'input fresco e l'output: il costo per risposta scende a circa 1,4 centesimi. L'inferenza mensile del power user cala da 24 dollari a circa 8,40, un taglio del 65% senza cambiare nulla di ciò che l'utente vede. Manda le domande più semplici a un modello classe Haiku e scende ancora. La feature che sembrava a margine negativo su un piano fisso ora ci sta dentro comodamente, e la stessa disciplina ti ha detto esattamente dove mettere il tetto di consumo. È tutto qui: il costo dei token non è un motivo per evitare le feature AI. È un numero attorno a cui progettare, e i team che lo misurano prima del lancio tengono il margine che quelli che tirano a indovinare perdono.