Olá pessoALL, hoje de manhã, tomando café e passando o olho no meu feed de notícias, três artigos apareceram um atrás do outro. Um do Visual Studio Blog sobre um controle novo de "thinking effort" nos modelos. Um do Microsoft Developer Community Blog chamado "Surprise AI bill?". E um do Azure Architecture Blog explicando a hierarquia de budgets do GitHub Copilot. Times diferentes, blogs diferentes, tudo publicado na mesma semana.

Esse post não é um case de cliente. É opinião mesmo, minha impressão depois de rodar Copilot num time próprio e de ajudar empresa a montar governança de IA: controle de budget em coding agent deixou de ser tarefa de FinOps e virou requisito de arquitetura. Do mesmo jeito que ninguém sobe API pública sem rate limit, ninguém deveria liberar agente de código numa empresa sem teto e sem alguém responsável por olhar o número.

As três notícias e o que elas têm em comum

Tell your model when to think harder: o Visual Studio 18.9 Insiders 2 passou a expor um controle de thinking effort por modelo, com níveis Low, Medium, High, Extra High e Max. Quanto mais alto, mais raciocínio e mais crédito consumido.

Surprise AI bill? GitHub Billing controls to the rescue!: o Chris Noring conta a história de uma fatura que veio maior que o esperado e mostra o caminho de investigação, de SKU até cost center, antes de aplicar qualquer guardrail.

Mastering GitHub Copilot Budgets: o Gaurav Bhardwaj destrincha a hierarquia de avaliação dos budgets e a ordem de precedência entre eles.

Repara no que os três têm em comum. Nenhum deles fala de qualidade de código ou de produtividade. Os três falam de onde o dinheiro vaza. Quando blogs de produto da Microsoft convergem pro mesmo assunto na mesma semana, normalmente é porque o suporte está recebendo o mesmo ticket repetidas vezes.

E eu já vivi esse ticket. No post em que rodei o CSV do meu time no preview tool do GitHub, a fatura de abril saiu de $457,91 no modelo PRU para $2.668,78 no modelo de AI Credits. Multiplicador de 5,83x, com 9 pessoas. Agora extrapola isso pra uma empresa com 300 devs. Ou 3.000.

O modelo mental que faltava: o parque aquático

Antes de configurar qualquer coisa, você precisa entender como o GitHub cobra. E a analogia do parque aquático que o Gaurav usou é a melhor que eu já vi pra isso, então vou pegar emprestada e adaptar.

Imagina sua empresa como um parque aquático:

• A caixa d'água compartilhada (included usage): cada licença Copilot Business ($19/mês) joga 1.900 AI Credits na caixa e cada licença Enterprise ($39/mês) joga 3.900. Não é balde individual, é um pool único da entidade de billing.
• Fase 1, o pool: todo dev licenciado bebe dessa caixa, de graça, até ela secar.
• Fase 2, o metered: caixa seca, a água extra custa $0,01 por crédito. E essa fase só liga se a empresa habilitar explicitamente a política de AI Credit Paid Usage.
• A pulseirinha individual (per-user budget): limita quanto uma pessoa consome, somando fase 1 e fase 2.
• A comanda do grupo (budget de org, cost center ou enterprise): só entra em ação na fase 2, limitando o gasto excedente.

Na prática, o que isto significa é que existem dois tipos bem diferentes de limite convivendo no mesmo painel. Um conta crédito incluído mais crédito pago, o outro conta só o pago. Confundir os dois é a origem de quase todo "por que meu dev foi bloqueado se ainda tem budget sobrando?".

E aqui já cabe a primeira ressalva honesta: se o seu time nunca estourou o pool, você nunca viu nada disso funcionar de verdade. Você tem uma configuração de billing que nunca foi exercitada, e isso é sorte, não segurança.

Como o GitHub decide bloquear (a parte que ninguém lê)

Toda vez que alguém dispara um Copilot Chat, um agente ou uma sessão de CLI, o GitHub avalia a requisição em três etapas, nessa ordem.

Passo 1, o guardrail pessoal (User-Level Budget). Limita o consumo total da pessoa, pool mais metered, e é sempre hard stop. Entre os limites de usuário vale o mais específico: override individual, depois cost center (per user), depois universal.

Passo 2, a checagem do pool incluído. Se a pessoa ainda tem espaço no limite dela, o sistema olha se sobrou crédito incluído. Dá pra cercar o pool por cost center, pra um time não drenar os créditos que outro time trouxe com as licenças dele.

Passo 3, os tetos de excedente. Pool vazio, começa a cobrança de $0,01/crédito. Aí o sistema checa, nesta ordem: cost center budget, organization budget, enterprise budget.

Agora a regra que fecha o raciocínio, e que o Gaurav batizou muito bem de "lowest headroom wins": se o dev tem $10 sobrando na pulseirinha pessoal, mas o budget de enterprise tem só $1 até o teto, quem bloqueia é o enterprise. Vale sempre o limite que chega primeiro no fim.

E o que acontece quando bloqueia? Param de funcionar Copilot Chat, CLI, agentes e modelos de raciocínio, ou seja, tudo que consome AI Credit. Continuam funcionando as code completions inline e as next edit suggestions, que vêm inclusas na licença.

Isso é uma decisão de produto muito boa e quase ninguém comentou. Mesmo com a torneira fechada, o dev perde o agente mas mantém o autocomplete.

Vale ressaltar um detalhe cruel: uma requisição bloqueada não cai automaticamente para um modelo mais barato, ela simplesmente falha. Se você esperava um fallback silencioso pra Haiku, esquece.

Antes do limite, a investigação: siga o dinheiro

Aqui é onde o post do Chris Noring brilha, e é onde eu mais concordo com ele. A tentação, quando a fatura assusta, é criar um teto baixo pra todo mundo na sexta-feira à tarde. Mas limite criado no susto não resolve o problema, só transfere a dor pro time de produto na segunda de manhã.

O caminho é outro: descobrir de onde veio o aumento antes de decidir quanto cortar.

Comece por qual produto cresceu. Em Billing and licensing → Usage → Metered usage, agrupe por billing category (SKU). Isso te diz se o crescimento é Copilot Enterprise, cloud agent, Actions ou outra coisa.

Depois, qual organização. Um total consolidado esconde um pico concentrado numa unidade só.

Por último, qual cost center. Organização ainda é grosso demais. Cost center é o agrupamento de billing que amarra o consumo a um time, programa ou função, ou seja, a uma pessoa que pode explicar o número.

No exemplo do artigo, esse drill-down termina com um cost center concentrando a maior parte do consumo, numa média de $20.000/mês. Isso muda completamente a conversa. Em vez de "a IA está cara", você passa a discutir "esse time gasta $20.000 por mês, e o líder dele consegue dizer se isso está pagando ou não".

Lição aprendida, e essa eu aprendi na marra olhando meu próprio CSV: sem cost center, todo mês vai ser "alguém" que estourou. Com cost center, vira "o squad X, e dá pra investigar".

Onde quase todo mundo erra: o toggle que não vem ligado

Você fez tudo certo. Investigou, achou o cost center, criou o budget de organização de $200.000 e saiu da tela com sensação de dever cumprido.

Mas olha bem a caixinha "Stop usage when budget limit is reached". Ela não vem marcada por padrão. E budgets de organização, cost center e enterprise, sem esse toggle ligado, não param nada: eles só mandam e-mail enquanto a conta continua subindo.

Essa é a diferença entre expectativa e realidade que mais custa dinheiro. O admin acha que blindou a empresa, o gasto continua acumulando sem teto, e a fatura chega. Aí vem a reunião desconfortável em que alguém pergunta "mas a gente não tinha configurado um budget?".

E tem uma segunda armadilha, mais sutil, que aparece na letra miúda azul da tela: "Usage before budget creation isn't counted in the current billing cycle". Se você criar o budget no dia 18 do ciclo, o consumo dos dias 1 a 17 não entra na conta, e a primeira fatura pode estourar o limite que está escrito na tela. É comportamento documentado, não é bug. Mas se ninguém te avisar, parece bug.

Agora, sendo justo com quem projetou isso: deixar o Stop usage desligado é uma escolha legítima em cost center. O dono do time recebe alerta em 75%, 90% e 100%, e tem tempo de revisar o workload ou pedir mais teto antes de alguém travar no meio da sprint. É exatamente o que eu recomendo nos dois primeiros meses de qualquer piloto.

O problema não é o toggle desligado. O problema é o toggle desligado no enterprise, sem ninguém saber que ele está desligado.

Mea-culpa: agora existe budget por usuário de verdade

Aqui eu preciso voltar atrás numa coisa que escrevi.

No post anterior, eu disse que não existia budget no nível de usuário e ensinei o workaround: criar um cost center com uma pessoa só dentro, pra simular um teto individual. Funcionava, mas era gambiarra.

Não precisa mais. O escopo Users apareceu no formulário de New budget, com direito a badge de New, e ele faz exatamente o que eu queria: define limite por usuário licenciado, contando crédito incluído e crédito pago.

São três níveis, e a ordem importa. O universal é a linha de base pra todo mundo com licença. O cost center (per user) sobrescreve o universal para os usuários daquele cost center. E o individual user sobrescreve tudo, pra uma pessoa específica.

O exemplo da tela deixa a conta explícita: $200 por usuário equivalem a 20.000 AI credits a $0,01/crédito. É o tipo de tradução que ajuda muito na hora de defender o número numa reunião de orçamento, porque tira a conversa do abstrato.

Um exemplo prático de precedência: universal de $100, cost center de $200, override individual de $500. O especialista fica com $500, os colegas do cost center dele ficam com $200 cada, e o resto da empresa com $100 cada. Os tetos compartilhados de org e enterprise continuam valendo em paralelo, e quem esgotar primeiro bloqueia.

Mas a tentação óbvia aqui é errada. Quando o gasto assusta, o instinto é baixar o teto universal pra todo mundo, o que pune exatamente quem está entregando mais, porque heavy user quase sempre é heavy delivery. A ordem certa é a inversa: baseline razoável no universal, exceção por cost center onde o resultado justifica, e override individual só com necessidade documentada. Assim a exceção continua sendo fácil de auditar.

O outro lado da moeda: cortar desperdício, não só cortar teto

Até aqui, tudo que eu falei é sobre teto, e teto é defesa. Mas defesa sozinha não ganha jogo, e é por isso que o terceiro artigo, o do thinking effort, acabou sendo o mais interessante dos três apesar de parecer o menos relacionado.

Renomear uma variável e debugar um memory leak não precisam do mesmo nível de raciocínio. Ainda assim, na configuração padrão, o modelo trata os dois igual. O controle novo do Visual Studio muda isso: no model picker, em Manage models, o thinking effort ganhou uma coluna própria, do lado das capabilities, do context size e do custo.

Os níveis são Low, Medium (geralmente o default), High, e em alguns modelos Extra High e Max. Quanto mais alto, mais crédito.

Por que isso importa tanto? Porque quando eu abri meu próprio drill-down de custo por modelo, o Claude Opus 4.6 sozinho respondia por 63% do custo em AI Credits do time, e a família Anthropic inteira passava de 90%. Por unidade real de uso, Opus pesa cerca de 9x o que pesa Sonnet. E isso com zero otimização consciente da minha parte, diga-se, porque eu mesmo deixei Opus como default achando que garantia a melhor resposta.

O thinking effort adiciona um segundo eixo nessa conta. Antes você escolhia só qual modelo. Agora escolhe qual modelo e quanto ele pensa, mesmo modelo e mesma conversa, com esforço diferente por tarefa.

Vale registrar que a comunidade reclamou disso nos comentários do artigo, e a crítica é justa: um leitor comparou a experiência com a de um piloto de corrida tendo que ajustar cada botãozinho antes de usar IA. Concordo em parte. Ajuste manual constante mata produtividade, e o ideal seria o modelo calibrar sozinho. Mas enquanto isso não existe, prefiro ter o botão do que não ter, principalmente porque em escala de empresa esse botão vira política e não escolha individual.

E é aqui que os três artigos se encontram. Budget cobre o risco depois que o gasto aconteceu; escolha de modelo e thinking effort atacam o desperdício na origem. Governança que só aperta o teto faz o time reclamar, e governança que só solta o consumo faz o CFO reclamar.

O roteiro que eu implementaria hoje

Baseado no que eu já quebrei na minha própria tenant, essa é a sequência que eu seguiria numa empresa começando do zero.

1. Habilite cost centers antes de habilitar qualquer teto. Sem eles você não tem sujeito na frase. Um cost center por squad, ou por unidade de negócio, o que fizer sentido no seu organograma.
2. Rode duas a quatro semanas só com alertas. Budgets criados, Stop usage desligado, alertas de 75/90/100 ligados. Você quer enxergar o baseline antes de bloquear qualquer coisa, porque travar dev com teto mal calibrado no meio de uma sprint é a pior forma possível de começar.
3. Ligue o Stop usage no enterprise. Esse é o fusível, o que impede uma sessão agentic em loop de custar $5.000 num sábado. Se você for ligar em um lugar só, ligue nesse.
4. Defina o universal per-user budget com base no dado, não no medo. No meu time, os $2.668,78 de abril divididos por 9 pessoas dão $296 por cabeça. Um teto universal de $200 bloquearia gente todo mês. Pegue a média real do seu baseline e some uns 50% de folga.
5. Crie exceções por cost center, não por pessoa. Data science, plataforma e quem usa coding agent pesado vão precisar de mais. Exceção em grupo é auditável; 300 overrides individuais são um pesadelo de manutenção.
6. Trate escolha de modelo e thinking effort como política, não como preferência. Default sensato no settings do time (Sonnet ou equivalente em Medium), com Opus em High reservado pro que realmente exige, tipo refactor complexo e decisão de arquitetura.
7. Nomeie um dono da revisão. Alguém que olha alertas, requisições bloqueadas e resultado de negócio numa cadência fixa. Sem dono, budget vira um monte de e-mail que ninguém lê.
8. Cuidado com budgets sobrepostos. O menor teto sempre manda. Se você cria budget no enterprise e no cost center pra mesma SKU sem pensar, alguém vai ser bloqueado e ninguém vai entender o porquê.

Lições aprendidas

1. Coding agent entra na mesma categoria de risco de uma API pública sem rate limit. Consumo elástico, disparado por automação, sem limite natural. Budget aí é decisão de arquitetura, não burocracia de FinOps.
2. Budget sem Stop usage ligado não bloqueia nada. Nos escopos de org, cost center e enterprise, o toggle desligado só manda e-mail enquanto a conta sobe.
3. Investigue antes de limitar. SKU, depois organização, depois cost center. Teto criado no susto castiga quem entrega e não conserta a origem do gasto.
4. Teto uniforme é o jeito mais rápido de matar adoção. Baseline universal, exceção por cost center, override individual só com necessidade documentada.
5. Escolha de modelo e thinking effort cortam o desperdício na origem. Budget só evita que o desperdício vire prejuízo, ele não reduz consumo burro.
6. Quem hoje está dentro da cota é quem vai liderar o ranking de custo amanhã. O subsídio invisível acabou, e o dado que confortava virou o dado que assusta.

E na sua empresa?

Se você administra Copilot em qualquer escala, faz um exercício de cinco minutos comigo. Abre Billing and licensing → Budgets and alerts e responde três perguntas, sem consultar ninguém:

Quantos budgets existem hoje? Em quantos deles o Stop usage está realmente ligado? E quem é a pessoa, com nome e sobrenome, que recebe os alertas de 75%?

Se você travou em alguma das três, esse é o seu backlog da semana. E se travou nas três, você não está sozinho: eu também travei quando fiz esse exercício na minha própria tenant, e é exatamente por isso que esse post existe.

Me conta nos comentários: na sua empresa, o controle de gasto de IA é responsabilidade de quem? Do time de engenharia, do FinOps, ou daquele lugar confortável chamado "ninguém, até a fatura chegar"?

Referências

Os três artigos que originaram esse post

• Tell your model when to think harder — Rachel Kang, Visual Studio Blog: o controle de thinking effort no Visual Studio 18.9 Insiders 2
• Surprise AI bill? GitHub Billing controls to the rescue! — Chris Noring: o caminho de investigação SKU → org → cost center e os guardrails
• Mastering GitHub Copilot Budgets — Gaurav Bhardwaj: a hierarquia de avaliação e a analogia do parque aquático

Changelogs do GitHub

• Assign enterprise teams to cost centers — atribuição de times a cost centers
• Per-user AI credit budgets available for cost centers — o escopo Users que substitui o workaround do cost center unitário
• Cost centers now support included usage caps — cerca no pool de créditos incluídos

Documentação

• Setting up budgets to control spending on metered products — escopos, alertas e o toggle de stop usage
• Manage and monitor spending for GitHub Copilot — hub de FinOps do Copilot
• Models and pricing — custo por modelo e por 1M tokens
• Pick, manage, and get the most from your models — tour completo da tela de gerenciamento de modelos do Visual Studio

Posts relacionados aqui no blog

• Rodei o CSV do meu time no preview tool do GitHub: $457 viram $2.668 — os números reais que fundamentam esse post
• A Conta Chegou: GitHub Anuncia AI Credits e Marca 1º de Junho como o Fim da Era PRU — a mecânica de PRU → AIC e pooled credits

[]s e até a próxima.