El precio por token no dice cuánto cuesta un resultado. Un token es un pedazo de texto de pocas letras: el proveedor cobra el modelo por token.
Esta cuenta suma el modelo en todos sus intentos y el tiempo de la persona que revisa. Después reparte ese total entre las tareas que salen bien.
Cambiá los valores por los de tu caso. El link de la barra de direcciones guarda el cálculo.
Cálculo
Valores de ejemplo, inventados, a noviembre de 2026. Son los de la ficha de costo. Los precios cambian, y a veces suben. Poné los de tu proveedor, con la fecha.
Algunos valores del link no servían. Esos campos muestran el valor de ejemplo.
Modelo, por intento
USD 0,10
Modelo, por tarea (todos sus intentos)
USD 0,15
Revisión humana, por tarea
USD 1,50
Por tarea intentada, salga bien o mal
USD 1,65
Por tarea exitosa
USD 2,06
De qué está hecho el costo de una tarea
Modelo: 9 %
Revisión humana: 91 %
La tasa de éxito de esta cuenta es la de una tarea con los reintentos permitidos. No uses pass^k acá. pass^k mide si salen bien los k intentos. Sirve como criterio de salida en el plan de evaluación.
costo por intento = tokens de entrada × precio de entrada / 1.000.000
+ tokens de salida × precio de salida / 1.000.000
costo del modelo = costo por intento × intentos por tarea
costo de revisión = minutos de revisión / 60 × costo de una hora
costo por tarea exitosa = (costo del modelo + costo de revisión) / tasa de éxito
Alguien también resuelve las tareas que fallan. Ese costo va aparte. La ficha de costo guarda la cuenta con su fecha. También trae una tabla de sensibilidad (cómo cambia el costo si cambia cada valor) y un presupuesto con corte.
Lo que hay que medir es cuánto cuesta cada tarea que sale bien, no cuánto cuesta cada llamada al modelo.
Veredicto: Sí. El token, la unidad de texto que cobra el modelo, se paga igual si el resultado está bien o mal. La revisión humana también es costo. Un juego hecho por un agente solo costó 9 dólares y no respondía a los controles. Con un arnés de tres agentes costó 200 dólares y se podía jugar.
Criterio
Calculá el costo por tarea exitosa. Sumá los tokens de todos los intentos, los reintentos y las horas de revisión. Dividí eso por las tareas que salieron bien. Medilo por flujo, no con la factura del mes.
Por qué confianza media. La cuenta es simple y nadie la discute. Lo que faltan son mediciones publicadas. El caso del juego es del propio proveedor, sin grupo de control. El dato de revisión lo da un ingeniero de Microsoft sobre una herramienta de Microsoft. El resto son hilos chicos de Reddit con cifras autoinformadas. Las fuentes que matizan muestran algo más. La cuenta puede dar a favor del agente si el trabajo se parte en pasos chicos.
Ver el detalle de las 7 pruebasOcultar el detalle5 a favor, 0 en contra, 2 matizan
El post dice que el precio por token es la métrica equivocada, porque se paga igual si el resultado está bien o mal. La confiabilidad cae con el largo de la cadena de pasos, así que hay que sumar el costo de revisar. El autor concluye que no se puede automatizar trabajo serio de forma rentable. Un comentario propone algo más útil: medir el costo por resultado exitoso.
Números
77 %, 60 % y menos de 36 %Confiabilidad de un proceso de 5, 10 y 20 pasos con 95 % de acierto por paso, si los errores fueran independientes.
Limitación Hilo muy chico (2 puntos y 6 comentarios en el archivo) y el post promociona un artículo del autor. La cuenta es aritmética, no una medición. Se leyó en el archivo público Arctic Shift porque reddit.com bloquea la lectura automática. La cita se comparó letra por letra con el original.
“Cost per successful outcome seems like a far more useful metric than cost per token”
Compara un agente solo con un arnés de tres agentes (planificador, generador y evaluador) para construir aplicaciones completas. El arnés dio resultados claramente mejores, pero costó más de 20 veces. Los agentes que se califican a sí mismos son demasiado generosos. El evaluador separado también fallaba hasta que lo afinaron para ser escéptico y probar con una herramienta externa. Cada pieza del arnés supone algo que el modelo no puede hacer solo, y con un modelo mejor (Opus 4.6) sacaron piezas.
Números
20 minutos y 9 dólares contra 6 horas y 200 dólaresUn juego retro con Opus 4.5: agente solo (el juego no respondía a los controles) contra arnés completo (jugable).
3 horas 50 minutos y 124,70 dólaresUna estación de audio digital con Opus 4.6 y el arnés simplificado.
Limitación Casos propios del proveedor, sin grupo de control sistemático.
“agents reliably skew positive when grading their own work”
Diez meses de datos del agente de código de Copilot en el repositorio dotnet/runtime. Más de la mitad de sus pull requests se aceptaron y casi no se revirtieron, porque cada uno pasó por revisión experta. Rindió mejor en tareas mecánicas y acotadas (limpieza, tests) y peor en las que piden juicio (rendimiento). Un archivo de instrucciones y la configuración del build casi duplicaron el éxito. El cuello de botella pasó de escribir código a revisarlo.
Números
878 PR, 67,9 % de éxitoPull requests del agente y tasa de éxito (87,1 % en los PR de personas de Microsoft; poblaciones no comparables).
0,6 % contra 0,8 %PR aceptados que después se revirtieron: del agente contra el resto.
de 38,1 % a 69 %Éxito antes y después de agregar instrucciones y configurar el build.
86,2 % contra 55,1 %Éxito con commits de una persona en el PR y sin ellos.
de 5 a 9 horasRevisión que generaron nueve PR abiertos por el autor en un rato.
Limitación Lo escribe un ingeniero de Microsoft sobre una herramienta de Microsoft. Es un repositorio con revisores muy expertos. El propio autor aclara que el agente y las personas no hacen el mismo tipo de tareas.
“we cannot compromise on review quality, on expert and experienced eyes validating the changes”
u/Consistent-Arm-875 (autor del post). r/AI_Agents
Una persona que opera cinco agentes en producción cuenta cómo bajó el gasto después de una factura de 4.000 dólares en un mes. Le sirvió usar primero un modelo barato, y el caro solo si falla la validación. También recortó el historial que se reenvía en cada llamada y usó caché para los prompts de sistema repetidos. Además, usó salida estructurada y midió el costo por flujo. Un endpoint que devolvía JSON mal formado multiplicaba el consumo, y solo apareció al medir por flujo.
Números
70 % menos en 6 semanasBaja del gasto total, según el autor.
60 % y 30 %Menos tokens de entrada al recortar el historial, y menos gasto con caché en agentes que hacen muchos pedidos.
5 vecesAumento del consumo por un endpoint con JSON mal formado.
Limitación Cifras autoinformadas en un hilo chico (1 punto y 16 comentarios en el archivo). Se leyó el texto original en el archivo público Arctic Shift porque reddit.com bloquea la lectura automática. La cita está en el texto del post y se comparó letra por letra.
Son los precios de lista de los modelos de Anthropic, consultados el 1 de noviembre de 2026 y revisados el 2 de noviembre. Entre el modelo más caro y el más barato de la misma generación hay una brecha de 40 veces. La página también documenta costos que no se ven en la tabla. El tokenizador nuevo corta el mismo texto en más tokens, que son las unidades que se cobran. La inferencia solo en EE. UU. cuesta más, y declarar herramientas de navegador o de uso de computadora suma miles de tokens de entrada por pedido.
Números
US$ 4 y US$ 20Claude Opus 5.5: entrada y salida por millón de tokens (lectura de caché: US$ 0,20).
US$ 2 y US$ 10Claude Sonnet 5.5: entrada y salida por millón de tokens (lectura de caché: US$ 0,10).
US$ 0,10 y US$ 0,50Claude Haiku 5.5, con prompts de hasta 100.000 tokens: entrada y salida por millón.
US$ 15 y US$ 75Claude Opus 4 y 4.1, el tope de gama de 2025: entrada y salida por millón.
cerca de 30 % más tokensEfecto del tokenizador nuevo para el mismo texto.
50 % menosDescuento por procesamiento en lote (Batch API); no aplica a sesiones de agentes interactivas.
1,1 vecesMultiplicador de precio por pedir inferencia solo en EE. UU.
Limitación Los precios vencen rápido: revisarlos antes de usar estas cifras. Haiku 5.5 cuesta más con prompts de más de 100.000 tokens. El precio por token no es el costo por tarea: depende de cuántas vueltas da el agente y de cuánto contexto reenvía.
Un SaaS mediano cuenta cómo armó un agente de triage de soporte, que clasifica los pedidos y decide quién los atiende. Empezó por contraseñas y facturación. El agente solo responde si puede citar un artículo o un dato de la base. Las personas revisaron el 100 % de las respuestas los primeros 30 días. Reembolsos, cancelaciones, clientes grandes y respuestas con poca confianza pasan a una persona. La primera versión sin revisión inventó una función que no existía. El equipo no se achicó: pasó a los casos difíciles.
Números
47 % y 22 %Tickets resueltos sin persona, y tickets redactados por el agente y enviados por una persona, a los 90 días.
0,18 contra unos 3,50 dólaresCosto por ticket con el agente contra el costo humano anterior.
0,85Umbral de confianza: debajo, la respuesta va a una persona.
Limitación Números autoinformados en un hilo chico (3 puntos y 7 comentarios en el archivo), sin verificación independiente. Se leyó el texto original del post en el archivo público Arctic Shift porque reddit.com bloquea la lectura automática.
Hilo sobre un artículo que pide escribir el flujo de control en código y no en prompts. Un comentarista cuenta que un agente de QA debía recorrer unos 200 archivos de requisitos y se rompía cerca del archivo 30. Un arnés determinista (código que fija cada paso) lo resolvió. Otro dice que, con el trabajo partido en piezas chicas, modelos más baratos rinden como los de frontera. Algunos se quejan de que las plataformas prefieren flujos solo con prompts.
Números
unos 200 archivos, falla cerca del 30Caso de un agente de QA guiado solo por prompt, según un comentarista.
590 puntos y 296 comentariosTamaño del hilo.
Limitación Relatos de usuarios, sin datos medidos. Se leyó en news.ycombinator.com y en la API pública de Algolia. Las citas del hilo no se cotejaron palabra por palabra y por eso no se usan.
Poné un tope de gasto que corte al agente. El costo por tarea sirve para decidir, pero no frena una tarea trabada. Sin tope, esa tarea se puede llevar el presupuesto.
Un agente en producción necesita un tope de gasto que lo corte.
Veredicto: Sí. La lista de riesgos de OWASP para agentes pide topes de costo, de tasa o de tokens con corte automático. Un equipo con cinco agentes recibió una factura de 4.000 dólares en un mes. El costo por hora sube justo cerca del límite de lo que el modelo puede hacer, donde más falla. El tope no tiene que ser bajo. Hay quien gasta de 2.000 a 5.000 dólares por mes, y su empresa lo acepta.
Criterio
Poné un tope de gasto por tarea y por día que corte al agente y avise a una persona. Si una tarea llega al tope, que pare y la derive en vez de seguir reintentando.
Por qué confianza media. OWASP es una lista de consenso de expertos, no una medición. Los casos de gasto vienen de Reddit y de un hilo de Hacker News sobre un ensayo de 2025, con cifras autoinformadas o estimadas. La fuente en contra no discute el tope: muestra que un gasto alto puede valer la pena.
Ver el detalle de las 4 pruebasOcultar el detalle3 a favor, 1 en contra, 0 matizan
Es la primera lista de consenso de OWASP hecha para agentes. Los diez riesgos van desde el secuestro del objetivo del agente (ASI01) hasta los agentes rebeldes (ASI10). Entre ellos están el mal uso de herramientas (ASI02) y el abuso de identidad y privilegios (ASI03). También están la cadena de suministro agéntica (ASI04) y las fallas en cascada (ASI08). Suma el principio de mínima agencia: no dar autonomía que no hace falta. Como mitigaciones pide perfiles de mínimo privilegio por herramienta, aprobación humana para acciones destructivas y controles fuera del modelo. También pide topes de costo, tasa o tokens con corte automático.
Números
10 riesgos (ASI01 a ASI10)Tamaño de la lista. ASI02 y ASI03 extienden la agencia excesiva (LLM06) de la lista de 2025 a flujos de varios pasos.
Limitación Es un marco voluntario de consenso: no obliga a nadie y no mide nada. En la lista de agentes, el consumo sin límites ya no es un ítem propio: aparece como escenario y mitigación dentro de ASI02. Se leyó el PDF completo (57 páginas).
“deploying agentic behavior where it is not needed expands the attack surface”
u/Consistent-Arm-875 (autor del post). r/AI_Agents
Una persona que opera cinco agentes en producción cuenta cómo bajó el gasto después de una factura de 4.000 dólares en un mes. Le sirvió usar primero un modelo barato, y el caro solo si falla la validación. También recortó el historial que se reenvía en cada llamada y usó caché para los prompts de sistema repetidos. Además, usó salida estructurada y midió el costo por flujo. Un endpoint que devolvía JSON mal formado multiplicaba el consumo, y solo apareció al medir por flujo.
Números
70 % menos en 6 semanasBaja del gasto total, según el autor.
60 % y 30 %Menos tokens de entrada al recortar el historial, y menos gasto con caché en agentes que hacen muchos pedidos.
5 vecesAumento del consumo por un endpoint con JSON mal formado.
Limitación Cifras autoinformadas en un hilo chico (1 punto y 16 comentarios en el archivo). Se leyó el texto original en el archivo público Arctic Shift porque reddit.com bloquea la lectura automática. La cita está en el texto del post y se comparó letra por letra.
Hilo sobre un ensayo de Toby Ord que usa datos de METR para estimar el costo por hora de los agentes. Ese costo sube mucho cuando la tarea se acerca al límite de lo que el modelo puede hacer, justo donde más falla. El contrapunto más fuerte del hilo es que modelos abiertos más baratos completan el mismo conjunto de tareas por mucho menos.
Números
unos 350 dólares por horaCosto de o3 en su horizonte máximo, donde todavía falla cerca de la mitad de las veces.
306 puntos y 137 comentariosTamaño del hilo.
Limitación El ensayo es de 2025 y usa modelos de ese año. Se leyó el hilo en news.ycombinator.com y en la API pública de Algolia, no el ensayo completo. Las citas del hilo no se cotejaron palabra por palabra en la verificación de origen y por eso no se usan.
El autor gastó unos 50 dólares de API en una aplicación chica de fin de semana. En el trabajo, una suscripción de 20 dólares le alcanza para usar mucho más. Para él, el precio de hoy está subsidiado, y con un cobro por uso real muchos usos de agentes dejan de cerrar. Otros lo comparan con los viajes baratos de Uber en 2015. En cambio, un comentarista gasta de 2.000 a 5.000 dólares por mes, y su empresa lo acepta porque le multiplica el rendimiento.
Números
unos 50 contra 20 dólaresGasto de API en una aplicación chica contra una suscripción mensual, según el autor.
de 2.000 a 5.000 dólares por mesGasto de un comentarista, que su empresa acepta.
991 puntos y 457 comentariosTamaño del hilo según el archivo. El comentario citado tiene 74 puntos.
Limitación Cifras chicas y autoinformadas; el hilo es una opinión sobre el futuro de los precios. La cita es del contrapunto a favor, no de la tesis del hilo. Se leyó en el archivo público Arctic Shift porque reddit.com bloquea la lectura automática. La cita se comparó letra por letra con el original.
“It's been a force multiplier so my company has no problem with that additional cost.”
Veredicto: Probablemente acelera la producción, pero el tamaño es incierto. En un experimento aleatorizado con un asistente, todos mejoraron en una tarea de negocio. En proyectos abiertos que adoptaron Cursor, las líneas agregadas subieron 281,3 % el primer mes. Pero la mejora se apagó a los dos meses. METR repitió su estudio en 2026. METR cree que la IA probablemente acelera más que en 2025, aunque no confía en sus propios números.
Criterio
No des por hecha la ganancia: medila en tu propio trabajo, comparando contra hacerlo sin la herramienta. Volvé a medir la calidad unos meses después, porque la velocidad del arranque puede dejar deuda.
Por qué confianza media. El experimento aleatorizado es con un asistente de chat, no con agentes. Los datos de agentes de código son observacionales. Uno es de Microsoft sobre su propio despliegue y otro es sobre proyectos de código abierto. La repetición de METR tiene intervalos que cruzan el cero. METR desconfía de su dato por sesgo de selección. Un proveedor que estima la productividad con sus datos la achica al ajustar por éxito.
Ver el detalle de las 5 pruebasOcultar el detalle2 a favor, 1 en contra, 2 matizan
Cruces, G., Fernández Meijide, D., Galiani, S., Gálvez, R. H., Lombardi, M. NBER (Working Paper 34851)
Es un experimento aleatorizado (con grupos armados al azar) con un asistente de IA generativa, en una tarea de resolver un problema de negocio. Todos mejoran, y los que tienen menos educación mejoran más. La brecha se achica mucho, pero no desaparece, y al sacar la IA vuelve en buena parte. Los que tienen más educación usan mejor la herramienta.
Números
de 0,548 a 0,139 desvíos estándarBrecha de desempeño por educación sin IA y con IA (se cierra cerca de tres cuartos), en 1.174 adultos de 25 a 45 años.
Limitación Se leyó la página de NBER con el resumen. Mide educación, no experiencia; es un asistente de chat, no un agente, y la tarea es en línea, fuera de una empresa. Tiene revisiones de mayo y octubre de 2026.
Murphy-Hill, E., Butler, J., Savelieva, A. arXiv (Microsoft)
Estudia el despliegue de dos agentes de código de terminal entre decenas de miles de ingenieros de Microsoft. Quienes los adoptaron fusionaron más pull requests que un grupo de control sintético. En los ingenieros más junior (IC2), los pull requests creados subieron más: +34 %, contra +21 % del nivel de referencia (IC4). Por antigüedad, la mejora tiene forma de C: ganan más los de poca y los de mucha antigüedad. El estudio de adopción mira solo Copilot CLI: ahí los perfiles junior lo probaron menos al principio. El uso se contagió sobre todo por redes de colegas. No mide calidad.
Números
+24,0 % (de +14,5 % a +33,7 %)Pull requests fusionados por ingeniero por día frente al control, en una ventana de 4 meses (intervalo de 95 %).
+34 % contra +21 %Aumento de pull requests creados con 3 días de uso por semana, frente a las semanas sin uso de la misma persona. Compara el nivel IC2 contra IC4, el de referencia (IC3: +21 %, IC5: +25 %, IC6: +22 %). Leído de la figura 9, con Claude Code y Copilot CLI.
-13 % y -14 %Chances de probar Copilot CLI al principio en los niveles IC2 e IC3 frente a IC4 (IC5: +22 %). Solo Copilot CLI: el estudio de adopción no incluye Claude Code.
Limitación Observacional, no aleatorizado. Los autores son de Microsoft, dueña de GitHub, y lo declaran. Un pull request no es valor entregado. El aumento por nivel compara semanas con y sin uso de cada persona: es una asociación, no una causa. El estudio de adopción incluye solo Copilot CLI.
“first use spread primarily through social networks”
Los proyectos de GitHub que adoptaron Cursor aceleran mucho al principio, pero la mejora se apaga a los dos meses. Quedan más complejidad y más alertas de análisis estático (revisión automática del código), y eso frena la velocidad después. Cursor acelera un rato y deja deuda técnica (problemas para arreglar más adelante).
Números
+281,3 % y +48,4 %Líneas agregadas en el mes 1 y en el mes 2 después de adoptar, en 806 repositorios contra 1.380 de control.
+30,26 % y +41,64 %Alertas de análisis estático y complejidad del código después de adoptar.
Limitación Diferencias en diferencias sobre proyectos de código abierto, no empresas. Los números salen de la versión 3 (26 de enero de 2026); el título cambió entre versiones y no se verificó si cambiaron los resultados. La discusión menciona 25,1 % de complejidad, que no coincide con la tabla.
“a statistically significant, large, but transient increase in project-level development velocity”
Becker, J., Rush, N., Cunningham, T., Rein, D., Mahamud, K. METR
METR repitió su estudio con más desarrolladores y con herramientas de fines de 2025. Los números indican que la IA ahora acelera el trabajo, pero METR no confía en ellos. Muchos desarrolladores no quisieron trabajar sin IA y dejaron afuera tareas para no hacerlas sin ella. Concluye que hoy la IA probablemente acelera más que en 2025, pero el dato es una evidencia muy débil del tamaño de la mejora. También cambió el diseño del experimento.
Números
57 desarrolladores, 143 repositorios, más de 800 tareasTamaño del nuevo estudio (10 repiten y 47 son nuevos).
-18 % y -4 %Cambio en el tiempo con IA: los que repiten (intervalo de -38 % a +9 %) y los nuevos (de -15 % a +9 %).
+19 %Cambio en el tiempo con IA en el estudio original de 2025 (intervalo de +2 % a +39 %).
entre 30 % y 50 %Desarrolladores que no presentaron algunas tareas para no hacerlas sin IA.
Limitación Sesgo de selección que METR reconoce. Además bajó el pago, y quienes usan varios agentes en paralelo miden mal su tiempo. Los intervalos cruzan el cero: no muestran una mejora segura.
Con datos de noviembre de 2025, en el chat de Claude la colaboración volvió a superar a la automatización. Bajaron las conversaciones en las que la persona solo da órdenes. En la API, que usan sobre todo empresas, la automatización sigue en cerca de tres cuartos. El éxito de la tarea es menor en la API, y al ajustar por éxito se achica la mejora de productividad estimada. El informe dice que el primer efecto neto puede ser descalificar trabajos, es decir, sacarles las tareas que piden más habilidad.
Números
52 % y 45 %Conversaciones de colaboración y de automatización en el chat. Las directivas bajaron a 32 % (39 % en agosto de 2025).
67 % y 49 %Éxito de la tarea en el chat y en la API.
de 1,8 a 1,0 a 1,2 puntosAporte anual estimado al crecimiento de la productividad laboral de EE. UU., antes y después de ajustar por éxito.
Limitación Lo publica el proveedor con sus propios datos. Son 1 millón de conversaciones y 1 millón de transcripciones de la API (13 al 20 de noviembre de 2025).
“the productivity benefits will be smaller than raw speedups suggest”