Controlar os custos com IA virou um dos maiores desafios para empresas que já passaram da fase de experimentos e colocaram ferramentas de inteligência artificial no coração das suas operações de desenvolvimento.
A lógica parece simples no começo: você adota uma ferramenta de IA para o time de desenvolvimento, a produtividade dispara, todo mundo fica feliz. Aí vem a fatura. 😅
Na Databricks, o uso de agentes de codificação melhorou de forma mensurável todas as métricas de velocidade que a empresa acompanha, e em alguns times chegou a multiplicar a produção por dez. Só que junto com esse ganho gigante veio um problema que quase toda empresa que escalou IA enfrentou: custos crescendo de forma exponencial. Essa curva é insustentável. Se ninguém mexer nela, em algum momento ela ultrapassa a própria receita.
Esse é o paradoxo que empresas como Databricks, Stripe, Uber, Coinbase e Ramp descobriram na prática. De um lado, existe o desejo de empurrar a transformação com IA ao máximo e colocar ferramentas poderosas nas mãos dos funcionários. Do outro, existe a necessidade de conciliar isso com um perfil de custo agregado que ameaça minar, ou até reverter, os próprios ganhos de eficiência que a IA proporciona.
A boa notícia é que várias dessas empresas, entre as primeiras a adotar IA em larga escala, convergiram para um conjunto de estratégias que resolve esse quebra-cabeça. O objetivo ficou claro e ganhou até um nome: o mandato duplo. Ele significa oferecer acesso amplo às ferramentas de IA, com o mínimo de atrito possível, e ao mesmo tempo manter os gastos dentro de um envelope mais ou menos fixo por usuário. 🚀
O Problema Real Por Trás da Conta de IA
Antes de falar em solução, vale entender por que o problema aparece com tanta força e tão rapidamente. Quando uma empresa começa a usar IA de forma pontual, o impacto financeiro é quase invisível. Um time pequeno, algumas chamadas por dia, um modelo aqui e ali. O custo entra como uma linha discreta e ninguém audita com cuidado.
O problema real começa quando a adoção escala de verdade, quando dezenas ou centenas de desenvolvedores passam a depender dessas ferramentas no dia a dia. Quando um usuário digita um pedido simples num agente de codificação, algo como investigue e corrija esse bug, o agente sai coletando um volume enorme de contexto, invoca várias ferramentas, vasculha a base de código e integra informações e habilidades fornecidas pela empresa. Na hora em que a inferência cara do modelo de linguagem realmente acontece, o texto original do usuário representa uma fração mínima de tudo que foi jogado para dentro do sistema. Ou seja, o custo é dominado por contexto que o usuário nem incluiu de propósito.
A Fronteira de Eficiência Para Modelos de Código
A maior alavanca de custo de todas é migrar os gastos para modelos mais eficientes conforme eles são lançados. E aqui mora uma sutileza importante. No dia a dia, o termo modelo de fronteira costuma significar o modelo mais inteligente que existe, e os laboratórios de ponta focam em avançar esse pico de inteligência. Esses modelos já conseguem resolver problemas inéditos de matemática ou cibersegurança.
Só que, quando a IA é aplicada em larga escala, outro tipo de fronteira importa mais: a fronteira de eficiência. Ela é definida pelo conjunto de modelos que oferecem o melhor preço para um determinado nível de inteligência. A maior parte da codificação do cotidiano não exige provas matemáticas nem descobertas de segurança. O que importa no agregado é o custo dos modelos que atendem ao padrão de qualidade do trabalho típico de engenharia de software. E essa fronteira de eficiência está avançando muito mais rápido que a fronteira de inteligência, com modelos novos surgindo quase toda semana com melhor inteligência por unidade de preço. 💡
Alavanca 1: Modelos Open Source e de Menor Custo
Adotar rapidamente modelos mais novos e eficientes entrega os maiores ganhos de custo entre todas as técnicas. Mas, para capturar esses ganhos, a empresa precisa primeiro saber quais modelos realmente batem os que ela já usa. Isso não é trivial, porque os benchmarks públicos fazem um trabalho ruim de indicar o desempenho real em tarefas de código.
Para avaliar modelos novos, muitas empresas construíram avaliações automatizadas que consideram mais representativas do seu mix interno de desenvolvimento. A Databricks publicou recentemente um exemplo desse tipo de benchmark, no qual observou um desempenho por preço bastante competitivo dos modelos GLM, o que levou a empresa a disponibilizá-los internamente para os desenvolvedores.
Vale lembrar que nem todo modelo novo avança a fronteira de eficiência. As avaliações frequentemente dão resultado negativo. A Stripe descobriu que o Opus 4.7 não melhorava a qualidade de forma relevante em relação ao Opus 4.6, e ainda aumentava o custo, então decidiu não disponibilizá-lo internamente. A Databricks viu regressões de custo parecidas ao comparar o Opus 5.0 com o 4.8.
Flexibilidade de Harness e de Modelo
Como os maiores ganhos vêm da troca por modelos novos, adotar ferramentas que permitam flexibilidade de modelo virou peça crítica para manter os custos sob controle. A ferramenta que mais é usada em conjunto com um modelo específico se chama harness. Modelos proprietários de ponta estão cada vez mais desenhados para funcionar bem com harnesses específicos. Se a empresa quer preservar independência de modelo, existem basicamente dois caminhos:
- Pedir para os usuários trocarem de harness: a empresa oferece um conjunto de harnesses, como Claude Code, Codex ou Cursor, e pede que os desenvolvedores troquem quando for preciso migrar gastos para modelos mais baratos. O ponto negativo é que o custo dessa troca para um desenvolvedor pode ser alto, e o harness acaba virando um travamento de fato num modelo.
- Usar um meta-harness: uma abordagem nova e cada vez mais popular é usar um meta-harness, que apresenta uma experiência comum ao desenvolvedor enquanto despacha as requisições para os harnesses por baixo. Isso garante independência de modelo e reduz o custo de troca. Na Databricks, esse é o modo padrão com o Omnigent.
Alavanca 2: Roteamento Dinâmico de Requisições e Tarefas
Em vez de pedir para os usuários escolherem o modelo mais adequado sozinhos, uma linha crescente de pesquisa sugere que a seleção automática de modelo e ferramenta pode extrair ainda mais eficiência dos fluxos de codificação com agentes. As abordagens de roteamento se dividem em três categorias:
- Roteamento em nível de requisição: um proxy com estado fica entre o cliente e os modelos de base, tentando direcionar cada requisição para o modelo mais barato capaz de respondê-la. Esse roteamento também precisa considerar o cache do lado do servidor, já que um cache frio tem custo altíssimo em cargas de contexto grande. Exemplos incluem o Cursor Router, o AutoRouter da OpenRouter, o Router da Ramp e o Smart Routing da própria Databricks no Unity AI Gateway.
- Roteamento em nível de tarefa: um processo do lado do cliente distribui as tarefas para harnesses diferentes conforme a complexidade. Renomear um componente de X para Y é uma tarefa simples, enquanto explorar considerações de design para reduzir latência é uma tarefa complexa. O Omnigent é um exemplo de meta-harness que suporta esse padrão.
- Padrões de escalonamento e delegação: um único harness combina dois modelos, um caro e inteligente e um trabalhador barato. Em abordagens como a Advisor Tool do Claude, o modelo barato conduz e escala quando percebe que a tarefa exige mais potência. No Devin Fusion da Cognition, o padrão é invertido: o modelo caro é o loop principal e terceiriza trabalho para o mais barato.
Resultados internos da Databricks mostram que o Smart Router do AI Gateway reduz o custo médio por tarefa em mais de 30%, mantendo praticamente a mesma qualidade do modelo mais caro do conjunto. Outras empresas relataram números parecidos. 😎
Alavanca 3: Visibilidade, Alertas e Orçamentos
Pode surpreender que este artigo não tenha começado e terminado com deem um orçamento mensal e pronto. Os orçamentos rígidos, em que o uso é totalmente cortado ao atingir um limite, são usados apenas como último recurso em todas as empresas consultadas. Há dois motivos para isso.
Primeiro, se um desenvolvedor bate no teto, cortar o acesso à IA seria devastador para a produtividade. Nem a empresa nem o funcionário querem esse resultado. Segundo, pelo menos alguns dos usuários que mais gastam são justamente aqueles que alcançaram ganhos monumentais de eficiência e estão produzindo muito. Desestimular essas pessoas é atirar no próprio pé.
Em vez de um teto rígido, a maioria das empresas adotou uma abordagem mais progressiva, focada em visibilidade e em níveis crescentes de atrito conforme o gasto sobe:
- Visibilidade: todas as empresas consultadas oferecem feedback quase instantâneo sobre o gasto em andamento, muitas com dicas de como reduzir custos usando modelos mais baratos. É importante que o usuário veja seu gasto em todas as ferramentas.
- Portões de gasto: os desenvolvedores podem ser convidados a tomar ações ou pedir aprovações conforme o gasto aumenta. A forma mais simples é o portão autoliberável, um aviso de que a taxa de gasto passou de certo limite. A Databricks achou esse mecanismo útil para evitar gastos acidentais.
- Downshifting: ao bater num portão, o desenvolvedor pode ser rebaixado para um modelo mais barato em vez de ser suspenso. Como os modelos mais baratos custam muito menos, ele segue produzindo sem gerar gasto absurdo.
- Suspensão: no caso limite, os sistemas ainda conseguem cortar totalmente o acesso. Mas isso costuma ser temporário e serve de ponto de partida para uma conversa sobre uso mais eficiente.
Alavanca 4: Reduzindo o Excesso de Tokens
Como já vimos, boa parte do custo real vem de contexto que o usuário nem pediu para incluir. Reduzir esse inchaço de contexto ainda é uma área nova, mas várias abordagens promissoras estão sendo exploradas:
- Forçar compactação e compressão mais frequente do contexto ativo.
- Usar harnesses menos tagarelas, ou seja, mais eficientes em tokens, ou ajustar os existentes para gerar menos sobrecarga.
- Auditar as ferramentas mais populares e diminuir a verbosidade delas.
- Incentivar os desenvolvedores a quebrar tarefas em unidades menores, reduzindo o escopo de contexto.
Quando o contexto fica grande, o cache de prompt também tem um papel importante no desempenho geral. Modelos proprietários e open source têm configurações que permitem ligar o cache e ajustar por quanto tempo ele fica armazenado. Escrever no cache custa dinheiro, mas leituras de cache podem reduzir drasticamente o custo por inferência. Esse equilíbrio depende da carga de trabalho de cada empresa, então ajustar manualmente essas configurações pode gerar melhorias enormes.
Na Databricks, um ajuste relativamente simples do harness e das configurações de cache levou a uma redução de quase 50% no número de tokens gerados e nos custos associados, sem nenhuma queda de qualidade observada pelos desenvolvedores.
O Padrão de Design do AI Gateway
Todas essas técnicas trazem requisitos técnicos implícitos. Para aproveitar modelos novos com rapidez, é preciso um local central onde o menu de modelos é gerenciado. Para dar visibilidade de orçamento entre várias ferramentas, é preciso uma observabilidade unificada de custos. Para controlar o inchaço de contexto, é preciso observar as saídas das ferramentas e impor compressão.
Essas necessidades vêm sendo resolvidas por uma nova classe de software de infraestrutura, o AI Gateway. Trata-se de um local central onde acontecem quatro coisas:
- Gestão de capacidade e proxy de acesso aos modelos, sejam proprietários ou open source.
- Rastreamento e aplicação de orçamento, incluindo políticas complexas como níveis progressivos de atrito e rebaixamento de modelo.
- Gestão de configuração das ferramentas dos usuários, para impor listas de modelos permitidos e configurações de compactação.
- Registro de traces das sessões de codificação para análise de eficiência e benchmark.
Na Databricks, o Unity AI Gateway cuida de todas essas funções.
Juntando Tudo
O crescimento exponencial dos custos de IA não é uma inevitabilidade, é um problema de engenharia e governança que tem solução. As empresas que domaram essa curva compartilham um mesmo manual de jogo.
Elas perseguem a fronteira de eficiência em vez da fronteira de inteligência, adotam ferramentas que preservam a flexibilidade de modelo, roteiam o trabalho de forma inteligente para o modelo mais barato capaz de resolver, trocam orçamentos rígidos por visibilidade e atrito progressivo, e cortam a sobrecarga de tokens que domina o gasto real. Nenhuma dessas técnicas exige abrir mão dos ganhos de produtividade que tornaram a adoção de IA valiosa em primeiro lugar. Juntas, elas permitem satisfazer aquele mandato duplo de acesso amplo e de baixo atrito dentro de um envelope de custo previsível.
Um conjunto novo de abstrações de infraestrutura está surgindo para dar às empresas as ferramentas de controlar seus custos. A Databricks liberou como software aberto ou gratuito os componentes centrais da sua pilha de gestão de custos: o Unity AI Gateway para a gestão central e o Omnigent para as ferramentas de desenvolvimento. Milhares de empresas usam esses componentes todos os dias.
O que fica claro ao olhar para essas experiências é que não existe uma bala de prata única. O que existe é um conjunto de princípios que, adaptados ao contexto de cada organização, criam as condições para que o uso de inteligência artificial escale de forma saudável. Visibilidade real sobre o consumo, diversificação inteligente de modelos, roteamento automático e uma cultura de uso consciente são os elementos que separam quem mantém a IA como um ativo estratégico de quem fica preso numa espiral de custos crescentes sem retorno claro. O mercado está amadurecendo rápido, e as práticas que eram diferenciais competitivos há pouco tempo já estão virando o novo padrão esperado de qualquer organização que leve a sério o uso de IA em produção. 🚀
