Costo por sesión de agente de código: dónde se dispara

Una sesión de agente de código cuesta 155,6x más en un modelo que en otro dentro de la misma franja de duración: US$ 3,734 contra US$ 0,024 entre 10 y 49 turnos. En Opus 5.5, la sesión larga cuesta 4,6x la corta. La cuenta se planifica por sesión, no por precio de millón de tokens.

La ventana cierra el 18/10/2026, con 30 días de sesiones reales de ocho modelos. Lo que mide la tabla es el costo de una sesión que termina, y ese número es el que aparece en la factura del mes siguiente.

Principales hallazgos

1. La mediana de costo de una sesión de 10 a 49 turnos varía 155,6x entre el modelo más caro y el más barato del conjunto, de US$ 3,734 a US$ 0,024.
2. En la franja de 2 a 9 turnos la amplitud relativa es mayor, 209,8x, porque la sesión corta del modelo más barato cuesta US$ 0,005, medio centavo.
3. En Opus 5.5 la sesión de 10 a 49 turnos cuesta 4,6x la de 2 a 9 turnos y 10,2x la de turno único; en Sonnet 5.5, 3,8x y 8,4x.
4. La primera petición de una sesión en carpeta vacía grabó 17.047 tokens en caché a US$ 5 por millón, US$ 0,085, para una respuesta de cuatro tokens; la lectura del mismo bloque cuesta US$ 0,20 por millón, 25x menos.
5. Con 22 días hábiles, 5 sesiones cortas por día suman US$ 34 al mes en Opus 5.5 y US$ 17 en Sonnet 5.5; 10 sesiones largas por día suman US$ 306 y US$ 131.
6. La CLI nativa del agente reportó de US$ 0,16 a US$ 0,31 para sesiones de Haiku que costaron medio centavo, entre 32 y 62 veces el valor real, y sobreestimó sesiones de Opus 5.5 en cerca de 50%.
7. La misma carga mensual de tres rutinas de trabajo cuesta US$ 1,79 en Haiku 5.5 y US$ 172,62 en Fable 5.1, 96,4x de distancia para el mismo servicio entregado.

Cada línea se sostiene sola, con el número, la franja de duración y la ventana que la produjeron. Quien cite una de ellas cita la estadística completa, no un pedazo de ella.

¿Cómo se recopilaron los datos?

Base: medianas de costo por sesión de agente de código publicadas por un agregador de inferencia, en dólares, en una ventana de 30 días cerrada el 18/10/2026. Ocho modelos, tres franjas de duración, una mediana por franja. La pieza calculó amplitudes, múltiplos y presupuestos mensuales; la medición por sesión es de terceros.

Mediana es el valor que divide la muestra en dos: la mitad de las sesiones costó menos, la mitad costó más. No es promedio. La distinción pesa en una distribución con cola, porque una sesión que lee un monorepo entero arrastra el promedio hacia arriba y describe mal la sesión que el equipo repite todos los días.

La mediana responde cuánto cuesta la mayoría de las sesiones. El promedio responde cuánto costó el mes entero.

La muestra cubre ocho modelos en tres franjas: una petición, 2 a 9 turnos y 10 a 49 turnos. El valor es el costo total de la sesión, no el precio de un turno ni el precio de un millón de tokens. El agregador publica un punto central por celda, lo que significa que esta pieza no ve las sesiones individuales, solo la mediana de cada combinación de modelo y duración.

Lo que la pieza calculó por cuenta propia: las amplitudes entre modelos (155,6x y 209,8x), los múltiplos por duración en cada modelo, los presupuestos mensuales con 22 días hábiles y la tabla de capas de tarea. Toda cuenta aparece en la sección en la que se usa el número, con los factores a la vista, para que el lector rehaga la multiplicación y discuta el redondeo si quiere.

Lo que no se puede concluir. La atribución entre harness y modelo es otro problema, ya medido en Caché de prompt y enrutamiento medidos juntos: dónde se forma realmente el costo del agente. El costo de una sesión depende del tamaño del repositorio y de cuánto de él lee la sesión, variable que la mediana no controla. Una prueba controlada de corrección de errores corrió en un proyecto pequeño, con caché caliente, y quedó por debajo de las medianas: sirve para comparar configuraciones, no para presupuestar. La medición del lado de la aplicación, y no de la sesión, tiene tratamiento propio en Cómo medir el costo real de una aplicación de IA más allá del precio por token.

Y la ventana tiene 30 días. Precio de modelo y política de caché se mueven, así que un múltiplo de octubre no es una promesa para enero.

¿Cuánto cuesta una sesión de agente de código por modelo y por duración?

Una sesión de 10 a 49 turnos cuesta de US$ 0,024 a US$ 3,734, mediana por modelo: 155,6x de amplitud. En la franja de 2 a 9 turnos el intervalo va de US$ 0,005 a US$ 1,049, 209,8x. Ocho modelos, tres franjas, la misma ventana de 30 días cerrada el 18/10/2026.

Valores en dólares, mediana por sesión:

La escalera tiene ocho peldaños y tres columnas, y lo primero que salta es la distancia entre la cima y la base en la franja larga: US$ 3,734 contra US$ 0,024. En valores absolutos, la elección de capa vale US$ 3,710 por sesión, prácticamente el precio entero de la sesión más cara. En valores relativos, vale 155 veces el costo de la más barata.

En la franja corta la amplitud relativa es mayor, 209,8x, porque el denominador se encoge más rápido que el numerador. La sesión de 2 a 9 turnos de GPT-6 Luna cuesta medio centavo, y cualquier número dividido por medio centavo queda grande. Amplitud relativa y distancia absoluta apuntan a lados distintos aquí, y las dos lecturas son correctas: quien arma política mira la relativa, quien firma la factura mira la absoluta.

Lo que esta tabla no hace es explicar la distancia entre las líneas. Atribuir la diferencia al harness o al modelo es otra pregunta, con respuesta publicada en el artículo citado en la metodología. El uso aquí es otro: la distancia medida se vuelve instrumento de presupuesto, porque la pregunta que responde es cuánto cuesta una sesión que termina.

Una salvedad de alcance, para evitar extrapolaciones. Los números valen para las tres franjas medidas. Una sesión de 200 turnos no está en la tabla, y nada aquí autoriza a estimarla por interpolación lineal.

¿Por qué la primera petición cuesta más que las siguientes?

La primera petición graba el bloque de contexto en caché y paga por escrito: 17.047 tokens a US$ 5 por millón, US$ 0,085, incluso cuando la respuesta tiene cuatro tokens. Todo turno siguiente lee el mismo bloque a US$ 0,20 por millón, 25x más barato. El costo de la sesión es piso fijo más cola por turno.

La prueba que separa las dos capas es simple y un poco humillante: una sesión de Opus 5.5 abierta en carpeta vacía, con una pregunta trivial. La respuesta tuvo cuatro tokens. La sesión grabó 17.047 tokens en caché, cobrados a US$ 5 por millón en la escritura, y la cuenta cerró en US$ 0,085 antes de cualquier trabajo útil. Cuatro tokens de respuesta, US$ 0,085 de entrada.

El turno siguiente no paga eso de nuevo. Lee el mismo bloque a US$ 0,20 por millón, y el costo marginal de un turno pasa a ser la relectura barata del bloque más lo que ese turno agrega, y no el bloque a precio de escritura. La lectura del bloque entero cuesta US$ 0,0034, un veinticincoavo de la escritura.

Por eso la mediana de turno único es 0,136 y no 0,085. Un proyecto real no abre en carpeta vacía: suma instrucciones, archivos leídos y salida de herramienta. El valor de 0,085 es piso de caché, no presupuesto de sesión.

La lectura corriente trata el costo de sesión como precio por token por volumen, y esa multiplicación se equivoca en los dos extremos. Subestima la sesión corta, que paga un piso desproporcionado al trabajo entregado, y sobreestima la cola, que lee a precio de lectura. La sesión tiene dos precios, y el primero es el caro.

¿Cuánto suma un mes de uso en cada rutina de trabajo?

Con 22 días hábiles, cinco sesiones cortas por día suman US$ 34 al mes en Opus 5.5 y US$ 17 en Sonnet 5.5. Veinte sesiones cortas suman US$ 134 y US$ 68; diez largas, US$ 306 y US$ 131. Entre los dos modelos, la rutina pesa 9x y la capa de modelo, 2,3x.

La cuenta de una línea, para verificación: 5 sesiones a US$ 0,305 dan US$ 1,525 por día, por 22 días hábiles, US$ 33,55, redondeados a 34. Veinte sesiones a US$ 0,305 dan US$ 6,10 por día y US$ 134,20 al mes. Diez sesiones largas a US$ 1,390 dan US$ 13,90 por día y US$ 305,80 al mes, contra US$ 5,96 y US$ 131,12 en Sonnet 5.5.

El número que cambia el comportamiento es la diferencia entre las columnas, no el total. En uso ligero, cambiar Opus 5.5 por Sonnet 5.5 ahorra US$ 17 al mes, valor que no paga la reunión necesaria para decidir el cambio. En uso pesado de sesiones largas, el mismo cambio ahorra US$ 175, y ahí la decisión se paga sola.

Los 22 días hábiles son un supuesto del presupuesto, no una medición. Quien opera en turnos o cubre fin de semana cambia el 22 por el número real de días, y la multiplicación sigue válida. Lo que no se cambia es la franja de duración, porque es ella la que define qué mediana entra en la cuenta.

El presupuesto mensual también es el lugar donde el costo por sesión se encuentra con el costo por persona. Diez sesiones largas por día describen a alguien en un día de investigación; cinco cortas por día describen a alguien en mantenimiento. La distancia entre US$ 34 y US$ 306 no viene del modelo. Viene de la rutina.

¿Por qué la sesión larga desborda el presupuesto incluso con token barato?

La sesión larga se desborda porque cada turno relee un contexto grande y graba lo que agrega; cada sesión nueva vuelve a pagar el piso. En Opus 5.5, la franja de 10 a 49 turnos cuesta 4,6x la de 2 a 9 y 10,2x la de turno único. El múltiplo no desaparece cuando el token se abarata.

El orden se invierte cuando el eje es relativo. GLM-5.3 amplía 8,3x de la franja corta a la larga; Opus 5.5 amplía 4,6x. La capa barata tiene cola proporcionalmente más empinada, y el motivo es aritmético: su piso es casi nada, así que el crecimiento aparece entero en el múltiplo.

El piso se paga una vez por sesión, mientras el bloque en caché sigue válido; cuando expira o cambia, la grabación vuelve al precio de escritura. La cola se paga en cada turno.

Esto desmonta una política común, la de tratar el modelo barato como capa de costo fijo. US$ 0,044 en una sesión corta de GLM-5.3 y US$ 0,363 en una larga son el mismo modelo, y la distancia de 8,3x es el tamaño del error de quien presupuestó por la franja equivocada.

La lectura correcta tiene dos columnas y ninguna de ellas sola resuelve. En absoluto, la capa frontier cuesta más en cualquier franja, y es ahí donde el tope de gasto pide atención. En relativo, la capa barata es la que más sorprende cuando la sesión se alarga, y es ahí donde la clasificación de tarea pide disciplina.

En la franja larga, Opus 5.5 cuesta 2,3x Sonnet 5.5 y 26x Haiku 5.5. Quien sube de Sonnet a Opus paga 2,3x; quien sube de Haiku a Opus paga 26x. La diferencia entre esos dos números es la diferencia entre una política de capa y un susto.

¿Cómo presupuestar por tarea en vez de por precio de millón de tokens?

Presupuestar por tarea es clasificar la sesión por la franja de turnos que usa, multiplicar la mediana de esa franja por el número de sesiones del mes y sumar las tareas que comparten la misma clave. Cuarenta sesiones cortas cuestan US$ 12,20 en Opus 5.5 y US$ 0,28 en Haiku 5.5. El presupuesto sale de esa suma.

La cuenta por tarea tiene tres pasos y ninguno de ellos es el precio del millón. Primero, clasificar la sesión por la franja de turnos que suele usar. Segundo, multiplicar la mediana de esa franja por el número de sesiones del mes. Tercero, sumar las tareas que comparten la misma clave. El total de la última línea es exactamente eso: 40 sesiones cortas más 24 de investigación más 120 de fondo, cada una en su mediana.

La distancia entre la primera y la última columna es 96,4x para la misma carga de trabajo: US$ 1,79 en Haiku 5.5 contra US$ 172,62 en Fable 5.1. Ninguno de los dos extremos es absurdo en abstracto. La pregunta que decide es qué tarea exige qué capa, y la respuesta cuesta una fracción de lo que cuesta descubrirlo en la factura.

La elección de ruta por calidad y costo por tarea ya tiene artículo propio, Orquestación multi-modelo en la práctica: 2 puntos de índice menos por la mitad del costo por tarea. Aquí la variable es otra: duración de la sesión y costo fijo de apertura. Las dos decisiones se suman sin sustituirse.

Y el presupuesto solo vale si el medidor ve la factura. La CLI nativa del agente calcula el costo por la tabla de precios del proveedor del modelo y se equivoca cuando el nombre del modelo no es reconocido. En el conjunto medido, reportó de US$ 0,16 a US$ 0,31 para sesiones de Haiku que costaron cerca de medio centavo, entre 32 y 62 veces el valor real, y sobreestimó sesiones de Opus 5.5 en cerca de 50%.

Un tope calculado sobre un medidor que se equivoca 50% es un tope con 50% de holgura invisible.

La medición que cuadra con la factura viene del lado del gateway, donde el gasto se forma.

Qué cambian estos números en la práctica

Tres decisiones salen directo de la tabla: qué capa de modelo atiende cada tipo de sesión, qué tope de gasto recibe cada clave y cada proyecto, y cuándo abrir sesión nueva en vez de continuar la actual. Las tres son política de equipo, no configuración de proveedor.

Política de modelo por tipo de sesión

La rutina corta va a la capa barata. La mediana de 2 a 9 turnos en Haiku 5.5 es US$ 0,007, y ninguna tarea de mantenimiento justifica pagar US$ 0,305 por la misma sesión en Opus 5.5, 43x más.

La investigación larga va a la capa frontier. La franja de 10 a 49 turnos es donde el trabajo deja de ser mecánico, y subir de Sonnet 5.5 a Opus 5.5 cuesta 2,3x por sesión. Esa es la cuenta que la investigación larga necesita justificar, no la diferencia de precio por token.

El trabajo de fondo va a la capa mínima. Sesiones de un turno cuestan US$ 0,002 en Haiku 5.5 y US$ 0,136 en Opus 5.5, y 120 de ellas al mes suman US$ 0,24 contra US$ 16,32. Tarea de fondo en capa frontier es la manera más cara de no ahorrar.

Tope de gasto por clave y por proyecto

El tope de una clave es la suma de los presupuestos de las tareas que esa clave atiende, y el tope de un proyecto es la suma de las claves. Ese cálculo sustituye la estimación por orden de magnitud, que es como la mayoría de los equipos define el límite hoy.

El artículo Contabilidad de costo de LLM por equipo, usuario y modelo: lo que la hoja de cálculo no muestra trató el reparto por equipo y por usuario. El tope por clave es el paso anterior a ese reparto, porque la clave es la unidad en la que el gasto se forma y el lugar donde se puede interrumpir.

Sesión nueva cuando la tarea cambia

El bloque de contexto se paga una vez por sesión, mientras la caché se mantiene válida. Continuar la sesión hacia una tarea distinta carga contexto que la tarea nueva no necesita, y cada turno siguiente paga por releer ese bloque ajeno. La sesión nueva paga un piso y lee menos; la continuación no regraba el bloque mientras vale, y lee lo que no debía.

La regla práctica cabe en una frase: si el siguiente pedido no necesita lo que la sesión ya leyó, abre sesión nueva. El costo de ignorarlo aparece en el múltiplo: una sesión que debía haberse cerrado en la franja corta y sigue hacia la larga cuesta 4,6x en Opus 5.5, y no todo ese múltiplo es trabajo nuevo.

Las tres decisiones anteriores solo valen si hay dónde aplicarlas. Nexforce Router expone exactamente las tres cosas que esa política necesita: consumo en tiempo real por sesión y por agente, tope de gasto por clave de API, por agente o por proyecto, y reglas de ruta por clave. Ninguno de los tres cambió el precio de caché del proveedor, y ninguno participó de la medición. La medición es de terceros; la política es del equipo.

Preguntas frecuentes

¿La mediana por sesión sirve para presupuestar un repositorio grande?

Sirve como punto de partida, no como respuesta. El costo depende de cuánto del repositorio lee la sesión, y la mediana agrega proyectos de tamaños distintos. La práctica que funciona es medir la primera semana del repositorio real y comparar con la mediana de la franja de duración correspondiente.

¿El número incluye el costo de caché de prompt?

Incluye. El valor es el costo total de la sesión, y la prueba en carpeta vacía aísla la porción de caché: 17.047 tokens grabados a US$ 5 por millón, US$ 0,085, contra US$ 0,0034 para releer el mismo bloque. La diferencia entre los dos es lo que separa piso de cola.

¿Por qué el análisis usa mediana y no promedio?

Porque la distribución de costo por sesión tiene cola larga: una sesión que recorre un monorepo entero empuja el promedio hacia arriba y describe mal la sesión típica. La mediana responde la pregunta que hace el presupuesto, que es cuánto cuesta la sesión que el equipo repite.

¿La prueba controlada de corrección de errores puede convertirse en base de presupuesto?

No puede. Corrió en un proyecto pequeño, con caché caliente, y quedó por debajo de las medianas de la tabla. Sirve para comparar configuraciones entre sí, con el mismo repositorio y la misma tarea, y no para dimensionar el gasto de un equipo con repositorios de tamaños distintos.

Referencias y cómo citar este análisis

Para citar el conjunto: NEXFORCE. Costo por sesión de agente de código: dónde se dispara la cuenta. Nexforce Blog, 6 de noviembre de 2026. Al citar un número aislado, cite la franja de duración junto, porque la mediana de 1 turno y la de 10 a 49 turnos no son la misma estadística, y cambiar una por la otra cambia el argumento de quien cita.

La tabla se recopila de nuevo cada trimestre, con la misma ventana de 30 días y las mismas tres franjas. La próxima revisión cierra en enero de 2027, y los múltiplos se recalcularán sobre los nuevos puntos, porque precio de modelo y política de caché se mueven más rápido que cualquier hoja de cálculo de presupuesto.

El número cambia cada trimestre. La pregunta que responde, cuánto cuesta una sesión que termina, no cambia.

Próximo paso: medir la propia sesión

El próximo paso es medir la sesión que el equipo repite, con el costo por sesión visible en Nexforce Router, y comparar el número con la banda de duración correspondiente de este análisis.