Como a Databricks gerencia seus próprios gastos com agentes de codificação com os orçamentos do Unity AI Gateway

Na Databricks, a maneira como desenvolvemos software está mudando rapidamente à medida que adotamos a AI de forma agressiva na engenharia. Milhares de nossos engenheiros usam agentes de codificação todos os dias, alternando entre Claude Code, Codex, Cursor e outros, muitas vezes vários ao mesmo tempo. Essa adoção é excelente, mas cria um novo problema: os gastos com agentes de codificação são agora um dos itens de linha que mais crescem em R&D, e um único loop de automação fora de controle pode consumir um mês de orçamento em uma tarde.

Este post compartilha como resolvemos isso internamente, usando os mesmos Unity AI Gateway Budgets que oferecemos aos clientes. Como todo agente de codificação na Databricks, independentemente da ferramenta ou do modelo, roteia seu tráfego através do nosso gateway, podemos aplicar uma única política de gastos em toda a frota sem tocar nos consoles de administração individuais de cada agente de codificação.

As principais lições dessa implementação foram:

1. Separe a proteção contra gastos fora de controle dos limites de gastos mensais. Essas são tarefas diferentes que precisam de limites diferentes com ciclos de redefinição diferentes.
2. A maioria dos limites atingidos não são problemas. São engenheiros normais fazendo um trabalho normal, portanto, o caminho para desbloqueio deve ser por autoatendimento, e não uma fila de aprovação.
3. As aprovações devem ser reservadas para casos verdadeiramente excepcionais e devem ter limite de tempo, para que um projeto de um mês não se torne um direito permanente.
4. Nada disso funciona a menos que todo o tráfego de agentes flua por um único ponto de controle. O gateway é o que torna uma única política aplicável a todos os agentes de codificação.

Vamos entender em detalhes como chegamos aqui.

Nota: os valores em dólares neste post são ilustrativos, não nossos números internos reais.

O problema com os limites de gastos mensais

Quando começamos nossa jornada de gestão de custos, definimos exatamente um limite: cada engenheiro recebia um limite padrão de gastos mensais (digamos, US$ 500) e, quando o atingia, enviava uma solicitação para aumentá-lo. Isso parece razoável no papel, mas descobrimos que, na prática, essa estratégia cria atrito em todos os lugares.

Como esse limite também era nossa única proteção contra gastos fora de controle, cada aumento de limite também era realizado nos mesmos intervalos de US$ 500. Os usuários frequentes tinham que enviar uma nova solicitação toda vez que atingiam seu novo limite, às vezes várias vezes em um único mês, e qualquer valor acima de US$ 2.500 precisava de revisão manual. Pior ainda, cada aumento era permanente. Um engenheiro que cometesse um erro caro ou trabalhasse em um projeto de alto custo mantinha um limite alto indefinidamente, aumentando silenciosamente a parcela da empresa suscetível a erros caros. Além disso, não havia um processo de emergência para que os engenheiros pudessem se desbloquear para tarefas críticas e urgentes, como usar AI para depurar incidentes de clientes.

Na nossa escala, algo entre 500 e 1.000 engenheiros atingiam o limite todos os meses. Isso significa centenas de chamados, centenas de sessões de trabalho interrompidas e um canal Slack #ai-devtools muito mal-humorado.

Princípios em primeiro lugar

Antes de projetar qualquer coisa, escrevemos o que realmente acreditávamos sobre os gastos com AI, e tudo se resumia a dois princípios:

1. Geralmente, permitir que os engenheiros gastem sem impedimentos de aprovações e escalonamentos. O objetivo é aproveitar o potencial da AI. Barreiras de proteção que atrasam todos para evitar erros raros geram um prejuízo líquido.
2. Evitar o desperdício, que ocorre exatamente de duas formas.
   • O desperdício de curto prazo é o gasto rápido que pode ser acidental, como uma automação que inicia involuntariamente centenas de sessões de agentes.
   • O desperdício de longo prazo é o gasto ao longo de dias ou semanas que sugere uma técnica excessivamente cara, como executar subagentes paralelos de modelos de fronteira para trabalhos que não precisam deles.

Escrever isso expôs o conflito. Para conter gastos fora de controle, um limite deve ser pequeno o suficiente para que algumas horas de acidentes o acionem. Mas um limite tão pequeno interrompe constantemente o uso mensal normal. Nenhum número único consegue fazer as duas coisas.

Como separamos a proteção contra gastos fora de controle dos limites de gastos mensais

Reestruturamos o processo em torno de um princípio simples: deixar os engenheiros gastarem sem impedimentos e intervir apenas nos dois tipos de desperdício que realmente importam: o desperdício de curto prazo e o de longo prazo.

A solução para esses dois modos de falha se mapeia em dois orçamentos no Unity AI Gateway:

Um limite diário para conter gastos fora de controle. Esse limite é deliberadamente pequeno em relação aos gastos mensais. Quando um engenheiro o atinge, não presumimos que haja algo errado. Ele recebe uma notificação no Slack, confirma que o gasto foi intencional e o limite aumenta automaticamente em mais um incremento. Sem aprovação, sem chamado, sem espera. Se o gasto foi um acidente, a notificação é exatamente o alerta de que ele precisava. O orçamento diário é redefinido todas as noites em nosso horário de menor uso e é totalmente zerado no início de cada mês.

Um limite mensal para controlar gastos extraordinários. Esse limite é definido como alto o suficiente para que o engenheiro comum nunca o encontre. Ultrapassá-lo significa que alguém está solicitando gastar significativamente mais do que seus colegas, o que não tem problema, mas deve estar associado a uma prioridade de negócios específica. Esses aumentos passam pela aprovação do gerente, em vez de um comitê de aprovação centralizado, e vêm em alguns níveis amplos, em vez de pequenos aumentos infinitos e, crucialmente, são limitados ao tempo de duração do projeto. Quando o projeto termina, o limite retorna ao original.

Os dois limites permanecem vinculados por meio de uma proporção fixa. Em nossa implantação, um engenheiro que gasta de forma constante ao longo do mês nunca atingirá o limite diário, pois o orçamento mensal dividido pelos dias úteis fica confortavelmente abaixo do limite diário. Se um gerente aumentar o limite mensal de alguém para um grande projeto, o limite diário e o incremento aumentam proporcionalmente, de modo que a proteção contra gastos fora de controle continue sendo eficaz sem se tornar um incômodo.

Nos bastidores, o limite efetivo a qualquer momento é simples de definir. Os gastos de um usuário são controlados por ambos os orçamentos e, portanto, serão limitados ao menor de dois valores: o uso acumulado neste mês mais um incremento de gastos fora de controle, e o limite máximo mensal. Quando um usuário é bloqueado, essa fórmula também nos diz exatamente em qual situação nos encontramos. Se ele atingir o limite de gastos fora de controle, o uso poderá ser retomado após uma confirmação por autoatendimento. Se atingir o limite máximo mensal, ele precisará conversar com seu gerente.

O fluxo de trabalho de confirmação por autoatendimento

O limite diário só funciona se o desbloqueio for genuinamente sem atritos, por isso concentramos a maior parte do nosso esforço de design nesse caminho. Veja o que um engenheiro realmente vivencia.

Assim que um usuário ultrapassa cerca de 90% do seu limite diário, ele se torna qualificado para um aumento antes mesmo de ser bloqueado. Uma notificação no Slack chega com o contexto (quanto ele gastou hoje, qual é a margem restante) e um único botão para confirmar que o gasto é intencional. Clicar nele aumenta o limite diário em um incremento imediatamente. O mesmo autoaumento está disponível em nosso portal interno de orçamentos e na CLI, que exibe a cota diária e mensal restante, junto com os links para aumentar qualquer uma delas.

Não há limite para o número de autoconfirmações por dia. Um engenheiro que executa uma carga de trabalho genuinamente pesada pode confirmar dois ou três incrementos em um único dia, e não há problema nisso. Cada confirmação é um sinal humano deliberado que diz "sim, sou eu e pretendo fazer isso". Uma tarefa cron não monitorada não pode clicar em um botão do Slack. O tamanho do incremento é importante aqui: se for muito pequeno, as notificações se tornam ruído que treina as pessoas a clicarem sem ler; se for muito grande, a proteção deixa de proteger. Dimensionamos o nosso para que um engenheiro que gaste de forma constante em relação ao seu orçamento mensal nunca veja nenhuma notificação.

Substituições em níveis em vez de limites arbitrários

Em vez de permitir que os limites flutuem para valores arbitrários por usuário, ambos os orçamentos passam por um pequeno conjunto de níveis fixos, implementados como associação de grupo no gateway. Todos começam no nível básico e cada nível acima aumenta o limite em uma etapa fixa. Isso mantém o sistema legível: uma listagem de grupos responde quem está acima do padrão e por quanto.

Os dois orçamentos passam por seus níveis de maneira diferente, correspondendo às suas diferentes funções.

Os níveis diários mudam automaticamente. Todo mundo começa o mês no nível básico. Cada autoconfirmação promove o usuário em um nível, e um job agendado também promove os usuários proativamente quando seus gastos se aproximam do teto atual, no máximo uma vez por dia, para que o uso normal nunca seja interrompido. No final do mês, outro job redefine todos de volta ao nível básico. O grande esforço do mês passado não se acumula como margem para este mês.

Os níveis mensais mudam de forma deliberada. Existem apenas alguns, cerca de 2x, 5x, até efetivamente ilimitados, e cada promoção precisa da aprovação do gerente ou de um nível acima. As promoções são limitadas ao escopo do projeto que as justifica, normalmente por um, três ou seis meses, e depois revertidas. As etapas mais amplas forçam uma conversa real sobre os gastos, em vez de pequenos aumentos que ninguém analisa. Aumentar o nível mensal também dimensiona o incremento diário proporcionalmente, mantendo calibrada a proteção contra gastos excessivos.

Aplicando isso pelo gateway

A razão pela qual isso funciona quase sem infraestrutura personalizada é que o Unity AI Gateway já monitora tudo. Cada solicitação de cada agente de codificação, seja para o Claude, GPT, Gemini ou modelos de código aberto, é atribuída a uma identidade de usuário e medida em um só lugar. Os orçamentos configurados para o gateway se aplicam a todas as ferramentas que um engenheiro usa, e os gastos não podem exceder nenhum dos orçamentos aplicáveis. Essa última propriedade é o que implementa o comportamento de "mínimo dos dois limites" sem esforço adicional: definimos ambos os orçamentos e ambos entram em vigor a qualquer momento.

Os níveis diários e mensais são implementados atribuindo as substituições de limite por usuário do orçamento a diferentes grupos. E a promoção de nível é realizada tornando o usuário um membro do grupo de nível superior, por meio de automação diária, autoconfirmações e aprovações de gerentes.

Como o gateway armazena todos esses dados de uso no Unity Catalog, também temos a parte de observabilidade sem custo adicional. Os gerentes visualizam os gastos no nível da equipe nas mesmas tabelas do Lakehouse onde criamos nosso benchmark interno de agentes de codificação, e o setor financeiro recebe uma única fatura em vez de cinco.

O que mudou

A fila de aprovação baseada em interrupções acabou. Sob o novo modelo, esperamos que apenas um pequeno grupo dos nossos usuários mais ativos atinja o limite diário em um determinado mês, e cada um desses casos é resolvido com um único clique de confirmação. Os aumentos de limite mensal deixaram de ser uma tarefa repetitiva para cada engenheiro e passaram a ser uma decisão rara, com escopo definido por projeto, que o gerente toma apenas uma vez.

Tão importante quanto isso, os engenheiros pararam de racionar o uso. O objetivo dessas proteções nunca foi reduzir o uso de IA. Era eliminar o medo de custos descontrolados para que pudéssemos continuar impulsionando a adoção. Agora, o gasto é algo que moldamos com dados, em vez de algo que limitamos por precaução.

Próximos passos

Continuamos a ajustar os números à medida que os padrões de uso evoluem, e os padrões que se mostraram eficazes internamente estão servindo de base para o próprio produto Budgets: ciclos de orçamento diários nativos, substituições temporárias que expiram com o ciclo de orçamento e um modelo de permissão que permite aos usuários finais aumentarem sozinhos seu próprio limite diário diretamente pela API de orçamento, com mais flexibilidade do que os grupos de substituição predefinidos.

Também estamos trabalhando para tornar o caminho mais caro menos necessário em primeiro lugar, por meio de um roteamento de modelos mais inteligente, para que as tarefas diárias sejam direcionadas a modelos eficientes e os modelos de fronteira sejam reservados para o trabalho que realmente precisa deles. Traremos mais detalhes sobre isso em uma publicação futura.

Se a sua organização está escalando agentes de codificação e cada ferramenta tem seu próprio console de orçamento, a solução é a mesma que usamos aqui. O suporte a agentes de codificação no Unity AI Gateway já está disponível para todos os clientes da Databricks. Acesse a documentação para começar.

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original