Uso de tokens: coste por tarea de programación aceptada

Volver

Kevin Riedl

11 min de lectura · 17 de agosto de 2026
Última revisión 5 de octubre de 2026

Siguiente

Un agente de programación puede enviar menos tokens y generar una factura mayor. Las lecturas de caché, las entradas nuevas, las escrituras y las salidas tienen precios distintos. Una ejecución aparentemente barata también puede trasladar trabajo a otro modelo o a una persona. La pregunta útil es cuánto costó realmente un cambio aceptado.

Revisado el 5 de octubre de 2026. Esta guía mide y mejora un flujo de programación existente; no clasifica los modelos más baratos. El ejemplo utiliza datos contables sintéticos, no un benchmark de Wavect ni una promesa de ahorro.

1. Normaliza la factura antes de cambiar el agente

Registra identificadores de tarea e intento, modelo y versión, proveedor, categorías de tokens, precios, herramientas, latencia y resultado de aceptación. Incluye intentos rechazados y agentes auxiliares. Un fallo sigue sumando costes al numerador; aceptar dos veces la misma tarea no debe aumentar el denominador.

Anthropic informa los input_tokens sin caché por separado de la creación y lectura de caché. Separa escrituras con vigencia de cinco minutos y una hora. Los multiplicadores habituales de escritura son 1,25× y 2×. La lectura suele costar 0,1× la entrada base, pero Opus 5.5 utiliza 0,05× y Fable 5.1/Mythos 5.1, 0,025×. Son categorías de facturación específicas de cada modelo, no un precio universal por token.

No reutilices el mismo analizador para todos los proveedores. La entrada total de OpenAI incluye los tokens en caché; los modelos que exponen cache_write_tokens también requieren separar las escrituras. Calcula la entrada ordinaria con los campos documentados sin contarla dos veces. Los datos ausentes o incoherentes son un error contable que investigar, no un coste automáticamente nulo. Aplica los cargos de salida y razonamiento según las reglas del proveedor.

2. Haz reutilizable el contexto y mide la caché

Mantén estables las instrucciones reutilizables y los contratos de herramientas, con el material variable de la tarea más adelante cuando la API lo permita. Comprueba mínimos por modelo, caducidad y contadores reales de lectura y escritura. Claude Code puede reconstruir la caché tras cambios o inactividad; los subagentes pueden tener otro prefijo. Una vigencia mayor encarece la escritura y no siempre resulta más barata.

3. Exige aceptación verificable al enrutar y comprimir

Evalúa el enrutamiento con un conjunto fijo de tareas del repositorio, pruebas deterministas y criterios de revisión. Asigna al modelo económico las clases de tareas que demuestra resolver. Envía cambios de alto riesgo directamente a una verificación más fuerte o revisión humana cuando corresponda. La confianza declarada por el modelo o un JSON válido no prueban la corrección del código. RouteLLM es una referencia de implementación, no una garantía de ahorro en tu repositorio.

Recorta registros irrelevantes, recupera solo los archivos necesarios y conserva un manifiesto compacto. Mantén requisitos, versiones, evidencia de fallos y acceso al material completo. Mide las llamadas de resumen, la reutilización de caché perdida y los reintentos posteriores. Un contexto menor no garantiza menos coste ni más precisión; el tercer escenario ilustra deliberadamente una regresión de caché.

Como implementación concreta, nuestro análisis de RTK AI 1.0 separa filtros de shell, pipelines opcionales y proxy de API, incluyendo sus licencias y los límites de sus estadísticas de ahorro.

4. Sustituye trabajo determinista y agrupa tareas independientes

Utiliza formateadores, analizadores, búsquedas y scripts acotados para trabajo determinista. Mide las llamadas eliminadas en lugar de prometer un porcentaje fijo. Conserva permisos y revisión en operaciones destructivas. Agrupa evaluaciones o clasificaciones independientes cuando la latencia lo permita, no pasos interactivos que dependan de la respuesta anterior. OpenAI documenta un descuento del 50 % y una ventana de finalización de 24 horas para solicitudes batch compatibles, no para todos los proveedores o flujos.

5. Reproduce la diferencia entre tokens y coste

Usa las mismas dos tareas de corrección y los mismos criterios de aceptación en cada escenario. Cada escenario ilustrativo contiene tres intentos, uno rechazado, y dos cambios únicos aceptados. Los contadores agregan todos los intentos. Se aplican precios estándar de Sonnet 5.5 revisados el 5 de octubre, por millón de tokens: 2 USD de entrada sin caché, 2,50 de escritura de cinco minutos, 4 de escritura de una hora, 0,20 de lectura y 10 de salida. No se aplican modificadores regionales ni batch.

Solo para este ejemplo, añade a cada escenario 30 minutos totales de revisión a un supuesto de 60 USD/hora y 0,40 USD de otros costes del flujo. Son supuestos aritméticos, no salarios medidos ni facturas de herramientas. En producción, utiliza los costes reales de revisión, compresión auxiliar, infraestructura y herramientas sin contar dos veces los tokens de agentes auxiliares.

La regresión de caché envía menos tokens que el escenario optimizado, pero cuesta más en la API. Incluir revisión también cambia la escala económica de la comparación. Con cero tareas aceptadas, el coste por tarea aceptada no está definido: informa el fallo y su gasto, en lugar de dividir por cero o anunciar un ahorro.

Ejecuta este ejemplo con Python 3.10 o posterior. Verifica la aritmética, no la calidad del agente. Sustituye contadores y precios antes de utilizarlo para tu propia factura.

from decimal import Decimal as D

# USD per million tokens: uncached, write 5m, write 1h, read, output.
RATES = tuple(map(D, ("2", "2.50", "4", "0.20", "10")))
CASES = {
    "baseline": (1_000_000, 200_000, 0, 8_000_000, 100_000),
    "optimized": (500_000, 200_000, 0, 4_000_000, 100_000),
    "cache_regression": (1_400_000, 0, 0, 0, 100_000),
}

def cost(tokens, accepted=2, review_minutes=30, other_usd="0.40"):
    if type(accepted) is not int or accepted <= 0:
        raise ValueError("accepted must be a positive count of unique tasks")
    if len(tokens) != len(RATES) or any(type(n) is not int or n < 0 for n in tokens):
        raise ValueError("provide five non-negative integer token counts")
    review, other = D(str(review_minutes)), D(str(other_usd))
    if not review.is_finite() or not other.is_finite() or min(review, other) < 0:
        raise ValueError("review time and other costs must be finite and non-negative")
    api = sum(D(n) * rate for n, rate in zip(tokens, RATES)) / D(1_000_000)
    review_usd = review / D(60) * D("60")
    return api, (api + review_usd + other) / D(accepted)

for name, tokens in CASES.items():
    api, per_accepted = cost(tokens)
    print(f"{name}: API=${api:.2f}; total/accepted=${per_accepted:.2f}")

6. Introduce un solo cambio cada vez

1. Captura una referencia antes de cambiar prompts o rutas de modelos.
2. Modifica una variable: estabilidad del prefijo, recuperación, enrutamiento, herramienta determinista o un lote compatible.
3. Repite las mismas tareas y registra fallos, cambios aceptados, revisión y factura completa.
4. Conserva el cambio solo si calidad y latencia siguen siendo aceptables y mejora el coste medido.

La estrategia general está en Cómo reducir los costes de tokens LLM; la arquitectura, en la guía de agentes de programación multimodelo. El análisis de Spotify shunt separa la reducción de contexto principal de los costes auxiliares y la verificación.

Fuentes primarias revisadas el 5 de octubre de 2026

• Anthropic: facturación de caché y precios por modelo
• Claude Code: vigencia, cambios de prefijo y contadores
• OpenAI: contabilidad de caché y escrituras explícitas
• RouteLLM: implementación y evaluación del enrutamiento
• OpenAI: compatibilidad, precio y plazo de la API Batch