Ce que coûte vraiment une exécution d'agent de codage (et comment dépenser moins)

Quel que soit le modèle, des contextes plus grands coûtent plus cher. Sur l'API d'Anthropic, par exemple, l'entrée, la sortie et les lectures de cache sont tarifées séparément par million de tokens. [2]

Une exécution bon marché qui est jetée coûte plus cher qu'une exécution onéreuse qui est mergée. Mesurez donc ce que vous voulez réellement :

cost per merged PR =
  (agent spend + CI spend + review hours × hourly cost)
  ÷ PRs merged

Example (illustrative):
  Story A, vague:  4 runs × $3 + 4 CI runs × $0.40 + 60 min review  → 1 PR
  Story B, sharp:  1 run  × $5 + 1 CI run  × $0.40 + 15 min review  → 1 PR

Les chiffres sont inventés, pas la logique. L'exécution de la story B était plus chère, et pourtant bien plus économique au global — principalement grâce à la ligne relecture.

Sur le sujet du contexte, la documentation de Claude Code est directe : "Claude's context window fills up fast, and performance degrades as it fills." [4] Pour en savoir plus sur comment écrire un travail qui s'exécute bien du premier coup, voir notre guide sur les stories pour agents de codage.

Les minutes CI augmentent avec le volume de PR des agents. GitHub accorde à chaque compte un quota de minutes gratuites, et "any usage beyond the included amounts is billed to your account." [7] Deux tactiques aident : annuler les exécutions déjà remplacées par un push plus récent, et ne lancer les suites coûteuses que lorsqu'une PR est marquée prête à être mergée.

on:
  pull_request:
    # 'labeled' is needed so adding the label triggers the run
    types: [opened, synchronize, labeled]

concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: true

jobs:
  e2e:
    if: contains(github.event.pull_request.labels.*.name, 'ready-to-merge')

GitHub documente cancel-in-progress exactement pour cela. [9] Le plus gros poste de tous n'apparaît sur aucune facture : le temps de relecture. Il augmente avec chaque PR, c'est pourquoi les leviers ci-dessus comptent plus que le prix par token.

Dans nos propres dépôts, le volume de PR d'agents a augmenté d'environ 2,4× en un mois. Annuler les exécutions remplacées, alléger les jobs CI et ne lancer les tests end-to-end que sur les PR prêtes à être mergées a réduit le coût CI par PR d'environ 27–30 % — mais le total mensuel a quand même augmenté, car il y avait bien plus de PR. Budgétez par PR, pas par mois.

Trois modèles dominent : les crédits prépayés, les abonnements avec limites d'usage et les forfaits par siège. Le compromis se joue entre prévisibilité et gaspillage. Les forfaits par siège et les abonnements sont prévisibles mais paient des sièges inactifs et atteignent leurs limites au pire moment. Les crédits prépayés suivent l'usage réel. Un pool d'équipe partagé permet à la personne qui fait tourner cinq agents cette semaine d'emprunter à celle qui est en congé ; des limites par personne protègent contre une exécution incontrôlée.

Quel que soit votre choix, budgétez par PR mergée, pas par siège.

Aerunit est facturé exactement comme ce guide recommande de penser le coût : des crédits prépayés à l'usage dans un seul pool par équipe, sans abonnement. Les exécutions des agents elles-mêmes sont facturées par Cursor sur votre propre compte Cursor ; les crédits Aerunit couvrent le travail d'Aerunit — rédiger les stories, répartir et relire.

Cela agit aussi sur le plus gros multiplicateur — les exécutions de reprise. Le rédacteur de stories propose des issues Linear avec périmètre, critères d'acceptation et non-objectifs, et la répartition consciente des dépendances ne démarre un découpage qu'une fois l'issue bloquante mergée, pour que les agents ne s'appuient pas sur du code qui n'existe pas encore. La relecture automatique des PR renvoie les observations vers la session de l'agent avant que vous n'y passiez du temps de relecture.