Olá pessoALL,

Você abre um anúncio de IA, encontra outros dez links e, quando termina de ler, ainda precisa entender por que a conta cresceu. O boletim Microsoft FinOps de setembro reúne bastante coisa pra acompanhar. Fui ler com uma preocupação: quais dessas novidades ajudam a entregar o trabalho gastando menos, sem empurrar o problema pra quem vai revisar depois?

O que mudou na conversa sobre custo de IA

Tem lançamento de setembro, atualização e material de meses anteriores retomado pelo boletim. Considerei a disponibilidade em 8 de outubro de 2026, porque alguns recursos mudaram de status depois de setembro.

Pra comparar tudo isso, vou usar o custo por tarefa concluída. Num agente de código, pode ser uma alteração aprovada, com testes passando. Num agente financeiro, uma análise validada. A conta inclui chamadas ao modelo, ferramentas, novas tentativas e o tempo de revisão humana.

O preço de um milhão de tokens ajuda, mas conta só parte da história. Um modelo barato que exige três correções pode sair caro. Já uma execução mais lenta pode atender perfeitamente uma tarefa que vai rodar de madrugada.

Routines, Flex Processing, HydraFusion e as mudanças no Copilot mexem em partes diferentes dessa conta: frequência de execução, tarifa, colaboração entre modelos e contexto.

Routines: agentes que continuam trabalhando depois da conversa

Routines chegou à disponibilidade geral no Foundry Agent Service. O recurso permite executar agentes em um horário específico, numa agenda recorrente ou por eventos. As integrações iniciais incluem eventos de issues no GitHub e novas mensagens em canais do Teams.

A configuração reúne gatilho, ação, identidade e conexões, com histórico das execuções. Conforme a autenticação das ferramentas, a rotina pode usar permissões delegadas de quem a criou ou a identidade do próprio agente.

Eu resolveria essa escolha antes de definir a agenda. Uma rotina que acompanha o seu trabalho pessoal e outra compartilhada pela empresa têm responsáveis e necessidades de acesso diferentes. Quem vai responder por essa automação?

Existe também o reminder tool, ainda em preview e disponível para hosted agents. Ele permite que o agente agende uma continuação na mesma conversa, preservando o contexto. Uma Routine convencional inicia uma conversa nova. Essa diferença está detalhada na documentação de reminders.

Num exemplo hipotético, você pede uma análise que depende da exportação de um relatório. O agente inicia o trabalho, guarda o identificador e agenda uma verificação pra depois. Quando os dados chegam, continua a análise sem exigir que você volte ao chat.

Mas continuar trabalhando sozinho também significa continuar consumindo. A economia vai depender de como você organiza essas verificações.

Se essa rotina hipotética verifica uma tarefa a cada cinco minutos, durante oito horas, são 96 verificações por dia. Em 22 dias úteis, seriam 2.112. Antes de chamar um modelo em todas elas, eu verificaria se uma consulta simples à API resolve a checagem de status.

Também definiria prazo máximo, limite de tentativas e condição de encerramento. Se a exportação falhou definitivamente, a automação precisa parar e encaminhar a pendência. Ficar repetindo a mesma pergunta durante dias só mantém o consumo.

Nas tarefas recorrentes, acompanharia o custo acumulado por rotina, inclusive das execuções sem resultado útil. Uma agenda frequente demais ou uma integração que parou de entregar dados precisa aparecer nessa análise.

Flex Processing: quando esperar pode reduzir a conta pela metade

Flex Processing oferece 50% de desconto sobre o Standard correspondente nos tokens de entrada e saída. Continua em public preview. Você escolhe Flex por requisição, usando um deployment Global Standard compatível e compartilhando sua quota.

Você usa o mesmo modelo, com outra oferta de processamento: latência variável, capacidade sujeita à disponibilidade e ausência de SLA. A API continua síncrona, ou seja, a chamada espera pela resposta.

A lista de modelos compatíveis inclui GPT-5.6 Sol, Terra e Luna, na versão de 9 de julho, e GPT-6 Astra, de 3 de setembro. Confira a combinação de modelo e configuração antes de planejar a mudança.

Quando falta capacidade Flex, a requisição pode receber HTTP 429. Essa rejeição por indisponibilidade não gera cobrança. Configuração incompatível pode retornar HTTP 400. Também não existe fallback automático para Standard. Essas condições estão na documentação de Flex Processing.

O desconto que chega à fatura depende de como a aplicação lida com essas falhas. Retries são novas tentativas. Fallback é recorrer a uma alternativa quando o caminho inicial falha. Você precisa limitar os dois.

Eu começaria por avaliações de prompts, enriquecimento de documentos ou análises em background que tolerem espera. Ajuda ter um prazo definido: esse relatório, por exemplo, precisa estar pronto antes das oito da manhã.

Nesse cenário, a aplicação poderia tentar Flex algumas vezes, respeitando os intervalos indicados pelo serviço. Ao atingir o limite, precisa decidir se aguarda, encerra ou usa Standard. Quanto mais perto do prazo, mais relevante fica essa escolha.

Se houver timeout, repetir a operação de negócio pode duplicar seus efeitos. Por isso, manteria um identificador da tarefa e separaria a geração da resposta das ações que alteram sistemas.

Batch também entra nessa comparação. Ele recebe lotes de requisições de forma assíncrona, com meta de processamento em 24 horas e desconto de 50% sobre Global Standard. Você encontra o funcionamento na documentação de Batch.

Oferta	Forma de execução	Custo relativo de inferência	Onde eu avaliaria
Standard	Requisição online	Referência	Interação que precisa responder prontamente
Flex	Requisição síncrona, latência variável	50% menor	Trabalho tolerante a espera e indisponibilidade
Batch	Lote assíncrono, meta de 24 horas	50% menor	Grandes volumes preparados para processamento em lote

Suponha, numa conta ilustrativa, US$ 1.000 mensais de inferência Standard. Mantendo modelo, volume e proporção de entrada e saída, essa parcela cai para US$ 500 se tudo puder rodar em Flex.

Mas, se 80% desse consumo equivalente usar Flex e 20% precisar de Standard, teremos US$ 400 mais US$ 200. O total fica em US$ 600, com 40% de economia. Essa proporção é de consumo equivalente de tokens, porque as requisições têm tamanhos diferentes.

A simulação deixa de fora ferramentas, infraestrutura e tentativas adicionais. Pra saber quanto a mudança economizou, acompanharia o custo por tarefa e quanto do consumo ficou em Flex ou precisou de fallback.

Pretendo gravar um vídeo só sobre Flex Processing, com configuração, código e o comportamento da aplicação. Enquanto isso, já dá pra identificar quais tarefas do seu cenário podem esperar.

HydraFusion: escolhendo também como os modelos trabalham juntos

Project HydraFusion está em research preview no GitHub Copilot CLI. Além de escolher modelos, ele define como vão trabalhar na tarefa. São três modos:

• Single: um modelo conduz a tarefa.
• Cascade: um modelo mais econômico começa. Uma avaliação determina se a tarefa precisa de um modelo mais forte.
• Critique: um modelo produz a solução, outro faz uma crítica independente e o primeiro pode revisá-la.

No Critique, o crítico pertence a outra família de modelos e trabalha sem ferramentas, em modo de leitura. A cobrança considera os modelos utilizados, nas respectivas tarifas.

Nas avaliações offline publicadas pelo GitHub, a referência foi Claude Opus 5, sob condições controladas. O anúncio do Project HydraFusion apresenta estes resultados para as configurações testadas:

Benchmark	Redução estimada de custo	Variação de qualidade
TerminalBench 2.1	67%	+4,9 pontos percentuais
DeepSWE	36%	−1,5 ponto percentual
CheckpointBench	65%	−0,1 ponto percentual

Eu ainda não medi isso num repositório próprio. E, olhando os resultados publicados, a perda de 1,5 ponto percentual no DeepSWE precisa entrar na decisão junto com os 36% de economia.

Pra avaliar, escolheria tarefas com dificuldades diferentes, desde uma mudança localizada até uma investigação que cruza vários arquivos. Incluiria também correções com exigências de segurança, definindo critérios de aprovação pra cada grupo.

Minha hipótese inicial seria experimentar Cascade nas alterações pequenas. Se o primeiro modelo resolve com qualidade, a tarefa termina cedo. Se entrega um rascunho inadequado com frequência, aquela primeira etapa pode virar trabalho desperdiçado antes de acionar o modelo mais forte.

No Critique, observaria quais problemas a revisão encontra e se justificam a chamada adicional. Também registraria quando o crítico pede mudanças desnecessárias. É uma etapa a mais pra pagar, e eu gostaria de saber o que ela está corrigindo.

A seleção automática do Copilot escolhe um modelo pra cada prompt. HydraFusion também decide como a tarefa passa por modelos diferentes, incluindo etapas de revisão ou escalada.

Na comparação, somaria o custo dos modelos usados e acompanharia o tempo até a conclusão, junto com a intervenção humana necessária. Só adotaria a configuração depois de verificar esses resultados nas tarefas que preciso entregar.

Como o GitHub está reduzindo desperdício nos agentes de código

O GitHub publicou quatro mudanças no harness do Copilot, a camada de software que organiza instruções, ferramentas e execução ao redor do modelo:

1. Compressão seletiva de saídas repetitivas de instalação, build e testes, preservando conteúdo necessário à investigação.
2. Remoção de formatação dispensável, como prefixos de linha adicionados pela ferramenta de visualização.
3. Redução das instruções de tarefas. Uma primeira versão prejudicou o paralelismo e precisou de correção.
4. Entrega direta dos resultados de tarefas em background, evitando chamadas adicionais só para buscá-los.

Também houve uma avaliação do RTK. Na integração e nos workloads que o GitHub analisou, comprimir a saída fez o agente reler conteúdo e executar comandos de novo. A saída inicial ficou menor, mas o trabalho aumentou.

Ao remover prefixos, o GitHub mediu aproximadamente 5% menos custo de inferência offline e 3% menos custo médio diário por usuário online. Encurtar instruções economizou cerca de 1.300 tokens por turno. Já a entrega direta de resultados reduziu AI credits em 2,3%. Os detalhes estão em How we make AI coding more cost efficient without sacrificing task quality.

Como são experimentos e métricas diferentes, esses percentuais não podem ser somados pra calcular uma economia total.

Eu teria cuidado ao usar esse resultado pra julgar o RTK em qualquer cenário. Uma ferramenta pode funcionar bem num fluxo e atrapalhar outro. Pra decidir se a compressão ajudou, você precisa contar o trabalho que veio depois.

Numa saída de testes com centenas de linhas repetidas e um erro relevante, faz sentido experimentar um resumo que preserve o erro. Num diff, cortar uma mudança pode esconder sua relação com outra, justamente a informação necessária pra corrigir o código.

Faria o experimento com uma amostra fixa de tarefas, mantendo acesso à saída original. Além de tokens e chamadas de ferramentas, mediria duração e taxa de conclusão. Também contaria quantas vezes o agente pede novamente algo que já recebeu.

Se ele precisa reconstruir o contexto porque o resumo retirou informação necessária, parte daquela redução inicial se perde nas chamadas seguintes.

Também revisaria as etapas mecânicas que a aplicação está deixando pro modelo. Consultar repetidamente uma ferramenta só pra descobrir que o trabalho ainda não terminou é um candidato, como mostra a mudança na entrega de resultados em background.

As outras novidades que merecem entrar no radar

Foundry: deployment, modelos e ferramentas

A atualização de preços mantém Global como referência. Data Zone US fica 10% acima, e EU/APAC, 20%. Deployments regionais fora dos EUA têm adicionais de 25% a 50%. No Brasil, o adicional é de 50% sobre Global. Cuidado com a leitura: esse percentual compara as ofertas e não equivale a um reajuste de 50%.

Em Standard pay-as-you-go, os novos adicionais valem para modelos lançados a partir de 1º de setembro. Para PTUs, a aplicação é mais ampla. Antes de refazer a conta, confira as condições no aviso de preços por deployment, a tabela de preços e a disponibilidade regional.

GPT-5.6, anunciado em julho, tem Sol, Terra e Luna para diferentes necessidades, com preço promocional de Sol até pelo menos 30 de novembro. GPT-6.1 Sol chegou em setembro, em GA, com contexto de até um milhão de tokens. Confira os preços específicos de contexto longo antes de aproveitar essa capacidade.

Em voz, o boletim inclui um anúncio de 1º de outubro: MAI-Transcribe-2-Streaming e MAI-Voice-2.1, incluindo Flash. A transcrição tem preço introdutório de US$ 0,54/hora até o fim de 2026. Para imagens, MAI-Image-2.6 e Flash oferecem geração e edição em public preview.

Toolboxes permite descobrir ferramentas conforme a necessidade. A redução próxima de 97% foi nos tokens de entrada do benchmark de grandes bibliotecas, comparada ao envio antecipado das ferramentas. Esse resultado tem um escopo específico; o desconto na aplicação inteira vai depender do restante do consumo.

Nos vídeos sobre Model Router e escolha de modelos, vale acompanhar a comparação entre candidatos e o registro de qual modelo atendeu cada solicitação. É o que permite avaliar o custo e a qualidade do conjunto.

Copilots: execução, visibilidade e controles

No resumo de agosto, aparecem os níveis de esforço do Cowork e o comando /cost, além de Automations e exportação de métricas do Copilot e Agent 365. O dashboard inclui consumo de AI credits do GitHub. Claude Fable 5.1 também chegou ao Cowork e Copilot Studio, conforme elegibilidade e rollout.

Home, Today, Office, Code e Autopilot fazem parte da visão das novas experiências. Pra planejar uma implantação, acompanharia a disponibilidade por tenant no AI at Work Roadmap.

Os controles de FinOps para IA acrescentam políticas por grupos e visibilidade de consumo, junto com acompanhamento de valor. O anúncio inclui Code e Copilot Managed Runtime, com Copilot Studio previsto a partir de outubro. Já o material de governança de agentes trata de inventário, responsáveis e acompanhamento contínuo.

GitHub: medir, limitar e observar

O catálogo ganhou Grok 4.7, Claude Opus 5.5 e GPT-6 Sol/Luna, com acesso conforme plano e rollout. Na seleção automática, você pode priorizar eficiência, equilíbrio ou inteligência. Confira as tarifas em Models and pricing.

As métricas de uso passaram a distinguir a janela Agents do VS Code. OpenTelemetry no Copilot app permite exportar telemetria, sem conteúdo de prompts e respostas por padrão. O Impact Dashboard adicionou engajamento por funcionalidade. Eu cruzaria esse uso com o resultado entregue antes de concluir que uma funcionalidade está trazendo retorno.

O sandbox local, anunciado em preview em setembro, chegou a GA em 7 de outubro. Os pedidos de aumento de budget também estão em GA para Business e Enterprise elegíveis, com exceção de Enterprise Managed Users.

Operação e valor: começar com um resultado mensurável

O trial do Azure SRE Agent remove a cobrança always-on por 30 dias, para até três agentes de clientes novos no serviço. O consumo ativo continua cobrado.

Customer Zero, Frontier Playbook e Microsoft Finance trazem referências pra escolher processos e medir resultados. No Playbook, acelerar funções, redesenhar processos e criar capacidades novas são intervenções com objetivos distintos.

Pra operação, os materiais de context engineering, governança e plataformas para agentes abordam seleção de contexto e limites durante as requisições, além de execução isolada com Azure Container Apps Sandboxes. Alertas financeiros e limites de execução se complementam.

O que eu priorizaria depois de ler tudo isso

Eu escolheria uma tarefa representativa do seu cenário e definiria o que conta como concluída. Registraria custo, duração, tentativas e revisão necessária. Com essa referência, seguiria esta sequência:

1. Separar o que exige resposta imediata do que pode esperar por Flex ou Batch.
2. Revisar frequência, encerramento e permissões das automações.
3. Avaliar contexto e modelos usando a mesma amostra de tarefas.
4. Acompanhar custo e qualidade juntos, com um responsável pelo consumo.

Assim, dá pra voltar àquela conta que cresceu e investigar uma mudança por vez. Você define o resultado esperado e verifica se a tarefa passou a custar menos, mantendo a qualidade necessária.

Qual tarefa você escolheria pra começar? Conta nos comentários. Pretendo aprofundar Flex Processing em vídeo, com a implementação e o comportamento das chamadas.

[]s e até a próxima