A Databricks cortou até 90% do custo unitário de IA para programação sem pôr teto nos melhores devs

A Databricks liberou o modelo de fronteira Astra para todos os engenheiros, cerca de 3.500 pessoas. O modelo era claramente melhor nos problemas difíceis, como desenho de sistemas. O gasto subiu cerca de 60%, e nas tarefas do dia a dia, que os modelos anteriores já resolviam, o ganho não ficou evidente.

Esse detalhe, de uma entrevista que a Databricks publicou em 22 de outubro com o cofundador Patrick Wendell, é o número mais útil de uma história contada quase toda em percentuais. Ele mostra o formato do problema que toda empresa que escala agentes de código enfrenta agora: o modelo caro vale a pena para parte do trabalho, e a maior parte do trabalho não é essa parte.

Como a conta saiu do controle

Wendell descreve uma sequência conhecida. Para vencer a resistência dos engenheiros, a Databricks tirou todas as barreiras: o modelo mais caro, tokens à vontade. Aí a adoção decolou. Como as ferramentas de código agora são cobradas por consumo, e não por licença, uma pessoa pode, nas palavras dele, “rodar um pequeno loop no modelo mais caro e ir almoçar”. Os custos cresceram exponencialmente enquanto a receita não, até ameaçar anular os ganhos de eficiência que justificavam o rollout.

A empresa diz que hoje o gasto com tokens por pessoa está praticamente estável enquanto o uso continua crescendo, e que em alguns casos o custo unitário caiu até 90%. São números internos de uma empresa que vende a ferramenta que usou, e o texto não define a unidade nem a linha de base. As alavancas por trás deles são mais transferíveis que os números.

Quatro alavancas, por ordem de tamanho

Trocar o modelo padrão por um mais barato quando ele for bom o bastante. Wendell chama de chato e diz que foi o maior efeito, 50% ou mais sozinho. Modelos novos e mais baratos chegam o tempo todo; a economia só acontece se alguém os avaliar rápido no código da própria empresa e trocar o padrão num único lugar.

Rotear por tarefa. Renomear um componente não exige o modelo que desenha sistemas. A Databricks diz que o seu roteador reduz o custo médio por tarefa em mais de 30%, com qualidade próxima à do modelo mais caro, e tira dos desenvolvedores o peso de escolher.

Mostrar a cada pessoa o próprio gasto. Um relatório individual periódico, com sugestões, vale cerca de 10%, segundo a Databricks. Wendell cita outra empresa que imprime o modelo e o custo em cada pull request.

Cortar o overhead de tokens. O harness em volta do modelo pesa tanto quanto o modelo. No benchmark interno da Databricks, o mesmo modelo em dois harnesses diferentes variou mais de 2x em custo, e ajustar o harness e o cache economizou perto de 50%. É o que vimos quando a Asana cortou 76x o custo do seu agente de navegador, quase tudo antes de trocar de modelo.

Tetos rígidos punem justamente quem você quer manter

A parte da entrevista que mais vale copiar é sobre limites. Um teto rígido de gasto é a primeira reação óbvia, e a Databricks concluiu que é uma má reação. Ele interrompe as pessoas no meio da tarefa e custa horas de trabalho. Quem bate no teto costuma ser quem mais usa e melhor usa. E parte dessas pessoas responde migrando para uma conta pessoal, onde a empresa não enxerga mais nada.

A Databricks trocou o teto por uma fricção que aumenta aos poucos.

Do acesso livre ao bloqueio: onde a Databricks está hoje

Ilimitado, modelo mais caroTeto rígido

1. Onde começouTodas as barreiras removidas para acelerar a adoção
2. AvisoO desenvolvedor vê o gasto
3. AprovaçãoAlguém autoriza continuar
4. RebaixamentoO trabalho segue num modelo mais barato
5. BloqueioÚltimo recurso

Isso coincide com a posição que tomamos quando as plataformas começaram a lançar limites de gasto com IA: tetos rígidos servem para exploração, enquanto o uso em produção precisa de orçamentos com alertas e um caminho definido além do limite. O rebaixamento é o passo elegante. O desenvolvedor continua trabalhando; a empresa para de pagar preço de fronteira naquela sessão.

Preço por tarefa, medido no seu próprio código

Dois achados do benchmark interno da Databricks, montado a partir de pull requests reais e corrigido rodando os testes, e não por um LLM juiz, deveriam mudar a forma como os times comparam modelos:

• Um modelo aberto, o GLM 5.2, empatou em qualidade com o Opus 4.8 da Anthropic, custando cerca de um terço a menos por tarefa.
• Um modelo 1,7 vez mais barato por token custou mais por tarefa, porque consumiu mais tokens.

Preço por token é um mau indicador de custo. A unidade que importa é o custo de uma mudança aceita, que é o argumento do nosso framework de preço de inferência por tarefa concluída e da ideia de que o modelo mais barato é aquele cujos erros você consegue capturar. O benchmark da Databricks, corrigido por testes, é uma versão prática das duas coisas.

A camada de controle é a pré-condição

Todas as alavancas acima dependem de uma coisa: todo o tráfego das ferramentas de código passar por uma única camada que consiga enxergá-lo e direcioná-lo. A Databricks roteia Claude Code, Codex, Cursor e as próprias ferramentas por um único gateway, que depois virou o produto Unity Gateway. O conselho de Wendell a um CTO é direto: “descubra para onde o dinheiro está indo”. A maioria das empresas não sabe dizer quanto gasta com IA por time ou por modelo.

Essa camada também está virando uma questão contratual, agora que a OpenAI quer aprovar os gateways que oferecem seus modelos. O argumento de engenharia para ter uma não está em dúvida. Uma empresa que não enxerga o próprio tráfego de IA não consegue roteá-lo, orçá-lo nem trocá-lo, e vai continuar pagando a Lamborghini para ir à padaria da esquina.