Comparer les approches des agents
Lancez plusieurs candidats sur des branches séparées et choisissez un résultat à l’aide d’une vérification.
Ce que montre l’exemple
Section intitulée « Ce que montre l’exemple »Cet exemple permet d’essayer plusieurs corrections pour un même bug. Chaque candidat dispose de sa sandbox et de sa branche ; votre commande de test décide quel résultat peut être accepté.
- Candidats concurrentsMettez en course jusqu’à huit candidats et gardez le premier acceptable.
- Choisir un agentComposez Codex et Claude Code à partir de leurs harness prédéfinis.
- Claude CodeConnectez-vous sur l’hôte ; l’image de l’installation contient déjà sa CLI.
- Sessions de sandboxLancez les tests dans la sandbox encore ouverte du candidat.
- BudgetsUn seul budget borne les tentatives et les tokens de tous les candidats.
- Dépôt et brancheChaque candidat committe sur une branche nommée, dans son propre worktree.
Écrire le script
Section intitulée « Écrire le script »Enregistrez les fichiers présentés dans les onglets à côté du outpost.config.ts de la page Installation. Exécutez compete.ts pour comparer les candidats.
Préparez les candidats et vérifiez leur travail avant d’envisager une fusion.
Demandez la confirmation dans compete.ts, puis vérifiez à nouveau l’intégration avant la fusion.
Exécuter le script
Section intitulée « Exécuter le script »Le script affiche le statut et la branche de chaque candidat, par exemple claude winner outpost/speculation/<id>/claude et codex cancelled …, puis demande avant de fusionner. Relisez la branche avec git diff avant de répondre.
Comprendre les étapes
Section intitulée « Comprendre les étapes »Chaque lien indique qui transmet quoi à qui, dans le sens de la flèche.
Référence API : SpeculationResult, SpeculativeCandidateResult et SpeculationIntegration.
Adapter l’exemple
Section intitulée « Adapter l’exemple »Essayer plusieurs approches avec un seul agent
Section intitulée « Essayer plusieurs approches avec un seul agent »Donnez des briefs différents au même agent. Avec trois candidats et concurrency: 2, le troisième ne démarre que lorsqu’un des deux premiers termine sans gagner.
Laisser un agent de revue trancher
Section intitulée « Laisser un agent de revue trancher »Un relecteur lancé dans la sandbox du candidat lit ses commits et renvoie un verdict typé. Passez la fonction en validate: review.
Les tokens de la revue ne comptent pas dans budget. Le commit du gagnant est lu après validate : le relecteur ne doit donc pas committer.
Reprendre après un arrêt brutal
Section intitulée « Reprendre après un arrêt brutal »Passez durability à speculate() : tentatives, usage et résultats sont enregistrés via un transport, et une course terminée est renvoyée sans être rejouée.
version fait partie de l’identité de la course : après avoir modifié les candidats ou validate, lancez une nouvelle course sous un nouveau runId. Une course durable exige un fournisseur capable de récupération, aujourd’hui Docker ou Podman en mode monté, et conserve le worktree de chaque candidat. Après un arrêt brutal, récupérez la course avant de la rejouer : Candidats concurrents.
speculate()ne fusionne pas, ne pousse pas et n’ouvre pas de pull request.- Une intégration
cleann’est pas un verrou : toute modification ultérieure du checkout la rend obsolète, vérifiez donc à nouveau juste avant de fusionner. - Les candidats en cours peuvent dépasser la limite de tokens avant que leur usage soit remonté.
- Un worktree avec des fichiers non commités, non suivis ou ignorés, comme
node_modules, reste sous.outpost/workspaces: voir Rétention et nettoyage.
API : speculate · SpeculationResult · SpeculativeCandidateResult · checkSpeculationIntegration · SpeculativeValidation · SpeculationDurability.