Un’API LLM a basso costo può diventare cara per chi programma con agenti AI

Un modello può essere economico per token e costoso per sviluppatore nello stesso momento. Non è una contraddizione: si stanno confrontando due prodotti diversi.

Da una parte c’è un’API a consumo, in cui ogni token aumenta la fattura. Dall’altra c’è un abbonamento per il coding con un costo più prevedibile per l’utente, entro le condizioni d’uso e le quote previste. Per un agente autonomo che scandaglia repository, mantiene contesti molto lunghi e produce molte iterazioni, la domanda giusta non è quindi soltanto «qual è il modello meno caro per token?». È: quando si ferma il costo marginale per l’utente e quanto lavoro reale regge il piano?

Il prezzo basso non mette un limite alla spesa

GLM-5.2 è indicato a 1,40 dollari per milione di token in input, 0,26 dollari per milione di token in input da cache e 4,40 dollari per milione di token in output. 1 Sono tariffe interessanti per un uso API normale, ma su volumi molto elevati la scala cambia rapidamente:

• 1 miliardo di token in input non memorizzato in cache: 1.400 dollari;
• 1 miliardo di token in input da cache: 260 dollari;
• 1 miliardo di token in output: 4.400 dollari.

L’output è particolarmente rilevante nel coding con agenti. Un agente non si limita a leggere codice e documentazione: genera piani, modifiche, test, spiegazioni, chiamate agli strumenti e nuovi tentativi. Un flusso di lavoro con output consistente può quindi costare molto più di quanto lasci intuire il prezzo dell’input.

La cache può cambiare sensibilmente il risultato. Il contesto riutilizzato viene fatturato a una tariffa molto inferiore, ma il conto finale dipende sempre dalla composizione effettiva fra input non in cache, input in cache e output. 1

Perché il confronto sui costi giornalieri va letto con cautela

È circolato un confronto che colloca l’uso API di GLM-5.2 attorno a 7.800 yuan al giorno, a fronte di un costo fisso settimanale molto più basso per un abbonamento Codex. Il punto di fondo è reale — consumo a tariffazione variabile contro quota inclusa in un abbonamento — ma il volume di token richiede contesto.

Ai prezzi pubblicati per GLM-5.2, decine di miliardi di token in input non in cache, da soli, costerebbero decine di migliaia di dollari al giorno; l’output su quella scala costerebbe ancora di più. 1 Una spesa di 7.800 yuan al giorno potrebbe invece riflettere un volume fatturabile effettivo più basso, un’alta percentuale di input da cache, uno specifico rapporto input/output, prezzi scontati oppure una diversa base tariffaria.

La conclusione pratica è semplice: il totale dei token non basta. Per confrontare due flussi di coding AI bisogna misurare almeno:

1. token in input non in cache;
2. token in input da cache;
3. token in output;
4. finestre di reset e limiti del piano;
5. eventuale passaggio a consumo una volta esaurita la quota.

L’abbonamento limita la spesa dell’utente, non rende l’inferenza gratuita

Un abbonamento non elimina il costo dell’inferenza: sposta la variabilità. Con un piano mensile fisso, uno sviluppatore che resta entro l’uso consentito può ricevere un valore API equivalente superiore al prezzo pagato. L’utente ottiene un budget più prevedibile; il fornitore gestisce il rischio con finestre mobili, limiti di velocità, priorità, crediti e regole di uso corretto.

Ecco perché un’API più economica può convivere con un abbonamento di coding più conveniente per un utente molto intenso. Il prezzo API è il costo marginale diretto del calcolo. L’abbonamento è un’offerta aggregata e limitata: può essere ottima per molti utenti, ma non equivale a throughput illimitato.

Anche i piani di coding a canone possono essere fortemente misurati

La distinzione decisiva non è fra modelli cinesi e stranieri. È fra un contatore di token senza fine, un portafoglio di crediti e un pacchetto con quote abbastanza generose da coprire il carico reale.

GLM Coding Plan dichiara due vincoli: una quota a punti con finestra mobile di cinque ore e una quota settimanale. I limiti pubblicati includono, per il piano Pro, 12.000 punti ogni cinque ore e 60.000 punti alla settimana; per Max, 28.000 e 140.000 punti. Il consumo è calcolato combinando token in input, input da cache e output mediante coefficienti specifici per modello. 2

Qoder rende il meccanismo dei crediti ancora più esplicito. I piani a pagamento includono rispettivamente 2.000, 6.000 o 20.000 crediti mensili per i modelli premium; esauriti i crediti, il servizio passa a un modello base con messaggi limitati. Qoder precisa inoltre che le risorse premium incluse corrispondono al valore dell’abbonamento più eventuali risorse bonus. 17

Per chi esegue spesso attività autonome e di lunga durata, formule di questo tipo possono assomigliare più a un consumo prepagato con pagamento mensile che a un vero accesso senza limiti.

I moltiplicatori nelle ore di punta rendono visibile il vincolo di capacità

Le quote non sono l’unico freno. Un fornitore può anche variare la velocità con cui si consuma la quota nei momenti di maggiore domanda.

La documentazione attuale di Z.ai indica che GLM-5.3 consuma quota con moltiplicatore 1× fuori punta e 3× nelle ore di punta; per GLM-5.3-Flash i valori indicati sono 0,4× e 1,2×. 4 La panoramica del GLM Coding Plan identifica inoltre una finestra di punta nei giorni feriali, dalle 14:00 alle 18:00, UTC+8. 2

È un meccanismo di gestione della capacità: il prezzo dell’abbonamento non cambia, ma nelle ore più affollate la quantità di lavoro coperta dalla quota può ridursi. Non va però esteso automaticamente a ogni piano o periodo di GLM-5.2: occorre verificare le condizioni correnti dello specifico piano.

Cosa dimostrano — e cosa non dimostrano — le fonti sull’accesso

Segnalazioni su quote giornaliere esaurite, minore disponibilità di GLM-5.2, cache di breve durata, batching poco efficiente fra utenti o carenze di capacità di inferenza possono essere plausibili, ma non tutte sono dimostrate dai materiali qui esaminati.

La documentazione primaria disponibile conferma chiaramente massimali di quota, contabilità a punti pesata sui token e moltiplicatori legati all’orario. 24 Da sola, però, non verifica una spiegazione specifica del fornitore per ogni problema di accesso segnalato. In una decisione d’acquisto, le testimonianze informali dovrebbero quindi essere considerate segnali da mettere alla prova, non fatti conclusi.

La prova utile è un test sul carico di lavoro reale e negli orari in cui opera il team: dimensione dei repository, comportamento della cache, lunghezza degli output, agenti concorrenti, tempi di coda e comportamento al raggiungimento delle soglie contano più di un singolo listino.

La regola d’acquisto per i team che usano agenti intensivamente

Le API cinesi a basso costo restano interessanti per inferenza leggera o prevedibile, soprattutto quando il contesto può essere riutilizzato dalla cache. 1 Sono una scelta solida per chi vuole controllo diretto dell’API e sa governare con attenzione il budget token.

Il coding AI ad alta intensità è però un problema di acquisto diverso. Se un agente consuma volumi sostenuti, l’opzione migliore tende a essere quella che unisce:

• un tetto mensile prevedibile;
• una quota che regga le normali giornate di lavoro;
• regole chiare per reset e superamento dei limiti;
• accesso stabile nelle ore di punta;
• capacità sufficiente per attività parallele.

In breve: confrontare il lavoro utile effettivamente disponibile ogni mese, non soltanto il prezzo API di listino. Un modello a consumo economico vince quando l’utilizzo è controllato. Un abbonamento vince solo se i suoi limiti sono trasparenti e abbastanza ampi per il carico reale degli agenti.