Un cron job silenzioso ti svuota il budget token: cosa non vedi nel repository

Non è il modello a bruciare i token, è un processo che cresce senza limiti

Un racconto tecnico pubblicato su dev.to descrive una scena che chiunque abbia mandato codice in produzione riconosce: il contatore delle richieste è basso, ma il consumo di token schizza. La diagnosi finale è netta: "token consumption is a rate, not a total" (Token Forensics: Finding the Process That Ate Your Free Allowance). Il colpevole non era il modello e nemmeno una singola chiamata sbagliata, ma un cron job che ogni cinque minuti caricava l'intera cronologia di un thread e la spediva al modello. Il thread era cresciuto fino a centinaia di messaggi, e il costo saliva in modo lineare mentre il numero di richieste restava piatto.

È un guasto che né la code review né una dashboard di richieste intercettano, perché tutto "sembra sano". Il problema vive nel tempo, non in una riga.

Cosa significa se il tuo codice l'ha scritto Lovable

Quando descrivi a Lovable "riassumi i thread ogni cinque minuti" o "aggiorna un digest periodico", ottieni codice che funziona alla prima esecuzione. Nel giorno del test il thread ha tre messaggi, l'input è minuscolo, tutto scorre. Il generatore non ha modo di sapere che quella stessa struttura, tra tre settimane, spedirà quattrocento messaggi a ogni giro.

Il pattern tipico è esattamente quello del racconto: una funzione che chiama get_full_thread() e passa tutto al modello, senza cache incrementale e senza un tetto sull'input. È codice corretto dal punto di vista sintattico e logico, ma con un difetto di scala nascosto. Lo stesso vale per job che rileggono tutta una tabella, ricostruiscono contesto da zero a ogni run o accumulano storico senza mai troncarlo.

Il risultato non è un errore che va in crash. È un costo che cresce in silenzio, una latenza che peggiora e — se usi un tier a quota — un servizio che un giorno smette di rispondere senza un motivo evidente nei log applicativi.

Perché ora ti serve un audit

Il motivo per cui questi problemi restano invisibili è semplice: mancano finché non fanno male. Nel repository non c'è un test che dica "questo input può crescere all'infinito", non c'è un vincolo che limiti la dimensione del contesto, non c'è nessuno che abbia detto ad alta voce "questo job ha un costo che dipende dalla dimensione dei dati". Con il codice generato dall'AI questa consapevolezza spesso non esiste, perché non l'hai scritta tu riga per riga.

Un audit come VibeInspect serve proprio a produrre un verdetto sullo stato reale del tuo repository. Carichi lo ZIP, gli specialisti AI analizzano il codice e ricevi un PDF con la diagnosi. Il codice sorgente viene cancellato al termine dell'analisi: niente server, nessuna persistenza.

Con il piano Diagnostic ottieni file, riga ed evidenze: quel cron job che rilegge tutto lo storico, la funzione che passa un input non limitato al modello, la query che ricostruisce il contesto da capo a ogni esecuzione. Non è un pentest e non corregge il codice al posto tuo, ma ti mostra dove stai accumulando un costo o un rischio che oggi non vedi. Il valore è avere finalmente un giudizio esterno su un codice che hai pubblicato fidandoti di uno strumento.

Un audit non ti garantisce sicurezza assoluta e non sostituisce il monitoraggio in produzione. Ti dà però un punto di partenza onesto: la lista dei posti in cui il tuo repository si comporta in modo diverso da come pensi.

Cosa un linter non vede

Un linter è ottimo per la forma. Segnala variabili inutilizzate, import mancanti, indentazioni sbagliate, funzioni troppo lunghe. Ma un linter non conosce il comportamento del tuo sistema nel tempo.

Nessun linter ti dirà che get_full_thread() restituisce un input che cresce senza limiti. Non sa che quella funzione viene chiamata da un cron ogni cinque minuti. Non collega la dimensione dei dati al costo per chiamata, perché non ha idea di quanti messaggi conterrà quel thread tra un mese. Vede una chiamata a funzione perfettamente valida e passa oltre.

La differenza è tra correttezza statica e comportamento a runtime. Il difetto del cron job non è un errore di stile: è una decisione architetturale — mandare tutto lo storico invece del solo delta — che nessuna regola di formattazione può intercettare. Servono occhi che ragionino sul flusso dei dati, sulla frequenza di esecuzione e sulla crescita degli input. È esattamente lo spazio che un audit copre e un linter no.

Cosa fare questa settimana

Parti da un giro rapido, senza strumenti: apri l'elenco dei tuoi job schedulati e delle funzioni che parlano con un modello o con un servizio a consumo. Per ognuna, chiediti una sola cosa: "l'input che passo può crescere senza un tetto?". Se la risposta è sì o non lo so, hai trovato un candidato.

Poi verifica se esiste un limite esplicito sulla dimensione del contesto e se i job che ricostruiscono uno stato usano una cache incrementale invece di ripartire da zero. Il pattern del racconto è chiaro: invece di rimandare tutto lo storico, spedisci il riassunto precedente più i soli messaggi nuovi, così l'input resta costante anche se i dati crescono all'infinito.

Se non riesci a dare una risposta certa per il tuo repository, è il segnale che ti manca un verdetto. Carica lo ZIP su VibeInspect e usa il piano Diagnostic per farti indicare file e riga dei punti in cui il costo o la crescita dell'input sfuggono al controllo. Meglio scoprirlo da un PDF questa settimana che da un servizio bloccato alle tre di notte.