Anthropic lança o Claude Fable 5.2 e o Mythos 5.2, com fast mode até 2,5 vezes mais rápido
A Anthropic anunciou nesta segunda, 9 de novembro, o Claude Fable 5.2 e o Claude Mythos 5.2, que a empresa descreve como o mesmo modelo de base. O Fable 5.2 já está disponível em todas as plataformas, inclusive AWS, Google Cloud e Microsoft Azure, e na API pelo id claude-fable-5-2, a US$ 8 por milhão de tokens de entrada e US$ 40 por milhão de saída. O Mythos 5.2 continua restrito: chega a profissionais de segurança e pesquisadores de ciências da vida pelos programas de verificação e a clientes Enterprise pelo Claude Security.
Segundo a Anthropic, quem testou viu respostas até 30% mais rápidas que as da versão 5.1, e no esforço Medium, o padrão nos apps e no Claude Code, o 5.2 resolve tarefas difíceis com menos tokens que o 5.1. A tabela do anúncio coloca o Fable 5.2 à frente do 5.1 e do Opus 5.5 em benchmarks de código como o FrontierSWE v2 (69,9% contra 56,3% do 5.1). A novidade com mais efeito no bolso é o fast mode opcional: gera tokens até 2,5 vezes mais rápido, custa o dobro (US$ 16 e US$ 80 por milhão) e funciona no Claude Code, na Claude Platform, no Google Cloud e no Microsoft Foundry.
O próprio anúncio recomenda começar pelo Opus 5.5 na maioria das tarefas de código do dia a dia. O Fable fica para o que é mais pesado, e nos planos Pro e nos assentos padrão do Team ele entra em até 50% do limite semanal de uso.
Para quem usa .NET: Quem chama a API do Claude a partir de .NET troca só o id do modelo; antes de ligar o fast mode, faça a conta: o preço por token dobra.
Fonte: Anthropic
Microsoft mede: o rótulo de versão muda quanto alguns agentes conferem uma atualização
Waldek Mastykarz, da Microsoft, testou se agentes de código levam o SemVer a sério. Ele criou uma biblioteca npm fictícia com uma função renomeada e entregou a mesma mudança, byte a byte, ora como 1.4.3 (patch), ora como 2.0.0 (major), para o GitHub Copilot CLI atualizar. No primeiro experimento, o Claude Sonnet 5.5 conferiu a atualização em 10 de 10 execuções quando ela vinha como major, mas só em 2 de 10 quando vinha como patch. Opus 5.5, GPT-6.1 Sol e GPT-6.1 Terra conferiram sempre.
No segundo experimento, com seis modelos e 540 execuções, os merges sem conferência foram 13% sob o rótulo patch, 9% sob minor e 4% sob major. O efeito mais claro apareceu no Claude Haiku 5.5 (37% de merges sem conferir em patch, contra 7% em major). Quatro merges deixaram a main quebrada, todos com rótulo patch ou minor. O autor admite os limites: a quebra foi colocada de propósito num patch, os apps eram pequenos e não havia release notes.
A conclusão dele cabe numa frase: o número da versão diz ao agente o quanto se preocupar, mas só os testes dizem se ele deveria.
Para quem usa .NET: Vale igual para NuGet: se um agente ou o Dependabot sobe pacotes por você, exija CI verde em toda branch de dependência, inclusive nas de patch.
Fonte: Microsoft Developer Blogs
Copilot code review passa a ser configurado por API e usa três modelos no esforço equilibrado
O GitHub anunciou na sexta, 6 de novembro, que as configurações do Copilot code review podem ser gerenciadas pelas APIs REST e GraphQL, da política da empresa até cada repositório. Nos endpoints de repositório funcionam GitHub Apps e PATs fine-grained com a permissão Administration; nos de empresa e organização, não.
O resumo da revisão ficou mais compacto, com os arquivos pulados juntos numa seção "Files not reviewed". As sessões do agente de revisão passam a mostrar os créditos de IA gastos, a regra de pedir revisão automática aceita uma lista de exceções e, no esforço equilibrado, a revisão usa três modelos revisores e outro que junta os achados. Revisões que falham ou estouram o tempo são repetidas uma vez, sozinhas. Vale para os planos Pro, Pro+, Max, Business e Enterprise.
Para quem usa .NET: Quem padroniza repositórios .NET por script pode ligar a revisão do Copilot pela API junto com as outras regras de branch, sem clicar repo por repo.
Fonte: GitHub Changelog
Simon Willison sugere esconder a descrição de PR escrita pelo agente atrás de um details
Simon Willison publicou nesta segunda uma prática simples para PRs abertos com agentes de código. As descrições que eles escrevem costumam estar corretas, mas são longas demais para alguém ler. A proposta dele: abrir o PR com um parágrafo curto escrito por uma pessoa e colocar o texto completo do agente dentro de um bloco <details><summary>, que o Markdown do GitHub mostra recolhido.
No rótulo do bloco ele põe o modelo e o nível de esforço usados, como "Claude Opus 5.5 Medium". Quem revisa lê o essencial em segundos, abre o detalhe só se quiser, e o histórico registra com que ferramenta o código foi feito.
Para quem usa .NET: Serve para qualquer repositório .NET no GitHub: basta o HTML no corpo do PR, sem configuração.
Fonte: Simon Willison
Minha leitura
O modelo novo vai dominar as manchetes, mas a notícia que eu levaria para a reunião de segunda é a do SemVer. Ela mostra, com números, que um agente pode decidir o quanto conferir a partir de um rótulo que qualquer pessoa digita. A defesa não muda com o modelo: testes que rodam em toda atualização, inclusive nas pequenas. E isso conversa com o calendário: o suporte ao .NET 8 e ao .NET 9 termina amanhã, 10 de novembro, segundo o blog do .NET, e muita gente vai deixar um agente cuidar da migração para o .NET 10. Sem uma suíte de testes que pegue a quebra, o agente vai confiar no número da versão.
No Fable 5.2, o barulho é a corrida de benchmarks; o que importa é o preço e o fast mode, que dobra o custo por token. A própria Anthropic manda começar pelo Opus 5.5 no dia a dia, e eu seguiria essa ordem: subir de modelo só quando a tarefa pedir. Já o Copilot code review por API e o truque do details são coisas pequenas que deixam o trabalho com agentes mais governável, e é aí que está o ganho.
Leia também
- Claude Code com .NET: configuração e skills (Parte 1)
- .NET 10 e C# 14: as novidades que você precisa conhecer
Precisa de ajuda com backend .NET e IA aplicada? Conheça o serviço.