Paritok réduit-il vraiment le coût des coding agents ?

Ce que Paritok fait à une requête

Paritok est une passerelle de tokens : un proxy placé entre votre coding agent et l’API du modèle, qui 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 vous 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 » et explique pourquoi cet outil est intéressant, au-delà du simple nettoyage des requêtes.

Le projet est récent. Ses premiers tags publics datent de July 2026 et le tag actuel est v1.3.0, daté du 5 August 2026. Les poids et le code de la passerelle sont sous licence Apache 2.0. Le modèle de compression est un adaptateur LoRA (low-rank adaptation) basé sur 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 de coding agents.

Pourquoi il ne s’agit pas de suppression du contexte

La suppression efface les données. Lorsqu’un agent approche de sa limite de contexte et supprime les tours les plus anciens, le fichier qu’il a lu au tour 3 disparaît. S’il en a besoin au tour 20, il relit le fichier. Vous payez donc une deuxième fois pour ces tokens. L’économie n’était qu’un prêt.

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 de défaillance est donc différent. Un outil de suppression échoue en oubliant des informations, sans jamais vous le signaler. Un outil de compression échoue en transmettant au modèle un résumé avec perte. Le modèle peut alors demander le texte 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 les capacités de votre agent. Vous ne le découvrez alors qu’à travers une tâche qui échoue discrètement.

Les trois leviers, et celui qui est gratuit

Le premier levier est le filtre de schéma des outils. Chaque requête contient l’intégralité du tableau tools. Lors d’une session Claude Code avec quelques serveurs MCP (model context protocol) attachés, 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, conserve les outils correspondants et remplace les autres par des stubs. Le bloc passe ainsi à environ 8,000 tokens. Ce modèle d’embeddings s’exécute sur le 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, la sortie des outils et l’historique sont réécrits pour ne représenter que 25.7% de leur taille initiale. C’est de là que vient le chiffre annoncé de 74%. Lisez-le attentivement : 74% est le taux de compression appliqué au contenu compressé, pas la réduction de votre facture.

Le troisième levier est la synthèse de l’historique. Lorsque le budget de contexte est atteint, les échanges 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 ordinaire équipé d’un CPU, 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 sur 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 compresse le contenu à 25.7% de sa taille initiale tout en conservant 86.5% du taux de résolution sans compression. Avec gpt-5 comme compresseur, la qualité préservée est meilleure, 93.6%, mais la compression ne ramène le contenu qu’à 61.9%, et vous paieriez alors les tarifs frontier pour économiser sur ces mêmes tarifs frontier.

Lisez honnêtement la colonne de qualité. Conserver 86.5% du taux de résolution signifie que les exécutions compressées ont échoué sur des problèmes résolus par les exécutions sans compression, soit presque une résolution sur sept. Sur un benchmark, c’est un nombre dans un tableau. Dans votre dépôt, c’est une tâche que vous exécutez 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 totale 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 à quel moment cette progression s’arrête : avec un budget de 200,000 tokens, l’économie absolue plafonne à environ 48,000 tokens par tour, vers les tours 8 à 12, car une fois le contexte plein, l’historique cesse de s’allonger. Le chiffre souvent cité de « plus de 85% » décrit les sessions où le contexte est saturé. C’est le meilleur cas ; ne basez donc pas votre planification dessus.

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

Une carte de 24 GB 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 GB était de 0,44 $ par heure, les offres les moins chères étant proches de 0,20 $. Retenons 0,44 $. Si vous la laissez fonctionner tout le mois, cela représente 730 heures, soit 321 $. Si vous l’exécutez uniquement pendant les heures de travail, 8 heures par jour pendant 22 jours, cela représente 176 heures, soit 77 $.

Convertissons 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 total facturé, ce qui est courant pour un agent de programmation, puis vérifiez cette hypothèse sur 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 en fonctionnement est donc amortie lorsque 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 en pratique, vous devez dépenser environ 1,030 $ par mois avant que la location de la carte soit réellement rentable.

Deux éléments rendent le résultat meilleur que ne le suggère le tableau. Le modèle n’a pas besoin de 24 GB : le build q4 fait environ 2.5 GB et le build bf16 environ 8 GB. Une carte plus petite, ou une machine GPU que vous utilisez déjà pour une autre tâche, réduit donc tous les montants du graphique. Arrêter l’instance lorsque personne ne programme 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 temps de calcul. Chaque token que le modèle 4B compresse doit d’abord être lu, puis écrit, ce qui augmente la latence de chaque tour de l’agent. Avec une carte louée à l’heure, ce coût se traduit par du temps d’attente et non par une ligne sur la facture. Il est donc facile de ne pas le remarquer jusqu’à ce que vous le ressentiez.

Si vous comparez plus généralement les heures de GPU louées aux tokens d’API, le seuil de rentabilité entre un GPU VPS et les 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 marqué v1.2.8 le 29 July 2026, puis v1.3.0 le 5 August 2026. À ce rythme, le projet 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 suivante, sans conserver la version qui a produit les mesures.

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

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

Comme le modèle local génère une réécriture pour chaque segment qu’il compresse, une passe de compression trop longue se manifeste par un tour d’agent bloqué. La limite num_predict d’Ollama sur la longueur de sortie permet de plafonner cette durée.

Ajoutez paritok.yaml à côté. use_gpu_server: false garantit que la compression reste 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 qui regroupe toutes ces opérations : 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 de version. /stats renvoie les totaux de compression et l’estimation de ce que le proxy pense avoir économisé. 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 sert 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 concurrentes, ce qui devient important dès que plusieurs agents partagent la machine. La différence pratique entre Ollama et vLLM détermine le choix à faire.

Configurez l’agent pour utiliser le proxy avec les variables d’environnement de l’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 écrit donc ~/.codex/config.toml pour vous lorsque codex.enabled: true est défini dans paritok.yaml. Exporter uniquement la variable laisse Codex communiquer directement avec le fournisseur. Le signe révélateur est un compteur /stats qui ne bouge jamais pendant votre travail.

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

Exécutez-le avec systemd pour qu’il survive à un redémarrage. 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 à 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 son coût

Le projet propose également la compression en tant que service. Définissez 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, avec une utilisation gratuite jusqu’à la fin du mois d’août 2026, selon sa propre documentation. Vous n’avez alors plus à payer la location du GPU ni à effectuer les opérations décrites plus haut.

Cela signifie également que vos prompts et les fichiers lus par votre agent quittent votre machine et sont transmis à un tiers avant d’atteindre votre fournisseur de modèles. L’auto-hébergement sert précisément à éviter ce détour. Déterminez lequel de ces deux objectifs est prioritaire avant de définir cette option : sa modification tient sur une ligne, mais ses conséquences sont bien plus importantes.

Comment mesurer vos résultats 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.

• Faites fonctionner le système pendant une semaine normale, sans proxy sur le chemin. Relevez séparément les input tokens, les cache-read tokens et les output tokens sur la page d’utilisation de votre fournisseur, et non sous la forme d’un total en dollars.
• La semaine suivante, placez le proxy devant le système et effectuez le même type de travail.
• Comparez les lignes correspondant aux input tokens et aux cache-read tokens. La sortie devrait rester à peu près stable, car rien ne la compresse. Si la sortie a beaucoup changé, cela signifie qu’un autre élément a été modifié.
• Comptez les tâches que vous avez dû refaire. C’est la partie qualité du compromis, et aucun dashboard ne la mesure.
• Ajoutez les heures GPU de la deuxième semaine avant de comparer les totaux.

Il est important de séparer les entrées et les sorties, car leurs tarifs sont très différents 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 si un compresseur côté entrées présente un intérêt pour vous. La répartition réelle des tokens de Claude Code indique quelle partie de votre contexte est suffisamment volumineuse pour justifier une compression.

Le prompt caching complique en particulier le calcul des économies liées au filtrage des outils. Le bloc des outils se trouve au début de la requête. Après le premier tour, il bénéficie donc normalement d’un cache hit facturé à 10% du tarif 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 toute 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 ci-dessus proviennent du projet lui-même. Il n’existe aucune reproduction indépendante des résultats de SWE-bench Lite et, les premiers tags datant de July 2026, le code dispose également 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, et que vous devez les considérer différemment d’un chiffre que vous avez vous-même obtenu.

Un comportement documenté mérite d’être connu avant que vous n’incriminiez 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 une phase de warm-up de 10 à 15 secondes, puis environ 15 ms par appel. Envoyez une requête sans importance après le démarrage du proxy : votre premier véritable tour d’agent ne donnera pas l’impression de rester bloqué.

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

Concernant son positionnement par rapport à 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 l’objectif réel est de réduire la facture plutôt que d’utiliser précisément cet outil, l’ensemble plus large des leviers de réduction des 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 d’API ou seulement 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. Cette réduction est moins importante que ne le laisse entendre le 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 changent. 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 du seuil de rentabilité. Le filtre de schéma d’outils n’a besoin d’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 bénéficier de la réduction des blocs d’outils avec seulement 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 plutôt que supprimés, et le modèle en récupère un avec gateway_search_tools. Le vrai 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 doit 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. Envoyez une requête sans importance avec curl après le démarrage du proxy. Le premier tour réel de l’agent ne sera ainsi pas bloqué.

Dois-je utiliser le serveur GPU hébergé plutôt que l’auto-hébergement ?

Cette solution supprime le coût du GPU et la maintenance, pour un tarif de $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 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 à la fois le contexte et la clé API du fournisseur sur votre propre serveur.