Prime Intellect publie Prime Agent, un harnais RLM open source où les sous-agents sont des appels de fonction dans un noyau IPython persistant

Cline publie son SDK open source : un runtime d'agents qui alimente désormais son CLI et son Kanban, avec migration des extensions IDE

Cline, l'agent de codage IA open-source utilisé par des millions de développeurs, a annoncé cette semaine une refonte architecturale majeure avec la sortie de @cline/sdk, un runtime d'agent TypeScript désormais disponible en open-source. Concrètement, l'équipe a extrait le coeur du moteur agentique, jusqu'ici étroitement couplé à l'extension VS Code, pour en faire un SDK indépendant, modulaire, sur lequel tous ses produits sont désormais reconstruits : l'extension VS Code, JetBrains, le CLI et le tableau Kanban. Le SDK est structuré en couches strictement ordonnées : @cline/shared (types, schémas, utilitaires), @cline/llms (passerelle vers Anthropic, OpenAI, Google, AWS Bedrock, Mistral, LiteLLM et tout endpoint compatible OpenAI), @cline/agents (boucle d'exécution stateless, compatible navigateur), et @cline/core (orchestration Node.js, sessions, stockage, télémétrie, plugins). Chaque couche est installable séparément, ce qui permet par exemple d'utiliser uniquement @cline/llms comme proxy LLM sans embarquer tout le runtime. Cette architecture redéfinie apporte des gains concrets mesurables. Avec Cline 2.0, l'équipe a reécrit les prompts, simplifié la boucle agentique et amélioré la gestion du contexte. Les résultats publiés sur Terminal Benchmark 2.0 (tbench.ai) au 8 mai 2026 sont frappants : sur claude-opus-4.7, le CLI Cline atteint 74,2% contre 69,4% pour Claude Code d'Anthropic sur le même modèle. Sur claude-opus-4.6, l'écart est similaire, 71,9% contre 65,4%. Sur les modèles open-weight, Cline marque 55,1% sur Kimi-K2.6, contre 37,1% pour OpenCode et 45,5% pour Pi-Code. Côté stabilité, les sessions agentiques longues ne meurent plus lors d'un redémarrage de l'interface : la boucle reste stateless et portable, tandis que la persistance est gérée séparément par le runtime. Cette sortie s'inscrit dans une tendance plus large : celle de la fragmentation et de la standardisation de l'outillage agentique. Pendant des années, les agents IA étaient construits comme des monolithes liés à une interface spécifique, VS Code, un navigateur, un SaaS. Le choix de Cline de découpler son moteur de ses surfaces d'affichage ouvre la voie à une nouvelle génération d'outils où le même agent peut s'exécuter dans un IDE, un terminal, un serveur serverless ou un environnement browser sans réécriture. Le système de plugins intégré au SDK permet en outre aux équipes tierces d'enregistrer leurs propres outils, d'observer les événements du cycle de vie de l'agent et d'étendre ses capacités. Pour les éditeurs et startups qui cherchent à construire sur une base agentique robuste sans repartir de zéro, @cline/sdk représente une fondation crédible, et son positionnement open-source face à des alternatives propriétaires comme Claude Code ou Cursor pourrait accélérer l'adoption dans les environnements d'entreprise.

Y Combinator publie en open source QM, un cadre d'agents multijoueurs sous licence MIT, fonctionnant sur Slack et sur le web

Y Combinator a mis en open source QM, pour quartermaster, le harnais multi-agents qu'elle utilise en interne pour faire tourner ses propres équipes comptabilité, juridique, événementiel et ingénierie, y compris pour développer QM lui-même. Le projet est publié sous licence MIT et YC le présente comme une expérimentation encore jeune, avec des bugs connus. QM fonctionne à la fois dans Slack et sur le web, et son déploiement ne nécessite pas de cloner le dépôt : une organisation crée son propre dépôt de déploiement qui dépend du paquet @yc-software/qm, puis lance la commande qm init avec un identifiant d'organisation et une cible d'hébergement, Fly.io ou AWS. Cette initialisation déclenche un parcours guidé couvrant l'infrastructure, la connexion web, les connecteurs, l'accès Slack optionnel et une vérification en conditions réelles. La connexion des utilisateurs repose par défaut sur un système intégré qui envoie un lien à usage unique par email, remplaçable par un fournisseur d'identité externe. YC cible en priorité les startups et entreprises de taille moyenne, entre 10 et 500 salariés, disposant d'au moins un ingénieur plateforme, les grandes entreprises devant d'abord auditer le modèle de sécurité. L'intérêt de QM tient à sa conception : plutôt que de démultiplier un assistant personnel unique à l'échelle d'une entreprise entière, ce qui devient vite complexe selon l'équipe YC, chaque employé dispose d'un espace de travail isolé que les autres ne peuvent pas affecter, tout en pouvant collaborer avec l'agent dans des canaux ou des projets partagés. Chaque personne et chaque salon obtient sa propre mémoire, ses fichiers, ses permissions, ses tâches planifiées et son bac à sable durable et isolé. Côté sécurité, l'agent agit avec les identifiants et permissions de la personne qu'il représente, et chaque action est auditée. Une organisation choisit une posture globale, allant d'un mode strict qui suspend chaque appel d'outil pour validation humaine, à un mode automatique qui filtre les données externes via un classifieur avant qu'elles n'atteignent le modèle, jusqu'à un mode sans filtrage destiné aux usages les plus permissifs. Techniquement, QM repose sur un noyau central sans interface qui gère l'API, l'identité, les politiques et la planification, adossé à une couche PostgreSQL pour les données utilisateurs et l'historique de session. Le cœur tourne en TypeScript sur Node avec Fastify, le plugin Slack utilise Bolt et l'interface web s'appuie sur Vite et Lit. Surtout, QM se veut agnostique du moteur d'agent : Pi, OpenCode, Codex et Claude Code peuvent tous piloter le même noyau, ce qui évite tout verrouillage vers un fournisseur unique dans un marché des outils multi-agents encore en pleine consolidation.

💬 Bon, sur le papier, YC ne réinvente rien, mais l'idée d'isoler chaque salarié dans son propre bac à sable plutôt que de brancher un assistant unique sur toute la boîte, c'est le truc que tout le monde va copier d'ici un an. Selon Le Fil IA, QM déplace le vrai problème des agents en entreprise, qui n'est pas le modèle mais l'isolation des permissions et des données par utilisateur. Reste à voir si ça tient en prod au-delà de YC elle-même, mais l'agnosticisme côté moteur (Claude Code, Codex, peu importe) est la bonne décision dans un marché encore trop verrouillé.

NVIDIA AI publie 'OpenShell' en open source : un environnement d'exécution sécurisé pour les agents IA autonomes

NVIDIA franchit une étape importante dans la sécurisation des agents IA autonomes en publiant OpenShell en open source sous licence Apache 2.0. Cet environnement d'exécution dédié répond à un problème concret : les agents capables d'exécuter du code et d'interagir avec des systèmes fichiers ou des endpoints réseau représentent une surface d'attaque bien plus large que les applications LLM classiques, limitées aux échanges textuels. L'enjeu est de taille pour l'industrie. Jusqu'ici, la sécurité des agents autonomes reposait principalement sur l'alignement interne du modèle, une approche jugée insuffisante face à des risques d'exécution de commandes non souhaitées ou d'accès non autorisé à des données sensibles. OpenShell introduit une couche de sécurité externe et explicite, indépendante du comportement du modèle, ce qui représente un changement de paradigme pour les équipes de développement. Techniquement, la solution s'articule autour de trois piliers. D'abord, un sandbox à isolation kernel qui confine tout code généré, scripts Python, commandes Bash, dans un espace restreint. Ensuite, un moteur de politiques granulaire permettant un contrôle par binaire (git, curl, python), par endpoint réseau et par méthode d'API, avec un journal d'audit complet de chaque action. Enfin, un mécanisme de routage d'inférence privé qui intercepte le trafic modèle pour éviter les fuites de données vers des fournisseurs cloud externes. Point clé : OpenShell est agent-agnostique, il fonctionne sans modification avec Claude Code, Codex, LangChain ou tout autre framework existant, via une simple CLI et une interface TUI pour le monitoring en temps réel. La prise en charge d'exécution distante (openshell sandbox create --remote user@host) ouvre également la voie à des déploiements sur clusters GPU haute performance, ce qui positionne NVIDIA non seulement comme fournisseur de matériel, mais comme acteur central de l'infrastructure logicielle pour agents IA en production.

RightNow AI publie AutoKernel : un framework open source qui applique une boucle d'agents autonomes à l'optimisation des kernels GPU pour les modèles PyTorch

RightNow AI a publié AutoKernel, un framework open-source qui automatise l'optimisation des kernels GPU pour n'importe quel modèle PyTorch. Le principe est simple : soumettre un modèle avant de dormir et retrouver au matin des kernels Triton plus rapides, sans avoir à maîtriser la programmation GPU de bas niveau. Le système repose sur une boucle agentique autonome : un agent LLM modifie un fichier kernel.py, un banc de test vérifie la correction puis mesure le débit, et le résultat détermine si la modification est conservée ou annulée via un git reset. Chaque itération dure environ 90 secondes, ce qui permet de réaliser 300 à 400 expériences lors d'une session de 10 heures. L'agent suit un manuel d'optimisation en six niveaux encodé dans un document de 909 lignes, couvrant le réglage des tailles de blocs, les patterns d'accès mémoire, les optimisations de calcul comme TF32, les techniques avancées comme split-K, et les stratégies spécifiques aux architectures Hopper et Ampere de NVIDIA. L'enjeu est considérable pour l'industrie du machine learning. Optimiser un kernel GPU de haute performance exige de raisonner simultanément sur l'intensité arithmétique, la coalescence mémoire, la pression sur les registres, la synchronisation au niveau warp et la sélection des instructions tensor core, un ensemble de compétences qui prend des années à acquérir. Un seul kernel de multiplication matricielle performant peut représenter plus de 200 lignes de code CUDA ou Triton avec des dizaines de paramètres interdépendants. La suite de benchmarks KernelBench, qui évalue les grands modèles de langage sur 250 problèmes de kernels GPU, a montré que même les meilleurs modèles n'égalaient la baseline PyTorch que dans moins de 20 % des cas en génération directe. AutoKernel répond précisément à ce déficit en rendant cette expertise accessible sans spécialiste humain, ce qui pourrait accélérer significativement le développement et le déploiement de modèles d'IA. L'approche s'inspire directement du projet autoresearch d'Andrej Karpathy, dans lequel une boucle keep/revert appliquée à du code d'entraînement LLM avait permis de découvrir 20 optimisations en 700 expériences sur deux jours avec un seul GPU. AutoKernel transpose cette logique à l'espace des kernels, en substituant la loss de validation par un benchmark de correction et de débit comme fonction d'évaluation. La traçabilité est assurée par git, les résultats étant stockés dans un fichier TSV lisible directement par l'agent. Ce type de framework illustre une tendance plus large où les tâches d'ingénierie hautement spécialisées deviennent des cibles pour l'automatisation agentique, réduisant la dépendance aux rares experts en optimisation GPU à mesure que les architectures de modèles continuent d'évoluer.

💬 L'idée de laisser tourner une boucle agentique toute la nuit pour sortir des kernels Triton optimisés au matin, c'est exactement ce qu'on attendait depuis qu'on a vu Karpathy faire la même chose sur du code d'entraînement. La partie vraiment bien foutue, c'est le mécanisme d'évaluation : un benchmark de correction avant tout, et le git reset si ça régresse, ce qui évite de passer des heures à débugger des "optimisations" qui cassent tout. Pour les équipes sans expert CUDA dans les jambes, c'est une vraie bouffée d'air.