Databricks: Como os orçamentos do Unity AI Gateway controlam os gastos com agentes de programação

A Databricks mudou a forma como milhares de seus engenheiros usam agentes de programação depois que 500 a 1.000 funcionários passaram a atingir limites internos de gastos todos os meses. Agora, a empresa direciona Claude Code, Codex, Cursor e outros agentes por um único gateway, com orçamentos diários e mensais separados.

Esse desenho enfrenta um conflito criado pela rápida adoção de agentes. A Databricks quer que engenheiros usem IA livremente, mas um loop de automação sem supervisão pode consumir uma franquia mensal em uma única tarde. Seu limite mensal original tratava trabalho produtivo e software descontrolado como o mesmo problema.

O novo sistema faz uma aposta mais relevante. O controle de custos deve interromper máquinas antes de interromper pessoas de forma rotineira. Isso coloca a Databricks em oposição ao modelo convencional de limites fixos por usuário, tickets de aprovação e controles separados dentro de cada ferramenta de programação.

O design de orçamentos oferece um relato incomumente detalhado da governança de custos de IA em uma grande organização de engenharia. No entanto, seus resultados foram reportados pela própria empresa, e a documentação pública do produto deixa alguns detalhes de aplicação em aberto.

O que a Databricks mudou após os limites mensais falharem

A Databricks substituiu um único teto mensal por dois controles conectados porque a demanda normal e a automação descontrolada operam em escalas de tempo diferentes.

A empresa originalmente atribuía a cada engenheiro uma franquia mensal padrão. Funcionários que a atingiam solicitavam aumentos em incrementos fixos, enquanto pedidos excepcionalmente altos passavam por revisão manual. Cada aumento também se tornava permanente.

Esse arranjo gerava centenas de solicitações por mês. Usuários intensivos às vezes repetiam o processo várias vezes em um único ciclo de faturamento. Engenheiros lidando com trabalhos urgentes não tinham uma forma direta de restaurar o acesso.

Os aumentos permanentes também ampliavam o impacto potencial de erros posteriores. Um engenheiro que precisava de capacidade adicional para um projeto mantinha essa capacidade após o fim do trabalho. Gradualmente, a organização acumulava contas com mais margem para consumo acidental.

A falha mais profunda era estrutural. Um limite mensal pequeno o bastante para conter uma falha de automação que durasse uma tarde era restritivo demais para trabalho de engenharia contínuo. Um limite grande o bastante para usuários produtivos oferecia pouca proteção contra um loop rápido.

Por isso, a Databricks separou desperdício de curto prazo de desperdício de longo prazo. O desperdício de curto prazo inclui uma automação que inicia inesperadamente muitas sessões de agentes. O desperdício de longo prazo inclui um fluxo de trabalho caro repetido ao longo de vários dias ou semanas.

Um orçamento diário agora trata do primeiro caso. Ele é deliberadamente menor que a franquia mensal e é redefinido durante o período de menor uso da empresa. A companhia afirma que engenheiros que se aproximam do limite diário recebem uma notificação no Slack antes de perderem o acesso.

O funcionário pode reconhecer que a atividade é intencional. Essa ação eleva a franquia diária em outro incremento, sem solicitação de aprovação. A mesma opção aparece em um portal interno e em uma interface de linha de comando.

Um orçamento mensal lida com consumo sustentado e excepcional. A Databricks define esse limite alto o suficiente para que engenheiros típicos não o encontrem. Um aumento exige que um gestor relacione a capacidade adicional a uma prioridade específica do negócio.

Essas exceções mensais expiram. Em geral, a Databricks as atribui por um, três ou seis meses, segundo seu anúncio. Depois disso, o funcionário retorna ao nível padrão, salvo se outro projeto ativo justificar uma extensão.

Isso muda o significado de um evento de limite. Atingir um limite diário pergunta se uma pessoa pretendia realizar aquela atividade. Atingir um limite mensal pergunta se a organização ainda apoia o projeto subjacente.

A distinção importa porque agentes de programação podem continuar trabalhando além de um único prompt. Eles podem pesquisar repositórios, editar arquivos, executar testes e iniciar tarefas paralelas. Assim, o consumo pode acelerar enquanto o engenheiro se concentra em outro lugar.

A Databricks não publicou suas franquias internas reais. Ela descreveu explicitamente os números usados em seu exemplo como ilustrativos. Leitores não devem tratar esses exemplos como referências para outra organização.

O que é transferível é o modelo operacional. Um ciclo curto de redefinição detecta anomalias repentinas, enquanto um ciclo mais longo governa a demanda persistente. Vinculá-los impede que qualquer um dos controles assuma ambas as responsabilidades.

Databricks: Como dois orçamentos governam um engenheiro

O mecanismo central limita cada engenheiro ao menor dos dois limites: a franquia atual de curto prazo ou o máximo mensal aprovado.

Os orçamentos diário e mensal não funcionam como cotas independentes. A Databricks os mantém conectados por uma proporção fixa. Quando um gestor eleva o nível mensal de um funcionário, o incremento diário correspondente aumenta proporcionalmente.

Esse vínculo preserva espaço para um projeto legítimo sem tornar sem sentido sua proteção contra uso descontrolado. Um engenheiro com consumo constante deve permanecer abaixo do nível de alerta diário. Um pico acentuado ainda aciona uma confirmação humana.

A Databricks descreve o limite efetivo como o mínimo entre dois valores. Um reflete o uso mensal mais o próximo incremento de curto prazo. O outro reflete a capacidade mensal total aprovada para o funcionário.

O evento resultante informa ao sistema qual resposta deve vir a seguir. Um evento de limite diário pode ser resolvido por confirmação de autoatendimento. Um evento de limite mensal passa para um gestor porque representa consumo excepcional sustentado.

A Databricks começa a notificar usuários quando eles atingem cerca de 90% de sua franquia diária. A mensagem inclui o consumo atual e a margem restante. Funcionários podem aumentar o limite antes que uma sessão ativa seja bloqueada.

Não há um teto fixo para confirmações diárias. Alguém executando uma carga de trabalho deliberadamente exigente pode aprovar vários incrementos. Cada confirmação fornece um sinal humano que um processo sem supervisão não consegue oferecer por si só.

Essa fricção é pequena, mas deliberada. Se os incrementos forem estreitos demais, alertas repetidos viram ruído de fundo. Se forem amplos demais, a proteção permite atividade não intencional em excesso antes de pedir atenção.

A empresa afirma que calibrou os incrementos para que o consumo mensal constante não gere notificações. Essa alegação importa mais do que o número de níveis disponíveis. Uma proteção que interrompe repetidamente o comportamento esperado incentivará a evasão ou aprovações indiscriminadas.

A Databricks implementa os níveis por meio de associação a grupos. Todos começam em um nível base, e entrar em um grupo superior altera o limite aplicável. Isso evita uma coleção crescente de valores arbitrários atribuídos a indivíduos.

A movimentação entre níveis diários é majoritariamente automática. Um processo agendado pode promover alguém à medida que o uso se aproxima do teto atual, mas apenas uma vez por dia. Outro processo devolve todos ao nível base quando o mês termina.

Os níveis mensais seguem um caminho separado. Gestores escolhem entre um pequeno número de níveis amplos, em vez de negociar muitos ajustes incrementais. A Databricks afirma que os níveis superiores são aproximadamente duas e cinco vezes o nível base, seguidos por uma opção efetivamente irrestrita.

A estrutura ampla exige uma decisão sobre o valor para o negócio. Um gestor aprova uma exceção do tamanho de um projeto, em vez de processar repetidamente pequenos pedidos. Sua expiração também impede que trabalho temporário crie exposição permanente.

Esse mecanismo toma emprestada uma ideia importante da confiabilidade de produção. Sistemas frequentemente distinguem entre uma anomalia súbita e uma pressão sustentada sobre recursos, porque cada uma exige uma resposta diferente. A governança de agentes de programação agora precisa da mesma separação.

Um alerta diário se assemelha a um detector de anomalias. A revisão mensal se assemelha ao planejamento de capacidade. Combinar ambos produz informações mais úteis do que um único teto fixo.

A abordagem também oferece aos engenheiros uma saída durante incidentes. Um funcionário que investiga um problema de cliente pode reconhecer imediatamente uma atividade intencional. Isso evita esperar por um comitê centralizado enquanto o trabalho de produção permanece bloqueado.

Ainda assim, autoatendimento não é o mesmo que gastos irrestritos. Cada confirmação se torna um evento observável vinculado a uma identidade. Confirmações repetidas podem orientar mudanças posteriores em fluxos de trabalho, roteamento ou orçamentos de projetos.

Um gateway substitui uma pilha de consoles de fornecedores

A Databricks só consegue aplicar uma política porque todos os agentes de programação compatíveis enviam seu tráfego de modelos por um ponto de controle compartilhado.

Ferramentas individuais já oferecem controles administrativos. A Anthropic fornece limites de gastos no nível da organização e do usuário para Claude Code, enquanto a OpenAI oferece limites de usuário e espaço de trabalho para Codex. Esses controles se tornam mais difíceis de conciliar quando engenheiros usam vários produtos.

A Databricks afirma que seus engenheiros frequentemente combinam Claude Code, Codex, Cursor e outros agentes. Alguns usam vários simultaneamente. Um limite dentro do console de um fornecedor não consegue ver o consumo gerado por outro fornecedor.

O Unity AI Gateway fica entre esses clientes e os modelos que eles chamam. O gateway autentica cada funcionário, mede as solicitações e registra qual modelo tratou o trabalho. Assim, um orçamento pode acompanhar o usuário entre ferramentas.

A empresa diz que o gateway processa solicitações direcionadas a Claude, GPT, Gemini e modelos de código aberto. Engenheiros não precisam de chaves de provedores separadas em suas máquinas ao usar a configuração governada. O Unity Catalog determina quem pode acessar cada serviço de modelo.

Essa camada de roteamento transforma consumo fragmentado em uma única superfície de políticas. O gateway verifica todos os orçamentos aplicáveis a um usuário antes de permitir mais atividade. Ele também produz registros de uso consolidados para gestores e finanças.

O tutorial de agentes de programação descreve a configuração pública como um recurso beta. Administradores configuram agentes externos para usar um endpoint de gateway e, então, aplicam permissões, limites de taxa e controles de gastos.

Limites de taxa e orçamentos resolvem problemas diferentes. Um limite de taxa controla o volume de solicitações ou tokens durante um intervalo curto. Um orçamento acompanha o consumo monetário, que varia conforme a seleção de modelo e o tamanho de cada solicitação.

A identidade é essencial para ambos. Chaves de API compartilhadas dificultam distinguir um engenheiro produtivo de um processo em segundo plano com falha. A autenticação por usuário permite que o gateway atribua o consumo e aplique limites individualizados.

O roteamento centralizado também dá à Databricks um caminho para a otimização de modelos. Um roteador futuro poderia direcionar trabalho rotineiro para modelos mais eficientes, reservando modelos de fronteira para tarefas exigentes. A empresa afirma que esse roteamento está em desenvolvimento.

Esse plano expõe uma pressão competitiva mais ampla. Fornecedores de agentes de programação oferecem cada vez mais suas próprias análises e controles, mas os clientes raramente se padronizam em apenas um agente. Empresas precisam de governança acima da camada de ferramentas quando o uso abrange vários provedores.

Os controles administrativos da Anthropic incluem limites granulares de gastos e análises de uso do Claude Code. As análises de uso da OpenAI detalham o consumo de créditos entre usuários, produtos e modelos.

O Google também relata a atividade do Gemini Code Assist por meio do Cloud Monitoring. Suas métricas incluem usuários ativos, sugestões aceitas, chamadas de API e tokens. No entanto, o Google observa que algumas medições abrangem apenas a atividade dentro da IDE.

Esses consoles nativos continuam úteis porque expõem sinais específicos de cada produto. Um gateway central oferece uma vantagem diferente: atribuição consistente entre clientes e modelos. Muitas organizações precisarão das duas camadas, em vez de um único painel universal.

O modelo da Databricks pressiona as equipes de plataforma a decidir onde a autoridade deve ficar. Se cada console de fornecedor permanecer independente, as políticas se desviam e a área financeira recebe várias visões da mesma função de engenharia.

Se todo o tráfego passar por um gateway, a organização obtém controles consistentes, mas assume a responsabilidade pela disponibilidade e configuração desse gateway. Um erro de roteamento pode afetar todos os agentes participantes de uma só vez.

Essa é a principal disputa do artigo: controles fragmentados por fornecedor versus governança centralizada e baseada em identidade. A Databricks escolheu a centralização porque seus engenheiros já cruzavam fronteiras entre produtos. Essa escolha torna a política aplicável, e não apenas documentada.

Para organizações de engenharia que estão criando fluxos de trabalho semelhantes, uma base de conhecimento técnico pesquisável pode preservar o raciocínio por trás de exceções aprovadas. Registros de custo, por si só, não explicam por que uma sessão cara de agente foi importante.

O Autoatendimento Elimina Tickets, Mas Não a Responsabilização

A Databricks trata a maioria dos eventos diários de limite como trabalho legítimo, invertendo a premissa de que o consumo incomum deve começar em uma fila de aprovação.

Esta é a parte mais interessante do desenho. Muitos sistemas de controle de custos fazem o usuário comprovar o valor do consumo extra antes que o trabalho continue. A Databricks, em vez disso, exige confirmação para um aumento de curto prazo e reserva a aprovação para exceções persistentes.

Essa política reflete o custo da interrupção. Um ticket não consome apenas o tempo de um administrador. Ele também interrompe o fluxo de trabalho de um engenheiro e pode atrasar depuração, testes ou resposta a incidentes.

A Databricks afirma que de 500 a 1.000 engenheiros atingiam o limite mensal anterior durante um mês típico. Nessa frequência, a aprovação se torna trabalho operacional rotineiro, e não uma revisão significativa. Solicitações repetidas também dificultam a identificação dos casos realmente excepcionais.

O fluxo de trabalho substituto pede menos evidências no limite diário. Uma única ação confirma que uma pessoa reconhece o consumo e quer que ele continue. Esse sinal interrompe software não supervisionado, ao mesmo tempo que permite a retomada de trabalho deliberado.

Um loop de automação não consegue clicar na sua notificação do Slack. Um cron job também não consegue abrir o portal interno e confirmar que o consumo atual é intencional. A confirmação humana, portanto, cria uma barreira moderada voltada especificamente à atividade autônoma.

A barreira é comportamental, não tecnicamente absoluta. Um engenheiro pode aprovar repetidamente trabalho caro sem aprimorar o método subjacente. É por isso que o máximo mensal ainda exige julgamento gerencial.

O gerente não revisa cada pico. Em vez disso, decide se o consumo persistente e acima do normal pertence a um projeto importante. A exceção é vinculada a esse trabalho e termina quando o período aprovado expira.

Essa separação dá aos funcionários autonomia sem transferir a eles toda a decisão orçamentária. Os engenheiros controlam a continuidade de curto prazo. Os gerentes controlam desvios prolongados da faixa normal.

O modelo está alinhado ao princípio de FinOps de que as equipes devem assumir responsabilidade pelo uso de sua tecnologia. O framework de IA do FinOps também identifica dados granulares, gastos imprevisíveis e alocação entre plataformas como desafios distintos para a IA.

No entanto, a responsabilização exige mais do que um limite. Os gerentes precisam de contexto sobre qual repositório, fluxo de trabalho, tarefa e modelo geraram o consumo. Um total mensal, por si só, não pode mostrar se o trabalho economizou tempo ou gerou repetidamente resultados inutilizáveis.

A Databricks afirma que o uso do gateway chega ao Unity Catalog e pode aparecer nas mesmas tabelas Lakehouse usadas para análise interna. Isso fornece uma base para relacionar custos a metadados de engenharia. A empresa não publicou uma metodologia completa de retorno sobre o investimento.

Essa omissão é compreensível, mas importante. Um menor volume de tickets comprova que o novo fluxo de trabalho reduz a fricção administrativa. Não comprova que cada sessão adicional de agente gera valor de engenharia proporcional.

A empresa também afirma que os engenheiros deixaram de racionar o uso. Essa é uma observação interna, não um resultado de produtividade medido de forma independente. A maior adoção pode representar delegação útil, experimentação ou repetição evitável.

Portanto, um programa maduro deve acompanhar resultados ao lado dos gastos. Sinais relevantes incluem mudanças aceitas, tarefas concluídas, código revertido, esforço de revisão, resolução de incidentes e uso de modelos por fluxo de trabalho.

Essas medições têm limitações. Linhas aceitas podem recompensar verbosidade, enquanto contagens de tarefas podem ocultar a dificuldade. O custo por resultado só é útil quando a organização define cuidadosamente o que é um resultado.

A Databricks construiu a camada de aplicação antes de resolver todas as questões de medição. Essa ordem é defensável porque o consumo sem limites pode impedir a adoção imediatamente. Ainda assim, a questão do valor se torna mais importante quando o receio de custos descontrolados diminui.

O Produto Público Ainda Tem Questões de Aplicação

A Databricks apresenta um padrão interno comprovado, mas os clientes devem distinguir esse padrão dos controles precisos atualmente documentados para cada carga de trabalho pública.

O anúncio de 28 de julho afirma que o suporte a agentes de codificação no Unity AI Gateway está disponível para todos os clientes da Databricks. Também descreve orçamentos diários, substituições temporárias e aumentos de limite conduzidos pelo usuário como mecanismos internos que influenciam o desenvolvimento futuro do produto.

Essa redação importa. A lista de próximos passos da empresa inclui ciclos nativos de orçamento diário, substituições com expiração e modelos de permissão para aumentos de autoatendimento. Portanto, algumas partes do fluxo de trabalho interno parecem depender de automação em torno do gateway.

A documentação pública de orçamentos, atualizada antes do anúncio, concentra-se principalmente em gastos mensais. Ela também lista limitações que afetam o rastreamento, as substituições e o bloqueio de uso.

Por exemplo, a documentação afirma que a inferência de modelos externos e a capacidade provisionada não são atualmente rastreadas por esses orçamentos. Ela também descreve substituições por usuário e bloqueio como disponíveis apenas para orçamentos Genie nessa página.

Um tutorial beta separado afirma que os administradores podem definir um orçamento de gastos para todo o gateway e bloquear o uso de agentes de codificação. Essas páginas podem descrever diferentes estágios de lançamento, ambientes de nuvem ou configurações de recursos. A Databricks deve esclarecer esses limites para clientes que projetam controles de produção.

A aplicação quase em tempo real também permite algum excedente. A documentação alerta que solicitações ativas podem terminar após um limite ser atingido. Também pode haver um breve atraso antes que um bloqueio entre em vigor.

Esse comportamento é comum em sistemas medidos por consumo, mas os agentes complicam o risco. Uma ação do usuário pode criar várias chamadas de modelo, e sessões simultâneas podem manter várias solicitações ativas. As organizações devem testar a exposição no pior caso, em vez de presumir um limite perfeitamente rígido.

A latência de relatórios cria outra distinção. A Databricks afirma que a aplicação usa rastreamento quase em tempo real, enquanto as tabelas do sistema de faturamento podem ser atualizadas a cada poucas horas. Portanto, um alerta, um painel e uma consulta SQL podem mostrar totais diferentes no mesmo momento.

Essas diferenças de tempo afetam a revisão de incidentes. Um engenheiro pode receber um aviso antes que as linhas correspondentes apareçam em uma consulta financeira. Os procedimentos operacionais devem identificar qual interface orienta decisões imediatas.

O roteamento central também depende de cobertura completa. Um engenheiro que usa uma chave direta de provedor, uma integração não compatível ou outro caminho de faturamento pode escapar da visão do gateway. A arquitetura funciona apenas quando as políticas de identidade e roteamento impedem essas alternativas.

A Databricks afirma que todo o tráfego interno de agentes de codificação passa pelo gateway. Os clientes precisam validar essa condição em seus próprios ambientes. Uma política que cobre a maior parte do tráfego pode criar confiança equivocada em relação ao restante.

A confirmação de autoatendimento introduz seu próprio modo de falha. Alertas frequentes podem treinar funcionários a aprovar por reflexo, especialmente diante de prazos. A Databricks reconhece esse problema de calibração, mas não publica a fórmula de limite usada internamente.

As organizações precisarão de ajustes separados. Os preços dos modelos, horários de trabalho, formatos de projetos e comportamento dos agentes diferem entre equipes. Um limite adequado para desenvolvimento interativo pode ser inadequado para geração programada de testes ou trabalho de migração.

Questões de privacidade e trabalho também merecem atenção. Registros de gastos por usuário podem apoiar a alocação de custos, mas não devem se transformar em pontuações simplistas de desempenho de funcionários. O alto consumo pode refletir atribuições difíceis, e o baixo consumo pode refletir trabalho eficiente ou adoção limitada.

A interpretação mais segura é restrita. A Databricks descreveu um padrão de controle crível e relatou menor fricção de aprovação. Ela não estabeleceu uma proporção orçamentária universal nem verificou de forma independente ganhos de produtividade.

Os clientes devem começar com observação, identificar distribuições normais de uso e testar a aplicação com cargas de trabalho controladas. Também devem confirmar quais tipos de solicitação contam para cada orçamento antes de confiar nele como limite financeiro.

Três Sinais Mostrarão se o Modelo Escala

O próximo teste é verificar se a Databricks consegue transformar sua automação interna em controles claros e nativos de produto, sem recriar a fricção que eliminou.

O primeiro sinal é o suporte nativo a ciclos de orçamento diário e aumentos de autoatendimento. A Databricks afirma que essas capacidades estão influenciando seu roadmap de produto. Sua chegada reduziria a automação personalizada necessária para reproduzir o fluxo de trabalho interno.

Os detalhes importarão mais do que o nome do recurso. Os clientes precisam de horários de redefinição configuráveis, notificações conscientes da identidade, confirmações auditáveis e permissões claras. Também precisam de comportamento previsível quando várias solicitações cruzam um limite simultaneamente.

Se esses controles chegarem com documentação consistente, a Databricks reforçará seu argumento em favor da governança no nível do gateway. Se permanecerem dependentes de scripts internos ou prévias limitadas, o padrão será mais difícil de adotar pelos clientes.

O segundo sinal são as substituições mensais temporárias. A expiração é central para o argumento da empresa porque impede que um projeto amplie permanentemente a exposição futura. Exceções nativas com escopo de projeto converteriam esse princípio em um controle reutilizável.

Uma implementação útil deve registrar o gerente aprovador, a justificativa de negócio, o período de vigência e o grupo de identidade afetado. Também deve reverter automaticamente sem exigir outro ticket.

Se a Databricks lançar esse ciclo de vida, o gateway se tornará mais do que uma camada de medição. Ele passará a codificar como engenharia, finanças e gestão compartilham a responsabilidade pelo consumo de agentes.

O terceiro sinal é um roteamento de modelos mais inteligente. A Databricks afirma que quer que tarefas rotineiras usem modelos eficientes, reservando sistemas de fronteira para trabalhos mais difíceis. Isso trataria o fluxo de trabalho caro antes que um limite orçamentário intervenha.

O roteamento exigirá avaliação confiável. Uma solicitação mais barata tem pouco valor se produzir mais tentativas, trabalho de revisão ou código defeituoso. A Databricks precisará conectar a escolha do modelo aos resultados das tarefas, e não apenas ao consumo de tokens.

O sucesso reforçaria a tese central da empresa. A governança poderia aumentar a adoção ao mesmo tempo em que molda como o consumo ocorre. Resultados fracos de roteamento deixariam os orçamentos gerenciando sintomas depois que decisões ineficientes já tivessem sido tomadas.

O mercado mais amplo também reagirá. OpenAI, Anthropic e Google continuam adicionando análises de uso, limites e administração empresarial. Seus controles nativos podem se tornar suficientes para organizações comprometidas com um único fornecedor.

Ambientes de engenharia com ferramentas mistas criam uma necessidade diferente. Essas equipes exigem uma camada de políticas que acompanhe a identidade entre clientes e modelos. A Databricks está posicionando o Unity AI Gateway para esse papel.

Líderes de engenharia deveriam agora examinar seu próprio tráfego de agentes. Quantas ferramentas geram consumo, com que rapidez um loop autônomo pode escalar e quais exceções merecem recuperação imediata por autoatendimento?

O guia prático da Databricks oferece um ponto de partida útil, mas sua lição central é organizacional. Anomalias de curto prazo e decisões de investimento de longo prazo não deveriam compartilhar um único mecanismo de aprovação.

Observe se controles diários nativos, substituições temporárias com expiração e roteamento orientado por resultados serão disponibilizados conforme prometido. Juntos, esses sinais mostrarão se a Databricks criou um modelo de governança transferível ou uma personalização interna eficaz.