Il downgrade è l'ultima leva, non la prima
Passare da Opus 4.8 a Sonnet 4.6 riduce i prezzi per token del 40 percento, e rigenera ogni risposta che il tuo prodotto fornisce. È la scelta a cui la maggior parte dei team ricorre per prima, ed è di solito prematura, perché due sconti più grandi si trovano già sul listino prezzi del modello che usi oggi: il prompt caching legge il contesto ripetuto a circa un decimo del prezzo dell'input, e la Batch API applica uno sconto fisso della metà a tutto ciò che può aspettare. Nessuno dei due cambia una sola risposta. Si sommano. E se li applichi per primi, il downgrade a cui ti stavi preparando spesso smette di essere necessario.
Per mantenere onesti i numeri continueremo a lavorare sullo stesso paziente: il chatbot di supporto di cui abbiamo smontato la fattura da $1,460 nella parte uno. Quattro leve, applicate in ordine, senza cambio di modello per il traffico che conta:
| Voce | Importo |
|---|---|
| Fattura parte 1 | $1,460 |
| + prompt caching | $1,332 |
| + routing | $799 |
| + riduzione output | $673 |
Il chatbot della parte 1, quattro leve dopo
Opus 4.8, 10,000 conversazioni / mese · leve applicate da sinistra a destra
Modellato sulle assunzioni della parte 1 (10,000 conversazioni a quattro turni; un blocco di sistema da 1,500 token; domande da 500 token, risposte da 700 token; Opus 4.8 a $5 / $25 per 1M). Il caching usa finestre da 5 minuti e rispetta il prefisso minimo memorizzabile in cache di Opus 4.8 da 4,096 token, quindi inizia a rendere solo dal turno 3. Il routing invia la metà più facile delle conversazioni a Haiku 4.5 ($1 / $5) e cambia quelle risposte. La riduzione taglia le risposte del ~30% lasciando l'input invariato, il che mantiene la stima conservativa.
Leva 1: il prompt caching, lo sconto nascosto nel tuo contesto ripetuto
La parte uno ha mostrato che il contesto reinviato è la voce più grande di una bolletta conversazionale: lo stesso system prompt e la stessa cronologia in crescita, rifatturati a ogni turno. Il caching attacca esattamente quella voce. Segni il prefisso stabile della tua richiesta, paghi un sovrapprezzo una tantum per scriverlo (1.25x il prezzo dell'input sul tier da 5 minuti, 2x sul tier da 1 ora), e ogni richiesta successiva che inizia con gli stessi byte lo rilegge a circa un decimo del prezzo.
| Tier di cache | Sovrapprezzo di scrittura | Prezzo di lettura | Si ripaga |
|---|---|---|---|
| 5 minuti | 1.25x il prezzo dell'input, una volta | ~0.1x il prezzo dell'input | Al 2° utilizzo del prefisso |
| 1 ora | 2x il prezzo dell'input, una volta | ~0.1x il prezzo dell'input | Al 3° utilizzo |
Due avvertenze oneste prima di dare per scontato il 90 percento. Primo, lo sconto si applica alla porzione in cache, non alla bolletta: il nostro chatbot scende da $1,460 a $1,332, un taglio del 9 percento, perché le sue conversazioni sono brevi. Su Opus 4.8 nulla sotto i 4,096 token può essere messo in cache, quindi una chat a quattro turni supera quella soglia solo al terzo turno; i turni più profondi e costosi ottengono lo sconto, quelli iniziali no. Secondo, il sovrapprezzo di scrittura fa sì che mettere in cache un prefisso che nessuno riutilizza sia un modo per pagare di più. Il caching dà il meglio dove il contesto è grande o le conversazioni sono profonde, che è esattamente dove la parte uno diceva che sta il dolore.
Leva 2: la Batch API, uno sconto fisso della metà su tutto ciò che può aspettare
La Batch API è lo sconto più semplice del catalogo: invii il lavoro in modo asincrono, ricevi i risultati nell'arco di minuti o ore, paghi il 50 percento del prezzo standard su ogni token del job, token in cache compresi. Non c'è alcun compromesso sulla qualità; è lo stesso modello che produce le stesse risposte, solo non mentre qualcuno guarda uno spinner.
Il punto sta nella definizione di "può aspettare". Un cliente nel mezzo di una conversazione non può, quindi il traffico dal vivo del nostro chatbot non ottiene nulla da questa leva, ed è per questo che non compare nel waterfall qui sopra. Ma quasi ogni prodotto AI porta con sé un carico di lavoro nascosto che può aspettare: i riepiloghi notturni di quelle conversazioni di supporto, la classificazione di massa, la generazione di report, le pipeline di contenuti. Prezzali separatamente ed elaborali in batch come impostazione predefinita; pagare la tariffa dal vivo per un lavoro che nessuno sta aspettando è la falla più silenziosa nella maggior parte delle bollette.
Leva 3: instrada in base alla difficoltà, non per impostazione predefinita
Non tutte le conversazioni hanno bisogno del tuo modello migliore. I reset di password e le domande sullo stato di consegna non richiedono Opus 4.8; richiedono una ricerca corretta e una frase cortese, che Haiku 4.5 fornisce a $1 / $5 per milione di token, cinque volte più economico per token. Nel nostro modello, inviare la metà più facile delle conversazioni a Haiku porta la bolletta da $1,332 a $799, il singolo passo più grande nel waterfall.
Tratta questa leva diversamente dalle due precedenti, perché è la prima che cambia gli output. Il caching e il batching restituiscono risposte identiche; il routing assegna alla fetta instradata un modello diverso. La disciplina che la mantiene sicura: classifica in modo conservativo, instrada solo il traffico che un modello più economico supera in modo dimostrabile sul tuo set di test, e mantieni un percorso di escalation verso il modello grande nel momento in cui la conversazione smette di essere facile.
Leva 4: riduci il lato output, perché viene fatturato a cinque volte l'input
Ogni modello Claude fissa il prezzo dei token di output a esattamente cinque volte l'input, quindi la lunghezza delle tue risposte è una decisione di pricing, che tu l'abbia presa deliberatamente o no. Le risposte di supporto imbottite di domande riformulate e convenevoli di chiusura costano soldi veri su larga scala. Istruire l'assistente a rispondere nella forma più breve che risolva completamente il ticket riduce le nostre risposte modellate di circa il 30 percento e la bolletta da $799 a $673, e sulla famiglia Opus l'impostazione di effort è lo stesso comando un livello più su: abbassala per il traffico di routine e il modello spende meno token di reasoning per arrivare allo stesso punto.
Il limite qui non è tecnico ma umano: taglia oltre il punto di utilità e le risposte iniziano a suonare brusche, il che si ripresenta più tardi sotto forma di contatti ripetuti. Elimina il riempimento, mantieni la sostanza.
Da dove arriva davvero il 50-90 percento
Somma le leve sul nostro chatbot e la fattura si attesta a $673, il 54 percento sotto il punto in cui la parte uno l'aveva lasciata, con la metà difficile del traffico ancora sullo stesso identico modello che produce le stesse identiche risposte. Se il tuo numero si avvicinerà di più al 50 o al 90 lo decidono due proprietà del tuo carico di lavoro: quanta parte del tuo input è contesto ripetuto, e quanto del tuo lavoro può aspettare.
| Carico di lavoro | Risparmiato |
|---|---|
| Chatbot di supporto dal vivo | -54% |
| Pipeline documentale notturna | -64% |
| Agent asincrono, contesto condiviso pesante | -88% |
Quanto è profondo il taglio dipende dalla forma
Quota della bolletta mensile risparmiata, modellata per carico di lavoro
Tre carichi di lavoro modellati, sempre con gli stessi modelli. Chatbot: le assunzioni della parte 1 più le tre leve sopra ($1,460 a $673). Pipeline: 60,000 documenti al mese su Sonnet 4.6 ($3 / $15), un blocco di istruzioni condiviso da 2,500 token (in cache) più un documento da 3,000 token in ingresso e 500 token in uscita, eseguiti di notte tramite la Batch API ($1,440 a $518). Agent: 100,000 chiamate asincrone al mese su Opus 4.8 con un pacchetto di contesto condiviso da 10,000 token tenuto caldo, 200 in ingresso / 300 in uscita per chiamata, elaborati in batch ($5,850 a $675). I cache hit dentro le esecuzioni Batch sono best effort, quindi considera gli estremi destri come tetti massimi.
Un chatbot dal vivo si colloca all'estremo più modesto, perché le conversazioni brevi entrano in cache tardi e nessuna parte del traffico dal vivo può essere elaborata in batch. Una pipeline documentale notturna se la cava meglio: il suo blocco di istruzioni entra perfettamente in cache e ogni token del job prende lo sconto batch. E l'agent asincrono con un grande pacchetto di contesto condiviso è la forma per cui gli sconti sono stati creati; nove decimi del suo input vengono letti dalla cache e l'intera esecuzione va in batch, quindi l'88 percento della bolletta semplicemente sparisce.
Il controllo di idoneità
Prima di toccare la stringa del modello, percorri una volta il tuo carico di lavoro lungo questa tabella.
| Leva | Il tuo carico di lavoro richiede | Risparmio realistico | Attenzione a |
|---|---|---|---|
| Prompt caching | Un prefisso stabile sopra il minimo del modello, riutilizzato entro la finestra di cache | ~90% di sconto sulla porzione ripetuta | Il sovrapprezzo di scrittura si ritorce contro sotto i 2-3 riutilizzi; le chat brevi iniziano a usare la cache tardi |
| Batch API | Tolleranza a una latenza di minuti-ore | -50% fisso sull'intero job | Mai per un utente in attesa; i cache hit dentro i batch sono best effort |
| Routing per difficoltà | Una fetta di traffico che un modello più economico gestisce in modo dimostrabile | Fino a 5x sulla fetta instradata | Cambia gli output; testa prima la qualità e mantieni un percorso di escalation |
| Riduzione output + effort | Bollette a forte componente di output (l'output costa 5x l'input) | Proporzionale al taglio | Troppo aggressiva suona come risposte brusche e incomplete |
Esegui l'audit in quest'ordine: prima il caching se un qualsiasi contesto si ripete, elabora in batch tutto ciò per cui un utente non sta aspettando, riduci l'output che tanto non stavi mai leggendo, poi instrada la fetta dimostrabilmente facile. Solo quando tutte e quattro sono a posto la questione del downgrade merita una risposta, e a quel punto è una questione molto più piccola. E se il numero a cui arrivi sembra ancora troppo alto per ciò che la funzionalità rende, la domanda non è più come farla girare a costo minore; è se debba esistere del tutto, che è esattamente lo scopo della parte tre.
