RTK 0.45 : ce qui a changé depuis notre analyse
Outils
En avril, nous avons publié une analyse de RTK 0.30.0 à partir de sessions réelles de programmation assistée. Le constat était simple : un outil qui compresse les sorties peut faire économiser des tokens, mais devenir contre-productif s’il masque un traceback ou une valeur dont l’agent a besoin pour continuer.
RTK a évolué depuis. Cette mise à jour vérifie les deux cas les plus marquants avec RTK 0.45.0, installé localement au moment de l’essai.
Ce qui est corrigé : les réponses JSON de curl
Dans RTK 0.30.0, une réponse JSON obtenue avec rtk curl pouvait être transformée en schéma de types. Un token JWT devenait string, ce qui empêchait l’agent de le réutiliser dans la requête suivante.
Ce comportement n’est plus reproduit en 0.45.0. Sur une API externe, RTK préserve désormais les valeurs du corps JSON. Le cas du JWT masqué décrit dans l’article d’avril doit donc être lu comme un comportement historique de la version 0.30.0.
La version 0.36.0 avait déjà introduit une première correction pour les adresses internes et localhost. La préservation des réponses JSON est maintenant plus générale dans la version vérifiée.
Ce qui reste fragile : certains résumés pytest
Le sujet pytest est plus nuancé. RTK a corrigé en 0.36.0 la détection directe de la ligne de résumé produite par pytest -q. Une erreur de collecte avec traceback n’a pas été masquée lors de notre essai direct sur macOS avec RTK 0.45.0.
Il reste toutefois un cas reproductible. Si le projet définit addopts = -q dans pytest.ini, alors :
# Résultat brut
$ pytest test_quiet_mode.py
2 passed
# Résumé RTK 0.45.0
$ rtk pytest test_quiet_mode.py
Pytest: No tests collected
Les tests ont bien été exécutés, mais le résumé est incorrect. RTK ajoute lui-même un mode silencieux lorsqu’il ne voit pas de flag dans les arguments de la commande. Il ne peut pas détecter l’option équivalente déclarée dans pytest.ini.
Ce cas est suivi dans le ticket #2960. Il confirme que le problème n’est pas entièrement résolu pour pytest, mais il ne valide pas l’idée que toutes les sorties pytest seraient encore masquées en 0.45.0.
Ce que cela change pour l’article initial
L’analyse d’avril reste pertinente sur un point de méthode : la compression doit être évaluée aussi sur l’information perdue et sur les tours supplémentaires qu’elle peut provoquer chez un agent.
En revanche, les exemples doivent être distingués :
- le cas
curlet JSON est corrigé dans la version vérifiée ; - le cas
pytestest partiellement corrigé, avec au moins une régression encore reproductible ; - une sortie RTK vide ou ambiguë mérite toujours une exécution directe avant de modifier le code.
La bonne règle reste donc pragmatique : utiliser RTK là où le format de sortie est stable, et revenir à la commande brute dès que le résumé ne correspond pas à ce qui est attendu.