La stima che non coincide mai con la fattura
La pagina dei prezzi e la fattura descrivono due cose diverse. La pagina dei prezzi descrive un token: $5 per milione su Claude Opus 4.8, una frazione di centesimo per una domanda di un cliente. La tua fattura descrive come il tuo prodotto chiama davvero il modello, e quel percorso e' piu' lungo, e molto piu' costoso, del token che avevi messo a preventivo. Nessuno ti sta addebitando piu' del dovuto.
Lo scarto non e' un unico costo misterioso. E' un piccolo insieme di moltiplicatori specifici, con un nome preciso, e una volta che riesci a vederli puoi metterli a budget. Eccoli, uno alla volta, quotati su un chatbot di assistenza che gira su Claude Opus 4.8.
| Voce | Importo |
|---|---|
| La tua stima | $200 |
| Context multi-turno | + $1,260 |
| La tua fattura | $1,460 |
Quanto metti a budget vs quanto ti viene fatturato
Chatbot di supporto · 10,000 conversazioni / mese · Claude Opus 4.8 ($5 / $25 per 1M)
Modellato, non un preventivo. Ipotesi: una conversazione da 4 turni; un system prompt da 1,500 token più la conoscenza recuperata, rinviati a ogni turno; un messaggio del cliente da ~500 token e una risposta da ~700 token per turno. Sono ~15,200 token di input e ~2,800 di output per conversazione, ovvero $760 di input + $700 di output su 10,000 conversazioni. I tuoi numeri saranno diversi; la forma no.
Il titolare attento stima $200 al mese: 10,000 conversazioni, ognuna una domanda breve e una risposta piu' lunga, quotate onestamente a $5 di input e $25 di output. La fattura e' $1,460. Il titolare che ha contato solo la domanda del cliente - i token di input, un solo turno - aveva messo a budget $25 e ha sbagliato di quasi sessanta volte. Nessuno dei due ha commesso errori di aritmetica. Hanno stimato la quantita' sbagliata.
Trappola 1: hai quotato la domanda, ma la risposta costa cinque volte tanto
Su ogni modello Claude attuale, i token di output costano esattamente cinque volte i token di input. Fable 5 e' $10 in input e $50 in output. Opus 4.8 e' $5 e $25. Sonnet 5 e' $3 e $15 (con una tariffa introduttiva di $2 e $10 fino al 31 agosto 2026). Il rapporto non cambia mai, e punta nella direzione sbagliata rispetto a come le persone fanno le stime: quotiamo la cosa che scriviamo noi, che e' breve, e dimentichiamo la cosa che il modello ci scrive in risposta, che e' lunga.
Nell'esempio dell'assistenza la domanda del cliente e' di circa 500 token e la risposta di circa 700. Quelle risposte da sole - 700 token per 10,000 conversazioni a $25 per milione - arrivano a $175 al mese, che e' gia' sette volte l'intera stima basata solo sull'input di $25. Se il tuo prodotto riassume, redige bozze, spiega o scrive codice, il lato output e' dove finiscono i tuoi soldi, ed e' il lato che il prezzo di listino sottovaluta in silenzio.
Trappola 2: una conversazione non e' una domanda
Questa e' quella grossa, ed e' la trappola che trasforma una stima ordinata in una fattura sorprendente. L'API non ha memoria. Non ricorda il tuo turno precedente. Quindi, per continuare una conversazione, la tua applicazione re-invia l'intera cosa a ogni singolo turno: il system prompt, qualunque conoscenza tu abbia recuperato e tutto lo scambio avvenuto fino a quel momento. Ti viene fatturato tutto, di nuovo, ogni volta che il modello parla.
Segui la conversazione di assistenza lungo quattro turni. Un system prompt e uno snippet di conoscenza da 1,500 token viaggiano insieme a ogni turno. Al quarto turno stai anche re-inviando tre domande precedenti e tre risposte precedenti. Fai la somma e una singola conversazione di quattro turni consuma circa 15,200 token di input, non i 500 che immaginavi quando guardavi una sola domanda. Sono all'incirca trenta volte l'input che avevi stimato, ed e' il motivo per cui il contesto re-inviato, non il modello che hai scelto, e' la voce piu' grande nella fattura qui sopra.
Inoltre si accumula. Poiche' ogni turno ripaga tutti i turni precedenti, il costo totale di una conversazione cresce con il quadrato della sua lunghezza, non in linea retta. Una conversazione di dieci turni non costa dieci volte una conversazione di un turno, costa molto di piu'. Una funzione di chat che sembra economica in una demo da tre messaggi puo' comportarsi in modo molto diverso una volta che gli utenti reali si assestano su thread da venti messaggi.
Trappola 3: il ragionamento che paghi ma non vedi mai
Il modello ragiona prima di rispondere, e quel ragionamento viene fatturato come output che tu lo veda o meno. Su Fable 5 questo ragionamento e' sempre attivo: una richiesta che restituisce un'ordinata risposta da 500 token potrebbe aver speso diverse migliaia di token a ragionare prima, e ognuno di quei token invisibili e' quotato alla tariffa di output di $50. La risposta sul tuo schermo e' la piccola parte di cio' che hai pagato.
La stessa leva esiste sulla famiglia Opus tramite l'impostazione dell'effort. Alza l'effort e il modello pensa piu' a lungo e chiama piu' strumenti, spendendo piu' token per maggiore affidabilita'. Abbassalo e il modello va piu' veloce e costa meno. Nessuna delle due opzioni e' sbagliata, ma se non hai mai scelto un livello stai pagando qualunque cosa costi il valore predefinito. Se stai valutando un modello sempre pensante rispetto a uno standard, il confronto onesto non e' tra i due listini prezzi ma tra i due conteggi di token che un compito reale produce - che e' esattamente cio' che approfondisce la nostra analisi Fable 5 contro Opus 4.8.
Trappola 4: lo stesso testo, contato come piu' token
Ecco quella che coglie di sorpresa anche i team attenti. Quando passi a un modello piu' recente, il suo tokenizer - la cosa che spezza il testo in token fatturabili - puo' contare il testo identico come piu' token di prima. Hai cambiato una stringa del modello, non hai aggiunto alcuna funzione, hai mantenuto esattamente lo stesso prezzo per token, e la fattura e' comunque salita.
| Modello | Importo |
|---|---|
| Sonnet 4.6 | $900 |
| Sonnet 5 | $1,170 |
| Differenza | + $270 |
Stesso testo, stesso listino, una fattura più alta
Un mensile carico di lavoro sull'identico listino ($3 / $15 per 1M)
La cifra pubblicata di deriva del tokenizer (~30%) applicata a un volume fisso. Lo stesso insieme di documenti viene tokenizzato in ~100M token su Sonnet 4.6 (50M input + 50M output = $150 + $750 = $900) e in ~130M su Sonnet 5 (65M + 65M = $195 + $975 = $1,170). Stesse parole, stesso listino, +$270 al mese.
Sonnet 5 conta circa il 30 percento di token in piu' rispetto a Sonnet 4.6 per le stesse parole. Il tokenizer di Opus 4.7 si colloca da qualche parte tra lo stesso valore e circa il 35 percento in piu' rispetto a Opus 4.6, a seconda del contenuto. Quindi un aggiornamento che sulla pagina dei prezzi sembra gratuito puo' alzare in silenzio una fattura di un terzo. La soluzione non e' evitare di aggiornare - i modelli piu' recenti di solito valgono la pena - ma ri-misurare i tuoi conteggi reali di token dopo qualsiasi passaggio e rifare il budget a partire dai nuovi numeri, invece di dare per scontato che un listino identico significhi una fattura identica.
Trappola 5: i tentativi che non vedi mai
La pulita richiesta-e-risposta che immagini e' il percorso ideale. In produzione ci sono errori transitori che vengono ritentati, rifiuti per motivi di sicurezza e loop di agenti che chiamano uno strumento, leggono il risultato e chiamano di nuovo il modello. Ognuno di questi giri aggiuntivi e' altri token sul contatore, e nessuno di essi compare nel tuo modello mentale di "una domanda, una risposta".
C'e' una sfumatura reale che vale la pena conoscere qui. Su Fable 5, una richiesta rifiutata prima che produca alcun output non viene fatturata affatto, mentre una rifiutata a meta' stream fattura la parte gia' trasmessa. I retry sono economici da eseguire e facili da lasciare senza limiti, quindi un piccolo bug - un agente che va in loop una volta di piu' del dovuto, una policy di retry senza un tetto - si presenta come una voce in fattura, non come uno stack trace.
L'intera fattura nascosta in una pagina
Tra un listino prezzi di un LLM e la fattura si frappongono sei moltiplicatori. Cinque di essi risiedono nel modo in cui chiami il modello; il sesto risiede nel modo in cui pianifichi il lavoro. Nessuno e' un trucco o un costo nascosto, e ciascuno ha una leva specifica che lo appiattisce.
| Costo nascosto | Cosa lo innesca | Dimensione tipica | La leva che lo appiattisce |
|---|---|---|---|
| Output quotato a 5 volte l'input | Ogni risposta che il modello scrive | Di solito la maggior parte della fattura | Accorcia le risposte, limita l'output massimo, abbassa il livello di effort |
| Contesto re-inviato | L'API e' stateless, quindi la cronologia viene re-inviata a ogni turno | Il costo totale della conversazione cresce con il quadrato del numero di turni | Prompt caching (letture a circa 0.1x sul prefisso in cache) |
| Token di ragionamento | Ragionamento sempre attivo (Fable 5) o un'impostazione di effort elevata | Puo' superare di gran lunga la risposta che vedi davvero | Adatta l'effort al compito, usa un livello non pensante per il lavoro semplice |
| Deriva del tokenizer | Un modello piu' recente conta lo stesso testo come piu' token | ~+30% da Sonnet 4.6 a Sonnet 5 | Ri-misura i conteggi di token dopo qualsiasi cambio di modello, poi rifai il budget |
| Retry e loop di strumenti | Errori transitori, rifiuti, giri di andata e ritorno degli agenti | Ogni tentativo fallito puo' essere rifatturato | Idempotenza piu' backoff, mantieni i loop degli strumenti limitati |
| Lavoro in background non batchato | Eseguire sull'API live lavori che tollerano la latenza | Prezzo pieno per lavoro che potrebbe aspettare | Batch API (-50% su tutto) |
La maggior parte della fattura e' opzionale
Rileggi quella tabella e nota la colonna a destra. Quasi ogni moltiplicatore ha uno sconto seduto di fronte a se', e i tre piu' grandi non sono "passa a un modello piu' economico" - sono cose che puoi fare sul modello che gia' usi.
- Prompt caching attacca direttamente il contesto re-inviato. Quel system prompt da 1,500 token che invii a ogni turno puo' essere messo in cache una volta e poi riletto a circa un decimo del prezzo di input a ogni turno successivo. C'e' un piccolo sovrapprezzo una tantum per scrivere la cache, quindi conviene proprio quando riutilizzi molto lo stesso contesto, che e' esattamente cio' che fa una funzione di chat.
- La Batch API toglie il 50 percento su tutto per il lavoro che puo' tollerare un po' di latenza - riassunti notturni, classificazione di massa, qualunque cosa un utente non stia aspettando in tempo reale.
- Dimensionare correttamente il modello e l'output - inviare la meta' facile del tuo traffico a un livello piu' economico, limitare la lunghezza della risposta, scegliere un livello di effort di proposito - riduce il lato output a 5 volte della fattura senza cambiare una sola risposta a cui gli utenti tengono.
Impilate nell'ordine giusto queste mosse possono tagliare una fattura di piu' della meta' senza peggiorare l'esperienza, cosa a cui e' dedicato un intero articolo a se'. Se sei ancora nella fase in cui decidi se una funzione di AI valga la pena di essere costruita del tutto, il punto di partenza onesto e' lo stesso che questo articolo sostiene: stima a partire dal percorso reale della chiamata, poi confrontalo con quanto vale il compito. La nostra guida all'automazione AI pratica per le piccole imprese e' una buona tappa successiva.
