O GitHub anunciou em 9 de junho que o Claude Fable 5, modelo da Anthropic para tarefas longas de programação e trabalho do conhecimento, passou a ficar disponível no GitHub Copilot. A própria página do changelog depois registrou uma suspensão em 12 de junho e a reativação em 1º de julho, então o ponto técnico do anúncio precisa ser separado da disponibilidade de cada momento: o modelo entrou no Copilot, mas com política específica, cobrança por uso e uma exigência de retenção de dados diferente de outros modelos Claude.
Segundo o GitHub Changelog, o Claude Fable 5 ficou disponível para Copilot Pro+, Max, Business e Enterprise em superfícies como Visual Studio Code, Visual Studio, Copilot CLI, Copilot cloud agent, github.com, GitHub Mobile, JetBrains, Xcode e Eclipse. O rollout seria gradual, o que significa que a presença do modelo no seletor poderia variar por usuário, plano e organização.
O detalhe que muda a conversa para empresas é a retenção. O GitHub informou que administradores de Copilot Business e Enterprise precisam habilitar uma política própria para o modelo, desativada por padrão. Ao habilitar, a organização reconhece que prompts e saídas podem ser retidos por até 30 dias para operar classificadores de segurança da Anthropic. A página afirma também que essa retenção não se aplica aos outros modelos Claude no Copilot, que continuam sob Zero Data Retention.
O que mudou no Copilot
O anúncio coloca o Claude Fable 5 na categoria de modelos usados para tarefas mais longas e autônomas. A Anthropic descreve o Fable 5 como um modelo da classe Mythos, com foco em tarefas complexas de engenharia de software, conhecimento, visão e pesquisa científica. O mesmo comunicado diferencia Fable 5 de Mythos 5 pelas salvaguardas: Fable é a versão de uso geral; Mythos é restrito a parceiros específicos em áreas como ciberdefesa.
Para quem usa Copilot no dia a dia, isso muda a escolha de modelo. Não é apenas uma lista maior no seletor. A organização passa a decidir se aceita um modelo mais capaz para certos fluxos e, ao mesmo tempo, se aceita a política de retenção associada. Em ambientes com contratos rígidos, dados sensíveis, código proprietário ou exigência de ZDR, essa diferença precisa aparecer em política, treinamento interno e revisão de risco.
Também há um recorte de custo. O GitHub afirma que o modelo é cobrado por preço de fornecedor dentro de Usage Based Billing. Na prática, times que deixam agentes e IDEs chamarem modelos mais caros sem orçamento, limite ou visibilidade podem descobrir o custo só depois do uso. A decisão de habilitar o Claude Fable 5 deve vir junto de relatórios, limites por equipe e critérios claros para quando usar um modelo mais forte.
Retenção de dados vira requisito de arquitetura
Retenção por até 30 dias não significa automaticamente uso indevido dos dados, mas muda o desenho de governança. Uma organização que exige ZDR para todo código-fonte não pode tratar o Fable 5 como equivalente aos demais modelos Claude. A diferença precisa ser explícita em política de Copilot, documentação de segurança e orientação para desenvolvedores.
O ponto mais importante é separar tipos de conteúdo. Há diferença entre pedir explicação sobre um erro público, analisar trecho genérico, revisar código proprietário, colar log com identificador interno ou enviar material de cliente. Quando um modelo exige retenção para operar classificadores, a organização precisa definir quais desses usos são permitidos e quais continuam restritos a modelos sem retenção.
Isso afeta também agentes. Um agente que lê repositório, abre issue, interpreta falha de CI e prepara pull request pode carregar mais contexto do que um chat pontual. Se o modelo escolhido muda a política de dados, a configuração do agente não pode ficar implícita. O usuário precisa saber quando está usando Fable 5, quais dados entram no prompt e quais controles limitam o escopo.
Salvaguardas reduzem risco, mas não substituem política
A Anthropic afirma que o Claude Fable 5 usa classificadores de segurança que podem redirecionar respostas sobre certos temas para outro modelo, como Claude Opus 4.8. A empresa também diz que esses classificadores foram ajustados de forma conservadora e podem gerar falsos positivos. Essa escolha tenta equilibrar capacidade e segurança, mas não remove o dever de configurar o uso em cada organização.
Em engenharia, salvaguarda de fornecedor é uma camada. Ela ajuda a reduzir certos usos perigosos, mas não sabe sozinha quais arquivos são sensíveis, quais clientes têm restrição contratual, quais repositórios contêm segredo ou qual operação precisa de revisão humana. A política local continua necessária.
O post sobre Zero Data Retention em modelos de ponta conversa diretamente com essa decisão. ZDR não é selo genérico de qualidade; é um requisito operacional. Quando um modelo sai desse regime, a adoção precisa ser documentada e limitada.
O que revisar antes de habilitar
A primeira revisão é administrativa: quem pode habilitar o Claude Fable 5, para quais planos e em quais organizações. A segunda é de dados: quais repositórios, arquivos, logs e tickets podem ser enviados ao modelo. A terceira é de orçamento: que limite impede uma automação longa de consumir créditos sem controle.
Também vale revisar instruções de agente. Se uma automação pode chamar ferramentas, abrir PR, alterar arquivos ou comentar em issue, ela precisa de guardrails próprios. O post sobre prompt injection em agentes de IA explica por que permissões, revisão humana e limites de ferramenta importam antes do clique.
Para empresas brasileiras, o caminho prático é tratar o Claude Fable 5 como uma opção potente, não como padrão automático. Habilitar por equipe, testar em repositórios de menor sensibilidade, medir custo e deixar claro quando a retenção de dados se aplica reduz surpresa. Modelo mais capaz pode melhorar fluxo de desenvolvimento, mas só vira ganho operacional quando a política acompanha a capacidade.
