Aller au contenu principal

frembench — benches de développement

frembench est une machine Linux que vous louez à la minute et à laquelle vous accédez depuis votre navigateur : un bench de développement. Elle embarque la même chaîne d’outils de langages que vos runners CI, si bien que ce qui se construit sur un bench se construit aussi en CI.

Ce que cela coûte

Un utilisateur bench coûte 39 € par mois et inclut 200 heures d’exécution. Au-delà de cette réserve, c’est 0,20 € de l’heure, et le total est plafonné sans condition : votre facture ne peut jamais dépasser 99 € par utilisateur bench sur un mois, quelle que soit l’intensité d’utilisation. Pour un seul utilisateur, le plafond est atteint à 500 heures d’exécution ; au-delà, le bench continue de tourner sans frais supplémentaires. Tous les montants de cette page sont en euros, la devise dans laquelle les benches sont facturés, comme le reste de votre abonnement.

Les heures sont mises en commun entre les utilisateurs bench, de la même manière que les minutes de CI. Le forfait est de 200 heures × nombre d’utilisateurs, mesuré sur l’ensemble de ce qu’ont exécuté les benches de votre organisation : deux utilisateurs se partagent donc 400 heures. Un bench très sollicité puise dans le forfait d’un collègue plus calme au lieu de passer directement en dépassement. Le plafond est mis en commun de la même façon : il est de 99 € par utilisateur bench, et non par machine, si bien qu’un seul bench dans une organisation de deux utilisateurs peut représenter plus de 99 € tant que l’organisation reste sous 198 €.

Deux tailles

StandardLarge
Machine2 vCPU, 8 Go4 vCPU, 16 Go
Utilisateur39 € / mois78 € / mois
Apport à la réserve commune200 heures400 heures
Heures de réserve consommées par heure d’exécution12
Au-delà de la réserve0,20 € / heure0,40 € / heure
Coût maximal d’un utilisateur sur un mois99 €198 €

Un utilisateur Large compte pour deux utilisateurs bench à tous égards : tout ce qui figure sur cette page s’applique donc à lui avec des chiffres doublés. Une seule réserve pour toute l’organisation, le même décompte à la seconde, le même plafond. Un utilisateur peu actif, quelle que soit sa taille, couvre un utilisateur très actif. Un administrateur de l’organisation achète les utilisateurs Large sur la page de facturation et choisit la taille lorsqu’il attribue un utilisateur à une personne ; le bench est créé à la taille de l’utilisateur de son propriétaire.

Deux détails à connaître, car ils changent ce que vous payez réellement :

  • Le temps est mesuré en secondes et arrondi une seule fois, à la fin de la période. Un bench se met en veille après 30 minutes d’inactivité et se réveille lorsque vous vous y connectez : une journée de travail se compose donc de nombreux intervalles courts. Arrondir chacun à la minute supérieure facturerait vingt réveils de dix secondes comme vingt minutes, et vous ferait payer notre propre optimisation de mise en veille.
  • 200 heures, c’est bien plus qu’un mois de travail en temps connecté. La réserve est dimensionnée sur le temps réel pendant lequel un bench est éveillé, et non sur les heures passées au clavier : un agent laissé sur une longue tâche compte, un éditeur inactif ne compte pas.

Les utilisateurs sont facturés au prorata lorsque vous en ajoutez ou en retirez, comme tout autre utilisateur. Consultez la page des tarifs pour voir comment cette offre s’intègre au reste de l’abonnement.

Vous n’avez rien à gérer. Le bench se réveille lorsque vous vous y connectez et se met de lui-même en veille lorsque personne n’est connecté et que rien ne tourne.

Ce qui survit, et ce qui ne survit pas

C’est la seule chose à bien comprendre avant d’utiliser un bench, car elle conditionne tout le reste.

Votre bench a deux disques. Le volume de profil, de 50 Go, vous appartient et persiste. Le disque de démarrage est reconstruit à partir d’une image neuve à chaque réveil : c’est ainsi que vous recevez les correctifs sans fenêtre de maintenance et sans qu’on vous demande jamais de redémarrer.

$HOME se trouve sur le volume de profil. Par conséquent :

ÉlémentSurvit à une mise en veille
Votre code, vos node_modules, vos artefacts de buildoui
Dotfiles, historique du shell, configuration git, clés SSHoui
npm i -g, pip --user, uv tool, pipx, cargo install, go installoui
Votre connexion à Claude Codeoui
apt installnon

apt est l’exception délibérée : les paquets système sont précisément le rôle de l’image. Si vous en avez besoin d’un chaque matin, il a sa place dans l’image : ouvrez un ticket plutôt que de l’ajouter par script à votre profil de shell, et la reconstruction hebdomadaire fera que ce ne sera plus votre problème.

Emporter vos fichiers

Votre volume de profil survit à une mise en veille, mais pas à la suppression de votre bench. Lorsqu’un administrateur de l’organisation retire votre utilisateur bench, le bench est supprimé avec lui :

  • Il s’arrête immédiatement et vous ne pouvez plus l’ouvrir, ni dans le navigateur, ni avec fremforge bench attach.
  • Son volume de profil est conservé 30 jours. Pendant ces 30 jours, un administrateur de l’organisation peut annuler le retrait sur la page d’administration Benches de l’organisation. Le bench revient alors tel qu’il était, en veille, sur le même disque, avec votre utilisateur.
  • Après 30 jours, le volume de profil est supprimé. Il ne peut plus être rattaché ni récupéré, et un nouveau bench démarre toujours avec un profil vide.

Récupérez donc ce que vous voulez garder tant que vous avez encore le bench, par exemple avant de quitter un projet ou l’organisation. S’il a déjà été retiré, demandez à un administrateur de l’organisation d’annuler le retrait dans les 30 jours, copiez vos fichiers comme décrit ci-dessous, puis laissez-le le retirer à nouveau.

Il n’y a ni scp, ni rsync, ni SSH vers un bench : il n’a aucun chemin réseau entrant, et fremforge bench attach vous donne un terminal, pas un transfert de fichiers. Ce que vous emportez sort par frem.sh, de l’une des trois manières ci-dessous.

Poussez votre travail

Le code a sa place dans git, et le bench dispose déjà d’un identifiant git pour frem.sh. Pour trouver tous les dépôts de votre répertoire personnel contenant quelque chose qui n’a pas encore été poussé (modifications non commitées, ou commits sur une branche absente de tout remote) :

find ~ \( -name node_modules -o -name .cache \) -prune -o -name .git -print 2>/dev/null |
while read -r g; do
  r=$(dirname "$g")
  if [ -n "$(git -C "$r" status --porcelain)" ] ||
     [ -n "$(git -C "$r" log --branches --not --remotes --oneline -1)" ]; then
    echo "not pushed: $r"
  fi
done

Commitez et poussez chacun d’eux. Si vous ne pouvez pas pousser sur la branche où vous êtes, poussez sur une branche à vous (git switch -c wip/<topic>, puis git push -u origin HEAD). git stash list affiche les stashes, qu’un push n’emporte pas.

Tout le reste : un dépôt privé

Les dotfiles, notes et fichiers de travail qui n’appartiennent à aucun dépôt peuvent aller dans un dépôt privé dédié. Créez-en un dans votre organisation depuis l’interface web de frem.sh (New repository, visibilité Private), par exemple bench-files-<your-login>. Si vous ne pouvez pas créer de dépôts dans l’organisation, demandez à un propriétaire de l’organisation. Ensuite, sur le bench :

mkdir ~/bench-files && cd ~/bench-files
cp -a ~/.bashrc ~/.tmux.conf ~/notes .   # whatever you want to keep
git init -b bench-files
git add -A
git commit -m "Files from my bench"
git remote add origin https://frem.sh/<org>/bench-files-<your-login>.git
git push -u origin bench-files

La branche s’appelle bench-files et non main afin que la protection de branche de votre organisation, qui couvre main par défaut, ne refuse pas le push. Sur votre propre machine :

git clone -b bench-files https://frem.sh/<org>/bench-files-<your-login>.git

Deux choses à ne pas copier :

  • ~/.git-credentials et ~/.config/fremforge/token. Ils sont créés pour le bench, révoqués lorsqu’il disparaît, et ne fonctionnent nulle part ailleurs.
  • Vos propres secrets, comme des clés privées SSH ou des identifiants de CLI cloud. Toute personne ayant accès au dépôt peut les lire, y compris les propriétaires de l’organisation. Créez-en de nouveaux sur votre prochaine machine.

Git se prête mal aux gros fichiers binaires : limitez le dépôt à ce dont vous avez réellement besoin.

Un seul petit fichier : téléchargez-le dans votre navigateur

Pour un seul petit fichier, il existe un raccourci via les Ports redirigés. Regroupez ce que vous voulez dans un seul fichier et servez son répertoire :

mkdir -p ~/outbox
tar -czf ~/outbox/dotfiles.tar.gz -C ~ .bashrc .tmux.conf
cd ~/outbox && python3 -m http.server 8000

Le port 8000 apparaît sous Ports redirigés. Ouvrez-le, cliquez sur le fichier pour le télécharger, puis arrêtez le serveur avec Ctrl-c. Une réponse redirigée est limitée à 8 Mo : cela ne fonctionne donc que pour de petits fichiers. Utilisez un dépôt pour tout ce qui est plus volumineux.

Exécuter un agent

Codex et opencode sont préinstallés. Tous deux sont sous licence open source, nous les fournissons donc.

Claude Code n’est pas préinstallé, et la raison tient à une licence, pas à un oubli : ses conditions ne constituent pas une licence open source, et il s’agit d’un produit que nous vendons ; le fournir reviendrait à redistribuer un logiciel propriétaire. Il suffit d’une commande, sous votre propre contrat Anthropic :

frembench-install-claude-code
claude

Il s’installe depuis le registre npm public via le proxy de sortie du bench, comme tout autre paquet que vous installez sur le bench. Vous ne le faites qu’une fois : l’installation et la connexion sont sur votre volume de profil.

Aucune télémétrie de la part des outils préinstallés. Les rapports d’utilisation et les vérifications de mise à jour sont désactivés pour les agents et outils fournis avec un bench (OpenChamber, opencode, Codex, Mistral Vibe, Claude Code lorsque vous l’installez, ainsi que les outils cloud, de build et de paquets), et chaque build de l’image du bench le vérifie. Quelques outils récupèrent encore du contenu dont ils ont besoin pour fonctionner, pas des données vous concernant : la liste des modèles d’opencode, le catalogue de plugins de Codex et la vérification de version d’Azure CLI à son premier lancement. Pour réactiver les rapports d’un outil, définissez vous-même sa variable.

Faire tourner plusieurs choses à la fois

Le terminal de votre bench n’est pas un simple shell : il se connecte à une session tmux nommée frembench :

tmux new-session -A -s frembench

C’est ce qui permet à un agent de survivre à la fermeture de votre ordinateur portable, et c’est aussi ainsi que vous en faites tourner plusieurs à la fois. La touche de préfixe est la touche standard Ctrl-b, et la souris est activée.

TouchesEffet
Ctrl-b cNouvelle fenêtre : lancez-y un deuxième agent
Ctrl-b n / Ctrl-b pFenêtre suivante / précédente
Ctrl-b 0 … Ctrl-b 9Aller directement à une fenêtre
Ctrl-b wChoisir dans la liste des fenêtres
Ctrl-b ,Renommer la fenêtre courante : utile, nommez-les par tâche
Ctrl-b %Diviser en volets côte à côte
Ctrl-b "Diviser en volets superposés
Ctrl-b zAgrandir un volet en plein écran, et revenir
Ctrl-b dSe détacher : tout continue de tourner

Un deuxième onglet du navigateur est un miroir, pas une copie indépendante. Chaque connexion rejoint la même session frembench : deux onglets affichent donc la même fenêtre et se la disputent. Utilisez des fenêtres et des volets pour le travail en parallèle, pas davantage d’onglets.

Si vous voulez vraiment que deux onglets affichent des choses différentes, donnez au second sa propre vue des mêmes fenêtres :

Ctrl-b :  new-session -t frembench -s second
Ctrl-b :  switch-client -t second

-t frembench regroupe la nouvelle session avec l’originale : les deux voient la même liste de fenêtres, mais chacune peut se placer sur une fenêtre différente. Un onglet fraîchement ouvert arrive toujours sur frembench : vous relancez donc switch-client pour chaque onglet.

Deux détails qui surprennent :

  • Une nouvelle fenêtre est un simple shell de connexion. ~/.frembench/startup ne s’exécute qu’à la création de la session et ne se relance donc pas pour chaque fenêtre.
  • Des onglets de tailles différentes ne se rétrécissent pas mutuellement. aggressive-resize est activé : une fenêtre est dimensionnée selon le client qui l’affiche réellement, et non selon le plus petit client connecté.

Ouvrir un serveur de développement dans votre navigateur

Un bench n’a aucun chemin réseau entrant. Rien sur internet ne peut l’atteindre, et ce n’est pas une limitation que nous prévoyons de lever : c’est ce qui rend la surface de connexion défendable.

Les serveurs de développement fonctionnent quand même. Lancez-en un comme d’habitude :

npm run dev

En quelques secondes, le port apparaît sous Ports redirigés : une carte à part sur la page frembench, sous Ce qui la maintient éveillée ; sous le shell sur la page du terminal en plein écran. Cliquez dessus. La connexion transite en sortie par le même canal que votre terminal ; aucun port n’est exposé et aucun binaire de tunnel n’intervient.

La carte indique ce qui écoute ainsi que l’endroit :

PortService
5173node
8000python3

Quelques points à connaître :

  • Seuls les ports sur lesquels votre bench écoute réellement sont proposés. Vous ne pouvez pas demander un port arbitraire, pas plus que quiconque détenant un lien.
  • La colonne Service affiche le nom court du processus lui-même, lu sur le bench : node plutôt que vite, parce que c’est ainsi que le processus se nomme. Elle affiche Unknown pour un port dont le processus n’a pas pu être identifié, ainsi que sur un bench qui exécute une image antérieure à cette fonctionnalité ; il la récupère à son prochain réveil.
  • Un serveur lié uniquement à l’adresse privée du bench n’est pas listé, car une redirection vers lui échouerait. Liez-le à localhost ou à 0.0.0.0.
  • SSH n’est jamais proposé. Utilisez le terminal.
  • Le rechargement à chaud fonctionne. Une page redirigée est servie depuis l’origine propre de votre bench, et un WebSocket ouvert depuis cette origine est aussi transporté : c’est ce dont a besoin le canal de rechargement en direct d’un serveur de développement. Cette note indiquait auparavant le contraire ; elle avait été écrite avant l’arrivée de l’origine par bench et était restée en place ensuite.

C’est aussi ainsi que vous accédez à l’interface web d’un agent comme OpenChamber. Elle est installée sur chaque bench et démarre à chaque réveil, sur le port 3000, derrière un mot de passe généré pour votre bench (OPENCHAMBER_UI_PASSWORD dans ~/.frembench/openchamber.env) : ouvrez ce port. N’exécutez pas openchamber tunnel : c’est un tunnel Cloudflare, alors que la redirection ci-dessus est à la fois la voie souveraine et celle qui vous authentifie déjà.

L’identifiant d’API sur un bench

Un bench s’authentifie auprès de frem.sh avec deux identifiants, et savoir lequel sert à quoi vous épargne un après-midi.

IdentifiantEmplacementCe qu’il permet d’atteindre
Identifiant git~/.git-credentialsgit clone / push / pull, et l’API propre de Forgejo sous /api/v1/…
Identifiant d’API~/.config/fremforge/tokenl’API fremforge sous /_app/api/v1/…

Tous deux sont créés pour vous par la plateforme. Vous ne les créez pas, ne les collez pas et ne les renouvelez pas, et vous ne devez pas les remplacer par un jeton personnel.

Il est créé à chaque réveil

L’identifiant d’API est un jeton ffp_… créé au démarrage de votre bench, valable environ une journée et révoqué lorsque le bench se met en veille. Le réveil suivant en crée un nouveau. C’est pourquoi il peut sans risque rester sur le volume de profil : un jeton lu sur un disque mis au rebut a déjà été révoqué.

Conséquence pratique : une modification de ce que votre bench est autorisé à faire prend effet au prochain réveil, pas immédiatement. Si une capacité vient de vous être accordée et que l’API refuse encore, mettez le bench en veille puis réveillez-le avant de signaler un bug.

Il agit en votre nom, avec une portée plus restreinte

Le jeton est lié à votre identité, pas à une organisation. Chaque requête reste vérifiée par rapport à vos droits réels sur les organisations : un bench ne peut donc jamais atteindre une organisation que vous ne pourriez pas atteindre depuis votre ordinateur portable.

Ce qu’il ne porte délibérément pas : la facturation, la configuration SSO, les modifications d’utilisateurs payants et la possibilité de créer d’autres jetons. Ce sont les scopes dont les conséquences survivraient à la mise au rebut du bench. Tout le reste dont un bench a besoin au quotidien est inclus : organisations, runners, résultats de sécurité, SBOM, lectures d’audit, mises à jour des dépendances, environnements de déploiement et leurs secrets, ainsi que le lancement et le téléchargement d’un export de données.

403 Token lacks required scope '…' depuis un bench signifie que le point de terminaison existe et que l’identifiant de votre bench ne porte pas ce scope. Cela ne signifie pas que la fonctionnalité manque. Le message se lit facilement comme « ce point de terminaison n’existe pas » : vérifiez le scope avant de tirer la moindre conclusion sur l’API.

Les propriétaires d’une organisation peuvent désactiver entièrement l’identifiant d’API des benches pour toute l’organisation dans administration → Politique d’authentification. Il est activé par défaut.

Utilisation

curl -fsS https://frem.sh/_app/api/v1/orgs/<your-org>/environments \
  -H "Authorization: Bearer $(cat ~/.config/fremforge/token)"

Notez le préfixe /_app. Le chemin nu /api/v1/… est l’API propre de Forgejo, qui n’accepte pas ce jeton ; et son message de refus cite le jeton que vous avez envoyé : évitez donc de coller la sortie d’un appel en échec dans un ticket ou une conversation.

Veille, réveil et ce qui vous est facturé

Vous payez les minutes pendant lesquelles votre bench est éveillé. Un bench en veille ne coûte que son volume de profil : il vaut donc la peine de savoir précisément ce qui le maintient éveillé.

Ce qui le maintient éveillé

Votre bench reste actif tant que l’une de ces conditions est vraie :

  • Quelqu’un est connecté : un onglet du navigateur ou une session SSH effectivement connectés.
  • Un agent travaille. Pas seulement en cours d’exécution : voir ci-dessous.
  • Vous l’avez maintenu éveillé, depuis la page du bench.

Lorsqu’aucune ne s’applique, le bench se met en veille après 30 minutes.

Ce que signifie « un agent travaille »

Un agent qui attend à une invite ne travaille pas, et c’est cette distinction qui détermine votre facture. Une session Claude laissée ouverte toute la nuit semble active selon toute mesure naïve (elle consomme toujours environ 1 % d’un CPU) : nous ne nous fions donc pas au CPU seul pour décider.

Un agent est considéré comme au travail lorsque l’une de ces conditions est vraie :

  • il a écrit dans son propre historique de session au cours des 10 dernières minutes, ou
  • lui-même ou un processus qu’il a lancé utilise au moins 10 % d’un cœur de CPU.

La seconde condition existe pour les longs appels d’outils. Si votre agent lance un build de trente minutes, il n’écrit rien pendant trente minutes en attendant ; mais le compilateur qu’il a lancé est occupé, donc le bench reste éveillé.

Un agent réellement inactif cesse donc de maintenir votre bench éveillé environ 10 minutes après sa dernière activité, et le bench se met en veille environ 30 minutes plus tard : soit à peu près 40 minutes après votre dernière interaction, si rien d’autre ne le maintient éveillé.

Le seul cas que vous devez nous signaler

Une longue tâche que vous avez lancée vous-même, et non via un agent, ne maintient pas le bench éveillé. Un make -j, un import de données, un test d’endurance : si vous le lancez dans un shell et fermez votre ordinateur portable, le bench se mettra en veille en plein milieu.

C’est délibéré. Si n’importe quel processus actif maintenait une machine éveillée, n’importe quoi pourrait faire facturer indéfiniment un bench inactif, et la chose la moins chère à faire tourner sur la machine de quelqu’un d’autre est un mineur de cryptomonnaie. La règle est donc que nous ne comptons que le travail que nous pouvons attribuer à un agent, et que tout le reste relève de votre décision : maintenez le bench éveillé, puis autorisez de nouveau sa mise en veille une fois la tâche terminée.

Rester connecté fonctionne aussi, puisqu’un client connecté maintient lui-même le bench éveillé.

Le réveil est automatique : connectez-vous et le bench revient. Vos fichiers sont là où vous les avez laissés, et la disposition de votre terminal revient avec eux : les fenêtres que vous aviez ouvertes sont recréées dans les mêmes répertoires, et Claude, Codex, opencode et OpenChamber sont relancés, chacun reprenant la session où il se trouvait, en attente à une invite. Rien n’est rejoué à votre place ; un agent n’agit pas en votre absence.

Deux choses ne reviennent pas. Une session lancée sans identifiant de reprise revient sous la forme d’une nouvelle session dans le bon répertoire, et tout autre processus de longue durée (votre propre serveur de développement, un build) n’est pas relancé. Déclarez-le dans ~/.frembench/restore-commands.txt, un nom de commande par ligne, si vous voulez qu’il le soit.

Maintenez un bench éveillé depuis la page du bench lorsque vous avez une longue tâche que notre suivi ne verrait pas. Ce maintien n’est pas permanent : un bench resté trop longtemps sans reconstruction reçoit ses correctifs malgré tout, car une machine non corrigée sur internet n’est pas quelque chose qu’un maintien en éveil devrait permettre d’acheter.

En obtenir un

Les benches de développement sont activés par tenant. Si votre organisation en dispose, la page se trouve sous Paramètres → Dev benches ; sinon, cette page l’indique. L’administrateur de votre organisation définit combien de benches votre tenant peut exécuter simultanément.

Un bench par organisation

Un bench appartient à une organisation, pas à vous. Si vous êtes membre de plusieurs organisations disposant d’utilisateurs bench, vous obtenez un bench dans chacune : des machines distinctes, des profils distincts, facturés séparément à l’organisation qui vous a attribué l’utilisateur. Vous ne pouvez pas créer de bench dans une organisation qui n’a pas acheté d’utilisateurs bench, si bien qu’aucune organisation ne peut être facturée pour une machine qu’elle n’a pas acceptée.

Les profils ne vous suivent pas d’une organisation à l’autre. Chaque bench a son propre volume de profil : les outils, la configuration du shell et les identifiants que vous installez sur un bench n’existent pas sur un bench d’une autre organisation. Configurez chacun de ceux que vous utilisez.

C’est une conséquence de la frontière entre tenants, et non une limitation que nous prévoyons de lever : un profil partagé signifierait qu’une organisation paie pour stocker le travail d’une autre, et ferait passer des fichiers à travers une frontière sur laquelle les clients comptent.

Les benches se mettent en veille indépendamment après trente minutes d’inactivité : avoir des benches dans plusieurs organisations ne maintient donc pas plusieurs machines en marche. Seul celui que vous utilisez réellement reste éveillé.

Pourquoi Claude Code n’est pas préinstallé

L’image du bench fournit codex (Apache-2.0) et opencode (MIT) prêts à l’emploi. Claude Code n’est pas préinstallé, et c’est une décision de licence, pas un oubli : sa licence n’est pas open source, et frembench est un produit que nous vendons. Le fournir dans notre image reviendrait à le redistribuer au sein d’un service que nous facturons.

L’installer vous-même tient en une commande, et il s’exécute alors sous votre contrat Anthropic plutôt que le nôtre. C’est aussi pourquoi il survit à une mise en veille : votre volume de profil le conserve, vous ne l’installez donc qu’une fois par bench.

C’est la même règle que partout ailleurs dans le produit : les dépendances que nous fournissons sont souveraines, à jour et entièrement sous licence open source. Tout ce qui ne remplit pas ces conditions est quelque chose que vous apportez, pas quelque chose que nous intégrons.