coding agent AI

Shrinktoken: perché i piani AI da 20 euro durano sempre meno



Indirizzo copiato

I coding agent AI promettono produttività a prezzi stabili, ma quote opache, limiti temporali e consumo legato ai task riducono il valore reale degli abbonamenti. Lo shrinktoken colpisce soprattutto gli utenti esperti, tra Codex, Claude Code, Antigravity, Manus e soluzioni locali come Ollama

Pubblicato il 16 giu 2026

Andrea Tironi

Project Manager – Digital Transformation



Agenti AI coding
Foto Shutterstock
AI Questions Icon
Chiedi all'AI
Riassumi questo articolo
Approfondisci con altre fonti


Hai presente le Pringles? No, non la roba dentro. La scatola. Quella scatola cilindrica arancione che negli anni si è tenacemente rifiutata di cambiare prezzo, ma ha trovato altri modi per risparmiare: meno chips, più aria, quantità nominale identica. Si chiama shrinkflation: il prodotto si restringe, il prezzo resta, l’acquirente paga lo stesso e ottiene meno. È un giochetto vecchio quanto il mercato di massa, e funziona perché è difficile da vedere finché non metti a confronto due confezioni comprate a distanza di anni.

Benvenuti nel mondo dei coding agent AI, dove la stessa cosa sta accadendo, in modo ancora più silenzioso.

Venti euro al mese per ChatGPT Plus con Codex. Venti dollari per Claude Pro con Claude Code. Venti euro per Google AI Pro con Antigravity. Prezzi stabili, comunicazione stabile, pagina di marketing stabile. Quel che cambia, però, è invisibile: quanto lavoro reale riesci a fare prima che il sistema ti freni, ti rallenti o ti dica che hai esaurito la quota. Con task sempre più complessi, repository sempre più grandi, sessioni sempre più lunghe, il tuo abbonamento di fatto si è ristretto, anche se non è cambiato nulla sulla fattura.

Chiamiamolo con il nome che merita: shrinktoken.

Shrinktoken: il parallelo con la shrinkflation

La shrinkflation è un fenomeno economico ben documentato: i produttori, sotto pressione dei costi, riducono la quantità del prodotto senza ridurre il prezzo. Non è illegale. Non è nemmeno sempre evidente. È però un trasferimento di valore dal consumatore al produttore mascherato da immobilismo.

La shrinktoken funziona in modo analogo, ma con una complessità in più: non è necessariamente il risultato di una scelta deliberata dei vendor. È il risultato strutturale di un’asimmetria informativa tra come vengono comunicati i piani e come vengono realmente consumati nella pratica.

I vendor misurano i consumi in unità opache: crediti (Manus), finestre temporali di 5 ore (Claude Code), quote giornaliere con refresh automatico (Codex), quota legata al “work done” dell’agente (Antigravity/Google). Nessuno di questi parametri ti dice, in modo diretto e comprensibile, quanti refactoring puoi fare prima di rallentare. Quante sessioni di debug puoi fare in una settimana. Quanti task multi-file puoi completare in un mese.

E qui entra il paradosso cruciale dello shrinktoken: più diventi bravo, più lo strumento ti costa.

Il menu dei coding agent: cosa compri davvero

Facciamo una fotografia, non una classifica. Quattro strumenti, quattro sistemi di quota, quattro modi di finire prima di quanto ti aspettavi.

Codex via ChatGPT Plus (circa 20 euro/mese)

Codex gira su ChatGPT Plus e porta con sé una finestra di utilizzo che OpenAI definisce con una certa vaghezza: 5 ore per local messages, con limit settimanali aggiuntivi per cloud tasks e code reviews. Il consumo su un singolo refactoring medio-grande, soprattutto con repository ampie, molte iterazioni e sessioni lunghe, può essere significativo.

In pratica: 2-3 sessioni pesanti al giorno possono portarti rapidamente a vedere messaggi di limitazione, soprattutto se i task sono agentico-intensivi. Plus è nato per un uso più tradizionale, e Codex ci è stato aggiunto sopra. Il risultato è uno strumento potente ma non pensato per un uso agentico continuo e quotidiano.

Claude Code (circa 20 dollari/mese su Claude Pro)

Claude Code condivide i limiti del piano Claude Pro, con finestre da 5 ore e tetti settimanali. Una sessione di refactoring medio-grande può consumare una parte significativa della finestra disponibile, soprattutto quando la sessione include un repository ampio, molte iterazioni di test, debugging e uso del modello ad alto consumo.

Il rischio maggiore è strutturale: sessioni ravvicinate nella stessa finestra, combinate con l’accumulo sui limiti settimanali, possono portare a rallentamenti reali in momenti critici di un progetto. Non è un fallimento del tool, è la logica del piano base che non è stata pensata per developer che lavorano intensivamente tutto il giorno.

Antigravity / Google AI Pro (circa 20 euro/mese)

Google AI Pro porta quota più generosa con refresh dichiarato ogni 5 ore, ma il meccanismo di consumo è legato al “work done” dell’agente, non semplicemente al numero di prompt inviati. Questo significa che refactoring multi-file, uso del terminale, cicli di test, browsing e task agentici complessi consumano proporzionalmente molto di più di prompt semplici.

Per chi lavora su progetti code-heavy, le limitazioni operative possono arrivare in poche ore di lavoro intensivo. Il vantaggio di Antigravity sta nell’integrazione con l’ecosistema Google, ma il sistema di quote rimane fondamentalmente opaco rispetto all’uso reale atteso.

Manus (circa 20 dollari/mese per il piano Pro)

Manus adotta un sistema a crediti: 4.000 al mese, con consumo che aumenta in base a complessità, durata, token, strumenti e risorse usate. Un task medio-grande non è necessariamente “killer” del piano, ma la matematica è impietosa: task standard consumano nell’ordine delle centinaia di crediti, task complessi possono avvicinarsi o superare i 900 crediti.

Una stima prudente: pochi task complessi esauriscono buona parte del budget mensile. Una decina di task medio-standard. Decine di task solo se sono leggeri. Il vantaggio del sistema a crediti è la trasparenza relativa del consumo, ma resta il problema di fondo: quanti crediti vale un task, lo scopri solo dopo averlo fatto.

Il paradosso del professionista: più sei bravo, più consumi

Qui sta il nucleo del problema, e vale la pena soffermarcisi perché è controintuitivo.

Un utente alle prime armi che chiede al coding agent di spiegare una funzione, di generare uno snippet semplice, di completare un metodo isolato, consuma pochissimo. I limiti del piano base gli sembrano infiniti. La sua esperienza è ottima, i limiti non li tocca mai.

Un developer esperto che usa l’agente per quello per cui è pensato, cioè refactoring su codebase reali, cicli di test, sessioni lunghe con molto contesto, debugging iterativo su più file, tocca i limiti con regolarità. E lo strumento si restringe esattamente nel momento in cui sarebbe più utile.

Lo shrinktoken colpisce i professionisti, non i curiosi. Ed è questa la sua ironia più acuta: il prodotto che si restringe di più è quello venduto a chi ha più bisogno che non si restringa.

C’è un altro elemento che complica il quadro: il contesto accumulato. Un agente che lavora su un repository da settimane ha interiorizzato struttura, convenzioni, variabili ricorrenti. Ricominciare con un nuovo provider non è neutro: si perde contesto, si ricomincia a formare lo strumento, si spende tempo e, paradossalmente, si spendono più token per ricostruire ciò che l’agente precedente già sapeva. Il costo di switching non è solo economico, è cognitivo.

Ollama e il sogno del free: gratis sì, ma fino a dove?

Nel panorama dei coding agent, Ollama occupa una posizione peculiare: è la risposta locale, open source, tecnicamente illimitata in termini di quota. Nessun credito, nessuna finestra di 5 ore, nessun limite settimanale. Il modello gira sul tuo hardware, il costo marginale per token è zero.

Però “gratis” è sempre una parola che nasconde i costi altrove. Con Ollama, i costi si spostano su tre assi.

• Hardware: i modelli di coding di qualità (DeepSeek Coder, Qwen2.5-Coder, CodeLlama) richiedono GPU con almeno 16-24GB di VRAM per girare in modo decente. Se non hai già questa infrastruttura, il costo di averla supera abbondantemente il piano Pro di qualsiasi provider cloud.

• Capacità: i modelli open source di coding hanno fatto progressi enormi, ma su task agentici complessi, refactoring su codebase grandi e ragionamento multi-step, il gap con i modelli frontier dei provider commerciali rimane reale. Non insormontabile, ma reale.

• Attenzione e configurazione: Ollama non è plug-and-play per il coding agentico. Richiede configurazione, integrazione con editor, scelta del modello giusto per il task. Il tempo investito è un costo reale.

Detto questo, per chi ha già l’infrastruttura o per task di media complessità su codebase contenute, Ollama è un’opzione concreta. E soprattutto, non ha shrinktoken: il piano non si esaurisce mai, perché non c’è piano.

Come ridurre il consumo dei coding agent AI

La buona notizia è che lo shrinktoken si può parzialmente contrastare con una gestione consapevole dei prompt. Il token è una risorsa, e come tutte le risorse va trattata con rispetto, senza diventare nevrotici.

Alcune pratiche concrete che fanno differenza.

Contesto minimo necessario, non massimo disponibile

L’errore più comune è incollare tutto il codice “per sicurezza”. Spesso l’agente ha bisogno solo del file rilevante, non dell’intera codebase. Sii selettivo: indica esplicitamente quale file o funzione riguarda il task, e lascia che l’agente chieda se ha bisogno di altro.

Sessioni chirurgiche, non sessioni aperte

Una sessione lunga con molti task diversi accumula contesto inutile nel tempo. Meglio sessioni brevi e focalizzate su un obiettivo preciso. Al termine di ogni sessione, salva un “riassunto di sessione” generato dall’agente stesso: è più economico da ricaricare in contesto rispetto all’intera conversazione.

Istruzioni precise, non conversazioni esplorative

Il prompt esplorativo (“cosa potresti fare con questo codice?”) consuma token per rispondere a una domanda aperta. Il prompt preciso (“refactorizza questa funzione eliminando la dipendenza da X e aggiungendo un test unitario”) consuma token per fare il lavoro. La seconda opzione è più economica e produce risultati migliori.

Sfrutta le ore di bassa richiesta e i refresh di finestra

Per i provider con finestre temporali (Claude Code, Codex), pianificare i task più pesanti subito dopo un refresh di finestra massimizza l’utilizzo. Non è ottimizzazione esasperata, è gestione sensata di una risorsa limitata.

Scegliere, cambiare, sopravvivere: la bussola per orientarsi

La domanda che riceviamo più spesso è: quale coding agent scelgo? La risposta onesta è: dipende da come lavori davvero, non da come pensi di lavorare.

Alcune coordinate pratiche per orientarsi.

• Se lavori su pochi progetti focalizzati con sessioni non quotidiane, Codex via ChatGPT Plus è sufficiente. L’architettura cloud task lo rende adatto a sessioni concentrate, non al ritmo serrato da developer full-time.

• Se il tuo workflow include molto debug iterativo e lunghe sessioni di ragionamento, Claude Code offre la migliore qualità di output per task complessi, ma richiede una gestione attenta delle finestre settimanali.

• Se sei già dentro l’ecosistema Google (GCP, Firebase, Android Studio), Antigravity offre integrazione nativa che vale il costo di quota, ma monitora il consumo su task agentici pesanti.

• Se hai necessità di automazione generalista con task misti (non solo coding), Manus è il candidato più versatile, con il vantaggio di un sistema di crediti relativamente più leggibile.

• Se hai infrastruttura GPU o lavori su codebase medio-piccole con task ripetitivi, Ollama è un complemento potente da affiancare a uno dei provider commerciali, non necessariamente un sostituto.

Si può cambiare? Sì. Ma il cambio ha un costo di attrito reale. Il contesto accumulato, le convenzioni apprese dallo strumento, le scorciatoie di prompt che hai sviluppato: tutto questo si azzera o quasi. Non è impossibile, ma va messo in conto come parte del costo di switching, e non è trascurabile su progetti in corso.

Le domande pratiche rimangono però in piedi anche dopo aver scelto: i modelli open source su Ollama funzionano davvero per il mio use case specifico? Come costruisco un prompt che spende meno token senza rinunciare alla qualità dell’output? Come organizzo il workflow per non trovarmi senza quota nel momento peggiore? Sono domande alle quali si risponde solo con la pratica, e la pratica richiede tempo che il piano base potrebbe non concederti.

Il prezzo vero dei coding agent AI

La shrinkflation delle Pringles è visibile, almeno in retrospettiva. Puoi pesare la confezione, confrontarla con quella di cinque anni fa, calcolare il delta. Lo shrinktoken è strutturalmente più difficile da vedere, perché il consumo dipende da come lavori tu, dai tuoi task, dalla tua codebase, dalla tua abitudine di usare molto contesto o poco. Due persone con lo stesso abbonamento possono avere esperienze radicalmente diverse.

Questo è il vero problema dell’asimmetria informativa che i vendor oggi non risolvono: non ti danno strumenti per stimare il tuo consumo reale prima di averlo già superato. La pagina marketing mostra la quota, non mostra quanti dei tuoi task reali quella quota supporta.

Il costo di un coding agent non è il canone mensile. È il rapporto tra output reale che ottieni e aspettative che il marketing ha costruito. Finché questo non diventa trasparente, finché i provider non offrono simulatori di consumo o benchmark realistici per tipo di task, lo shrinktoken continuerà a sorprendere chi lo usa sul serio.

Nel frattempo, la raccomandazione è quella di sempre: leggi le note a piè di pagina, non solo il titolo. Nel mondo dei coding agent, le note a piè di pagina si chiamano “rate limits”, “fair use policy”, “subject to change without notice”.

Le Pringles almeno avevano l’attenuante di dirlo in piccolo sulla scatola.

Partecipa alla community

guest

0 Commenti
Più recenti
Più votati
Inline Feedback
Vedi tutti i commenti

Articoli correlati

0
Lascia un commento, la tua opinione conta.x