Paritok riduce davvero i costi degli agenti AI?

Cosa fa Paritok a una richiesta

Paritok è un gateway per i token: un proxy che si trova tra il tuo agente di coding e l'API del modello e comprime ogni richiesta prima di inoltrarla. Il tuo agente comunica con http://127.0.0.1:8080 invece che con il provider. Il proxy riscrive gli schemi degli strumenti, le letture dei file, l'output degli strumenti e i turni precedenti, invia a monte un payload più piccolo e restituisce la risposta senza modificarla.

Il provider ti addebita ciò che riceve, quindi un payload più piccolo produce una fattura più bassa. Questo è il concetto fondamentale. Si tratta di un'affermazione diversa da «il contesto dura più a lungo» ed è il motivo per cui questo strumento è interessante, non soltanto più ordinato.

Il progetto è recente. I primi tag pubblici sono datati luglio 2026 e il tag attuale è v1.3.0, datato 5 agosto 2026. I pesi e il codice del gateway sono distribuiti con licenza Apache 2.0. Il modello di compressione è un adattatore LoRA (low-rank adaptation) basato su Qwen3-4B-Instruct-2507, addestrato su 45,000 campioni distillati da un insegnante e ricavati da traiettorie reali di agenti di coding.

Perché non si tratta di riduzione del contesto

La riduzione elimina i contenuti. Quando un agente si avvicina al limite del contesto ed elimina i turni più vecchi, il file letto al turno 3 non è più disponibile. Se gli serve al turno 20, legge di nuovo il file e quei token vengono conteggiati una seconda volta. Il risparmio era solo temporaneo.

Paritok sostituisce un segmento con una forma più breve e un tag, [REF:id], mantenendo il testo completo sul proxy. Il modello recupera un segmento chiamando read_original o expand_context. Questo modifica la modalità di errore. Un sistema di riduzione fallisce perché dimentica il contenuto e non lo segnala mai. Un sistema di compressione fallisce fornendo al modello un riepilogo con perdita di informazioni; quando il riepilogo non basta, il modello può richiedere l'originale.

Il filtro degli strumenti funziona nello stesso modo. Gli schemi degli strumenti filtrati vengono sostituiti da stub invece di essere rimossi e il modello ne recupera uno chiamando gateway_search_tools. Questo è importante perché un filtro che nasconde definitivamente uno strumento modifica le operazioni che l'agente può eseguire, e te ne accorgeresti solo quando un'attività termina senza errori evidenti ma con un risultato errato.

I tre meccanismi e quale non costa nulla

Il primo meccanismo è il filtro dello schema degli strumenti. Ogni richiesta contiene l'intero array tools. In un turno di Claude Code con alcuni server MCP (model context protocol) collegati, il progetto misura questo blocco in circa 29,000 token. Il filtro incorpora la richiesta dell'utente e la descrizione di ogni strumento con BAAI/bge-small-en-v1.5, un modello di embedding da 130 MB, mantiene gli strumenti pertinenti e sostituisce gli altri con stub. Il blocco scende a circa 8,000 token. Il modello di embedding viene eseguito sulla CPU.

Il secondo meccanismo è la compressione dei contenuti. È la parte che richiede il modello 4B su una GPU. La lettura dei file, l'output degli strumenti e la cronologia vengono riscritti fino a raggiungere il 25.7% delle dimensioni originali. Da qui deriva il valore del 74%. Leggetelo con attenzione: il 74% è il tasso di compressione del contenuto compresso, non la riduzione della fattura.

Il terzo meccanismo è il riepilogo della cronologia. Quando il budget del contesto si esaurisce, i turni precedenti alla finestra recente vengono riepilogati. In questo modo una sessione lunga continua a funzionare invece di raggiungere il limite.

Solo il secondo meccanismo richiede una GPU. Questa è la frase più importante di questa pagina. pip install "paritok[toolselect]" offre il filtro degli strumenti su un normale VPS con CPU e rappresenta la metà del prodotto che non comporta costi mensili. Provatelo prima di noleggiare una GPU.

Cosa ha misurato il progetto e sul quale harness

[
  {
    "label": "Paritok-4B-v1",
    "compressed_to_pct": 25.7,
    "quality_retained_pct": 86.5
  },
  {
    "label": "gpt-4.1-mini",
    "compressed_to_pct": 50.2,
    "quality_retained_pct": 85.6
  },
  {
    "label": "gpt-5",
    "compressed_to_pct": 61.9,
    "quality_retained_pct": 93.6
  }
]

Questi sono i dati pubblicati dal progetto, misurati sul suo harness e su SWE-bench Lite. Paritok-4B-v1 comprime il contenuto al 25.7% delle dimensioni originali, mantenendo il 86.5% del tasso di risoluzione senza compressione. Usando gpt-5 come compressore si conserva una qualità maggiore, 93.6%, ma si comprime soltanto al 61.9% e si pagano prezzi da modello frontier per risparmiare sui prezzi da modello frontier.

Leggi con attenzione la colonna della qualità. Conservare l'86.5% del tasso di risoluzione significa che le esecuzioni compresse non hanno risolto problemi risolti invece dalle esecuzioni senza compressione: quasi una soluzione su sette. In un benchmark è un numero in una tabella. Nel tuo repository è un'attività che esegui due volte.

[
  {
    "label": "Turn 1",
    "saved_pct": 25
  },
  {
    "label": "Turn 5",
    "saved_pct": 39
  },
  {
    "label": "Turn 12",
    "saved_pct": 57
  },
  {
    "label": "Turn 20",
    "saved_pct": 63
  }
]

Il risparmio end-to-end aumenta durante la sessione, perché la cronologia si accumula ed è proprio la cronologia a essere compressa. Il progetto riporta circa il 25% su un singolo turno, il 39% al turno 5 e il 63% al turno 20. Indica anche quando la crescita si arresta: con un budget di 200,000 token, il risparmio assoluto si stabilizza intorno a 48,000 token per turno, tra il turno 8 e il turno 12 circa, perché quando il contesto è pieno la cronologia smette di crescere. Il valore "oltre l'85%" citato più spesso descrive sessioni con il contesto saturo. È il caso migliore, quindi non pianificare basandoti su questo valore.

Una GPU da 24 GB conviene per Paritok?

Una scheda da 24 GB è l’unità di noleggio abituale per un modello di queste dimensioni. Al 7 agosto 2026, la tariffa on-demand mediana pubblicata per una RTX 4090 con 24 GB era di $0.44 all’ora, mentre le offerte più economiche erano vicine a $0.20. Usiamo $0.44. Se resta in esecuzione per tutto il mese, sono 730 ore, quindi $321. Se la usi soltanto durante l’orario di lavoro, 8 ore al giorno per 22 giorni, sono 176 ore, quindi $77.

Ora converti la riduzione dei token in una riduzione in dollari. La riduzione riguarda i token di input. I token di output passano attraverso il proxy senza modifiche, quindi non cambiano. Supponi che i token di input rappresentino l’80% del totale in dollari, un valore normale per un coding agent, e verifica questa ipotesi sulla tua fattura. Il risparmio in dollari è quindi la riduzione dei token moltiplicata per 0.8.

[
  {
    "label": "Turn 5 (39% saved)",
    "bill_always_on_usd": "1,030",
    "bill_workday_only_usd": 248
  },
  {
    "label": "Turn 20 (63% saved)",
    "bill_always_on_usd": 637,
    "bill_workday_only_usd": 154
  },
  {
    "label": "Saturated (85% saved)",
    "bill_always_on_usd": 472,
    "bill_workday_only_usd": 114
  }
]

Con il valore dell’85% per una sessione satura, risparmi il 68% della fattura. Una scheda lasciata sempre in esecuzione si ripaga quindi quando la spesa mensile per l’agent supera circa $472, oppure circa $114 se arresti l’istanza fuori dall’orario di lavoro. Con il valore del 63% al turno 20, le soglie diventano $637 e $154. Con il valore del 39% al turno 5, che riflette l’uso effettivo delle sessioni brevi, servono circa $1,030 al mese prima che valga la pena noleggiare la scheda.

Due fattori migliorano il risultato rispetto a quanto indicato nella tabella. Il modello non richiede 24 GB: la build q4 occupa circa 2.5 GB e la build bf16 circa 8 GB. Una scheda più piccola, oppure un server GPU che esegui già per un altro scopo, riduce quindi tutti i valori del grafico. Inoltre, arrestare l’istanza quando nessuno scrive codice è la misura più efficace, perché riduce il costo di noleggio di circa tre quarti.

Un fattore peggiora il risultato. Il passaggio di compressione richiede effettivamente lavoro. Ogni token compresso dal modello 4B deve prima essere letto e poi riscritto, aumentando la latenza di ogni turno dell’agent. Su una scheda noleggiata a ore, questo costo si manifesta come tempo di attesa e non come una voce della fattura. Per questo è facile non notarlo finché non inizi a percepirlo.

Se stai confrontando in generale le ore di una GPU a noleggio con i token API, il punto di pareggio tra un GPU VPS e i token API applica lo stesso calcolo all’inferenza vera e propria.

Eseguire il gateway Paritok su un VPS

È richiesto Python 3.10 o una versione successiva. Ubuntu 24.04 include Python 3.12, quindi per la parte che usa solo la CPU è sufficiente un'immagine VPS standard.

sudo apt update && sudo apt install -y python3-venv curl
python3 -m venv /opt/paritok/venv
source /opt/paritok/venv/bin/activate
pip install "paritok[proxy]==1.3.0"
pip install "paritok[toolselect]==1.3.0"

Blocca la versione. Il repository ha assegnato il tag v1.2.8 il 29 luglio 2026 e v1.3.0 il 5 agosto 2026. Un progetto che cambia a questa velocità rinomina le chiavi di configurazione tra una release e l'altra. Un semplice pip install paritok o un git clone di main ti fornisce la settimana prossima un gateway diverso e non lascia traccia di quale versione abbia prodotto i valori misurati.

Il backend predefinito è Ollama. Scarica il modello, quindi assegnagli il nome breve cercato dal proxy.

ollama pull paritok/paritok-4b-v1
ollama cp paritok/paritok-4b-v1 paritok-4b-v1

Scrivi paritok.yaml accanto al modello. use_gpu_server: false mantiene la compressione sul tuo hardware.

use_gpu_server: false
local_model:
  base_url: http://localhost:11434

paritok proxy --port 8080 --config-file paritok.yaml

paritok up è la scorciatoia per tutte le operazioni precedenti: scarica il modello se non è presente e avvia il proxy sulla porta 8080. Verifica il proxy prima di configurare un agent per usarlo.

curl http://127.0.0.1:8080/health
curl http://127.0.0.1:8080/stats

/health restituisce un piccolo oggetto JSON contenente "status":"ok" e una stringa con la versione. /stats restituisce i totali della compressione e la stima del proxy sul risparmio ottenuto. Considera questa stima come un'autovalutazione del proxy e verificala nella pagina dei consumi del provider.

Per privilegiare la velocità di elaborazione rispetto alla praticità, vLLM esegue l'adapter sopra il modello di base.

vllm serve Qwen/Qwen3-4B-Instruct-2507 \
  --enable-lora \
  --lora-modules paritok-4b-v1=paritok/paritok-4b-v1 \
  --port 8000

Ollama è più rapido da configurare. vLLM gestisce molto meglio le richieste simultanee, un aspetto che diventa importante non appena più di un agent condivide la stessa macchina. La differenza pratica tra Ollama e vLLM è il criterio decisivo in questo caso.

Configura l'agent per usare il proxy tramite le variabili d'ambiente dell'URL di base.

export ANTHROPIC_BASE_URL=http://127.0.0.1:8080
export OPENAI_BASE_URL=http://127.0.0.1:8080

Codex CLI ignora OPENAI_BASE_URL, quindi il progetto scrive ~/.codex/config.toml al posto tuo quando codex.enabled: true è impostato in paritok.yaml. Esportare la variabile da sola lascia Codex collegato direttamente al provider. Il segnale è un contatore /stats che non aumenta durante l'utilizzo.

Mantieni il listener su 127.0.0.1, mai su 0.0.0.0. Il proxy inoltra la chiave API del provider al servizio upstream. Un proxy raggiungibile da Internet diventa quindi un relay aperto per quella chiave: chiunque trovi la porta può spendere il tuo denaro senza vedere la chiave. Raggiungilo da un laptop tramite un tunnel SSH o una VPN invece di esporre la porta.

Esegui il servizio tramite systemd, in modo che sopravviva a un riavvio. Adatta i percorsi alla tua installazione.

[Unit]
Description=Paritok compression proxy
After=network-online.target

[Service]
User=paritok
WorkingDirectory=/opt/paritok
ExecStart=/opt/paritok/venv/bin/paritok proxy --port 8080 --config-file /opt/paritok/paritok.yaml
Restart=on-failure

[Install]
WantedBy=multi-user.target

Abilitalo con sudo systemctl enable --now paritok, quindi esegui nuovamente curl /health. Un'unità che si avvia e termina subito indica solitamente un percorso errato del file di configurazione. journalctl -u paritok -n 50 stampa il motivo.

L’opzione hosted e il relativo costo

Il progetto offre anche la compressione come servizio. Imposta use_gpu_server: true con una chiave API: il modello 4B viene eseguito sull’infrastruttura del servizio al costo di $0.30 per milione di token elaborati, con utilizzo gratuito fino alla fine di agosto 2026 secondo la documentazione del progetto. In questo modo elimini il costo del noleggio della GPU e tutte le attività operative descritte sopra.

Tuttavia, i prompt e i file letti dall’agent lasciano il tuo computer e raggiungono un soggetto terzo prima di arrivare al fornitore del modello. Il self-hosting serve proprio a evitare questo passaggio. Prima di impostare quel flag, stabilisci quale dei due obiettivi vuoi privilegiare: modificare il flag richiede una sola riga, ma le conseguenze sono diverse.

Come misurare il proprio prima e dopo

I numeri pubblicati sono quelli del progetto, ottenuti con l'harness del progetto, su SWE-bench Lite. Il vostro repository non è SWE-bench Lite. Misurate i vostri dati.

• Eseguite una settimana normale senza proxy nel percorso. Registrate i token di input, i token letti dalla cache e i token di output su righe separate, nella pagina dei consumi del provider, non come un unico totale in dollari.
• Eseguite la settimana successiva con il proxy davanti, svolgendo lo stesso tipo di attività.
• Confrontate le righe relative all'input e ai token letti dalla cache. L'output dovrebbe restare pressoché invariato, perché non viene compresso. Se l'output è cambiato molto, è intervenuto qualche altro fattore oltre al proxy.
• Contate le attività che avete dovuto ripetere. Questa è la componente relativa alla qualità del compromesso, che nessuna dashboard riporta.
• Prima di confrontare i totali, aggiungete le ore GPU della seconda settimana.

Separare input e output è importante perché hanno prezzi molto diversi e un compressore agisce soltanto su uno dei due. Ad agosto 2026, Claude Sonnet 4.6 costa $3 per milione di token di input e $15 per milione di token di output; la lettura dalla cache dei prompt costa il 10% della tariffa di input, cioè $0.30 per milione. La differenza tra il costo dei token di input e di output determina se un compressore applicato all'input è utile nel vostro caso. Dove vengono effettivamente utilizzati i token di Claude Code indica quale parte del contesto è abbastanza grande da giustificare la compressione.

La cache dei prompt complica in particolare il calcolo relativo al filtro degli strumenti. Il blocco degli strumenti si trova all'inizio della richiesta; dopo il primo turno, quindi, normalmente viene letto dalla cache al 10% del prezzo dell'input. Rimuovere 21,000 token da un blocco memorizzato nella cache fa risparmiare 21,000 token alla tariffa di $0.30 per milione, cioè circa $0.006 per turno, invece dei $0.063 che suggerirebbe la tariffa senza cache. Il progetto mantiene invariato il blocco filtrato per tutta la sessione, in modo che il prefisso memorizzato nella cache non cambi. Un filtro che selezionasse nuovamente gli strumenti a ogni turno invaliderebbe quel prefisso e costerebbe più di quanto farebbe risparmiare.

Cosa resta da verificare

Tutti i valori relativi alle prestazioni riportati sopra provengono dal progetto stesso. Non esiste una riproduzione indipendente dei risultati di SWE-bench Lite e, con i primi tag datati July 2026, il codice ha anche una storia operativa molto limitata. Sia il tasso di compressione sia il valore relativo alla qualità conservata sono misurati dalla parte che trae vantaggio dal fatto che risultino elevati. Questo non significa che siano errati. Significa che non sono confermati e che dovresti considerarli in modo diverso rispetto a un valore che hai prodotto autonomamente.

Prima di attribuire il problema alla tua configurazione, è utile conoscere un comportamento documentato. Il modello di embedding usato dal filtro degli strumenti viene caricato alla prima richiesta, non all'avvio. Per questo il progetto documenta un avvio a regime di 10 to 15 secondi, seguito da circa 15 ms per chiamata. Invia una richiesta di prova dopo l'avvio del proxy: il primo turno reale dell'agente non sembrerà bloccarsi.

In un pomeriggio puoi verificare personalmente quattro aspetti: se il proxy si avvia e rimane attivo, se /stats cambia mentre lavori, se la voce relativa agli input token del tuo provider diminuisce effettivamente e se l'agente completa comunque il lavoro. Per la tua configurazione, questi aspetti sono molto più determinanti di qualsiasi benchmark pubblicato.

Per quanto riguarda l'integrazione con gli altri strumenti: un gateway LiteLLM self-hosted instrada e misura le richieste senza modificarne il contenuto. Le due soluzioni risolvono quindi problemi diversi e possono essere usate in catena, con Paritok collocato più vicino all'agente. Se l'obiettivo reale è ridurre la spesa, invece di usare proprio questo strumento, l'insieme più ampio di controlli sui costi per un agente su un VPS include diverse modifiche che puoi provare prima senza costi.

FAQ

Paritok riduce il costo delle API o soltanto l'utilizzo del contesto?

Riduce il costo, perché il proxy riscrive la richiesta prima che raggiunga il provider, che addebita ciò che riceve. La riduzione effettiva è inferiore a quanto suggerisce il valore principale. Il 74% indica il tasso di compressione del contenuto compresso. Dall'inizio alla fine, il progetto riporta circa il 25% su un singolo turno e il 63% entro il turno 20; inoltre, vengono modificati soltanto i token di input. I token di output passano senza modifiche.

Quanta GPU serve per eseguire autonomamente il modello di compressione?

La build q4 occupa circa 2.5 GB e quella bf16 circa 8 GB, quindi il modello entra comodamente in una scheda da 24 GB. È sufficiente anche una scheda più piccola, migliorando il punto di pareggio dei costi. Il filtro degli schemi degli strumenti non richiede alcuna GPU: usa BAAI/bge-small-en-v1.5, un modello di embedding da 130 MB che funziona sulla CPU. Installa paritok[toolselect] su un VPS ordinario e ottieni la riduzione dei blocchi degli strumenti usando soltanto una piccola quantità di RAM.

Cosa succede se il compressore rimuove qualcosa che serviva all'agente?

Non viene rimosso nulla. I segmenti compressi contengono il tag [REF:id] e il modello recupera il testo completo con read_original o expand_context. Gli schemi degli strumenti filtrati vengono sostituiti da stub, non eliminati, e il modello ne recupera uno con gateway_search_tools. Il rischio effettivo è meno evidente di un file mancante: il modello lavora su un riepilogo con perdita di informazioni e non si rende mai conto di dover richiedere l'originale. È questo che misura il valore dell'86.5% di qualità mantenuta su SWE-bench Lite.

Perché la prima richiesta richiede quindici secondi?

Il modello di embedding usato dal filtro degli strumenti viene caricato alla prima richiesta, non all'avvio. Il progetto documenta un'inizializzazione di 10-15 secondi, seguita da circa 15 ms per chiamata. Dopo aver avviato il proxy, invia una richiesta di prova con curl; in questo modo il primo turno reale dell'agente non subirà rallentamenti.

Devo usare il server GPU in hosting invece di eseguire il servizio autonomamente?

Elimina il costo del noleggio della GPU e della manutenzione, con un prezzo di $0.30 per milione di token elaborati ad agosto 2026. Tuttavia, invia i prompt e i file letti dall'agente a terzi prima che raggiungano il provider del modello. Se esegui il servizio autonomamente per mantenere il codice su un'infrastruttura sotto il tuo controllo, questa impostazione contraddice il motivo per cui hai iniziato. L'esecuzione autonoma mantiene sia il contesto sia la chiave API del provider sul tuo server.