La semana en que el costo real de ejecutar agentes apareció en el estado de cuenta — y no es el precio del token: es el harness, el contrato de energía y dónde ocurre la inferencia.
Cuatro meses.
Fue el tiempo que le tomó a Uber quemar el presupuesto anual completo de herramientas de IA de codificación. Cinco mil ingenieros, Claude Code, y ninguna línea auditando el harness.
Esta es la Edición ai|expert. La semana en que el costo real de los agentes apareció en el estado de cuenta — y el culpable no fue el precio del token.
En febrero de este año, el 32% de los ingenieros de Uber usaban Claude Code. En marzo, 84%. En primavera, el uso activo mensual llegó al 95%. El CTO Praveen Neppalli Naga confirmó al The Information: el presupuesto de 2026 de Uber para herramientas de IA de codificación se consumió en cuatro meses. [ref: optimizing-coding-agent-costs-]
El costo promedio por ingeniero era de 150 a 250 dólares mensuales. Los usuarios pesados llegaban a 500 a 2.000 dólares. El propio Naga gastó 1.200 dólares en una única sesión de dos horas. Pero el detalle más revelador no es ese número. Es el mecanismo que generó el problema: Uber creó un ranking interno clasificando a los ingenieros por volumen de uso de Claude Code.
Un leaderboard de tokens. Una métrica de productividad que es, en la práctica, un incentivo directo para quemar presupuesto.
Desde entonces, la empresa impuso un techo de 1.500 dólares por mes por empleado por herramienta de agentes de código. Salesforce estima gastar 300 millones de dólares con Anthropic solo este año — para una fuerza de 15.000 ingenieros. Y la división Experiences and Devices de Microsoft canceló las licencias directas de Claude Code hasta el 30 de junio, redirigiendo todos los ingenieros a GitHub Copilot CLI.
Lo que está sucediendo aquí no es un problema de precio de modelo. Es un problema de visibilidad.
LangChain diagnosticó esto como tokenmaxxing — usar volumen de tokens como proxy de productividad — combinado con fragmentación de herramientas. Una sola feature puede pasar por Claude Code, Cursor y GitHub Copilot Chat. Cada herramienta emite telemetría incompatible. Sin normalización, es imposible comparar costo entre herramientas o atribuir gasto a modelo, harness o gestión de contexto. Los dashboards nativos simplemente fallan cuando tienes múltiples herramientas.
Y Databricks fue más lejos. Construyeron un benchmark interno en su propio codebase de millones de líneas — Python, Go, TypeScript, Scala, Rust, Java, Bazel, Protobuf — usando PRs reales, revisados manualmente para evitar los problemas de filtración de datos de entrenamiento que contaminan SWE-Bench y TerminalBench. [ref: databricks-benchmarks-coding-a]
El resultado es el dato más importante de esta semana.
Sonnet 5 es 1,7 veces más barato por token que Opus 4.8. Y aún así costó más por tarea: 2,09 dólares contra 1,94. Porque consumió 1,9 veces más tokens para completar el mismo trabajo. Y completó solo el 81% de las tareas, contra 87% del Opus. El precio por token es una métrica engañosa.
GLM 5.2, por otro lado, empató estadísticamente con Opus 4.8 en calidad — y costó 1,28 dólares por tarea, contra 1,94.
Pero el dato que realmente cambia la arquitectura es el harness. Databricks ejecutó el mismo modelo a través de diferentes harnesses — Pi versus Claude Code y Codex. Calidad idéntica. Costo más del doble en los harnesses más pesados. Pi enviaba aproximadamente tres veces menos contexto por turno, gestionaba la ventana de contexto con más rigor, y completaba las tareas en menos rondas.
El harness puede doblar el costo sin tocar la calidad. Esto significa que la mayoría de los equipos están perdiendo dinero en configuraciones predeterminadas — no porque eligieron el modelo equivocado, sino porque nunca auditaron cuánto contexto envía el harness en cada turno.
Es exactamente lo que aborda el blueprint NemoClaw de LangChain con NVIDIA. La combinación de Nemotron 3 Ultra con el harness Deep Agents Code logró 0,86 en la suite de evaluación interna de LangChain — con un costo de 4,48 dólares por iteración, contra 43,48 dólares del modelo de mejor desempeño siguiente. Una reducción de 10 veces. Sin ningún reentrenamiento. Cada ganancia vino de ingeniería del entorno alrededor del modelo: prompts del sistema, descripciones de herramientas, middleware. [ref: langchain-nvidia-deep-agents-b]
El caso de uso objetivo del NemoClaw es instructivo: modernización de COBOL. Un agente de código comprometido por inyección de prompt puede reescribir lógica de negocio o exfiltrar código fuente a escala industrial. El harness es donde comienza la gobernanza — antes del modelo, no después.
Y el lado de la oferta también se movió. Together AI lanzó Provisioned Throughput Units — PTUs — a 0,05 dólares por PTU por minuto, con SLA de 99% de disponibilidad. En MiniMax M3, un PTU entrega 138.840 tokens de entrada por minuto. Con utilización completa, eso equivale a 0,36 dólares por millón de tokens de entrada — contra 5 dólares en Claude Opus 4.8. Los clientes que migran de APIs propietarias a modelos abiertos reportan reducciones de 6 a 20 veces en costo de inferencia. [ref: together-ai-launches-provision]
El volumen de Together AI creció de 30 mil millones a más de 400 trillones de tokens por mes en nueve meses. Ese número solo es una señal de mercado.
Con una salvedad que necesita estar en tu modelo financiero: las PTUs se facturan continuamente — aproximadamente 2.160 dólares por mes. La capacidad ociosa aumenta el costo efectivo por token inmediatamente. El SLA del 99% permite casi 8,7 horas de tiempo de inactividad por mes. Los tokens de entrada, entrada en caché y salida consumen PTUs a diferentes tasas, complicando la previsión de gastos para tráfico variable. No es sin servidor. No es dedicado. Es un compromiso de rendimiento que asume cargas de trabajo de producción lo suficientemente estables para mantener las PTUs cerca de utilización completa.
La lección del primer segmento es directa: el precio del token es la línea más visible en la factura, pero rara vez la más grande. El harness, contexto por turno, modelo de compromiso de capacidad — esos son los multiplicadores que ninguna hoja de cálculo de ROI de agentes captura por defecto.
Doscientos cincuenta y ocho terawatios-hora.
Es lo que los servidores optimizados para IA consumirán en 2027, según proyecciones de Gartner. Para poner ese número en perspectiva: en 2025, eran 95 terawatios-hora. En 2026, 175 — crecimiento del 84% en un año. En 2027, por primera vez en la historia, el hardware de IA consumirá más energía que todos los servidores convencionales del mundo combinados.
El consumo global de centros de datos llegará a 565 terawatios-hora este año — crecimiento del 26% sobre 2025. Los sistemas de enfriamiento solos consumirán 195 terawatios-hora en 2026. Casi lo mismo que todos los servidores tradicionales del planeta. Los servidores de IA representarán el 31% del consumo total de centros de datos este año, ante aproximadamente 20% en 2025. [ref: ai-servers-will-dominate-data-]
Y EE.UU. concentra 204 de esos 565 terawatios-hora totales — 36% del consumo global. De los cuales, los centros de datos dedicados a IA representan 68 terawatios-hora, o un tercio del total estadounidense. Gartner es directo: la disponibilidad de energía es la restricción vinculante en el crecimiento de IA. Más de 75 proyectos de centros de datos valorados en 130 mil millones de dólares fueron bloqueados a principios de 2026 por disputas de acceso a energía y agua.
Y ahí es donde Oregon entra en la ecuación.
La Comisión de Servicios Públicos de Oregon aprobó un aumento del 29,7% en la tarifa eléctrica para clientes de Portland General Electric que consumen más de 20 megawatios — en línea con la POWER Act del estado. Las instalaciones por encima de ese umbral ahora necesitan firmar contratos de 10 a 30 años, pagar depósitos para nuevo servicio, y comprometer el 90% de la demanda contratada independientemente del consumo real. [ref: oregons-30-data-center-power-s]
Noventa por ciento de take-or-pay. Esto elimina cualquier ahorro de reducir flotas de inferencia durante períodos de bajo tráfico. Y si consumes por encima de lo planificado, las penalizaciones son 1,5 veces el costo de energía y 4 veces el costo de transmisión.
Oregon tiene más de 135 centros de datos. PGE invirtió 210 millones de dólares en expansión de red en Hillsboro. Un campus de 250 megawatios ahora necesita comprometer pago por aproximadamente 225 megawatios de suministro base — independientemente de la utilización de GPU. Un pico de entrenamiento por encima de lo planificado activa penalizaciones de transmisión que pueden destruir el pronóstico de presupuesto de un ciclo completo.
AWS y la Data Center Coalition ya advirtieron que este régimen empujará nuevas construcciones a otros estados. Montana ofrece trato fiscal favorable con HB 424. Washington está evaluando el impacto de grandes cargas en los ingresos fiscales del estado. Y la decisión paralela de PacifiCorp, esperada para noviembre de 2026, podría extender reglas similares a dos tercios de los clientes de servicios públicos de Oregon.
Al otro lado del Atlántico, el Reino Unido está tomando el camino opuesto.
El Parlamento británico aprobó en noviembre de 2025 una enmienda que añade centros de datos al régimen de Nationally Significant Infrastructure Projects — el NSIP. Bajo ese régimen, los desarrolladores presentan solicitud directamente al Secretario de Estado. Una única aprobación consolida licencia de planificación, adquisición compulsoria, obras viales y consentimientos auxiliares en un solo instrumento. [ref: uk-data-centers-get-national-i]
El Ministry of Housing, Communities, and Local Government estima que el cambio podría reducir los plazos de aprobación en hasta un año y ahorrar hasta 1,3 mil millones de dólares por proyecto. El gobierno está explorando si puede cortar los tiempos promedio de aprobación NSIP de 18 meses a 12 — contra un proceso estándar que ha tomado hasta cuatro años. Más de 80 proyectos ya entraron en el pipeline de pre-solicitud del Planning Inspectorate. Tres ya tienen clasificación NSIP.
Pero el estado NSIP no garantiza subestación, conexión a la red eléctrica, ni agua para enfriamiento. La National Policy Statement que define los umbrales de elegibilidad aún no ha sido publicada. Cualquier modelo de capex que asuma aceleración NSIP está apostando por un umbral que aún no existe en el papel.
Lo que Oregon y el Reino Unido muestran juntos es que el compute ya no puede ser una sola línea en un presupuesto de tres años. Oregon te encierra en contratos de 10 años con penalizaciones de 4 veces el costo de transmisión por picos imprevistos. El Reino Unido podría ofrecer aprobación en 12 meses — pero solo para proyectos lo suficientemente grandes como para calificar como infraestructura nacional.
El arbitraje geográfico — elegir dónde ejecutar inferencia basado en el costo de energía — se convirtió en un cálculo de supervivencia. Y el plazo para asegurar acuerdos de interconexión y rediseñar instalaciones para enfriamiento líquido se está reduciendo.
Si los dos primeros segmentos muestran que los costos de ejecutar agentes viven en las capas alrededor del modelo — harness, contrato de energía, compromiso de capacidad — el tercero muestra adónde se está migrando la inferencia en sí. Y se está saliendo del API.
Tres nuevos destinos aparecen esta semana con datos de producción: dentro de PostgreSQL, en el sandbox sin estado de 300 millones de dólares en ARR de Modal, y en la CPU que NVIDIA lanzó específicamente para orquestación de agentes.
Comienza con AlloyDB. Google llevó a GA en PostgreSQL 17 un conjunto completo de funciones de IA — ai.generate, ai.summarize, ai.if, ai.rank, ai.forecast — con una capa de aceleración que cambia las matemáticas de inferencia en tablas de alta cardinalidad. [ref: alloydb-introduces-local-infer]
El número de referencia es 23.000 veces. Es la ganancia de rendimiento que Google reporta en pruebas internas al comparar llamadas de API línea por línea con el modelo proxy local de AlloyDB para ai.if. La versión más conservadora — smart batching en GA — ya entrega 2.400 veces de mejora sobre el baseline row-at-a-time, procesando 10.000 filas por segundo. El modelo proxy alcanza 100.000 filas por segundo con 6.000 veces de reducción de costo.
Cómo funciona: una sentencia PREPARE envía una muestra de tus datos a un modelo frontier en Vertex AI, que entrena un modelo proxy ultra-ligero dentro de la base de datos. Las queries luego se ejecutan contra ese proxy a velocidad de base de datos. Cuando la confianza del proxy cae por debajo del umbral, AlloyDB revierte al LLM remoto.
El resultado práctico: 100.000 filas por segundo para filtros semánticos, sin 100.000 viajes redondos al API. Para cargas de trabajo de filtro semántico en tablas de producto, logs o datos de comportamiento del usuario, esto cambia fundamentalmente la ecuación de latencia y costo.
Pero con una salvedad crítica: estos números son de pruebas internas de Google, aplican específicamente a ai.if en preview, no al catálogo completo de funciones. Google no ha revelado el costo absoluto por token, latencia p50 o p99 en la ruta de fallback, ni GPU-hours necesarias durante PREPARE. El proxy necesita suites de regresión customizadas para medir drift por dominio. Raimundas Juodvalkis, arquitecto de Starburst, recomienda: trata estas funciones como extensiones de base de datos gobernadas, no como cláusulas WHERE mágicas. Comienza con flujos de trabajo read-heavy antes de escribir campos derivados de modelo de vuelta en sistemas core.
De la base de datos al sandbox. Modal cerró una Serie C de 355 millones de dólares, valorada en 4,65 mil millones, liderada por General Catalyst y Redpoint Ventures. Lo que importa más que la financiación es la mezcla de ingresos: los sandboxes ya representan más de un tercio de los 300 millones de dólares en ARR de la empresa. Más de mil millones de sandboxes se han lanzado en la plataforma hasta la fecha. [ref: modal-cto-on-agent-workload-in]
Ese número es un cambio de paradigma. Significa que las cargas de trabajo de agentes — loops sin estado multi-paso, tool-calling, ejecución de código no confiable, inspección de output, retry — se convirtieron en el driver dominante de infraestructura de IA. Superando la inferencia sin estado.
El CTO Akshat Bubna explica por qué en el podcast Latent Space: Kubernetes fue diseñado para ciclos HTTP request/response. Los agentes necesitan escribir código, mutar estado del entorno, e iterar en loops de feedback apretados. Modal construyó una stack Rust desde cero — filesystem customizado, container runtime, scheduler, GPU memory snapshotting — accesible a través de decoradores Python que integran funciones serverless, sandboxes, inferencia elástica con decodificación especulativa, contenedores en red y RDMA en un plano de control unificado.
El GPU snapshotting mejoró cold starts en 100 veces. Los rollouts de RL llegaron a 100.000 sandboxes en paralelo. Ramp reporta que su agente de código Inspect escribe el 70% de los PRs que llegan a merge en su plataforma. Lovable procesó 250.000 creaciones de app en un único fin de semana usando más de un millón de sandboxes.
El ARR creció aproximadamente cinco veces desde septiembre de 2025. Esa es la señal de que las cargas de trabajo de agentes migraron de experimental a producción.
Y hay un problema operacional que surge a esa escala: cuando los agentes escriben código, la observabilidad se vuelve más difícil que la revisión de código. Debuggear artefactos generados por agente a través de dashboards tradicionales no escala. Modal promete RBAC granular para alcance de capacidades de agentes — pero aún está por venir.
Al nivel más bajo de la stack — la CPU que orquesta el sandbox — NVIDIA lanzó la Vera. Ochenta y ocho núcleos monolíticos. Core Olympus, diseño out-of-order de 10 vías con soporte SVE2 FP8. Dos megabytes de L2 privado por núcleo. Caché L3 unificado de 162 a 164 megabytes. Ancho de banda de memoria LPDDR5X de 1,2 terabytes por segundo a menos de 40 watts. Ancho de banda core-a-core de 3,4 terabytes por segundo — tres veces más que cualquier CPU de centro de datos x86. [ref: nvidia-vera-maximizing-single-]
Perplexity ejecutó un flujo de trabajo real en Vera: clonar un repositorio y ejecutar la suite de pruebas en sandboxes. Resultado: 1,5 veces más rápido que x86. Spin-up de sandboxes concurrentes: 1,9 veces más rápido.
El fundador de Phoronix, Michael Larabel, describió a Vera como la CPU de servidor no-x86 más competitiva que ha probado — 63% de mejora geomédica sobre la anterior Grace de NVIDIA y 55% sobre el Xeon 6980P de 128 núcleos de Intel. NVIDIA afirma 40% de reducción en latencia pico cargada versus x86, y el Vera CPU Rack entrega más de 4 veces la capacidad y dos veces el desempeño por watt de racks de servidor x86.
La lógica es directa: los agentes gastan más tiempo orquestando sandboxes y esperando memoria que dentro de una capa transformer. Una CPU monolítica con ancho de banda uniforme elimina los saltos NUMA de los chiplets y los acantilados de desempeño cuando los threads desbordan entre dominios. Si tu stack de agentes aún está dominada por forward passes de modelos grandes, las ganancias de Vera no cambian la economía unitaria. Pero si ejecutas sandboxes de código, tool calls y recuperación intensiva de datos, la CPU del host se convirtió en el cuello de botella.
Con la salvedad operacional que no puede quedarse afuera: los binarios optimizados requieren GCC 16.1 o LLVM Clang 21 o más reciente. Los contenedores x86 y las bibliotecas existentes no son compatibles. Para quienes ejecutan COBOL, .NET legado, o cualquier toolchain basada en Windows, eso significa nodos worker Linux separados o upgrades de kernel antes de migrar a Vera. Vera ya está en producción en CoreWeave, Lambda y Oracle Cloud Infrastructure. La disponibilidad amplia de OEM — Dell, HPE, Lenovo, Supermicro — está prevista para el segundo semestre de 2026.
Y los tres destinos — base de datos, sandbox sin estado, CPU de orquestración — tienen un denominador común que NemoClaw hace explícito: la superficie de ataque crece junto con la complejidad de ejecución.
Cuando la inferencia entra en el proceso de la base de datos, o el agente ejecuta código en un sandbox, o la CPU ejecuta scoring cuantizado sin cruzar el fabric PCIe — el perímetro de seguridad deja de ser el borde del API. Es el proceso en sí. NemoClaw resuelve esto con enforcement fuera del proceso. [ref: langchain-deep-agents-on-nvidi]
OpenShell usa Landlock LSM y Seccomp BPF para bloquear filesystem, red y políticas de proceso en la creación del sandbox. Las credenciales quedan con NemoClaw — fuera del sandbox. Egreso de red negado por defecto a menos que sea aprobado por request. Cada sesión genera una snapshot de auditoría almacenada fuera del proceso del agente. La identidad root siempre es rechazada.
La lógica es elegante: si el agente no puede acceder a sus propios controles, no puede deshabilitarlos. Un agente comprometido por inyección de prompt llega a la pared del sandbox — no la cruza.
Pero Futurum Group señala el límite: OpenShell cubre solo el final de la cadena de confianza — la ejecución en runtime. La gobernanza upstream — selección de modelo, clasificación de datos, procedencia de skills — aún depende de lo que tu equipo construyó antes del runtime. La imagen comprimida del sandbox tiene aproximadamente 2,4 gigabytes y requiere Ubuntu 22.04 o más reciente con Docker y Node.js 20+. Los hosts de contenedor más antiguos y los toolchains Windows — comunes en proyectos de modernización de COBOL y .NET — necesitarán upgrades o nodos worker Linux separados.
El blueprint está disponible en GitHub bajo licencia Apache 2.0. Trata la versión actual como objetivo de evaluación, no como runtime de producción.
El hilo que conecta los tres segmentos de esta edición es visibilidad. El costo que no mides — en el harness, en el contrato de energía, en los cold starts del sandbox — es costo que no controlas.
Cuando el COO de Uber, Andrew Macdonald, le dijo a Fortune que el vínculo entre el gasto creciente en IA y features útiles para el consumidor "aún no está ahí", estaba describiendo exactamente lo que sucede cuando la factura llega sin el instrumento correcto para leerla.
Tres conclusiones de esta edición: primero, construye tu propio benchmark en PRs reales de tu codebase — el precio por token es una métrica engañosa y el harness puede doblar el costo solo. Segundo, trata los contratos de energía como reserved instances con penalizaciones de overage severas — no como compute facturado en nube. Tercero, la inferencia se está migrando a la base de datos, a sandboxes sin estado y a CPUs de orquestración — cada uno con un trade-off de seguridad que necesita enforcement fuera del proceso.
La cuenta de los agentes quedó visible esta semana — y tiene tres líneas que ninguna hoja de cálculo de ROI captura por defecto: el harness enviando demasiado contexto, el contrato de energía que castiga picos de entrenamiento con 4 veces el costo de transmisión, y el sandbox que necesita CPU monolítica para no convertirse en cuello de botella. Wire el lunes abre con Grok 4.5 entrando en la tier Opus a 2,49 dólares por tarea — y la nueva guerra de precios que desata. Buena semana.