Come ridurre i costi dei token degli agenti di IA in produzione

TL;DR

I costi dei token degli agenti AI crescono quando ogni passaggio rielabora ripetutamente istruzioni, cronologia della conversazione, risultati degli strumenti e stato intermedio.

Riduci il volume di token con budget a livello di run, filtraggio dei risultati degli strumenti, compattazione del contesto, limiti di retry e ragionamento controllato. Usa il prompt caching per input ripetuti stabili, ma ottimizza il loop dell’agente prima di passare a un modello più economico.

La metrica di produzione più utile è il costo per attività completata con successo, misurata sull’intero run—non il prezzo per richiesta o la dimensione del contesto della chiamata finale.

Questa guida si concentra specificamente sugli agenti AI multi-step. Spiega come il contesto ripetuto si compone lungo un run, come identificare la maggiore fonte di spreco e quali controlli implementare per primi.

Introduzione

Un chatbot può effettuare una sola richiesta al modello per messaggio dell’utente. Un agente AI può effettuare 10, 20 o più chiamate prima di completare un’attività.

Ogni passaggio può reinviare istruzioni, cronologia della conversazione, risultati degli strumenti e stato intermedio. Retry, ragionamento e subagent aggiungono ulteriore utilizzo, quindi una risposta finale breve può comunque consumare un gran numero di token.

Con l’aumentare dell’utilizzo, questi costi diventano più difficili da prevedere e possono rapidamente ridurre i margini di prodotto. Ridurli richiede l’ottimizzazione dell’intero loop dell’agente—non semplicemente il passaggio a un modello più economico.

Questo articolo si concentra sui costi specifici degli agenti. Per una guida più ampia che copra il prompt caching, l’exact response caching, il semantic caching, il model routing e la gestione generale dei costi API, vedi Come ridurre i costi delle API AI.

Perché i costi dei token degli agenti AI si accumulano?

In un agente multi-step, il costo di un’attività è la somma di ogni chiamata al modello—non solo della risposta finale.

Le principali fonti di utilizzo dei token dell’agente sono:

Esistono due modi distinti per ridurre la spesa:

1. Processare meno token tramite filtraggio, compattazione, limiti di output e controlli del loop.
2. Ridurre il prezzo effettivo dei token necessari tramite prompt caching o selezione del modello.

Distinzione chiave: il prompt caching riduce il costo dell’input ripetuto. La compattazione del contesto riduce l’input ripetuto stesso.

Come può un agente in 12 passaggi elaborare 147.000 token?

Considera un ipotetico agente di supporto con:

• Un prefisso stabile da 4.000 token
• 1.500 nuovi token aggiunti dopo ogni passaggio
• L’intera cronologia accumulata reinviata a ogni richiesta
• 12 chiamate totali al modello

L’input al passo n è:

Input at step n = 4,000 + 1,500 × (n - 1)

L’input cumulativo su 12 chiamate è:

Total input
= 4,000 × 12 + 1,500 × (0 + 1 + ... + 11)
= 48,000 + 99,000
= 147,000 input tokens

La chiamata finale contiene solo 20.500 token di input, ma l’intero run elabora 147.000 token di input cumulativi.

Ora applica due controlli:

1. Metti in cache il prefisso stabile da 4.000 token dopo la prima chiamata.
2. Compatta la cronologia dopo il sesto passaggio in un sommario di stato da 2.500 token.

Questo è un calcolo di pianificazione, non un benchmark del provider.

Presuppone che ogni richiesta includa l’intera cronologia accumulata. Gli agenti che costruiscono selettivamente lo stato, riassumono i messaggi più vecchi o recuperano solo le informazioni rilevanti possono seguire una curva di costo differente.

Regola della crescita dei costi: misura l’input cumulativo sull’intero run. La dimensione del contesto finale non rappresenta il numero totale di token elaborati.

Quali metriche rivelano lo spreco di token degli agenti?

Non iniziare cambiando modello. Identifica prima dove il workflow spende token senza migliorare il risultato.

Registra questi campi per ogni passaggio dell’agente:

La metrica primaria dovrebbe essere:

cost per successful task
= total workflow cost
/ accepted tasks

Un run più economico non è un miglioramento se causa più attività fallite, strumenti ripetuti o correzione umana.

Quattro metriche specifiche degli agenti aiutano a individuare il problema.

Amplificazione del contesto

context amplification
= cumulative input tokens
/ final-step input tokens

Un valore elevato indica che il contesto precedente è stato elaborato ripetutamente.

Rapporto di ritenzione degli strumenti

tool retention ratio
= tool-result tokens retained in context
/ tokens originally returned by tools

Un rapporto elevato può indicare che l’agente porta tra i passaggi troppa evidenza grezza.

Tassa di retry

retry tax
= retry and repair cost
/ total workflow cost

Quota di ragionamento

reasoning share
= reasoning-token cost
/ total model cost

Misura ogni carico di lavoro separatamente. Agenti di ricerca, coding, browser e customer support non dovrebbero condividere una baseline globale.

Sei modi per ridurre i costi di token degli agenti AI

1. Imposta un budget per l’intero run

Un limite di output per richiesta non controlla un agente multi-step.

Imposta limiti a livello di run per:

• Numero totale di passaggi del modello
• Input e output cumulativi
• Chiamate agli strumenti e dimensione dei risultati degli strumenti
• Retry per tipo di fallimento
• Subagent
• Tempo totale trascorso o costo stimato

Il seguente esempio Python, indipendente dal provider, valuta il run prima di ogni chiamata al modello:

from dataclasses import dataclass
from enum import Enum


class Action(str, Enum):
    CONTINUE = "continue"
    COMPACT = "compact"
    STOP = "stop"


@dataclass(frozen=True)
class Budget:
    max_steps: int = 12
    max_input_tokens: int = 120_000
    max_output_tokens: int = 18_000
    compact_at: float = 0.80


@dataclass
class Usage:
    steps: int = 0
    input_tokens: int = 0
    output_tokens: int = 0


def evaluate_budget(usage: Usage, budget: Budget) -> Action:
    if (
        usage.steps >= budget.max_steps
        or usage.input_tokens >= budget.max_input_tokens
        or usage.output_tokens >= budget.max_output_tokens
    ):
        return Action.STOP

    input_ratio = usage.input_tokens / budget.max_input_tokens

    if input_ratio >= budget.compact_at:
        return Action.COMPACT

    return Action.CONTINUE

Esegui il controllo prima di ogni richiesta al modello e aggiorna Usage dai dati dei token riportati dal provider.

All’80% del budget di input, compatta lo stato o restringi la query dello strumento successivo. Al 100%, interrompi con una motivazione strutturata.

Errore comune: limitare ogni risposta mentre si consentono passaggi, strumenti e retry illimitati.

2. Filtra i risultati degli strumenti prima che entrino nella trascrizione

Ritorna solo l’evidenza necessaria per la prossima decisione dell’agente.

Non appendere un’intera:

• Pagina web
• File di log
• Albero del repository
• Risposta del database
• Sessione di terminale
• Payload API

quando il passaggio successivo ha bisogno solo di pochi campi.

Uno strumento di ricerca potrebbe restituire:

{
  "source_id": "search_17",
  "title": "Relevant page title",
  "url": "https://example.com/page",
  "relevant_passage": "A short evidence block"
}

Archivia l’artifact completo fuori dal prompt e recupera una sezione più ristretta in seguito.

Regola di filtraggio degli strumenti: restituisci i campi necessari per la prossima decisione—non ogni campo che potrebbe tornare utile più avanti.

Errore comune: troncare i primi 1.000 caratteri di un payload JSON. Questo può rompere la struttura o rimuovere i record di cui l’agente ha effettivamente bisogno.

Analizza prima il payload, seleziona i campi in modo strutturale, limita gli array e poi serializza JSON valido.

3. Compatta lo stato operativo, non solo il testo della conversazione

La compattazione dovrebbe preservare le informazioni necessarie a proseguire l’attività rimuovendo la cronologia che non influisce più sull’azione successiva.

Uno stato compattato utile contiene:

• Obiettivo dell’utente e criteri di successo
• Decisioni già prese
• Fatti verificati e ID delle fonti
• File o record modificati
• Approcci falliti
• Questioni aperte
• La prossima azione
• Vincoli di sicurezza e di output

Non dovrebbe ri-raccontare l’intera conversazione.

OpenAI documenta la compattazione per interazioni durature con la Responses API. Anthropic fornisce controlli di gestione del contesto per cancellare o riassumere contenuti più vecchi. Queste implementazioni differiscono, quindi verifica i campi attuali del provider prima dell’integrazione.

Regola della compattazione: preserva decisioni e lavoro irrisolto. Rimuovi la narrazione e le evidenze che possono essere recuperate di nuovo.

Errore comune: omettere ID delle fonti, nomi file modificati, approcci respinti o vincoli irrisolti.

Dopo aver aggiunto la compattazione, misura se l’agente ripete ricerche o chiamate agli strumenti. Un prompt più corto non è più economico se l’agente deve ricostruire lo stato perso.

4. Mantieni stabile il prefisso riutilizzabile

I prompt degli agenti spesso contengono grandi blocchi riutilizzabili:

• Istruzioni di sistema
• Schemi degli strumenti
• Policy di sicurezza
• Formati di output
• Materiale di riferimento condiviso
• Istruzioni su repository o prodotto

Posiziona questi elementi stabili prima dei dati specifici della richiesta:

1. Istruzioni di sistema
2. Policy e vincoli
3. Definizioni degli strumenti
4. Esempi stabili
5. Materiale di riferimento condiviso
6. Dati specifici della richiesta

Evita di inserire timestamp, ID di richiesta, dati di sessione o valori che cambiano spesso vicino all’inizio.

Il caching è più utile quando il prefisso è lungo, stabile e riutilizzato. Potrebbe non far risparmiare per sessioni brevi o prompt che cambiano frequentemente.

Errore comune: ottimizzare per il tasso di cache-hit senza misurare i costi di scrittura, lettura o storage della cache.

Per un confronto più ampio tra prompt caching, exact response caching e semantic caching, vedi Come ridurre i costi delle API AI.

5. Impedisci ai retry di riprodurre lo stesso contesto

Un retry è un altro passaggio dell’agente, spesso con lo stesso prompt di grandi dimensioni.

Non ripetere una richiesta fallita senza cambiare la causa del fallimento.

Usa chiavi di idempotenza per operazioni con effetti collaterali come pagamenti, email, deployment e scritture su database.

Errore comune: ritentare più volte un modello soggetto a rate limit reinviando l’intero contesto dell’agente a ogni tentativo.

Tieni traccia della tassa di retry per tipo di fallimento in modo che il team possa sistemare per primo il ciclo più impattante.

6. Limita il ragionamento e i subagent ai passaggi che ne hanno bisogno

Non ogni passaggio dell’agente richiede deep reasoning.

Estrazione, formattazione, classificazione, validazione e selezione routinaria degli strumenti possono spesso usare uno sforzo di ragionamento più basso e output strutturati compatti.

Riserva sforzi di ragionamento più elevati per attività come:

• Pianificazione complessa
• Coding difficile
• Sintesi multi-documento
• Decisioni ambigue
• Recupero da esecuzione fallita

Regola del ragionamento: usa il minimo sforzo di ragionamento che preserva il tasso di attività accettate.

I subagent richiedono anche un confine chiaro. Dai a ogni worker:

• Un compito ristretto
• Uno slice di contesto specifico per il compito
• Una allowlist di strumenti
• Un budget di token
• Uno schema di output compatto

L’agente root di solito ha bisogno di risultati, ID dell’evidenza, confidenza e questioni irrisolte—non della trascrizione completa del worker.

Regola dei subagent: parallelizza il lavoro indipendente, non il contesto duplicato.

Errore comune: inviare l’intera cronologia dell’agente root a ogni worker prima di assegnare un compito ristretto.

Quale ottimizzazione applicare per prima?

Usa la telemetria dell’agente per scegliere il primo intervento.

Le soglie sotto sono trigger di indagine, non standard universali.

Una sequenza di implementazione sicura è:

1. Misura input cumulativo, ritenzione degli strumenti, retry e ragionamento.
2. Aggiungi limiti rigidi per passaggi, strumenti, retry e token totali.
3. Filtra i grandi risultati degli strumenti.
4. Compatta lo stato più vecchio a una soglia misurata.
5. Stabilizza il prefisso riutilizzabile del prompt.
6. Confronta i percorsi di modello solo dopo che il loop dell’agente è pulito.

Cambia una variabile principale alla volta e riproduci lo stesso set di valutazione.

Confronta:

• Tasso di accettazione delle attività
• Costo per attività completata con successo
• Input cumulativo
• Numero di chiamate agli strumenti
• Tassa di retry
• Quota di ragionamento
• Latenza p50 e p95
• Tempo di revisione umana

Annulla le modifiche che risparmiano token riducendo la qualità dell’attività o rimuovendo evidenza necessaria.

Testa i workflow degli agenti con CometAPI

Prima di eseguire una valutazione multi-modello, usa la pagina prezzi di CometAPI e la guida alla stima dei costi per stimare i costi di input, output, token in cache e di ragionamento.

Poi usa il catalogo dei modelli per identificare i percorsi idonei e la Quickstart per configurare un client compatibile con OpenAI.

Per il fallback in produzione, segui la guida al fallback dei modelli di CometAPI per cambiare percorso senza ripetere le chiamate agli strumenti completate o scartare lo stato validato.

L’accesso unificato semplifica il confronto dei modelli e l’integrazione del fallback. Budget di token, compattazione, validazione, filtraggio degli strumenti, limiti di retry e criteri di accettazione restano a livello applicativo.

FAQ

Perché gli agenti AI usano più token dei chatbot?

Gli agenti effettuano più chiamate al modello e possono reinviare a ogni passaggio messaggi precedenti, risultati degli strumenti, istruzioni e stato intermedio. Questo fa sì che il contesto precedente venga elaborato ripetutamente.

Il prompt caching riduce l’uso della finestra di contesto?

No. Il prompt caching può ridurre il prezzo effettivo o la latenza dell’input ripetuto, ma i token in cache fanno comunque parte del contesto elaborato. Usa compattazione, filtraggio o recupero selettivo per ridurre la dimensione del prompt.

Quando dovrebbe un agente AI compattare il proprio contesto?

Compatta prima che la crescita del contesto inizi a influire su costo, latenza o spazio di output disponibile. Verifica che lo stato compattato preservi decisioni, ID delle evidenze, file modificati, questioni aperte e vincoli di sicurezza.

I subagent riducono i costi dei token?

Non automaticamente. Possono ridurre il tempo trascorso o migliorare la copertura per lavoro indipendente, ma contesto duplicato e analisi sovrapposte spesso aumentano l’uso totale di token.

Qual è la migliore metrica per l’ottimizzazione dei costi degli agenti AI?

Usa il costo per attività completata con successo come metrica primaria. Diagnosticalo con input cumulativo, amplificazione del contesto, ritenzione degli strumenti, tassa di retry, quota di ragionamento, latenza e tempo di revisione umana.