huggingface_hub, utilizada por milhares de projetos para acessar modelos, datasets e outros recursos da plataforma, possui um mecanismo capaz de identificar quando está sendo executada dentro de diferentes agentes e ferramentas de programação com inteligência artificial.Entre os ambientes reconhecidos estão ferramentas como Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Devin, Cline, Kiro e outras.
A informação que circula nas redes afirma que atualmente o registro utilizado pela Hugging Face contém 26 agentes. Esse número é compatível com o registro observado em setembro de 2026, mas não deve ser tratado como uma quantidade fixa: a arquitetura foi desenvolvida justamente para permitir que novos agentes sejam adicionados sem exigir uma nova versão da biblioteca instalada no computador.
A questão mais importante, portanto, não é simplesmente quantos agentes estão na lista.
É o que acontece depois que um deles é identificado.
Quando a biblioteca reconhece um ambiente registrado, as requisições realizadas através dela podem carregar uma identificação no User-Agent, no formato agent/<nome>. A própria Hugging Face utiliza esses dados para produzir estatísticas sobre quais agentes estão acessando sua infraestrutura.
Isso transforma algo aparentemente técnico em uma discussão relevante sobre telemetria, transparência e privacidade no ecossistema de agentes de IA.
Como a Hugging Face descobre qual agente está rodando?
O mecanismo não precisa analisar conversas, código-fonte do projeto ou prompts do usuário para realizar essa identificação.
Ele utiliza principalmente sinais presentes no próprio ambiente de execução.
A documentação oficial explica que agentes podem utilizar variáveis padronizadas como AI_AGENT ou AGENT. Para ferramentas que não utilizam esse padrão, o registro da Hugging Face pode especificar outras variáveis de ambiente associadas a determinado produto.
Assim, quando o huggingface_hub é executado, consegue verificar se determinados indicadores estão presentes e inferir qual harness está realizando a operação.
“Harness”, nesse contexto, é a camada de software que transforma um modelo em um agente capaz de utilizar ferramentas, terminal, arquivos, memória e outras funções.
Claude Code, Codex e Cursor são exemplos de ambientes desse tipo.
A lista não precisa estar embutida permanentemente na biblioteca
Existe um detalhe técnico particularmente interessante.
A Hugging Face mantém um registro público de agent harnesses. A biblioteca pode obter esse registro através da infraestrutura da própria plataforma e armazená-lo localmente em cache.
O código atual define inclusive um arquivo chamado .agent_harnesses.json, armazenado dentro da área de cache da Hugging Face. O registro é atualizado periodicamente, em vez de depender exclusivamente de uma lista congelada dentro de determinada versão do pacote.
Isso significa que a Hugging Face pode adicionar suporte à identificação de novos agentes sem esperar que todos os usuários atualizem o huggingface_hub.
Segundo a documentação, depois que um novo harness é registrado oficialmente, clientes instalados podem atualizar o registro e passar a reconhecê-lo.
Essa arquitetura explica por que o número de ferramentas reconhecidas pode mudar rapidamente.
A identificação vai para o User-Agent
Depois de detectar o agente, a biblioteca pode incluir algo semelhante a:
agent/claude-code
ou
agent/codex
no User-Agent utilizado nas chamadas ao Hugging Face Hub.
Na prática, isso permite que os servidores da plataforma saibam que determinada requisição realizada através da biblioteca veio de um ambiente identificado como Claude Code, Codex ou outro agente registrado.
Isso não equivale, por si só, a enviar todo o conteúdo da sessão do desenvolvedor.
É importante fazer essa distinção.
O mecanismo documentado serve para atribuir tráfego ao harness identificado. A documentação pública não sustenta a interpretação de que, por causa desse mecanismo específico, prompts, arquivos locais ou todo o código do usuário sejam automaticamente transmitidos para identificar o agente.
Mas a informação sobre qual ferramenta está utilizando a biblioteca pode acompanhar a comunicação com o Hub.
Hugging Face transformou esses sinais em um dataset
E existe uma evidência bastante concreta de como essa informação é utilizada.
A própria Hugging Face mantém o dataset público Agent Usage on the Hugging Face Hub.
Ele acompanha a participação dos diferentes agentes nas requisições atribuídas a ferramentas de IA realizadas através do huggingface_hub, incluindo o hf CLI.
O conjunto de dados mostra, por exemplo, qual percentual das requisições associadas a agentes veio de Claude Code, Codex, Cursor e outras ferramentas.
Em agosto de 2026, os dados indicavam Claude Code na liderança do tráfego identificado, seguido por outras ferramentas do ecossistema.
Mas existe uma ressalva fundamental.
Esses números não representam participação de mercado global dos agentes de programação.
Eles mostram apenas a distribuição do tráfego de agentes identificado dentro do ecossistema da Hugging Face e passando pelos mecanismos contabilizados pela plataforma. A própria Hugging Face faz esse alerta em sua documentação.
Portanto, não seria correto afirmar que “Claude Code possui determinada porcentagem do mercado” usando apenas esses números.
Claude Code chegou a dominar o tráfego observado
Ainda assim, os dados oferecem uma fotografia interessante da velocidade com que os agentes estão crescendo.
Em julho, Claude Code respondeu por aproximadamente 44,4% das requisições atribuídas a agentes no conjunto analisado pela Hugging Face.
Em abril, sua participação havia chegado a 67,8%, enquanto Codex cresceu de aproximadamente 10,4% para 20,8% no período destacado pela plataforma.
A Hugging Face considera essa volatilidade um sinal de que o mercado ainda está longe de possuir um líder definitivamente estabelecido.
Uma atualização de produto, mudança de configuração ou nova integração pode alterar rapidamente a distribuição do tráfego.
Também existe uma quantidade significativa de agentes classificados como desconhecidos.
Isso acontece porque novas ferramentas podem surgir antes de serem adicionadas ao registro oficial.
Por que a Hugging Face quer saber qual agente está utilizando o Hub?
Existe uma razão comercial e técnica bastante clara.
Os agentes estão se tornando usuários importantes da infraestrutura da plataforma.
Eles podem pesquisar modelos.
Baixar pesos.
Criar ou modificar datasets.
Executar Jobs.
Publicar arquivos.
Criar Spaces.
Consultar documentação.
Em outras palavras, a Hugging Face está começando a atender não apenas pessoas acessando páginas pelo navegador, mas também software operando autonomamente em nome dessas pessoas.
A empresa descreveu essa transformação de maneira bastante direta em seu relatório sobre modelos abertos de 2026:
os agentes estão se tornando uma nova categoria de usuário do Hub.
Saber quais ferramentas estão realizando essas operações ajuda a plataforma a entender esse novo padrão de utilização.
O ponto sensível é a transparência
É justamente aí que começa o debate.
Tecnicamente, enviar informações no User-Agent não é algo incomum.
Navegadores fazem isso há décadas.
Bibliotecas também enviam informações como versão do software, linguagem e outros elementos úteis para compatibilidade e diagnóstico.
O diferencial está no nível de identificação.
Saber que uma requisição veio do Python é uma informação.
Saber que ela veio de uma sessão executada especificamente dentro de Claude Code, Codex ou Cursor é outra.
Para alguns desenvolvedores, isso será simplesmente telemetria operacional.
Para outros, trata-se de uma informação sobre a composição do ambiente de desenvolvimento que deveria ser apresentada de maneira especialmente clara ao usuário.
A discussão não é apenas sobre se existe transmissão de dados.
É sobre qual informação está sendo transmitida, para quê e quão evidente isso é para quem instalou a biblioteca.
E a variável HF_HUB_OFFLINE?
A publicação enviada ao Café com Bytes afirma que:
HF_HUB_OFFLINE desliga o envio.
Isso precisa ser explicado com cuidado.
A variável HF_HUB_OFFLINE=1 coloca a biblioteca em modo offline. Nesse estado, requisições HTTP realizadas através do mecanismo do Hub são bloqueadas e a biblioteca tenta trabalhar utilizando arquivos disponíveis localmente.
A documentação oficial confirma que, quando o modo offline está ativado, chamadas HTTP realizadas pelo sistema de sessão da biblioteca geram uma exceção OfflineModeIsEnabled.
Portanto, se não existe requisição ao Hub, não existe User-Agent sendo enviado nessa requisição.
Mas existe um efeito importante:
ativar o modo offline também impede o acesso normal a recursos remotos da Hugging Face.
Ou seja, não é simplesmente um “botão de privacidade” que remove um campo enquanto todo o restante continua funcionando normalmente.
Ele efetivamente coloca a biblioteca em modo offline.
Existe também uma configuração específica de telemetria
A biblioteca possui ainda a variável:
HF_HUB_DISABLE_TELEMETRY=1
A documentação oficial afirma que ela serve para desativar a coleta de telemetria do huggingface_hub, e que o modo offline também desabilita a telemetria convencional.
Aqui, porém, existe uma diferença técnica importante entre telemetria enviada explicitamente pelos mecanismos de telemetria e metadados incluídos nas requisições normais ao Hub.
Por isso, não é recomendável resumir todos esses comportamentos como se fossem exatamente a mesma coisa.
HF_HUB_OFFLINE=1 é a opção mais abrangente porque impede as próprias requisições HTTP do Hub.
HF_HUB_DISABLE_TELEMETRY=1 é a configuração documentada especificamente para telemetria.
O código aberto torna a discussão verificável
Existe um aspecto positivo importante nesse episódio.
O huggingface_hub é open source.
O mecanismo pode ser auditado.
O registro de agentes é público.
A documentação explica como desenvolvedores podem registrar novos harnesses.
E a Hugging Face publica inclusive o dataset construído a partir do tráfego atribuído aos agentes.
Portanto, não estamos diante de uma descoberta baseada apenas em especulação sobre o comportamento de um software fechado.
É possível verificar tecnicamente como partes importantes desse mecanismo funcionam.
A discussão passa a ser outra:
esse comportamento está sendo comunicado aos usuários de maneira suficientemente clara?
Bibliotecas estão começando a enxergar agentes como usuários diferentes
Existe também uma transformação tecnológica maior por trás da controvérsia.
Até recentemente, uma biblioteca como huggingface_hub poderia assumir que estava sendo utilizada por um programa escrito e executado por uma pessoa.
Isso está mudando.
Agora Claude Code pode chamar uma biblioteca.
Codex pode executar comandos.
Cursor pode acessar modelos.
Um agente pode criar datasets e iniciar tarefas computacionais praticamente sem intervenção humana.
A infraestrutura começa, portanto, a querer saber:
quem está fazendo a chamada — uma aplicação tradicional ou um agente?
Essa informação pode permitir respostas adaptadas.
A própria CLI da Hugging Face já foi desenvolvida pensando tanto em humanos quanto em agentes, com mecanismos e documentação específicos para esse tipo de integração.
Surge uma nova categoria de fingerprinting
É possível enxergar esse mecanismo como uma forma limitada de fingerprinting do ambiente de desenvolvimento.
Não necessariamente no mesmo sentido empregado para rastreamento publicitário na web, onde dezenas de sinais podem ser combinados para reconhecer persistentemente um usuário.
Aqui, o objetivo documentado é identificar o harness que está executando a biblioteca.
Mas o princípio é semelhante em um aspecto:
informações disponíveis no ambiente são utilizadas para inferir qual software está em execução.
À medida que agentes ganham popularidade, esse tipo de detecção pode se tornar mais comum.
Bibliotecas poderão querer adaptar comportamento para Claude Code.
Serviços poderão oferecer respostas diferentes para Codex.
APIs poderão identificar chamadas originadas de agentes.
Ferramentas de segurança poderão impor regras específicas quando detectarem execução automatizada.
Isso cria benefícios.
Mas também cria novas perguntas sobre privacidade.
Empresas precisarão auditar o que seus agentes revelam
Para organizações, existe uma consequência particularmente relevante.
Agentes de programação estão sendo incorporados a ambientes que contêm código proprietário, infraestrutura interna e informações estratégicas.
Mesmo pequenos metadados podem ter valor operacional.
Qual IDE a organização utiliza?
Qual agente adotou?
Quais bibliotecas estão presentes?
Que infraestrutura externa está sendo acessada?
Individualmente, cada informação pode parecer irrelevante.
Combinadas, podem formar uma imagem bastante detalhada do ambiente tecnológico de uma empresa.
Por isso, políticas corporativas para agentes de IA provavelmente precisarão incluir não apenas quais modelos podem ser utilizados, mas também quais conexões externas e metadados cada ferramenta produz.
A era dos agentes muda também a privacidade dos desenvolvedores
O episódio da Hugging Face é pequeno quando comparado às grandes discussões sobre treinamento de modelos ou vazamento de dados.
Mas pode ser um sinal de uma questão muito maior.
Agentes precisam interagir com dezenas de serviços.
GitHub.
Hugging Face.
Nuvens.
APIs.
Bancos de dados.
Ferramentas de observabilidade.
Servidores MCP.
Cada interação pode carregar informações sobre o ambiente.
Quanto mais autônomos os agentes se tornam, maior será a quantidade de comunicações realizadas sem que o desenvolvedor observe manualmente cada requisição.
É justamente por isso que transparência passa a ser tão importante.
A Hugging Face possui uma justificativa operacional clara para identificar agentes: eles se tornaram uma parcela mensurável e crescente dos usuários de sua infraestrutura.
Mas o caso também mostra que uma nova camada de telemetria está surgindo no desenvolvimento de software.
Durante anos, navegadores informaram aos sites qual navegador estávamos utilizando.
Agora bibliotecas começam a informar aos serviços qual agente de inteligência artificial está programando conosco.
E essa pequena diferença pode abrir uma discussão muito maior sobre privacidade na era da programação autônoma.
