Deja de pagar dos veces por los mismos tokens

Corrí cinco agentes revisores sobre un PR de 16K tokens. La configuración ingenua costó $1.32. Dos cambios arquitectónicos la bajaron a $0.49. Acá está la factura y lo que el experimento me sorprendió en el camino.

Cinco agentes especialistas revisaron el mismo pull request. Security, tests, perf, observability, API design. Cada uno volvió a leer el diff completo. Cada uno pagó precio completo. La cuenta llegó a $1.32 por un solo pase de revisión sobre Claude Opus 4.6.

Un PR. Una pasada de review. Dólar treinta y dos.

Si estás corriendo code review con varios agentes a cualquier escala, estás botando plata en los mismos tokens, una y otra vez, pagados completos cada vez.

Armé un harness para medir el sangrado y probar los dos arreglos obvios. Los números salieron más fuertes de lo que esperaba, y uno de ellos volteó mis supuestos sobre prompt caching.

Qué construí

Un harness chiquito en Python con tres modos y un mismo pull request diff de 49K caracteres. Cinco roles de revisor, cada uno con un system prompt apretado:

REVIEWER_ROLES = {
    "security":      "Auth, injection, secrets, access control...",
    "tests":         "Missing tests, skipped tests, weak assertions...",
    "perf":          "N+1 queries, sync I/O in request paths...",
    "observability": "Logging hygiene, error handling, missing metrics...",
    "api-design":    "Endpoint naming, status codes, idempotency...",
}

Tres modos contra el mismo diff:

Naive. Cada revisor hace su propio call con el diff completo en el user message. El texto del rol va primero, así que el prefix cambia entre llamadas. Nada se cachea.
Cache. Cada revisor mete el diff en el system message, idéntico en las cinco llamadas. La primera llamada escribe al prompt cache del proveedor. Las llamadas dos a cinco leen de él con 90% de descuento.
Librarian. Un primer pase digiere el diff en un resumen JSON compacto. Los revisores corren contra el digest, no contra el diff crudo. Inspirado en el paper de Cho et al. en arXiv, Long Live the Librarian!, que usa un sub-agente persistente de búsqueda para suprimir tokens redundantes de exploración entre agentes.

Cobré cada llamada a las tarifas de lista de la API de Anthropic: $15/M input, $1.50/M cache reads, $75/M output. Conteo real de tokens medidos, aritmética de precios de lista por encima.

Los números

Diff grande (49K caracteres, alrededor de 16K tokens por call), cinco revisores, una sola pasada fresca de review:

Modo	Input	Cached	Output	Total
Naive	80,248	0	1,500	$1.316
Cache	80,268	63,968 (4/5 calls)	1,500	$0.453
Librarian	20,915	0	2,300	$0.486

Naive es absurdamente desperdiciador. Cache y librarian recortan la factura aproximadamente dos tercios.

Cache le gana a librarian por tres centavos. Eso es real, y cambia cómo pienso qué palanca jalar primero.

Cuándo el caching le gana al librarian

El cache gana en una serie tibia. La primera llamada escribe al cache, las cuatro siguientes leen de él. Si puedes garantizar que cinco revisores corren back-to-back contra el mismo prefix compartido en la misma sesión tibia, prompt caching es la movida más limpia que puedes hacer. Refactor de dos líneas en el system message. 66% menos en la cuenta.

El problema: los bots de code review casi nunca corren así en producción.

Cada PR es una sesión fresca. Los PRs entran de developers distintos, repos distintos, branches distintos, a intervalos impredecibles. No hay “serie tibia.” Hay un desfile de arranques en frío.

Cuando cada llamada es fría, el modo cache colapsa al modo naive. Mismos dólares por call. Mismo sangrado.

Al patrón librarian no le importa si la sesión está tibia o fría. Cada revisor lee un digest chiquito, no el diff crudo. Los ahorros están metidos en la forma de las llamadas, no en el estado del cache en algún lado de la flota del proveedor.

Modo	Serie tibia (5 calls seguidos)	Frío en cada call (realidad operativa)
Naive	$1.32	$1.32
Cache	$0.45	$1.32
Librarian	$0.49	$0.49

Si tus revisores corren en ráfagas apretadas dentro de una sola sesión, cache. Si corren independientes entre cold starts, usa el librarian. La mayoría de sistemas reales son del segundo tipo.

Lo que me sorprendió del caching

Le metí al harness un guardrail que falla en voz alta. Si las llamadas 2 a N en modo cache reportan cero cached tokens, el harness aborta e imprime diagnósticos. El prefix cacheado debería pegar, y si no pega, el experimento es inválido.

Saltó dos veces en la corrida con el diff chico.

Mismo código, misma secuencia de cinco llamadas, mismo system message idéntico de 4,003 tokens. Las dos corridas devolvieron cached_tokens=0 en cada llamada. Modo cache y modo naive llegaron al mismo $0.413 exacto, a cuatro decimales.

Después corrí el diff grande con 16,000 tokens por call. Cuatro de cinco llamadas pegaron al cache limpiamente. 15,992 cached tokens cada una.

Entonces en algún punto entre 4K y 16K tokens de prefix idéntico, contra claude-opus-4.6 por el proxy de Copilot con un request en forma OpenAI, el prompt caching se activa. Por debajo de ese umbral, no. Los docs de Anthropic dicen que el mínimo es aproximadamente 1024 a 2048 tokens. Empíricamente, la curva de activación no es plana.

Si estás presupuestando sobre un descuento de cache declarado, modela tu hit rate como una banda. Corre el experimento sobre tus tamaños reales de payload. No asumas que la matemática del marketing aguanta para las llamadas que tú realmente estás haciendo.

Pruébalo tú mismo

El harness completo vive en github.com/AndreaGriffiths11/librarian-demo. Tres archivos de Python, un escenario de diff, un módulo de pricing. Córrelo así:

export COPILOT_OAUTH_TOKEN=$(sqlite3 ~/.copilot/data.db \
  "SELECT access_token FROM github_accounts WHERE is_default=1;")

python demo.py all --verbose --diff scenario/sample_pr_large.diff

Si tienes GitHub Copilot CLI instalado, ya tienes un token OAuth sentado en ~/.copilot/data.db. Apunta el SDK de OpenAI a https://api.githubcopilot.com con el header Copilot-Integration-Id: copilot-cli y tienes el catálogo completo de modelos (Anthropic, OpenAI, Google) sobre la forma chat-completions, con prompt_tokens_details.cached_tokens reportado. Sin PAT, sin token exchange. Como 30 líneas de pegamento:

import sqlite3, pathlib
from openai import OpenAI

con = sqlite3.connect(
    f"file:{pathlib.Path.home()}/.copilot/data.db?mode=ro", uri=True
)
token = con.execute(
    "SELECT access_token FROM github_accounts WHERE is_default=1"
).fetchone()[0]

client = OpenAI(
    base_url="https://api.githubcopilot.com",
    api_key=token,
    default_headers={"Copilot-Integration-Id": "copilot-cli"},
)

Una nota de billing: GitHub Copilot pasa a facturación basada en uso el 1 de junio de 2026. Bajo el nuevo modelo, el consumo de tokens se traduce directamente en GitHub AI Credits a las tarifas publicadas de la API de Anthropic, así que las cifras en dólares de este artículo aplican a usuarios de Copilot también, no solo a quienes usan la API directamente. La conclusión arquitectónica es la misma de cualquier forma. Si estás en un plan pago de Copilot, estos ahorros son dólares reales de tu asignación mensual de créditos.

Qué shippearía en realidad

Si estuviera reconstruyendo un pipeline de review mañana con estos datos sobre la mesa:

Mueve todo contexto compartido al system message. Es el refactor más barato en software, y no te cuesta nada cuando el cache no se activa.
Construye el pase librarian una vez que cruzas tres revisores, o una vez que tu contexto compartido es lo suficientemente grande para que el umbral de activación efectivamente kickee. El digest se paga solo entre sesiones frías.
Deja de tratar el cache hit rate como una constante. Mídelo sobre tus payloads, en tu entorno, contra el modelo con el que vas a shippear. Escribe un guardrail que falla en voz alta y déjalo gritar cuando los supuestos se rompen.

El paper de Cho et al. mide ahorros de energía de GPU sobre SWE-Bench Verified, hasta 25% en corridas multi-agente. Mi harness mide dólares de pared en una pasada de review de PR. Distinto proxy, misma lección: el contexto compartido persistente entre agentes es una palanca arquitectónica gratis tirada en el piso.

Paper: Cho, Choi, Heo, Choi. “Long Live the Librarian! A Persistent Search Sub-Agent for Energy-Efficient Multi-Agent Software Engineering Systems” (arXiv:2605.27787, mayo 2026).

Todos los números fueron medidos contra claude-opus-4.6 por el proxy de GitHub Copilot el 29 de mayo de 2026. Los breakdowns completos por llamada y el código del harness viven en el runs/findings.md del repo.