A semana em que o custo real de rodar agentes apareceu no extrato — e ele não é o preço do token: é o harness, a rede elétrica e o lugar onde a inferência acontece.
Quatro meses.
Foi o tempo que a Uber levou para queimar o orçamento anual inteiro de ferramentas de IA de código. Cinco mil engenheiros, Claude Code, e nenhuma linha de custo auditando o harness.
Esta é a ai|expert Edition. A semana em que a conta real dos agentes apareceu no extrato — e o culpado não foi o preço do token.
Em fevereiro deste ano, 32% dos engenheiros da Uber usavam Claude Code. Em março, 84%. Na primavera, a taxa de uso mensal ativo chegou a 95%. O CTO Praveen Neppalli Naga confirmou ao The Information: o orçamento de 2026 para ferramentas de IA de código foi consumido em quatro meses. [ref: optimizing-coding-agent-costs-]
O custo médio por engenheiro era de 150 a 250 dólares mensais. Usuários pesados chegavam a 500 a 2.000 dólares. O próprio Naga gastou 1.200 dólares em uma única sessão de duas horas. Mas o detalhe mais revelador não é esse número. É o mecanismo que gerou o problema: a Uber criou um ranking interno que classificava engenheiros pelo volume de uso do Claude Code.
Um leaderboard de tokens. Uma métrica de produtividade que é, na prática, um incentivo direto para queimar orçamento.
Desde então, a empresa impôs um teto de 1.500 dólares por mês por funcionário por ferramenta de agentes de código. A Salesforce estima gastar 300 milhões de dólares com Anthropic apenas neste ano — para uma força de 15.000 engenheiros. E a divisão Experiences and Devices da Microsoft cancelou as licenças diretas de Claude Code até 30 de junho, redirecionando todos os engenheiros para o GitHub Copilot CLI.
O que está acontecendo aqui não é um problema de preço de modelo. É um problema de visibilidade.
A LangChain diagnosticou isso como tokenmaxxing — usar volume de tokens como proxy de produtividade — combinado com fragmentação de ferramentas. Uma única feature pode passar por Claude Code, Cursor e GitHub Copilot Chat. Cada ferramenta emite telemetria incompatível. Sem normalização, é impossível comparar custo entre ferramentas ou atribuir gasto a modelo, harness ou gerenciamento de contexto. Dashboards nativos simplesmente falham quando você tem múltiplas ferramentas.
E a Databricks foi mais longe. Eles buildaram um benchmark interno no próprio codebase de múltiplos milhões de linhas — Python, Go, TypeScript, Scala, Rust, Java, Bazel, Protobuf — usando PRs reais, revisados manualmente para evitar os problemas de vazamento de dados de treino que contaminam o SWE-Bench e o TerminalBench. [ref: databricks-benchmarks-coding-a]
O resultado é o dado mais importante desta semana.
O Sonnet 5 é 1,7 vezes mais barato por token que o Opus 4.8. E ainda assim custou mais por tarefa: 2,09 dólares contra 1,94. Porque consumiu 1,9 vezes mais tokens para completar o mesmo trabalho. E completou apenas 81% das tarefas, contra 87% do Opus. O preço por token é uma métrica decoy.
O GLM 5.2, por outro lado, empatou estatisticamente com o Opus 4.8 em qualidade — e custou 1,28 dólares por tarefa, contra 1,94.
Mas o dado que muda a arquitetura de verdade é o harness. A Databricks rodou o mesmo modelo através de harnesses diferentes — Pi versus Claude Code e Codex. Qualidade idêntica. Custo mais que o dobro nos harnesses mais pesados. O Pi enviava aproximadamente três vezes menos contexto por turno, gerenciava a janela de contexto com mais rigor, e completava as tarefas em menos rodadas.
O harness pode dobrar o custo sem tocar na qualidade. Isso significa que a maioria das equipes está perdendo dinheiro nas configurações padrão — não porque escolheu o modelo errado, mas porque nunca auditou quanto contexto o harness envia em cada turno.
É exatamente isso que o blueprint NemoClaw da LangChain com NVIDIA endereça. A combinação de Nemotron 3 Ultra com o harness Deep Agents Code atingiu 0,86 de score na suite de avaliação interna da LangChain — com custo de 4,48 dólares por rodada, contra 43,48 dólares do próximo modelo de melhor desempenho. Redução de 10 vezes. Sem nenhum retreinamento. Cada ganho veio de engenharia do ambiente em volta do modelo: system prompts, descrições de ferramentas, middleware. [ref: langchain-nvidia-deep-agents-b]
O caso de uso-alvo do NemoClaw é instrutivo: modernização de COBOL. Um assistente de código comprometido por injeção de prompt pode reescrever lógica de negócio ou exfiltrar código-fonte em escala industrial. O harness é onde a governança começa — antes do modelo, não depois.
E o lado da oferta também se moveu. A Together AI lançou Provisioned Throughput Units — PTUs — a 0,05 dólares por PTU por minuto, com SLA de 99% de uptime. No MiniMax M3, um PTU entrega 138.840 tokens de entrada por minuto. Em utilização plena, isso equivale a 0,36 dólares por milhão de tokens de entrada — contra 5 dólares no Claude Opus 4.8. Clientes migrando de APIs proprietárias para modelos abertos relatam redução de 6 a 20 vezes no custo de inferência. [ref: together-ai-launches-provision]
O volume da Together AI cresceu de 30 bilhões para mais de 400 trilhões de tokens por mês em nove meses. Esse número sozinho é um sinal de mercado.
Com uma ressalva que precisa estar no modelo financeiro: PTUs faturam continuamente — aproximadamente 2.160 dólares por mês. Capacidade ociosa eleva o custo efetivo por token imediatamente. O 99% de SLA permite quase 8,7 horas de downtime por mês. Tokens de entrada, entrada em cache e saída consomem PTUs em taxas diferentes, complicando a previsão de gasto para tráfego variável. Não é serverless. Não é dedicado. É um compromisso de throughput que pressupõe workloads de produção estáveis o suficiente para manter os PTUs perto da utilização total.
A lição do primeiro bloco é direta: o preço do token é a linha mais visível da conta, mas raramente a maior. O harness, o contexto por turno, o modelo de comprometimento de capacidade — esses são os multiplicadores que nenhuma planilha de ROI de agente captura por padrão.
Duzentos e cinquenta e oito terawatts-hora.
É o que servidores otimizados para IA vão consumir em 2027, segundo projeções da Gartner. Para colocar esse número em perspectiva: em 2025, eram 95 terawatts-hora. Em 2026, 175 — crescimento de 84% em um ano. Em 2027, pela primeira vez na história, hardware de IA vai consumir mais energia do que todos os servidores convencionais do mundo combinados.
O consumo global de data centers vai chegar a 565 terawatts-hora neste ano — crescimento de 26% sobre 2025. Os sistemas de resfriamento sozinhos vão consumir 195 terawatts-hora em 2026. Quase o mesmo que todos os servidores tradicionais do planeta. Servidores de IA representarão 31% do consumo total de data centers neste ano, ante aproximadamente 20% em 2025. [ref: ai-servers-will-dominate-data-]
E os EUA concentram 204 dos 565 terawatts-hora totais — 36% do consumo global. Dos quais, data centers dedicados a IA respondem por 68 terawatts-hora, ou um terço do total americano. A Gartner é direta: disponibilidade de energia é a restrição vinculante no crescimento de IA. Mais de 75 projetos de data centers avaliados em 130 bilhões de dólares foram bloqueados no início de 2026 por disputas de acesso a energia e água.
E aí Oregon entra na equação.
A Oregon Public Utility Commission aprovou um aumento de 29,7% na tarifa elétrica para clientes da Portland General Electric que consomem mais de 20 megawatts — em linha com o POWER Act do estado. Facilidades acima desse limiar agora precisam assinar contratos de 10 a 30 anos, pagar depósitos por novos serviços, e comprometer 90% da demanda contratada independentemente do consumo real. [ref: oregons-30-data-center-power-s]
Noventa por cento de take-or-pay. Isso elimina qualquer economia de escalar para baixo frotas de inferência em períodos de baixo tráfego. E se você consumir acima do planejado, as penalidades são 1,5 vezes o custo de energia e 4 vezes o custo de transmissão.
Oregon tem mais de 135 data centers. A PGE investiu 210 milhões de dólares em expansão de rede em Hillsboro. Um campus de 250 megawatts agora precisa comprometer pagamento por aproximadamente 225 megawatts de fornecimento base — independentemente da utilização de GPU. Um pico de treinamento acima do planejado ativa penalidades de transmissão que podem destruir a previsão de orçamento de um ciclo inteiro.
A AWS e a Data Center Coalition já avisaram que esse regime vai empurrar novos builds para outros estados. Montana oferece tratamento tributário favorável com o HB 424. Washington está avaliando o impacto de grandes cargas na receita fiscal do estado. E o paralelo da PacifiCorp, com decisão esperada para novembro de 2026, pode estender regras similares para dois terços dos clientes de utilities de Oregon.
Do outro lado do Atlântico, o Reino Unido está tomando o caminho oposto.
O parlamento britânico aprovou em novembro de 2025 uma emenda que adiciona data centers ao regime de Nationally Significant Infrastructure Projects — o NSIP. Sob esse regime, desenvolvedores aplicam diretamente ao Secretário de Estado. Uma única aprovação consolida licença de planejamento, aquisição compulsória, obras viárias e consentimentos auxiliares em um único instrumento. [ref: uk-data-centers-get-national-i]
O Ministry of Housing, Communities, and Local Government estima que a mudança pode reduzir o processo de aprovação em até um ano e economizar até 1,3 bilhão de dólares por projeto. O governo está explorando se consegue cortar os tempos de aprovação NSIP de 18 meses em média para 12 — contra um processo padrão que tem levado até quatro anos. Mais de 80 projetos já entraram no pipeline de pré-aplicação do Planning Inspectorate. Três já têm classificação NSIP.
Mas o NSIP status não garante subestação, conexão à rede elétrica, nem água para resfriamento. A National Policy Statement que define os limites de elegibilidade ainda não foi publicada. Qualquer modelo de capex que assume aceleração NSIP está apostando em um threshold que não existe no papel ainda.
O que Oregon e o Reino Unido mostram juntos é que "compute" não pode mais ser uma linha única no orçamento de três anos. Oregon trava você em contratos de 10 anos com penalidades de 4 vezes no custo de transmissão por picos imprevistos. O Reino Unido pode oferecer aprovação em 12 meses — mas só para projetos grandes o suficiente para se qualificarem como infraestrutura nacional.
A arbitragem geográfica — escolher onde rodar inferência com base no custo de energia — virou um cálculo de sobrevivência. E o prazo para assegurar acordos de interconexão e redesenhar facilidades para resfriamento líquido está diminuindo.
Se os dois primeiros blocos mostram que o custo de rodar agentes está nas camadas que ficam em volta do modelo — harness, contrato de energia, comprometimento de capacidade — o terceiro mostra onde a inferência em si está migrando. E ela está saindo da API.
Três destinos novos aparecem esta semana com dados de produção: dentro do banco de dados PostgreSQL, no sandbox stateful de 300 milhões de dólares em ARR da Modal, e na CPU que a NVIDIA lançou especificamente para orquestração de agentes.
Começa com o AlloyDB. O Google levou a GA no PostgreSQL 17 um conjunto completo de funções de IA — ai.generate, ai.summarize, ai.if, ai.rank, ai.forecast — com uma camada de aceleração que muda a matemática de inferência em tabelas de alta cardinalidade. [ref: alloydb-introduces-local-infer]
O número de referência é 23.000 vezes. É o ganho de throughput que o Google reporta em testes internos ao comparar chamadas de API linha por linha com o modelo proxy local do AlloyDB para o ai.if. A versão mais conservadora — smart batching em GA — já entrega 2.400 vezes de melhoria sobre o baseline de row-at-a-time, processando 10.000 linhas por segundo. O modelo proxy chega a 100.000 linhas por segundo com 6.000 vezes de redução de custo.
Como funciona: uma instrução PREPARE envia uma amostra dos dados para um modelo frontier no Vertex AI, que treina um modelo proxy ultra-leve dentro do banco. As queries passam a rodar contra esse proxy em velocidade de banco de dados. Quando a confiança do proxy cai abaixo do threshold, o AlloyDB reverte para o LLM remoto.
O resultado prático: 100.000 linhas por segundo para filtros semânticos, sem 100.000 round trips para a API. Para workloads de filtro semântico em tabelas de produto, logs ou dados de comportamento de usuário, isso muda a equação de latência e custo de forma fundamental.
Mas com uma ressalva crítica: esses números são de testes internos do Google, aplicam-se especificamente ao ai.if em preview, não ao catálogo completo de funções. O Google não divulgou custo absoluto por token, latência p50 ou p99 no caminho de fallback, nem GPU-hours necessários durante o PREPARE. O proxy precisa de suítes de regressão customizadas para medir drift por domínio. O arquiteto Raimundas Juodvalkis da Starburst recomenda: trate essas funções como extensões de banco de dados governadas, não como cláusulas WHERE mágicas. Comece com workflows read-heavy antes de escrever campos derivados de modelo de volta em sistemas core.
Do banco de dados para o sandbox. A Modal fechou uma Série C de 355 milhões de dólares, avaliada em 4,65 bilhões, liderada por General Catalyst e Redpoint Ventures. O que importa mais que o funding é o mix de receita: sandboxes já respondem por mais de um terço dos 300 milhões de dólares em ARR da empresa. Mais de um bilhão de sandboxes foram lançados na plataforma até hoje. [ref: modal-cto-on-agent-workload-in]
Esse número é uma mudança de paradigma. Significa que workloads de agentes — loops stateful de multi-step, tool-calling, execução de código não confiável, inspeção de output, retry — se tornaram o driver dominante de infraestrutura de IA. Superando inferência stateless.
O CTO Akshat Bubna explica por quê no podcast Latent Space: Kubernetes foi projetado para ciclos de request/response HTTP. Agentes precisam escrever código, mutar estado de ambiente, e iterar em loops de feedback apertados. A Modal construiu uma stack Rust do zero — filesystem customizado, container runtime, scheduler, GPU memory snapshotting — acessível através de decoradores Python que integram funções serverless, sandboxes, inferência elástica com decodificação especulativa, containers em rede e RDMA em um plano de controle unificado.
GPU snapshotting melhorou cold starts em 100 vezes. Rollouts de RL chegaram a 100.000 sandboxes em paralelo. O Ramp relata que o agente de código Inspect escreve 70% dos PRs que chegam a merge na plataforma. A Lovable processou 250.000 criações de app em um único fim de semana usando mais de um milhão de sandboxes.
A ARR cresceu aproximadamente cinco vezes desde setembro de 2025. Esse é o sinal de que workloads de agente saíram do experimental para produção.
E há um problema operacional que emerge dessa escala: quando agentes escrevem o código, observabilidade fica mais difícil do que revisão de código. Debugar artefatos gerados por agente através de dashboards tradicionais não escala. A Modal promete RBAC granular para escopo de capacidades de agentes — mas ainda está por vir.
No nível mais baixo da stack — a CPU que orquestra o sandbox — a NVIDIA lançou a Vera. Oitenta e oito núcleos monolíticos. Core Olympus, design out-of-order de 10 vias com suporte SVE2 FP8. Dois megabytes de L2 privado por núcleo. Cache L3 unificado de 162 a 164 megabytes. Bandwidth de memória LPDDR5X de 1,2 terabytes por segundo a menos de 40 watts. Bandwidth core-a-core de 3,4 terabytes por segundo — três vezes mais que qualquer CPU de data center x86. [ref: nvidia-vera-maximizing-single-]
A Perplexity rodou um workflow real na Vera: clonar um repositório e executar a suíte de testes em sandboxes. Resultado: 1,5 vezes mais rápido que x86. Spin-up de sandboxes concorrentes: 1,9 vezes mais rápido.
O fundador da Phoronix, Michael Larabel, descreveu a Vera como a CPU de servidor não-x86 mais competitiva que ele já testou — 63% de melhoria geomédica sobre o Grace anterior da NVIDIA e 55% sobre o Xeon 6980P de 128 núcleos da Intel. A NVIDIA afirma 40% de redução na latência pico carregada versus x86, e o Vera CPU Rack entrega mais de 4 vezes a capacidade e duas vezes a performance por watt de racks de servidor x86.
A lógica é direta: agentes gastam mais tempo orquestrando sandboxes e esperando por memória do que dentro de uma camada transformer. A CPU monolítica com bandwidth uniforme elimina os saltos NUMA dos chiplets e os cliffs de performance quando threads transbordam entre domínios. Se a sua stack de agentes ainda é dominada por forward passes de modelos grandes, os ganhos da Vera não mudam a economia de unidade. Mas se você roda sandboxes de código, tool calls e recuperação de dados intensivos, a CPU do host virou o gargalo.
Com a ressalva operacional que não pode ficar de fora: binários otimizados exigem GCC 16.1 ou LLVM Clang 21 ou mais recente. Containers x86 e bibliotecas existentes não são compatíveis. Para quem roda COBOL, .NET legado, ou qualquer toolchain Windows-based, isso significa nós worker Linux separados ou upgrades de kernel antes de migrar para Vera. A Vera já está em produção na CoreWeave, Lambda e Oracle Cloud Infrastructure. Disponibilidade ampla de OEM — Dell, HPE, Lenovo, Supermicro — está prevista para o segundo semestre de 2026.
E os três destinos — banco de dados, sandbox stateful, CPU de orquestração — têm um denominador comum que o NemoClaw torna explícito: a superfície de ataque cresce junto com a complexidade de execução.
Quando a inferência entra no processo do banco de dados, ou o agente executa código em um sandbox, ou a CPU roda scoring quantizado sem cruzar o fabric PCIe — o perímetro de segurança deixa de ser a borda da API. Ele é o processo em si. O NemoClaw resolve isso com enforcement fora do processo. [ref: langchain-deep-agents-on-nvidi]
O OpenShell usa Landlock LSM e Seccomp BPF para bloquear filesystem, rede e políticas de processo na criação do sandbox. Credenciais ficam com o NemoClaw — fora do sandbox. Egress de rede negado por padrão a menos que aprovado por request. Cada sessão gera um snapshot de auditoria armazenado fora do processo do agente. A identidade root é sempre rejeitada.
A lógica é elegante: se o agente não pode acessar seus próprios controles, ele não pode desabilitá-los. Um agente comprometido por injeção de prompt chega até a parede do sandbox — não passa dela.
Mas o Futurum Group aponta o limite: o OpenShell cobre só o fim da cadeia de confiança — a execução em runtime. Governança upstream — seleção de modelo, classificação de dados, proveniência de skills — ainda depende do que sua equipe construiu antes do runtime. A imagem comprimida do sandbox tem aproximadamente 2,4 gigabytes e exige Ubuntu 22.04 ou mais recente com Docker e Node.js 20+. Hosts de container mais antigos e toolchains Windows — comuns em projetos de modernização de COBOL e .NET — precisarão de upgrades ou nós worker Linux separados.
O blueprint está disponível no GitHub sob licença Apache 2.0. Trate a versão atual como target de avaliação, não como runtime de produção.
O fio que conecta os três blocos desta edição é visibilidade. Custo que você não mede — no harness, no contrato de energia, na cold start do sandbox — é custo que você não controla.
Quando o COO da Uber, Andrew Macdonald, disse à Fortune que a ligação entre gasto crescente em IA e features úteis para o consumidor "não está lá ainda", ele estava descrevendo exatamente o que acontece quando a conta aparece sem o instrumento certo para lê-la.
Três takeaways desta edição: primeiro, construa seu próprio benchmark em PRs reais do seu codebase — preço por token é uma métrica decoy e o harness pode dobrar o custo sozinho. Segundo, trate contratos de energia como reserved instances com penalidades de overage severas — não como compute metered em nuvem. Terceiro, a inferência está migrando para dentro do banco de dados, para sandboxes stateful e para CPUs de orquestração — cada um com um trade-off de segurança que precisa de enforcement fora do processo.
A conta dos agentes ficou visível esta semana — e ela tem três linhas que nenhuma planilha de ROI captura por padrão: o harness que envia contexto demais, o contrato de energia que pune picos de treino com 4 vezes o custo de transmissão, e o sandbox que precisa de CPU monolítica para não virar gargalo. Wire na segunda abre com o Grok 4.5 entrando na tier Opus a 2,49 dólares por tarefa — e a nova guerra de preços que isso destrava. Boa semana.