Rester dans les limites
Maintenez le travail long des agents à l’intérieur des fenêtres d’utilisation actuelle de 5 heures et hebdomadaires. Vérifiez l’utilisation avant de lancer un travail substantiel et entre les vagues d’agents parallèles. Si une limite active (5 heures ou hebdomadaire) atteint ou dépasse 95 %, mettez en pause les nouveaux travaux jusqu’à ce que la fenêtre soit suffisamment libre pour continuer en toute sécurité.
Boucle principale
- Lancez une vague limitée de travail. Par défaut, au maximum 3 agents parallèles, sauf si l’utilisateur ou l’hôte indique un autre seuil.
- Attendez la fin de la vague. N’interrompez pas les agents en cours simplement pour économiser du budget ; cela fait généralement perdre du travail.
- Vérifiez l’utilisation actuelle (5 heures et hebdomadaire) avec l’outil de budget/utilisation de l’hôte.
- Si l’une des fenêtres atteint ou dépasse 95 %, arrêtez de lancer des travaux et planifiez une reprise auto-contenue lorsque la fenêtre concernée devrait se libérer.
- Lors de la reprise, vérifiez à nouveau la fenêtre réelle (ou le bloc) avant de continuer. Ne vous fiez pas uniquement au temps écoulé sur l’horloge murale.
Signaux d’utilisation
Privilégiez un outil d’utilisation propriétaire de l’hôte lorsqu’il est disponible. Dans Claude Code, utilisez :
npx -y cclusage@latest blocks --active --json
Utilisez le JSON pour identifier le début du bloc actif, le coût ou pourcentage actuel, et le temps restant. Au réveil, comparez l’horodatage de début du bloc actif avec le précédent ; un nouvel horodatage est une preuve plus forte que « assez de temps s’est écoulé ».
Si l’outil renvoie un coût plutôt qu’un pourcentage direct, convertissez-le via la limite actuelle du compte lorsqu’elle est connue. Pour les blocs de 5 heures de type Claude Max, certains utilisateurs préfèrent un seuil d’alerte plus précoce autour de 500-550 $ ; traitez cela comme un garde-fou configuré par l’utilisateur, pas une règle universelle. La règle d’arrêt par défaut reste 95 % de la limite active (5 heures ou hebdomadaire).
Mise en pause et reprise
Lorsqu’un outil de réveil/reprise est disponible, planifiez un réveil pour :
min(3600, secondesAvantLibérationFenêtre)
Si l’exécution limite les délais de réveil à 60-3600 secondes, enchaînez les réveils pour les attentes plus longues. Chaque réveil doit revérifier l’utilisation, replanifier si toujours au-dessus du budget, et ne continuer que lorsque la fenêtre est sûrement en dessous du seuil.
Faites en sorte que les invites de réveil soient auto-contenues. Incluez :
- Le plan restant.
- La règle de vérification puis replanification.
- Le seuil de 95 % et la limitation de vague.
- La commande exacte d’utilisation ou l’outil hôte à exécuter.
- L’identifiant du bloc/fenêtre précédent(e) lorsqu’il/elle est disponible.
- Les prochaines étapes de vérification.
- Les paquets de transmission de la prochaine vague, incluant la portée, les commandes de vérification et les conditions d’arrêt, si une délégation doit reprendre.
Choix du mécanisme d’attente
- Utilisez un outil de réveil/reprise lorsque l’agent a besoin d’instructions attachées à la reprise future.
- Utilisez un sommeil en arrière-plan ou un observateur pour les minuteries fixes et les choses qu’un processus peut observer directement.
- Utilisez cron ou des planifications récurrentes uniquement pour des travaux récurrents en nouvelle session.
Évitez les sondages à intervalle court pour les choses que l’hôte vous notifiera, comme la fin d’une tâche en arrière-plan ou d’un sous-agent. Pour les pauses budgétaires, un échec de cache d’invite après un long sommeil est acceptable ; préserver la limite est plus important.
Rapports
Si vous faites une pause, indiquez à l’utilisateur quelle fenêtre dépasse le seuil, l’utilisation observée, quand vous avez programmé ou attendez la prochaine vérification, et quel travail reste à faire. Conservez suffisamment d’état dans l’invite de réveil pour que le prochain tour puisse reprendre sans dépendre de l’élan de la conversation.