forkd : le fork de microVM pour le fan-out des agents IA

Les agents IA n’ont pas seulement besoin de meilleurs modeles. Ils ont besoin de meilleurs endroits pour s’executer.

Tout workflow d’agent serieux finit par rencontrer le meme probleme operationnel : le modele veut essayer plusieurs pistes en parallele, executer du code, inspecter des fichiers, lancer des tests, appeler des outils et parfois revenir en arriere apres une mauvaise decision. Les conteneurs sont pratiques, mais ils ne sont pas toujours la frontiere d’isolation souhaitee pour du code non fiable. Les machines virtuelles completes isolent mieux, mais demarrer une VM froide pour chaque branche de raisonnement est trop lent et trop couteux.

forkd est interessant parce qu’il cible directement cet espace. C’est un runtime de sandbox en microVM, publie sous Apache-2.0 et construit sur Firecracker, concu pour le fan-out des agents IA. Une microVM parente demarre une fois, chauffe le runtime, importe les dependances, charge l’etat, puis est mise en pause. Les enfants forkent ensuite depuis ce snapshot chaud avec de la memoire copy-on-write au lieu de redemarrer chacun un noyau.

forkd ressemble donc moins a un nouveau wrapper de conteneurs qu’a une version niveau VM de fork(2) pour l’infrastructure d’agents.

Ce qu’est forkd

forkd est un runtime de sandbox pour les workloads ou un environnement deja chaud doit produire rapidement beaucoup d’enfants isoles.

Le depot decrit une VM parente qui demarre une fois, importe le runtime, puis est mise en pause sur disque. Chaque enfant est lance comme un processus Firecracker separe qui mappe l’image memoire du parent en prive. Le copy-on-write de Linux garde la memoire inchangee partagee pendant que chaque enfant diverge independamment.

Pour les systemes d’agents IA, cela correspond a un schema simple :

1. Chauffer un environnement Python, Node, navigateur, base de donnees ou agent de code.
2. Forker plusieurs enfants depuis le meme etat prepare.
3. Lancer differents appels d’outils, tests, prompts ou patchs dans chaque enfant.
4. Garder chaque branche isolee.
5. Supprimer les branches perdantes sans reconstruire l’environnement.

C’est pour cela que le projet cible les code interpreters, les evaluations de type SWE-bench, l’execution de code par utilisateur, la CI non fiable et les integrations avec les frameworks d’agents.

L’idee centrale : fork depuis un etat chaud

Le cold start est l’ennemi du fan-out d’agents.

Si un agent veut evaluer dix correctifs possibles, lancer dix sessions de code interpreter ou tester un plan contre dix etats de depot, une pile classique paie le cout de demarrage a repetition. Ce cout peut inclure le runtime, l’installation de paquets, les imports de grosses bibliotheques, le demarrage d’un navigateur, le chargement de poids de modele ou la preparation d’une base de donnees de test.

forkd deplace ce cout dans le parent. Une fois le parent chaud, les enfants heritent de l’etat deja charge. Le projet rapporte un benchmark ou 100 sandboxes executant un workload numpy deja chaud demarrent en 101 ms, avec tres peu de memoire additionnelle par enfant car les pages inchangees sont partagees.

Le point important n’est pas le nombre exact sur le materiel du mainteneur. Le point important est le primitif : une isolation de vraie VM avec un cout de spawn plus proche d’un fork de processus que d’un demarrage froid de VM.

BRANCH : forker en plein raisonnement

La fonctionnalite la plus specifique aux agents est BRANCH.

Forker depuis un snapshot initial est utile, mais les agents doivent souvent se diviser apres avoir deja travaille. Un agent de code peut avoir clone un depot, installe des dependances, modifie des fichiers et lance un test en echec. Un agent de planification peut avoir accumule du raisonnement et des artefacts locaux. Un agent navigateur peut avoir atteint un etat couteux a reproduire.

BRANCH permet a forkd de mettre en pause une sandbox en execution, de snapshotter son etat courant, puis de reprendre depuis ce point. Dans les notes du mode live v0.4, forkd annonce une fenetre de pause p50 de 56 ms pour une source de 1,5 Gio sur son workload de benchmark, avec une copie en arriere-plan asynchrone possible pour les branches fire-and-forget.

Cela change l’orchestration des agents. Au lieu de demander au modele de serialiser chaque alternative en texte et de rejouer l’etat depuis zero, le systeme peut brancher l’etat reel de la machine.

Pourquoi c’est important pour les agents IA

Le contexte texte ne suffit pas pour beaucoup de taches d’agents.

L’etat utile d’un agent vit souvent hors du prompt :

• un depot clone;
• des fichiers generes;
• des paquets installes;
• des caches de test;
• des variables de notebook;
• un profil navigateur;
• des bases de donnees locales;
• des identifiants temporaires;
• un service local qui ecoute sur un port.

On peut resumer cet etat au modele, mais on ne peut pas mettre fidelement un arbre de fichiers de 50 Mio, un processus Python chaud ou un buffer de base de donnees modifie dans un prompt. La valeur de forkd est de traiter l’etat machine comme l’objet a brancher.

Cela le rend pertinent pour :

• les code interpreters qui ont besoin de sessions fraiches mais chaudes;
• les agents de code qui testent plusieurs patchs;
• les harnais d’evaluation qui lancent beaucoup de tentatives isolees;
• les agents navigateur ou Chromium domine le temps de demarrage;
• la CI qui execute du code non fiable;
• les tests avec fixtures de base de donnees isolees par test.

Comparaison avec les conteneurs

Les conteneurs restent le choix par defaut de nombreux workflows developpeurs parce qu’ils sont faciles a construire, distribuer et orchestrer. forkd ne les rend pas obsoletes.

La difference se situe dans l’isolation et le primitif de snapshot.

Avec forkd, chaque enfant est une microVM Firecracker appuyee par KVM. C’est une frontiere plus forte qu’un namespace de conteneur standard. L’enfant peut quand meme executer des workloads Linux reels, installer des paquets, faire des appels reseau sortants si la politique l’autorise, et utiliser des outils ordinaires. La relation memoire parent-enfant donne a forkd son profil de performance inhabituel.

Le compromis est la complexite operationnelle. Il faut Linux avec KVM, cgroup v2, Firecracker, des scripts de configuration hote et, pour certains chemins live-fork, un fork vendore de Firecracker jusqu’a ce que le support de backend memoire partage arrive upstream. C’est de l’infrastructure, pas une bibliotheque JavaScript a deposer dans n’importe quelle fonction serverless.

Surfaces developpeur

forkd expose plusieurs points d’entree pratiques :

• des commandes CLI pour creer des snapshots, forker des enfants, brancher des sandboxes, empaqueter des snapshots et lancer des benchmarks;
• un daemon de controle avec API REST, authentification bearer token, journaux d’audit et metriques Prometheus;
• un SDK Python avec une ergonomie proche d’E2B pour l’execution en sandbox;
• un SDK TypeScript pour les piles d’agents Node.js;
• un serveur MCP via forkd-mcp, afin que Claude Desktop, Claude Code, Cursor, Cline et d’autres clients MCP puissent piloter les sandboxes.

Cette surface compte parce que les runtimes de sandbox echouent souvent au niveau integration. Les equipes d’agents ne veulent pas d’un beau primitif qui ne fonctionne que depuis une demo sur mesure. Elles ont besoin qu’il s’insere dans LangGraph, AutoGen, CrewAI, les handoffs de type Swarm, l’automatisation navigateur et les workflows de code interpreter.

Le dossier de recettes de forkd est utile pour cette raison. Il montre que le projet n’est pas seulement une experience VMM; il est oriente vers les formes reelles de fan-out et d’execution des agents.

Ou forkd est le plus adapte

forkd est le plus convaincant lorsque trois conditions sont vraies :

1. Le workload est couteux a chauffer.
2. Il faut beaucoup d’enfants isoles et courts.
3. L’etat enfant ne se represente pas proprement en texte de prompt.

C’est exactement le profil des agents de code modernes et des code interpreters. Importer de grosses bibliotheques, construire l’etat d’un depot, lancer un navigateur, preparer une base de donnees et rejouer un historique d’outils prennent du temps. Si plusieurs branches peuvent partager le meme parent jusqu’a leur divergence, le cout d’infrastructure change fortement.

C’est aussi utile quand une isolation plus forte est obligatoire. Executer du code utilisateur dans un conteneur standard peut suffire pour des outils internes, mais devient plus difficile a defendre pour de l’execution multi-tenant, des plugins tiers ou de la CI non fiable.

Ce qui reste jeune

forkd est un logiciel alpha. Le README indique clairement que les API et les formats sur disque peuvent encore changer avant la version 1.0.

Le projet liste aussi des ecarts de maturite production : planification multi-noeuds, controle d’egress plus strict par defaut, quotas CPU, I/O et processus en plus des limites memoire, et audit de securite tiers.

Ce ne sont pas des details. Un runtime de sandbox entre dans la base de confiance de chaque agent qui l’utilise. Si vous prevoyez d’exposer forkd a des utilisateurs non fiables, la bonne posture est de le traiter comme une infrastructure prometteuse qui merite encore modelisation des menaces, politique reseau en couches, durcissement hote, journalisation et discipline de mise a jour.

Mon avis

forkd merite d’etre suivi parce qu’il se concentre sur un primitif dont les systemes d’agents ont vraiment besoin : le branchement rapide et isole d’un etat machine reel.

Beaucoup d’infrastructure IA suppose encore que le modele est tout le systeme. En pratique, les agents utiles sont des systemes distribues avec fichiers, processus, reseaux, caches, runtimes et effets de bord. Une fois ce constat accepte, “brancher le prompt” ne suffit plus. Il faut aussi brancher l’environnement.

C’est l’idee forte de forkd. Il donne aux builders d’agents une maniere de traiter l’etat d’execution chaud comme une infrastructure reutilisable, tout en gardant chaque branche dans une frontiere microVM. Pour l’experimentation locale, c’est deja interessant. Pour les plateformes d’agents en production, les questions portent maintenant sur le durcissement, la planification, la politique et la maturite operationnelle.

Si forkd continue dans cette direction, il pourrait devenir l’un des blocs open source importants pour les code interpreters auto-heberges et l’execution serieuse d’agents IA.