Aller au contenu
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉModéré
MÉTIERAutomatiser une tâche
POURCréateurs d'IA
POURFondateurs solo
SERVICESCron
SERVICESAgent
SERVICESConteneurs
POURQUOI HOODYÉconomie des conteneurs
POURQUOI HOODYIA-natif
POURQUOI HOODYHTTP-natif
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉModéré
MÉTIERAutomatiser une tâche
POURCréateurs d'IA
POURFondateurs solo
SERVICESCron
SERVICESAgent
SERVICESConteneurs
POURQUOI HOODYÉconomie des conteneurs
POURQUOI HOODYIA-natif
POURQUOI HOODYHTTP-natif
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉModéré
MÉTIERAutomatiser une tâche
POURCréateurs d'IA
POURFondateurs solo
SERVICESCron
SERVICESAgent
SERVICESConteneurs
POURQUOI HOODYÉconomie des conteneurs
POURQUOI HOODYIA-natif
POURQUOI HOODYHTTP-natif
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉModéré
MÉTIERAutomatiser une tâche
POURCréateurs d'IA
POURFondateurs solo
SERVICESCron
SERVICESAgent
SERVICESConteneurs
POURQUOI HOODYÉconomie des conteneurs
POURQUOI HOODYIA-natif
POURQUOI HOODYHTTP-natif
Cron · Agent · Conteneurs

Réveille un agent à 3h, retire-le à 4h

Un job nocturne qui scanne les exceptions de facturation de la veille, regroupe les doublons et écrit une note de triage. Il n'a besoin d'exister qu'environ une heure par jour. Deux entrées cron lancent un conteneur agent frais à 02:59 et le démontent à 04:01. Les 23 autres heures, il ne tourne pas, n'est pas warm, n'est pas facturé.

Lire la doc

Deux entrées cron, un conteneur éphémère

Pas de pool warm, pas de service de scheduler, pas de daemon de glu qui poll pour du boulot. Une entrée hoody-cron POST sur l'URL spawn de hoody-agent à 02:59. L'agent fait son run et sort. Un deuxième cron à 04:01 appelle DELETE pour s'assurer que le conteneur est bien parti. C'est toute la machine.

POST cron.hoody.com/users/root/entries
Trigger réveil · 02:59
// Entrée cron qui se déclenche une fois par jour et POST la requête spawnPOST cron.hoody.com/users/root/entries{ schedule: "0 3 * * *", command: "curl -X POST $AGENT_URL -d @prompt.json", comment: "billing-reconcile · 3am wake"}
se déclenche à 02:59 →
POST api.hoody.com/api/v1/projects/$PID/containers
Lancer un agent · ai + hoody_kit
// L'agent boot, réconcilie les invoices d'hier, écrit des notes, sortPOST api.hoody.com/api/v1/projects/$PID/containers{ name: "billing-reconcile-$(date +%s)", ai: true, hoody_kit: true, autostart: false}
conteneur sort, deuxième cron se déclenche à 04:01 →
DELETE api.hoody.com/api/v1/containers/$CID
Démontage · 04:01
// Ceinture et bretelles : un deuxième cron vérifie que le conteneur est partiDELETE api.hoody.com/api/v1/containers/$CID// Réponse de hoody-conteneurs200 OK · container deleted

Deux lignes cron dans une base. Une image agent. Le conteneur n'existe que pour le boulot, puis il cesse d'exister. Pas de pool warm, pas de primitive de tâche planifiée, pas de daemon de cycle de vie à opérer vous-même.

À quoi la nuit ressemble vraiment

Cinq moments. L'agent est vivant pour les trois du milieu. En dehors de cette heure, la ligne dans la table conteneurs a disparu.

  1. 02:59Cron · réveil

    L'entrée cron billing-reconcile-wake se déclenche. Elle POST sur api.hoody.com avec ai: true et hoody_kit: true. Un conteneur frais est lancé avec un filesystem propre et le prompt de l'agent chargé.

  2. 03:02Agent · lecture

    L'agent lit la table billing-exceptions d'hier via Hoody SQLite et demande à un LLM de regrouper les lignes par code de motif — soit via le Hoody AI Gateway (coût provider + 5%, pris sur votre AI Balance), soit en BYO key direct vers Anthropic / OpenAI / votre provider. Pas de mounts de file-share. Juste des URLs.

  3. 03:31Agent · écriture

    Il écrit une seule note de triage par cluster vers la même URL SQLite, puis envoie une notification avec le résumé du jour. Temps total écoulé jusqu'ici : environ trente minutes.

  4. 03:58Agent · sortie

    Le process agent retourne 0 et le conteneur sort tout seul. Hoody-conteneurs le marque stopped. À partir de cette seconde, rien de l'agent ne tourne, n'est warm, ni facturé.

  5. 04:01Cron · retraite

    Une deuxième entrée cron déclenche DELETE sur l'id du container. Si l'agent est déjà sorti, c'est un no-op 200 OK. S'il est resté pendu, le conteneur est démonté quand même. Idempotent et sans surveillance.

Cinq timestamps, deux lignes cron, un conteneur qui vit soixante-deux minutes. La nuit tourne toute seule, et vous apprenez qu'elle a tourné en lisant la note de triage le matin.

Pourquoi cette forme de cycle de vie marche

Un worker always-on, c'est la mauvaise forme pour un job qui tourne une fois par jour. Sur Hoody, le substrat est à tarif fixe — la victoire n'est pas la facturation à la seconde, c'est l'absence de pool warm, de service de scheduler, de daemon de glu à opérer.

Idle ne coûte rien de plus

Le conteneur n'existe pas entre les runs

Pas de pool warm assis en mémoire. Pas de service de 'tâche planifiée' qui garde de l'état. La ligne dans la table conteneurs disparaît pendant vingt-trois heures de la journée. Le serveur à tarif fixe que vous louez déjà fait tourner le boulot ; les heures idle ne génèrent pas de ligne séparée.

Pas de ligne par run

La facture du serveur ne bouge pas

Hoody facture la box, pas le runtime. Un agent nocturne de 60 minutes et un worker always-on 24/7 atterrissent sur la même facture de serveur à tarif fixe. La victoire n'est pas 'paie seulement ce que vous utilisez' — c'est ne pas payer deux fois pour une surcharge de pool warm dont vous n'avez pas besoin.

Pas de code de cycle de vie

Deux lignes cron, pas de daemon de glu

vous n'écris pas de Lambda de réveil, de worker 'fais tourner le conteneur', ni de watchdog qui le retire. Hoody-cron POST. Hoody-conteneurs spawn. L'agent sort. Un deuxième cron POST DELETE. C'est toute la surface.

Le coût d'un agent idle

La plupart des plateformes d'agent gardent le worker warm vingt-quatre heures sur vingt-quatre pour qu'il soit prêt en moins d'une seconde. Pour un batch job de 3h du matin, c'est exactement le mauvais tradeoff. Cold-spawn en quelques secondes, c'est très bien quand le planning est le tien.

Agent always-on24h × 30 jours
720h / mo

Un conteneur agent always-on, ou une place de pool warm réservée pour un agent qui tourne une fois par jour, est vivant 720 heures par mois. 719 de ces heures, il ne fait rien.

Idle est la ligne sur les plateformes par-seconde
Réveille-et-retire1h × 30 jours
30h / mo

Un conteneur éphémère lancé par une entrée cron existe pendant une heure par nuit. Trente heures par mois, total. Le process agent retourne 0 et la ligne dans la table conteneurs a disparu.

  • LUN02:59 → 04:0162m vivant
  • MAR02:59 → 04:0060m vivant
  • MER02:59 → 03:5858m vivant
  • JEU02:59 → 04:0061m vivant
  • VEN02:59 → 04:0060m vivant
  • SAM02:59 → 03:5959m vivant
  • DIM02:59 → 04:0060m vivant
Facture serveur inchangée

Hoody facture le serveur, pas le runtime. La colonne 'vivanvous montre quand l'agent existait chaque nuit — le même serveur à tarif fixe tourne qu'il soit là ou non. Le pricing démarre à $1/mo et varie selon la spec, la région et la durée de location.

Un agent qui n'existe que quand il y a du boulot à faire.

Heures vivant par jour1h02:59 → 04:01, puis parti
Variation facture serveur0Tarif fixe, vivant ou idle
Code de cycle de vie écrit0Deux lignes cron, pas de daemon
Voir l'API spawn

Ce que ça remplace

Les patterns qui paient pour qu'un agent existe 24/7. Sur Hoody, l'agent tourne dans le serveur à tarif fixe que vous louez déjà — pas de pool warm, pas de service de scheduler, pas de compteur par-seconde.

  • Conteneurs agent always-on23 heures idle, facturées au tarif actif
  • Pools warm AWS LambdaPayer pour garder les cold-starts loin du cron
  • Tâches planifiées Modal LabsRuntime fermé, facturation opaque
  • Code de cycle de vie warm-cold customTrois semaines à écrire, six mois à débugger
  • Polling sur des endpoints /spawnUn deuxième cron dont le seul boulot est de lancer le premier
  • Box GPU Hetzner toujours allumée$200/mo pour une seule inférence par jour

Un agent qui n'existe que quand il y a du boulot à faire.

Lire la doc

Lis les autres