À propos du projet

skillstate-proxy est un proxy HTTP local destiné aux workflows d'agents capables d'exprimer leur progression sous forme d'état structuré explicite. Il se place entre un client et un fournisseur de modèle configuré, construit le contexte à partir de la spécification de tâche, de l'état JSON de la session et de la dernière observation, puis extrait un state_patch de la réponse du modèle. Le README présente la réduction de tokens comme dépendante de la charge de travail et indique explicitement que les économies, la latence, la précision et la compatibilité avec les fournisseurs ne sont pas garanties. L'installation utilise npm (Node.js 20 ou plus récent). L'exécutable est skillstate, également disponible sous le nom skillstate-proxy. La configuration se fait via des variables d'environnement telles que SKILLSTATE_UPSTREAM, SKILLSTATE_API_KEY, SKILLSTATE_PORT (par défaut 127.0.0.1:8789), SKILLSTATE_SCHEMA, SKILLSTATE_INITIAL_STATE, SKILLSTATE_CONFIG et SKILLSTATE_VERBOSE, ainsi que des options CLI --config, --upstream, --port, --schema et --verbose. L'ordre de priorité est : options CLI, variables d'environnement, fichier de configuration, puis valeurs par défaut. Un client de chat compatible pointe vers http://127.0.0.1:8789/v1. Le contrat d'état fusionne les patchs en remplaçant les tableaux, en fusionnant récursivement les objets et en supprimant une clé lorsque la valeur de son patch est null. Le README souligne qu'il ne s'agit pas d'une archive de transcription sans perte : les faits non conservés dans l'état peuvent être indisponibles ultérieurement, et un enregistrement d'audit distinct est conseillé lorsque des preuves verbatim importent. Les listes de clés autorisées ne limitent pas la taille des valeurs ou des observations. La surface HTTP inclut POST /v1/chat/completions, POST /v1/messages (traduction au format Anthropic), GET /v1/models, GET /health, GET /state (avec ?session=ID), DELETE /state?session=ID et GET /cost. Le README avertit qu'une route implémentée ne prouve pas que toutes les fonctionnalités du SDK fonctionnent, et recommande de tester le streaming, la corrélation des appels d'outils, les sessions concurrentes, les tentatives et l'annulation avec le client, le fournisseur et le modèle exacts. Les paramètres optionnels rpm/tpm par upstream utilisent une fenêtre glissante locale d'une minute et ne constituent pas des quotas côté fournisseur ni des limiteurs distribués. La vérification depuis les sources utilise npm ci, npm run build et npm test avec le package-lock.json versionné ; la CI vérifie Node.js 20, 22 et 24. Les contrôles optionnels de mise en page de la documentation statique utilisent Python Playwright. Les benchmarks (conversation et boucle d'outils) nécessitent une configuration explicite du fournisseur et peuvent coûter de l'argent ; le README conseille de conserver la révision, la charge de travail, le modèle, le schéma, l'usage brut, les tentatives, les scores de qualité et les échecs avec tout résultat, et de comparer les coûts totaux facturés en entrée/sortie. Le projet fait référence à l'article SKILL.state (arXiv:2608.26263) et note que les résultats de recherche n'établissent pas la précision de cette implémentation ni sa compatibilité universelle. Il est sous licence MIT, sans affiliation avec OpenAI ou Anthropic, et la licence ne couvre pas l'inférence ou l'hébergement en amont. L'état est persisté localement et peut contenir des informations de tâche sensibles ; l'upstream reçoit le contexte réécrit, le listener doit donc rester privé. Le README indique que le projet n'est pas une frontière de sécurité multi-tenant simplement parce qu'il possède des identifiants de session.