Tâches Codex longues : garder un agent au travail pendant que vous dormez

Les tâches qui ne tiennent pas sur un portable

La plupart du travail avec Codex est bref. Une question, vingt secondes d'attente, un patch. On le fait cent fois par jour, et un portable suit sans problème.

Les tâches qui font exploser le modèle du portable ont une autre allure. Un refactor nocturne qui réécrit cinquante fichiers et relance la suite de tests après chaque passe. Une revue en lot où l'agent lit toutes les PR ouvertes, en écrit un résumé et le poste sur Slack. Un balayage de la documentation qui parcourt le code pendant deux heures et produit une référence fraîche. Ce ne sont pas des tours de chat — ce sont des jobs, et leur durée se compte en heures.

Le portable échoue partout de la même façon. Vous fermez le capot, vous changez de WiFi, ou la batterie meurt dans le train, et le processus Codex CLI part avec. Le contexte bâti par l'agent s'évapore. Vous revenez le matin devant un terminal mort, et rien pour justifier les six heures que vous vouliez lui laisser.

Ce que « longue durée » veut dire pour Codex

Une tâche Codex est longue dès que l'un de ces points est vrai :

• Le temps total dépasse une session de portable normale. Au-delà d'environ 2 heures, on croise une mise en veille, un trajet ou une réunion où vous fermez le capot
• La tâche doit survivre aux changements de réseau. Café → maison → bureau, c'est trois changements d'IP ; chaque transition peut couper la session Codex
• Elle dépend d'un état que l'agent a construit plus tôt. Si l'agent a passé une heure à lire et résumer des fichiers, perdre ce contexte vous coûte l'heure, pas juste la dernière requête
• Vous voulez que l'agent réagisse à des événements externes. Webhooks GitHub, déclencheurs cron, un fichier qui arrive dans S3 — tout cela n'attend pas que vous rouvriez le portable

Dès qu'une tâche franchit l'une de ces lignes, il vous faut un hôte qui reste en ligne quand vous ne l'êtes pas.

Quatre motifs qui tiennent sur plusieurs heures

Chaque flux Codex long que nous faisons tourner à Office Claws entre dans l'un de quatre profils. Aucun ne fonctionne sur un portable, tous fonctionnent sur un VPS.

Le fil rouge : l'agent doit être joignable, en marche et tenir son contexte à un moment qui n'a rien à voir avec celui où vous tapez.

Le montage VPS qui fonctionne vraiment

Sur Office Claws, chaque agent vit sur son propre droplet DigitalOcean, provisionné en environ deux minutes et demie depuis un snapshot pré-construit. Codex CLI est installé, connecté à votre abonnement ChatGPT Plus ou Pro, et joignable via Tailscale. Le droplet coûte 4 $/mois sur le plan Self-Hosted (4,99 $/mois pour l'app, 2,99 $ pour nos 100 premiers utilisateurs) ou est inclus dans 14,99 $/mois sur Managed.

Le flux que nous utilisons pour les tâches longues ressemble à ceci :

# From your laptop, over Tailscale — connects to the droplet
ssh office-claws-agent
 
# Start the task in a persistent session so it survives the SSH drop
tmux new -s refactor
codex "rewrite backend/services/* to use the new context shape; \
       after each file, run go test ./...; if tests fail, revert that file"
 
# Detach: Ctrl+b, then d. Close the laptop. Go to bed.

Le lendemain matin, tmux attach -t refactor et le log complet vous attend. L'agent a tourné toute la nuit. Votre abonnement a couvert les tokens. Le droplet vous a coûté environ douze centimes pour les huit heures.

Trois erreurs qui gâchent le montage

La plupart des échecs que nous avons vus se regroupent autour des trois mêmes points :

1. Lancer Codex dans une session SSH simple au lieu de tmux ou screen. La connexion SSH tombe et Codex tombe avec elle. Enveloppez toujours une tâche longue dans une session persistante — tmux, screen, ou un service systemd si vous la voulez totalement sans surveillance
2. Laisser le disque du VPS se remplir. Les refactors longs génèrent des logs et des artefacts de test. Un disque plein tue la tâche à la sixième heure. Ajoutez un cron qui tronque ~/.codex/logs chaque semaine
3. Ignorer les rate limits. ChatGPT Plus plafonne au nombre de messages sur une fenêtre glissante. Une tâche qui martèle l'API sans pause touche le plafond vers la troisième heure. Pour du travail nocturne vraiment lourd, passez à Pro — les 200 $/mois ne sont presque jamais atteints, même sur des flux agressifs

Quand préférer un job planifié

Toutes les tâches longues ne doivent pas être interactives. Si le job n'a aucune ambiguïté — « chaque lundi à 06:00, résume les commits de la semaine et publie-les sur Slack » — sautez la danse tmux et montez-le comme entrée cron sur le droplet. Codex CLI tourne sans problème en mode headless avec un prompt sur stdin. Le VPS devient l'ordonnanceur, vous recevez un e-mail en cas d'échec, et il n'y a rien à rattacher.

Nous couvrons le motif complet des charges planifiées et en lot dans un guide dédié, mais la version courte : si le prompt est le même à chaque fois et que la sortie est lisible par machine, ça va dans cron, pas dans une fenêtre de chat.

Ce que cela change dans votre façon de travailler

Dès que les tâches longues n'ont plus besoin d'un portable, la question se déplace. Vous ne demandez plus « ai-je le temps de lancer ça maintenant ? » mais « est-ce que je veux le résultat demain matin ou d'ici la fin de la semaine ? ». L'agent devient un worker de fond, pas un outil de premier plan. Le portable devient une interface vers quelque chose qui tournait déjà avant que vous ne l'ouvriez.

C'est tout le propos de mettre Codex sur un VPS. La facture de tokens reste la même. Le modèle reste le même. Ce qui change, c'est que l'horloge continue de tourner quand vous, vous vous arrêtez.

Pour aller plus loin

• Abonnement Codex vs API : quelle facture coûte vraiment moins cher — pourquoi un abonnement Plus à 20 $ sur un VPS bat l'API pour la plupart des charges
• Gérer des agents IA sur un VPS sans créer un chaos ops — le côté opérationnel pour garder en forme des agents longue durée
• Self-Hosted vs Managed — choisir le plan Office Claws qui colle à un flux long