Prezzi per contesti lunghi: fino a 6.7x, invisibili nei gateway

Il prezzo mostrato nella pagina di un modello su un gateway non coincide più con quello in fattura quando il prompt diventa lungo. Abbiamo inviato richieste tramite un grande aggregatore multi-provider, subito sotto e subito sopra ogni soglia di lunghezza documentata, per nove modelli con prezzi a scaglioni. Cinque hanno addebitato esattamente 2x il prezzo indicato nella pagina oltre la prima soglia. I tre modelli Alibaba sono saliti fino a 3x, 3x e 6.7x all’ultimo scaglione. Un modello servito da Azure ha addebitato 1.25x la tariffa pubblicata per l’endpoint su entrambi i lati della soglia, per poi raddoppiare. Le pagine non riportano nulla di tutto questo. Il meccanismo è documentato dai vendor: Google, OpenAI, xAI, Alibaba, ByteDance e MiniMax ricalcolano il prezzo dell’intera richiesta, output incluso, quando l’input supera una soglia di 32K, 128K, 200k, 256K, 272K o 512k token. Questo articolo mostra prima le fatture, poi le tabelle degli scaglioni su cui si basano e infine le impostazioni per mantenere una richiesta sotto la soglia.

TL;DR

• Tramite un aggregatore le cui pagine mostrano un solo prezzo, nove modelli a scaglioni hanno addebitato da 1.8x a 6.7x oltre la soglia del vendor. GPT-5.6 Luna tramite Azure ha addebitato 1.25x il prezzo indicato.
• qwen3.7-flash è passato da $0.03 a $0.10 e poi a $0.20 per milione di token in input, alle soglie di 32K e 256K. qwen3-coder-plus si è fermato a 3x, mentre il vendor indica 6x.
• Quando l’input supera una soglia compresa tra 32K e 512k token, i vendor ricalcolano il prezzo dell’intera richiesta, output incluso.
• Limitate l’input, non l’output: Claude Code /autocompact, Codex model_context_window, trigger di compattazione nelle API.

I gateway addebitano il prezzo indicato nella pagina?

No, quando il prompt diventa lungo. Per capire di quanto cambia servono due dati per ogni intermediario: i metadati tariffari pubblicati dal gateway e il costo effettivamente dichiarato per una richiesta su entrambi i lati della soglia.

Un grande aggregatore multi-provider pubblica il proprio catalogo con un array pricing.overrides: un prezzo base più regole condizionali come min_prompt_tokens: 200000, associate alle tariffe superiori. Per i modelli DeepSeek e Tencent include anche finestre utc_start / utc_end per le tariffe fuori picco. Nel catalogo acquisito il 2026-09-01, 60 voci contenevano override, tra cui i modelli Gemini Pro, Grok 4.x, qwen3.7-plus, qwen3.7-flash, qwen3-coder-plus, i modelli Seed 2.0 e l’intera famiglia GPT-5.6 alla soglia di 272,000. Le pagine dei modelli mostrano solo il prezzo base. Lo scaglione è nei metadati. Inoltre, i metadati non sempre riproducono tutti gli scaglioni del vendor: qwen3-coder-plus contiene regole a 32,000 e 128,000, ma nessuna per il quarto scaglione del vendor, a 256K.

Abbiamo quindi inviato richieste su entrambi i lati di ogni soglia documentata tramite quell’aggregatore, attivando la contabilizzazione dell’utilizzo (l’aggregatore restituisce nella risposta l’importo addebitato) e registrando l’endpoint usato. Sullo stesso aggregatore, un model id può instradare verso più host upstream, ciascuno con un prezzo diverso, che l’aggregatore chiama endpoint. Abbiamo eseguito due test per ogni punto, il 2026-09-02 e il 2026-09-03:

Le pagine sono state acquisite lo stesso giorno delle fatture. Mostrano un solo prezzo principale, una tabella per endpoint e nessuno scaglione basato sulla lunghezza. Tutti gli addebiti hanno seguito i metadati fino all’ultimo token. Tutti e nove i modelli sono passati allo scaglione successivo alla prima soglia del vendor, applicando il moltiplicatore previsto. Per i tre modelli Alibaba, la fattura ha seguito una scala che la pagina non menziona: qwen3.7-flash è passato da $0.03 a $0.10 a 32K, poi a $0.20 a 256K, cioè 6.7x il prezzo di una pagina che mostra $0.03. Anche GPT-5.6 Luna è passato allo scaglione successivo, con una differenza aggiuntiva: ogni esecuzione servita da Azure è stata addebitata a 1.25x rispetto al prezzo indicato per l’endpoint Azure, sia sotto sia sopra la soglia ($0.275 contro $0.22, $0.50 e $0.55 contro $0.40 e $0.44). Questo sovrapprezzo non compare né nella pagina né nei metadati dell’endpoint.

La scala può anche fermarsi prima di quella del vendor. Per qwen3-coder-plus, il prezzo è salito a 1.8x a 32K e a 3x a 128K, poi è rimasto a $1.95 per milione fino a 276k token. Nel listino Alibaba, invece, a 256K passa a $6 in input e $60 in output, rispettivamente sei e dodici volte il prezzo base. I metadati dell’aggregatore non contengono una regola a 256K, quindi l’addebito non è cambiato. Dall’esterno non è possibile sapere se l’aggregatore assorba la differenza o acquisti con un contratto diverso. Possiamo però verificare che la fattura segue i metadati e che metadati e pagina sono due documenti distinti.

La mancanza di trasparenza non è quindi tra metadati e fattura, ma tra la pagina e gli altri due. Il prezzo principale della pagina corrisponde alla tariffa dell’endpoint più economico nella tabella sottostante, non a quella dell’endpoint che servirà la richiesta. Nessuno dei due prezzi riporta la condizione sulla lunghezza. Una scheda modello con un solo prezzo non indica lo scaglione, quale endpoint servirà la richiesta successiva o se l’endpoint di cui state leggendo il prezzo sia effettivamente accessibile dal vostro account.

La regola pratica è semplice. Leggete i prezzi machine-readable del modello usato, a livello di endpoint, e cercate eventuali condizioni sulla lunghezza. Poi inviate una richiesta su ciascun lato della soglia con la contabilizzazione dell’utilizzo attiva e confrontate il costo dichiarato. Se l’addebito del gateway aumenta alla soglia ma la pagina non lo dice, il gateway sta applicando una regola del vendor senza mostrarla. Se resta invariato quando quello del vendor aumenta, il gateway serve il modello da un host con prezzi diversi oppure assorbe la differenza. Solo il primo caso è stabile nel tempo.

Dove sono le soglie e come si applicano gli scaglioni?

Sei vendor pubblicano una soglia di lunghezza. Per ogni modello che specifica la regola, la tariffa superiore si applica a tutti i token della richiesta, output incluso. Alla maggior parte delle prime soglie l’aumento è di 2x, ma gli scaglioni continuano a salire: 3x all’unica soglia di qwen3.7-plus, 6.7x in input al terzo scaglione di qwen3.7-flash, 6x in input e 12x in output al quarto scaglione di qwen3-coder-plus. I prezzi sono per milione di token e provengono dalle pagine tariffarie dei vendor acquisite il 2026-09-01.

Ci sono due dettagli sui limiti da riportare nel codice di fatturazione. Le due pagine di Google differiscono di un token: la nota di Vertex dice “maggiore o uguale a 200K”, mentre la tabella dei prezzi della Gemini API dice “prompt > 200k token”. Alibaba definisce inoltre K in modo esplicito: 128K equivale a 128,000 token e 256K a 256,000, non a potenze di due.

Lo scaglione è determinato solo dalla lunghezza dell’input, ma si applica all’intera richiesta e a ogni token, output incluso. Il costo marginale del token che supera la soglia equivale quindi a tutto il sovrapprezzo applicato ai token precedenti. Con Gemini 2.5 Pro, un prompt da 199,999 token costa $0.25 in input. A 200,001 token costa $0.50, mentre una risposta da 4,000 token passa da $0.04 a $0.06. Un token in più comporta $0.27 in più.

Per qwen3.7-plus l’aumento è di 3x: alla tariffa ufficiale, un prompt da 255,029 token costa $0.102, mentre uno da 257,332 token costa $0.309. Su qwen3-coder-plus lo stesso meccanismo si accumula su quattro scaglioni. Un prompt da 260k token viene quindi addebitato a una tariffa per token sei volte superiore rispetto a uno da 30k, e il relativo output a dodici volte tanto.

La regola è visibile su una fattura reale, non solo nella tabella del vendor. Gli scaglioni ufficiali di qwen3.5-plus sono $0.40 e $0.50 per milione di token in input alla soglia di 256K. Nella nostra fattura del gateway, il costo per token in input differiva esattamente di 1.25x tra dieci esecuzioni sotto la soglia, a 243k token, e 24 esecuzioni sopra, da 256k a 321k, mentre il prezzo dell’output restava invariato. La richiesta da 259k non ha pagato 1.25x solo sugli ultimi 3k token, ma su tutti.

In un agent che accumula la cronologia, il superamento avviene a metà sessione e senza segnali: il turno che oltrepassa la soglia paga il sovrapprezzo per tutti i turni precedenti inclusi nel contesto. Ogni turno successivo continua a pagarlo finché il contesto non viene ridotto.

Le capacità cambiano alla stessa soglia?

No. Abbiamo eseguito questa misura perché è facile scambiare lo scaglione tariffario per un limite di capacità, ma non lo è. Su due modelli Qwen con la soglia a 256K, abbiamo inserito a cinque profondità un needle con salt, cioè un fatto su una sola riga contenente un codice casuale diverso per ogni esecuzione. Entrambi i modelli lo hanno recuperato 30 volte su 30 a 243k, 269k e 320k token, con thinking disattivato. La latenza è cresciuta linearmente con la lunghezza, senza salti: 15.2 s, 17.0 s e 20.5 s di mediana su qwen3.7-plus. Un’attività più difficile, contare K occorrenze rare distribuite nell’intero log, peggiorava invece con la lunghezza. Su qwen3.7-plus, la quota rilevata è scesa dal 74% a 128k al 60% a 192k, al 58% a 243k e al 45% a 320k. Il calo inizia ben prima della soglia tariffaria, e i punti ai suoi due lati seguono la stessa pendenza.

La documentazione di Anthropic dà un nome a questo effetto graduale: all’aumentare dei token, accuratezza e capacità di recupero peggiorano, un fenomeno chiamato context rot. Il fenomeno è reale e continuo, ma non dipende dalla soglia tariffaria.

Come mantenere una richiesta sotto la soglia?

Limitate l’input, non l’output. Lo scaglione dipende dalla lunghezza dell’input della richiesta, quindi max_tokens, che limita l’output, non serve. Bisogna intervenire sulle impostazioni che limitano ciò che il client invia. Esistono a quattro livelli.

Queste sono le impostazioni che limitano il prompt, suddivise per livello. La colonna “Sotto uno scaglione?” indica quali accettano un numero assoluto di token e possono quindi essere configurate appena sotto una soglia tariffaria. Le impostazioni relative alla finestra mantengono invece la richiesta entro la finestra di contesto del modello, che è un valore diverso.

La tabella porta a due conclusioni. In un coding agent configurato con un modello a scaglioni, la finestra di compattazione è l’impostazione che sostituisce il salto di prezzo con un riepilogo. Va configurata con un numero assoluto di token appena inferiore alla soglia, non come frazione di una finestra da 1M. Inoltre, le due impostazioni di sicurezza più comuni, Responses truncation: "auto" e middle-out dell’aggregatore, proteggono solo dalla finestra massima del modello. Sui modelli Gemini e GPT-5.6 a scaglioni intervengono a 1M, non a 200,000 o 272,000 token, dove cambia il prezzo. Evitano il fallimento della richiesta, ma non il superamento della soglia tariffaria.

Non fate affidamento sulla cache per restare sotto la soglia. Il prompt caching riduce il costo, ma sui modelli Google non cambia lo scaglione, perché anche le letture dalla cache seguono lo stesso scaglione di lunghezza: un prefisso in cache da 150k più 60k di contesto nuovo costituisce un prompt da 210k e viene fatturato come tale. La capacità riservata elimina il problema alla radice, perché le provisioned throughput unit (PTU) vengono fatturate a ore, indipendentemente dai token. Se superare la soglia conviene, fatelo consapevolmente. Le misure sopra mostrano che il modello non peggiora proprio in corrispondenza della soglia. La decisione dipende solo dal valore del contesto marginale rispetto a un moltiplicatore di 2x, 3x o, negli scaglioni più alti, 6.7x sull’intera richiesta.

Come lo gestisce Synthorai

Uno scaglione basato sulla lunghezza è una condizione tariffaria, quindi il gateway lo tratta come tale. La scheda prezzi di un modello può contenere un elenco di scaglioni indicizzati per soglia di token in input. Ogni richiesta viene valorizzata secondo lo scaglione selezionato dalla lunghezza del proprio prompt, applicandolo a tutti i token, esattamente come fa il vendor. È il meccanismo usato nella fattura di qwen3.5-plus mostrata sopra. Il record di utilizzo conserva il numero di token del prompt e la versione del prezzo insieme al costo calcolato. È quindi possibile ricostruire una fattura fino alla singola richiesta che ha superato la soglia. Lo scaglione usato per calcolare il prezzo si può rileggere dal record di utilizzo, non soltanto da una tabella dei prezzi.

FAQ

La tariffa superiore per i contesti lunghi si applica solo ai token oltre la soglia?

No. Ogni vendor che documenta la regola ricalcola l’intera richiesta: Google parla di “tutti i token, sia in input sia in output, addebitati alle tariffe per contesti lunghi”, OpenAI di “intera richiesta”, xAI di “tutti i token della richiesta” e Alibaba di “tutti i token della richiesta addebitati al prezzo unitario dello scaglione corrispondente”. Un prompt che supera la soglia di un solo token paga il sovrapprezzo su tutti i token precedenti.

I gateway API applicano gli scaglioni tariffari per contesti lunghi?

Sì, nelle nostre misure. Tramite un grande aggregatore, nove modelli a scaglioni sono stati fatturati alla tariffa superiore del vendor oltre la relativa soglia, anche se le pagine dei modelli mostravano un solo prezzo. Lo scaglione compare nei metadati tariffari del gateway, non nella pagina. I metadati possono anche omettere uno scaglione del vendor, come è successo per qwen3-coder-plus oltre 256K.

max_tokens mantiene una richiesta sotto uno scaglione tariffario?

No. max_tokens limita l’output, mentre lo scaglione è determinato dalla lunghezza dell’input. Servono impostazioni che limitino il prompt: una finestra di compattazione o un limite di token nell’agent, come Claude Code /autocompact o Codex model_context_window, un trigger di compattazione nell’API oppure una troncatura lato client prima dell’invio.

La qualità del modello cala alla soglia tariffaria?

Non nelle nostre misure. Su due modelli Qwen a scaglioni, il recupero del needle è stato perfetto su entrambi i lati della soglia di 256K, mentre un’attività di conteggio peggiorava gradualmente con la lunghezza, senza salti in corrispondenza della soglia. Lo scaglione è una regola commerciale. Il peggioramento delle capacità sui contesti lunghi è reale, ma continuo.

Prezzi e regole sono tratti dalle pagine tariffarie dei vendor acquisite il 2026-09-01; le impostazioni di agent e API dalla documentazione collegata il 2026-09-02; le misure di fatturazione sono state eseguite dal 2026-09-01 al 2026-09-03 con thinking disattivato, prompt con salt e due esecuzioni per ogni punto dell’aggregatore. I prezzi cambiano; controllate la fonte collegata prima di inserire una soglia nel codice di fatturazione.

Articoli correlati: guida alle unità di fatturazione (il livello dei modificatori approfondito in questo articolo), anatomia del consumo di token, come funziona il prompt caching, misure delle soglie minime della cache.

← Torna al blog