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
| Standard | Large | |
|---|---|---|
| Machine | 2 vCPU, 8 Go | 4 vCPU, 16 Go |
| Utilisateur | 39 € / mois | 78 € / mois |
| Apport à la réserve commune | 200 heures | 400 heures |
| Heures de réserve consommées par heure d’exécution | 1 | 2 |
| Au-delà de la réserve | 0,20 € / heure | 0,40 € / heure |
| Coût maximal d’un utilisateur sur un mois | 99 € | 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ément | Survit à une mise en veille |
|---|---|
Votre code, vos node_modules, vos artefacts de build | oui |
| Dotfiles, historique du shell, configuration git, clés SSH | oui |
npm i -g, pip --user, uv tool, pipx, cargo install, go install | oui |
| Votre connexion à Claude Code | oui |
apt install | non |
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
doneCommitez 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-filesLa 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>.gitDeux choses à ne pas copier :
~/.git-credentialset~/.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 8000Le 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
claudeIl 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 frembenchC’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.
| Touches | Effet |
|---|---|
Ctrl-b c | Nouvelle fenêtre : lancez-y un deuxième agent |
Ctrl-b n / Ctrl-b p | Fenêtre suivante / précédente |
Ctrl-b 0 … Ctrl-b 9 | Aller directement à une fenêtre |
Ctrl-b w | Choisir 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 z | Agrandir un volet en plein écran, et revenir |
Ctrl-b d | Se 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/startupne 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-resizeest 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 devEn 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 :
| Port | Service |
|---|---|
| 5173 | node |
| 8000 | python3 |
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 :
nodeplutôt quevite, parce que c’est ainsi que le processus se nomme. Elle afficheUnknownpour 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 à
localhostou à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.
| Identifiant | Emplacement | Ce qu’il permet d’atteindre |
|---|---|---|
| Identifiant git | ~/.git-credentials | git clone / push / pull, et l’API propre de Forgejo sous /api/v1/… |
| Identifiant d’API | ~/.config/fremforge/token | l’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.