Économie de jetons : mesurer et réduire le coût

D'où vient le coût

À chaque tour, le modèle relit tout le contexte : le message système, la mémoire injectée, l'historique de la session, les résultats d'outils. Le coût par tour croît donc avec la longueur de la session, pas seulement avec la taille de votre question. C'est pour cela qu'une session qui grossit coûte de plus en plus cher à chaque échange.

• Session courte et bornée : coût prévisible et faible
• Session longue non compactée : coût qui croît à chaque tour
• Tâche planifiée : un coût par exécution, multiplié par la fréquence

Le levier modèle

Un modèle rapide et peu coûteux gère très bien les tâches banales (tri, résumés, reformatage). Réservez le modèle lourd aux tâches qui en tirent réellement du bénéfice : raisonnement long, code complexe, décisions sensibles. Un fallback bien réglé garde la qualité sans payer le modèle cher à chaque tour.

Le mode sans agent

Pour une tâche fixe qui n'a pas besoin de raisonner (lire un flux, formater un texte, pousser un message), le mode --no-agent des tâches planifiées livre la sortie d'un script pur : zéro jeton de modèle. Beaucoup de crons "utiles" ne devraient jamais faire tourner un modèle.

Mesurer avant d'optimiser

Le tableau de bord du provider donne la consommation réelle. Mesurez une semaine avec votre montage actuel, changez un levier, remesurez. Les économies les plus rentables sont presque toujours le choix du modèle et le compactage des sessions, pas les micro-optimisations de prompt.