Paritok réduit-il vraiment la facture de votre agent ?

Ce que Paritok fait avec une requête

Paritok est une passerelle de tokens : un proxy qui s’intercale entre votre agent de programmation et l’API du modèle, puis compresse chaque requête avant de la transmettre. Votre agent communique avec http://127.0.0.1:8080 au lieu du fournisseur. Le proxy réécrit les schémas des outils, les lectures de fichiers, la sortie des outils et les anciens tours de conversation, envoie la charge utile réduite en amont, puis renvoie la réponse sans la modifier.

Le fournisseur vous facture ce qui lui parvient. Une charge utile plus petite réduit donc la facture. C’est tout le principe. Cette affirmation diffère de « votre contexte dure plus longtemps ». C’est aussi ce qui rend cet outil intéressant, au-delà du simple rangement.

Le projet est récent. Ses premières versions publiques datent de juillet 2026 et la version actuelle est v1.3.0, datée du 5 août 2026. Les poids et le code de la passerelle sont sous licence Apache 2.0. Le modèle de compression est un adaptateur LoRA (adaptation de faible rang) appliqué à Qwen3-4B-Instruct-2507. Il a été entraîné sur 45,000 échantillons distillés par un modèle enseignant, issus de trajectoires réelles d’agents de programmation.

Pourquoi il ne s’agit pas d’une réduction du contexte

La réduction supprime des éléments. Lorsqu’un agent approche de la limite de son contexte et supprime les échanges les plus anciens, le fichier qu’il a lu au tour 3 disparaît. S’il a besoin de ce fichier au tour 20, il le relit et vous payez une deuxième fois pour ces tokens. L’économie n’était qu’un emprunt.

Paritok remplace un segment par une forme plus courte accompagnée d’une balise, [REF:id], et conserve le texte complet sur le proxy. Le modèle récupère un segment en appelant read_original ou expand_context. Le mode d’échec change. Un outil de réduction échoue en oubliant des informations, sans jamais vous le signaler. Un outil de compression échoue en transmettant au modèle un résumé avec pertes, mais le modèle peut demander l’original lorsque le résumé ne suffit pas.

Le filtre d’outils fonctionne de la même manière. Les schémas d’outils filtrés sont remplacés par des stubs au lieu d’être supprimés, et le modèle en récupère un en appelant gateway_search_tools. C’est important, car un filtre qui masque définitivement un outil modifie ce que votre agent est capable de faire. Vous ne le découvririez qu’en constatant qu’une tâche a échoué sans message explicite.

Les trois leviers, et celui qui est gratuit

Le premier levier est le filtre des schémas d’outils. Chaque requête contient l’intégralité du tableau tools. Lors d’un tour Claude Code avec quelques serveurs MCP (model context protocol), le projet évalue ce bloc à environ 29,000 tokens. Le filtre encode la requête de l’utilisateur et la description de chaque outil avec BAAI/bge-small-en-v1.5, un modèle d’embeddings de 130 MB. Il conserve les outils pertinents et remplace les autres par des stubs. Le bloc passe ainsi à environ 8,000 tokens. Ce modèle d’embeddings s’exécute sur CPU.

Le deuxième levier est la compression du contenu. C’est la partie qui nécessite le modèle 4B sur un GPU. Les lectures de fichiers, les sorties des outils et l’historique sont réécrits pour atteindre 25.7% de leur taille initiale. C’est de là que vient le chiffre de 74%. Lisez-le attentivement : 74% est le taux de compression appliqué au contenu compressé, et non la réduction de votre facture.

Le troisième levier est le résumé de l’historique. Lorsque le budget de contexte est rempli, les tours qui dépassent la fenêtre récente sont résumés. Une longue session peut ainsi continuer au lieu d’atteindre la limite.

Seul le deuxième levier nécessite un GPU. C’est la phrase la plus utile de cette page. pip install "paritok[toolselect]" vous fournit le filtre des outils sur un VPS CPU ordinaire, et c’est la moitié du produit qui ne vous coûte rien par mois. Essayez-le avant de louer une carte.

Ce que le projet a mesuré, et avec quel 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
  }
]

Il s’agit des chiffres publiés par le projet, mesurés avec son propre harness sur SWE-bench Lite. Paritok-4B-v1 réduit le contenu à 25.7% de sa taille d’origine tout en conservant 86.5% du taux de résolution sans compression. Utiliser gpt-5 comme compresseur conserve davantage de qualité, soit 93.6%, mais réduit seulement le contenu à 61.9%. Vous paieriez alors des tarifs frontier pour économiser sur des tarifs frontier.

Lisez honnêtement la colonne consacrée à la qualité. Conserver 86.5% du taux de résolution signifie que les exécutions avec compression ont échoué sur des problèmes résolus par les exécutions sans compression, soit environ un problème sur sept. Sur un benchmark, c’est un nombre dans un tableau. Dans votre repository, c’est une tâche que vous relancez deux fois.

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

L’économie de bout en bout augmente au fil de la session, car l’historique s’accumule et c’est lui qui est compressé. Le projet indique environ 25% sur un seul tour, 39% au tour 5 et 63% au tour 20. Il précise également quand cette progression s’arrête : avec un budget de 200,000 tokens, l’économie absolue plafonne à environ 48,000 tokens par tour, entre les tours 8 et 12, car une fois le contexte plein, l’historique ne s’allonge plus. Le chiffre souvent cité de « plus de 85% » décrit les sessions dont le contexte est saturé. C’est le meilleur cas ; n’en faites donc pas la base de votre planification.

Une carte GPU de 24 Go est-elle rentable pour Paritok ?

Une carte de 24 Go est l’unité de location habituelle pour un modèle de cette taille. Au 7 août 2026, le tarif médian publié à la demande pour une RTX 4090 de 24 Go était de $0.44 par heure, les offres les moins chères étant proches de $0.20. Prenons $0.44. Si elle reste allumée tout le mois, cela représente 730 heures, soit $321. Si vous l’exécutez uniquement pendant les heures de travail, à raison de 8 heures par jour pendant 22 jours, cela représente 176 heures, soit $77.

Convertissez maintenant la réduction du nombre de tokens en réduction en dollars. La réduction s’applique aux tokens d’entrée. Les tokens de sortie traversent le proxy sans modification et ne changent donc pas. Supposons que les tokens d’entrée représentent 80% de votre facture totale, ce qui est normal pour un agent de programmation, puis vérifiez cette hypothèse avec votre propre facture. Votre économie en dollars correspond alors à la réduction du nombre de tokens multipliée par 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
  }
]

Avec le taux de 85% pour une session saturée, vous conservez 68% de la facture. Une carte laissée allumée est donc amortie dès que vos dépenses mensuelles d’agent dépassent environ $472, ou environ $114 si vous arrêtez l’instance en dehors des heures de travail. Avec le taux de 63% au tour 20, ces seuils deviennent $637 et $154. Avec le taux de 39% au tour 5, qui correspond aux sessions courtes réelles, vous devez dépenser environ $1,030 par mois avant que la location de la carte soit rentable.

Deux éléments rendent le résultat plus favorable que ne le suggère le tableau. Le modèle n’a pas besoin de 24 Go : le build q4 occupe environ 2.5 Go et le build bf16 environ 8 Go. Une carte plus petite, ou une machine GPU que vous utilisez déjà pour autre chose, réduit donc tous les montants du graphique. Arrêter l’instance lorsque personne ne code est le levier le plus important, car cela réduit le coût de location d’environ trois quarts.

Un élément rend le résultat moins favorable. La passe de compression demande réellement du calcul. Chaque token que le modèle 4B compresse doit être lu, puis réécrit, ce qui augmente la latence de chaque tour de l’agent. Avec une carte louée à l’heure, ce coût se manifeste par du temps d’attente et non par une ligne sur la facture. Il est donc facile de ne pas le voir avant de le subir.

Si vous comparez de manière générale des heures de GPU louées avec des tokens d’API, le seuil de rentabilité entre un GPU VPS et des tokens d’API applique le même calcul à l’inférence elle-même.

Exécuter la passerelle Paritok sur un VPS

Python 3.10 ou version ultérieure est requis. Ubuntu 24.04 fournit Python 3.12 : une image VPS standard suffit donc pour la partie qui utilise uniquement le CPU.

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"

Verrouillez la version. Le dépôt a publié les versions v1.2.8 le 29 July 2026 et v1.3.0 le 5 August 2026. Un projet qui évolue à ce rythme renomme les clés de configuration entre les versions. Un simple pip install paritok ou un git clone de main vous fournira une passerelle différente la semaine prochaine, sans conserver la trace de celle qui a produit les valeurs mesurées.

Le backend par défaut est Ollama. Téléchargez le modèle, puis donnez-lui le nom court attendu par le proxy.

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

Ajoutez paritok.yaml à côté. use_gpu_server: false garantit que la compression est effectuée sur votre propre matériel.

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

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

paritok up est le raccourci pour effectuer toutes les opérations précédentes : il télécharge le modèle s’il est absent et démarre le proxy sur le port 8080. Vérifiez le proxy avant de configurer un agent pour l’utiliser.

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

/health renvoie un petit objet JSON contenant "status":"ok" et une chaîne indiquant la version. /stats renvoie les totaux de compression ainsi que l’estimation du proxy concernant les données économisées. Considérez cette estimation comme une auto-évaluation du proxy et vérifiez-la sur la page d’utilisation de votre fournisseur.

Pour privilégier le débit plutôt que la simplicité, vLLM exécute l’adapter au-dessus du modèle de base.

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

Ollama est plus rapide à mettre en place. vLLM gère beaucoup mieux les requêtes simultanées, ce qui devient important dès que plusieurs agents partagent la machine. La différence pratique entre Ollama et vLLM permet de choisir la solution adaptée à ce cas.

Configurez l’agent pour utiliser le proxy avec les variables d’environnement d’URL de base.

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

Codex CLI ignore OPENAI_BASE_URL. Le projet définit donc ~/.codex/config.toml pour vous lorsque codex.enabled: true est défini dans paritok.yaml. Exporter uniquement cette variable laisse Codex communiquer directement avec le fournisseur. Cela se voit au compteur /stats, qui ne progresse jamais pendant votre travail.

Laissez le listener sur 127.0.0.1, jamais sur 0.0.0.0. Le proxy transmet votre clé API du fournisseur au serveur en amont. Un proxy accessible depuis Internet devient donc un relais ouvert pour cette clé : quiconque découvre le port peut dépenser votre argent sans voir la clé elle-même. Accédez-y depuis un ordinateur portable au moyen d’un tunnel SSH ou d’un VPN au lieu d’ouvrir le port.

Exécutez-le avec systemd pour qu’il redémarre après un reboot. Adaptez les chemins à votre installation.

[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

Activez-le avec sudo systemctl enable --now paritok, puis exécutez de nouveau curl /health. Une unité qui démarre puis s’arrête immédiatement indique généralement que le chemin du fichier de configuration est incorrect. journalctl -u paritok -n 50 affiche la cause.

L’option hébergée et ce qu’elle vous coûte

Le projet propose également la compression en tant que service. Configurez use_gpu_server: true avec une clé API : le modèle 4B s’exécute alors sur son infrastructure, au tarif de $0.30 par million de tokens traités. D’après sa documentation, le service est gratuit jusqu’à la fin du mois d’août 2026. Cette option supprime le coût de location du GPU et toutes les opérations décrites plus haut.

Elle signifie également que vos prompts et les fichiers lus par votre agent quittent votre machine et parviennent à un tiers avant d’atteindre votre fournisseur de modèle. L’auto-hébergement existe précisément pour éviter ce détour. Déterminez lequel de ces deux objectifs vous privilégiez avant d’activer ce flag : sa modification tient sur une ligne, mais ses conséquences sont bien plus importantes.

Comment mesurer votre propre avant et après

Les chiffres publiés sont ceux du projet, obtenus avec son harness, sur SWE-bench Lite. Votre dépôt n’est pas SWE-bench Lite. Mesurez vos propres résultats.

• Exécutez une semaine normale sans proxy sur le chemin des requêtes. Relevez séparément les input tokens, les cache-read tokens et les output tokens sur la page d’utilisation de votre fournisseur. Ne les regroupez pas en un seul montant en dollars.
• La semaine suivante, placez le proxy devant le service et effectuez le même type de travail.
• Comparez les lignes des input tokens et des cache-read tokens. La sortie devrait rester à peu près stable, car rien ne la compresse. Si elle a beaucoup évolué, c’est qu’un autre élément a changé.
• Comptez les tâches que vous avez dû refaire. C’est la moitié qualité du compromis, et aucun dashboard ne la fournit.
• Ajoutez les heures GPU de la deuxième semaine avant de comparer les totaux.

Séparer les entrées des sorties est important, car leur tarification est très différente et qu’un compresseur n’agit que sur l’une des deux. En août 2026, Claude Sonnet 4.6 coûte $3 par million d’input tokens et $15 par million d’output tokens. La lecture du prompt cache coûte 10% du tarif des entrées, soit $0.30 par million. L’écart entre le coût des input tokens et celui des output tokens détermine l’intérêt d’un compresseur côté entrées dans votre cas. Où vont réellement les tokens de Claude Code indique quelle partie de votre contexte est suffisamment volumineuse pour justifier une compression.

Le prompt caching complique particulièrement le calcul lié au filtrage des outils. Le bloc d’outils se trouve au début de la requête. Après le premier tour, il est donc normalement lu depuis le cache, à 10% du prix des entrées. Supprimer 21,000 tokens d’un bloc mis en cache permet d’économiser 21,000 tokens au tarif de $0.30 par million, soit environ $0.006 par tour, et non $0.063 comme le laisserait penser le tarif sans cache. Le projet conserve le bloc filtré inchangé pendant la session afin que le préfixe mis en cache ne change pas. Un filtre qui sélectionnerait à nouveau les outils à chaque tour invaliderait ce préfixe et coûterait plus cher que les économies réalisées.

Ce qui reste à vérifier

Tous les chiffres de performance présentés plus haut proviennent du projet lui-même. Il n’existe pas de reproduction indépendante des résultats sur SWE-bench Lite. De plus, les premiers tags datant de July 2026, le code dispose de très peu d’historique opérationnel. Le taux de compression et le chiffre de qualité conservée sont tous deux mesurés par la partie qui a intérêt à ce qu’ils soient favorables. Cela ne signifie pas qu’ils sont faux. Cela signifie qu’ils ne sont pas confirmés. Vous devez donc les considérer différemment d’un chiffre que vous avez produit vous-même.

Un comportement documenté doit être connu avant d’incriminer votre configuration. Le modèle d’embedding utilisé par le filtre de l’outil est chargé à la première requête, et non au démarrage. Le projet indique donc un warm-up de 10 à 15 secondes, puis environ 15 ms par appel. Envoyez une requête sans effet après le démarrage du proxy. Ainsi, votre premier tour réel avec l’agent ne donnera pas l’impression de rester bloqué.

Vous pouvez vérifier vous-même quatre points en un après-midi : si le proxy démarre et reste actif, si /stats évolue pendant votre travail, si la ligne des input tokens de votre fournisseur diminue réellement, et si l’agent termine toujours le travail. Pour votre configuration, ces éléments sont bien plus déterminants que n’importe quel benchmark publié.

Concernant la place de cet outil à côté de vos autres outils : une gateway LiteLLM auto-hébergée route et mesure les requêtes sans modifier leur contenu. Les deux outils répondent donc à des problèmes différents et peuvent être utilisés ensemble, Paritok étant placé au plus près de l’agent. Si votre objectif réel est de réduire la facture plutôt que d’utiliser cet outil précis, l’ensemble plus large des contrôles de coûts pour un agent sur un VPS comprend plusieurs changements que vous pouvez d’abord essayer gratuitement.

FAQ

Paritok réduit-il ma facture API ou uniquement l’utilisation du contexte ?

Il réduit la facture, car le proxy réécrit la requête avant qu’elle n’atteigne le fournisseur, qui facture ce qu’il reçoit. La réduction réelle est toutefois inférieure au chiffre mis en avant. Le taux de 74 % correspond à la compression du contenu compressé. De bout en bout, le projet indique environ 25 % sur un seul tour et 63 % au tour 20. Seuls les tokens d’entrée sont modifiés. Les tokens de sortie sont transmis sans modification.

De quelle puissance GPU ai-je besoin pour auto-héberger le modèle de compression ?

La build q4 occupe environ 2.5 GB et la build bf16 environ 8 GB. Le modèle tient donc largement sur une carte de 24 GB. Une carte plus petite convient aussi et améliore le calcul de rentabilité en votre faveur. Le filtre de schémas d’outils ne nécessite aucun GPU : il utilise BAAI/bge-small-en-v1.5, un modèle d’embeddings de 130 MB qui fonctionne sur CPU. Installez paritok[toolselect] sur un VPS ordinaire pour obtenir la réduction des blocs d’outils avec une faible consommation de RAM.

Que se passe-t-il si le compresseur supprime un élément dont l’agent avait besoin ?

Rien n’est supprimé. Les segments compressés portent un tag [REF:id] et le modèle récupère le texte complet avec read_original ou expand_context. Les schémas d’outils filtrés sont remplacés par des stubs, au lieu d’être supprimés, et le modèle en récupère un avec gateway_search_tools. Le véritable risque est plus discret qu’un fichier manquant : le modèle travaille à partir d’un résumé avec perte et ne comprend jamais qu’il devrait demander l’original. C’est ce que mesure le taux de 86.5 % de qualité conservée sur SWE-bench Lite.

Pourquoi ma première requête prend-elle quinze secondes ?

Le modèle d’embeddings utilisé par le filtre d’outils est chargé lors de la première requête, et non au démarrage. Le projet indique une phase de warm-up de 10 à 15 secondes, puis environ 15 ms par appel. Après avoir démarré le proxy, envoyez une requête sans importance avec curl. Le premier tour réel de l’agent ne sera ainsi pas bloqué.

Dois-je utiliser le serveur GPU hébergé au lieu de l’auto-hébergement ?

Cette solution supprime les coûts de location du GPU et de maintenance. Elle est facturée $0.30 par million de tokens traités en août 2026. Elle envoie également vos prompts et les fichiers lus par votre agent à un tiers avant de les transmettre à votre fournisseur de modèle. Si vous vous auto-hébergez pour conserver votre code sur une infrastructure que vous contrôlez, ce réglage annule la raison initiale de votre choix. L’auto-hébergement conserve le contexte et la clé API du fournisseur sur votre propre serveur.