20 projets Jev open source à essayer en 2026 : MCP, agents de codage, automatisation de navigateur et plus encore

Jev n'est public que depuis peu, mais les développeurs l'ont déjà intégré à des agents de codage, des boucles de navigateur, des outils MCP, des pipelines de jeux de données, des jeux, des expériences de robotique et des systèmes de trading.

Il ne s'agit pas d'une autre liste de cas d'utilisation théoriques de Jev. Les projets ci-dessous montrent quelque chose de plus utile : où les développeurs placent un modèle de décision dans un logiciel réel, ce que Jev est autorisé à décider et quelles parties restent prises en charge par du code déterministe ou par un modèle génératif plus vaste.

Si le modèle lui-même est nouveau pour vous, commencez par notre explication de la façon dont fonctionnent les modèles de décision Jev. Si vous recherchez des schémas d'application plus larges plutôt que des dépôts individuels, le guide précédent consacré aux cas d'utilisation réels de Jev couvre l'orchestration d'agents, le triage de recherches, l'automatisation du navigateur et d'autres types de charges de travail.

Une réserve toutefois : cet écosystème est extrêmement récent. De nombreux dépôts sont des expériences, des démonstrations ou des projets développés par une seule personne. Vérifiez le dépôt actuel, la licence, le comportement de l'API et les limites de sécurité avant de considérer l'un d'eux comme un logiciel prêt pour la production.

Ce que ces 20 projets Jev testent réellement

Les projets semblent très différents en surface, mais la plupart suivent la même architecture :

état structuré ↓ décision bornée ↓ politique logicielle ordinaire ↓ outil, modèle ou action

L'important, c'est que Jev ne prend que rarement en charge l'ensemble du workflow. Il remplace généralement un jugement flou et ciblé qui nécessiterait autrement un autre appel à un LLM ou un nombre croissant d'heuristiques.

Les agents de codage deviennent le banc d'essai le plus intéressant de Jev

Les agents de programmation génèrent d’énormes quantités d’état intermédiaire : contenu des fichiers, sorties de commandes, traces de pile, différences, journaux de tests et décisions de routage répétées. Une grande partie de ce travail n’a pas besoin d’un paragraphe supplémentaire produit par un modèle de pointe. Elle a besoin d’une sélection.

1. fast-jev-compaction — Compressez le contexte sans le réécrire

fast-jev-compaction remplace l’étape habituelle de compression largement fondée sur la synthèse par des jugements de pertinence portant sur les appels d’outils et les résultats précédents.

L’historique de faible valeur peut être supprimé ou tronqué, tandis que les commandes, chemins, erreurs et sorties conservés restent verbatim. La compression du contexte devient ainsi un problème de sélection plutôt qu’un problème de réécriture.

L’intérêt n’est pas que Jev rédige un meilleur résumé. Il évite d’en rédiger un.

2. Winnow — Empêchez les sorties d’outils non pertinentes d’entrer dans le contexte

Winnow s’attaque au même problème plus tôt dans le pipeline. De grandes Lire, Bash ou Grep les résultats sont divisés en blocs, puis évalués en fonction de leur pertinence pour la tâche avant de consommer davantage de contexte.

La distinction par rapport à la compression est importante :

• Winnow : filtre les informations lors de leur entrée dans le contexte de travail.
• fast-jev-compaction : supprime les informations obsolètes déjà présentes dans l’historique de la conversation.

Ensemble, ils montrent deux points différents où les agents de programmation peuvent remplacer la synthèse gourmande en jetons par des jugements de pertinence encadrés.

3. Jev Codex Router — Déterminez de quel niveau de modèle une tâche a réellement besoin

Jev Codex Router place la décision à un niveau supérieur : avant que Codex ne traite une tâche, Jev sélectionne un niveau de modèle et un effort de raisonnement.

Jev devient ainsi un contrôleur de trafic plutôt qu’un modèle de programmation. Les tâches simples peuvent rester sur un parcours moins coûteux, tandis que les tours difficiles peuvent être réorientés.

Le dépôt présente une simulation historique suggérant des économies substantielles par rapport au routage de chaque tour testé via son parcours auparavant le plus coûteux, mais ce chiffre doit être considéré comme un backtest plutôt que comme une mesure des économies actuelles de quota Codex.

L’architecture se rattache également à une question plus générale que nous avons déjà explorée : savoir si un petit modèle peut acheminer les requêtes vers des modèles plus grands sans devenir lui-même le moteur de raisonnement final.

4. Jev Review — Consacrez l’attention de la revue là où elle compte

Jev Review décompose la revue de code en jugements plus ciblés, comme déterminer quels fichiers méritent de l’attention, quels éléments probants sont pertinents et quelle peut être la gravité d’un problème suspecté.

L’élément intéressant est la priorisation. Jev n’a pas besoin de générer la revue finale pour améliorer le flux de travail ; il peut d’abord réduire une grande différence aux endroits où un raisonnement plus approfondi ou une revue humaine méritent d’être mobilisés.

5. Blink — Parcourir une base de code, un choix sémantique à la fois

Blink traite la recherche dans un dépôt comme une sélection de chemin.

À chaque niveau de répertoire, les fichiers et dossiers visibles deviennent des candidats. Jev sélectionne la branche suivante la plus prometteuse pour la question actuelle, puis la recherche se poursuit récursivement.

Au lieu d’intégrer un dépôt entier avant chaque requête, le système pose plusieurs fois une question beaucoup plus ciblée : où dois-je chercher ensuite ?

6. Canny — Distinguer « Je pense avoir terminé » des preuves que le travail est terminé

Canny cible les affirmations de réussite des agents.

Les enregistrements déterministes indiquent ce qui s’est réellement passé : fichiers modifiés, commandes exécutées, tests terminés et résultats produits. Jev peut ajouter des jugements sémantiques autour de ces éléments de preuve, mais le modèle ne devient pas la couche d’autorisation ultime.

Cette séparation est importante pour les agents locaux capables de modifier des systèmes réels. Notre guide sur les limites de confiance liées à l’exécution d’outils explique le même principe à l’échelle plus large de l’architecture des agents : décider qu’une action semble appropriée n’est pas la même chose que lui accorder l’autorisation de l’exécuter.

Les projets MCP et CLI transforment Jev en infrastructure

Le groupe suivant est moins spécifique aux applications. Ces projets rendent Jev disponible comme primitive de décision réutilisable au sein d’outils existants.

7. typesafe-mcp — Donner aux agents existants un accès direct à Jev

typesafe-mcp expose Jev via le Model Context Protocol.

Un agent compatible avec Claude, Codex ou MCP peut demander un jugement structuré de type Choice, Score ou Noul sans implémenter une nouvelle intégration de Jev pour chaque flux de travail. L’agent décide toujours quand appeler l’outil et que faire du résultat.

8. jev-mcp — Transformer les décisions courantes en outils pour agents

jev-mcp élève le niveau d’abstraction en proposant des opérations familières telles que la classification, la notation, le filtrage et la mise en correspondance.

Au lieu que chaque agent invente un nouveau prompt pour le même jugement, les schémas de décision courants peuvent devenir des interfaces réutilisables avec des sorties structurées.

9. SemDecide — Intégrer la logique sémantique aux pipelines Unix

SemDecide explore une surface d’intégration encore plus réduite : la ligne de commande.

grep → jq → décision sémantique → action shell

C’est utile pour les questions difficiles à exprimer avec une expression régulière, mais encore trop limitées pour justifier un agent autonome, par exemple pour déterminer si une modification semble sensible du point de vue de la sécurité ou si un enregistrement appartient à une catégorie sémantique.

La frontière essentielle reste déterministe : les autorisations, les commandes destructrices et les contrôles de sécurité en production doivent rester dans du code classique.

Agents de navigateur et de bureau : choisir des actions plutôt que les générer

L’automatisation des navigateurs convient particulièrement bien à une couche de décision limitée. Une fois la page convertie en éléments candidats, une grande partie de la boucle consiste à sélectionner des actions plutôt qu’à générer du langage.

10. jev-ultrafast — Générer uniquement lorsque le navigateur a réellement besoin de mots

jev-ultrafast construit un espace d’actions indexé à partir de la page actuelle et laisse Jev choisir une opération et un élément cible.

Un modèle génératif n’est nécessaire que lorsque l’action sélectionnée exige du nouveau texte, par exemple pour remplir un champ de formulaire.

La démonstration Google Flights du projet indique environ sept secondes pour une tâche, en incluant la génération et les temps d’attente des pages. Cela ne doit pas être considéré comme une référence universelle pour les agents de navigateur. Le résultat architectural le plus important est le suivant : la sélection des clics et la génération de texte n’ont pas besoin d’utiliser le même modèle.

11. agent-desktop — Appliquer le même principe aux interfaces natives

agent-desktop expose les interfaces macOS au moyen de données d’accessibilité et de références stables aux éléments.

Au lieu de reconstruire le bureau à partir de captures d’écran à chaque étape, le système peut fournir à Jev un ensemble limité de contrôles et d’actions. Les outils natifs effectuent toujours le clic, la mise au point ou l’opération au clavier.

C’est un rappel utile : une meilleure observation compte souvent davantage qu’un modèle plus grand.

12. json-render + Jev — Interface utilisateur générative sans génération arbitraire d’interfaces

json-render expérimente l’utilisation de Jev pour composer des interfaces à partir d’un catalogue de composants appartenant à l’application.

L’application définit les composants, propriétés et actions autorisés. Jev choisit parmi ces possibilités, tandis que du code classique assemble et valide l’arborescence obtenue.

Le chemin de composition de Jev reste expérimental, mais il démontre une alternative utile à la génération non contrainte de JSON d’interface utilisateur : laisser l’application définir le vocabulaire, puis laisser le modèle choisir parmi ces éléments.

Les jeux et la robotique montrent où Jev ne doit pas prendre le contrôle

Les systèmes en temps réel rendent les limites architecturales évidentes. La physique, la gestion des collisions, la sécurité et les boucles de contrôle rapides ne peuvent pas attendre la réponse incertaine d'un modèle.

13. typesafe-mario — État structuré du jeu en entrée, action légale du contrôleur en sortie

typesafe-mario convertit la télémétrie de l'émulateur et la mémoire RAM en un état structuré et compact au lieu d'envoyer des captures d'écran à Jev.

Jev choisit ensuite parmi des actions légales du contrôleur, comme se déplacer vers la droite, sauter ou courir et sauter. Les calculs temporels, le contrôle de l'émulateur et l'extraction de l'état du jeu restent gérés par des logiciels ordinaires.

La démonstration isole clairement le problème de décision : le modèle n'a pas besoin de reconstruire le monde du jeu à partir de pixels avant chaque mouvement.

14. jev-drone — Garder le modèle au-dessus de la boucle de sécurité

jev-drone fait fonctionner un quadricoptère autonome dans une simulation MuJoCo.

Le contrôle géométrique rapide, le guidage et la sécurité restent déterministes. Jev opère beaucoup plus lentement, comme couche tactique consultative qui interprète la situation actuelle.

Contrôle de vol à 500 Hz ; guidage + sécurité à 50 Hz ; caméra à 15 Hz → scène symbolique à ~2,5 Hz ; jugement tactique de Jev

Le projet est une simulation, et non la preuve que Jev devrait piloter un véritable aéronef. Sa leçon architecturale est plus solide que cette affirmation : le jugement probabiliste doit se situer au-dessus de la logique de sécurité en temps réel strict.

15. OneVOneJev — Une boucle de jeu consiste surtout en une sélection répétée

OneVOneJev applique Jev à un jeu de tir un contre un dans un navigateur.

Le serveur gère la physique, le réseau et l'état légal du jeu. Jev opère dans ce monde contraint en choisissant des actions de déplacement ou de combat.

Le projet est donc utile moins comme produit de jeu que comme test de résistance pour des décisions répétées et encadrées, dans lesquelles produire des explications en langage naturel n'apporterait presque rien.

Expériences de trading : les modèles de décision ne doivent pas gérer le portefeuille

Les démonstrations financières méritent une interprétation plus stricte. Un jugement rapide du marché ne prouve pas la rentabilité des transactions, et il ne faut pas confondre un bot expérimental avec une stratégie validée.

16. jev-trader — Une décision de direction par bloc Monad

jev-trader surveille le carnet d'ordres Kuru MON-USDC sur Monad et demande à Jev de choisir une direction d'achat ou de vente une fois par bloc.

Le système environnant gère les données de marché, la construction des ordres à cours limité, les contraintes de position et l'exécution. Il prend également en charge le fonctionnement en simulation sans clé privée.

Cette limite est la partie utile : Jev apporte un jugement de marché ; les logiciels ordinaires restent responsables de la mécanique de trading.

17. Prism — Traiter Jev comme un signal, pas comme la stratégie

Prism adopte une approche davantage consultative. Jev évalue les conditions du marché, comme la qualité des flux, la pression ou les signaux de retour à la moyenne, tandis que les couches de stratégie et d’exécution restent séparées.

Il s’agit d’un meilleur modèle général pour les workflows à fort impact : les modèles peuvent fournir des éléments probabilistes sans obtenir d’autorité sur des actions irréversibles.

Les pipelines de recherche et de données montrent que Jev n’a pas besoin d’un agent

Certains des projets les plus puissants suppriment entièrement les agents autonomes. Jev devient une opération sémantique au sein d’un algorithme conventionnel.

18. neo4jev — Ajouter un jugement sémantique à la recherche dans les graphes

neo4jev utilise Jev lors du parcours d’un graphe de connaissances Neo4j.

À chaque nœud, les relations candidates deviennent un choix limité. Jev estime quelle arête est la plus prometteuse pour la question actuelle, tandis que le code de recherche classique gère le parcours, les nœuds visités, la largeur de faisceau et les conditions d’arrêt.

Il s’agit d’un modèle utile au-delà des graphes : remplacer une heuristique fragile au sein d’un algorithme existant plutôt que reconstruire toute l’application autour de l’IA.

19. jev-curate — Évaluer les données avant d’y consacrer davantage de calcul

jev-curate applique des jugements sémantiques répétés à des enregistrements JSONL ou Parquet avant leur intégration à des étapes plus coûteuses d’entraînement, d’analyse ou de révision.

La curation des données est une tâche naturellement axée sur la décision : des millions de lignes peuvent nécessiter des jugements de pertinence, de qualité ou de risque, mais presque aucune ne requiert un paragraphe de texte généré.

Le modèle s’occupe de l’évaluation nuancée ; le pipeline reste responsable du regroupement, des seuils, du stockage et de la politique d’acceptation finale.

20. killmyidea — Une petite démonstration qui rend l’architecture évidente

killmyidea demande à Jev d’évaluer une idée de start-up à partir de plusieurs questions structurées.

L’application applique ensuite des pondérations, des garde-fous et des seuils classiques pour transformer ces scores en un verdict final KILL, FIX ou SHIP.

idée ↓ scores Jev ↓ pondération déterministe ↓ KILL / FIX / SHIP

C’est un petit projet, mais il illustre un principe de conception important : l’IA peut apporter un jugement utile sans être responsable de la génération du produit final.

Quel projet Jev devriez-vous essayer en premier ?

Pouvez-vous exécuter ces projets Jev localement ?

Dans de nombreux cas, vous pouvez exécuter localement le projet environnant. Cela ne signifie pas que Jev lui-même s'exécute localement.

En septembre 2026, Jev est accessible en tant que service TypeSafe hébergé plutôt que sous forme de poids de modèle téléchargeables publiquement. Un agent de codage local, un serveur MCP ou un contrôleur de navigateur peut donc s'exécuter sur votre propre machine tout en envoyant l'état décisionnel sélectionné à l'API Jev.

fichiers locaux / navigateur / agent ↓ environnement local ou serveur MCP ↓ état structuré sélectionné ↓ API Jev ↓ décision typée ↓ le logiciel local s'exécute

Si le fait de conserver le modèle de décision lui-même sur votre matériel est important, c'est à ce niveau que l'architecture change. Notre guide consacré au modèle de décision local open source Laya examine une solution alternative avec des poids téléchargeables pouvant s'exécuter sur du matériel local.

La distinction est utile pour les déploiements en homelab et d'IA privée :

Cette différence compte davantage que le fait qu'un fichier README GitHub indique « local ». Un workflow peut être hébergé localement alors qu'une étape de décision dépend encore d'un service d'inférence externe.

Le véritable modèle Jev est plus petit qu'un agent

Le plus important à propos de ces 20 projets n'est pas le nombre d'applications que les développeurs ont déjà créées. C'est la constance avec laquelle Jev apparaît à un point précis de la boucle.

Un navigateur sait déjà quels éléments existent. Jev en choisit un.

Un agent de codage a déjà produit des milliers de lignes de sortie d'outils. Jev décide ce qui compte encore.

Un routeur sait déjà quels modèles sont disponibles. Jev choisit un itinéraire.

Un graphe contient déjà ses arêtes. Jev choisit celle qui semble utile.

Un drone possède déjà un contrôleur de vol. Jev fournit un jugement tactique plus lent.

Un système de trading possède déjà une logique d'ordres et des contraintes de risque. Jev fournit un signal de direction.

C'est ce qui rend la première vague de projets Jev plus intéressante qu'une nouvelle collection de démonstrations de chatbots. Les développeurs testent si certaines parties de la pile d'IA actuelle devraient cesser d'être génératives.

La question utile n'est donc pas de savoir si Jev peut remplacer un LLM de pointe.

C'est la preuve que de nombreux appels LLM coûteux et ouverts dans les logiciels actuels n'étaient en réalité que des décisions bornées qui attendaient une interface plus légère.