Lo que realmente cuesta una ejecución de un agente de codificación (y cómo gastar menos)

Sea cual sea el modelo, los contextos más grandes cuestan más. En la API de Anthropic, por ejemplo, la entrada, la salida y las lecturas de caché se tarifican por separado por cada millón de tokens. [2]

Una ejecución barata que se descarta cuesta más que una cara que se mergea. Así que mide lo que realmente importa:

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

Las cifras son inventadas; la forma no. La ejecución de la story B fue más cara, y aun así sale mucho más barata — sobre todo por la línea de revisión.

Sobre el punto del contexto, la documentación de Claude Code es directa: "Claude's context window fills up fast, and performance degrades as it fills." [4] Más sobre cómo escribir trabajo que se ejecuta bien a la primera en nuestra guía sobre stories para agentes de codificación.

Los minutos de CI escalan con el volumen de PRs de agentes. GitHub da a cada cuenta una cuota de minutos gratuitos, y "any usage beyond the included amounts is billed to your account." [7] Dos tácticas ayudan: cancelar ejecuciones que un push más reciente ya ha reemplazado, y ejecutar las suites caras solo cuando un PR se marca como listo para mergear.

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 documenta cancel-in-progress exactamente para esto. [9] La partida más grande de todas no aparece en ninguna factura: el tiempo de revisión. Crece con cada PR, por eso las palancas anteriores importan más que el precio por token.

En nuestros propios repositorios, el volumen de PRs de agentes subió alrededor de 2,4× en un mes. Cancelar ejecuciones reemplazadas, recortar jobs de CI y ejecutar las pruebas end-to-end solo en PRs listos para mergear redujo el coste de CI por PR en torno a un 27–30 % — pero el total mensual aun así subió, porque había muchos más PRs. Presupuesta por PR, no por mes.

Dominan tres modelos: créditos prepagados, suscripciones con límites de uso y planes por asiento. El compromiso está entre previsibilidad y desperdicio. Los planes por asiento y de suscripción son previsibles pero pagan por asientos inactivos y chocan con los límites en el peor momento. Los créditos prepagados siguen el uso real. Un pool compartido de equipo permite que quien ejecuta cinco agentes esta semana tome prestado de quien está de vacaciones; los límites por persona protegen frente a una ejecución descontrolada.

Elijas lo que elijas, presupuesta por PR mergeado, no por asiento.

Aerunit se factura tal como recomienda pensar esta guía: con créditos prepagados de pago por uso en un único pool por equipo, sin suscripción. Las ejecuciones de los agentes las factura Cursor en tu propia cuenta de Cursor; los créditos de Aerunit cubren el trabajo de Aerunit — escribir stories, repartir y revisar.

También actúa sobre el mayor multiplicador: las ejecuciones de retrabajo. El escritor de stories propone issues de Linear con alcance, criterios de aceptación y no-objetivos, y el reparto consciente de dependencias solo arranca una porción cuando el issue que la bloquea ya se ha mergeado, así los agentes no construyen sobre código que todavía no existe. La revisión automática de PRs devuelve los hallazgos a la sesión del agente antes de que gastes tiempo de revisión en ello.