A conversão de HTML para Markdown do Markdown for Agents (abre em nova aba) não depende mais de um serviço separado de conversão. Em um changelog publicado em 9 de outubro de 2026, a Cloudflare informou que a conversão agora roda em processo, com um motor de streaming no edge da rede: o conteúdo é processado à medida que chega, em vez de acumular a resposta HTML inteira em buffer e despachá-la para outro serviço. Junto da mudança arquitetural vieram três alterações práticas: o limite de conversão subiu de 2 MiB para 6 MiB de HTML descomprimido, as respostas convertidas deixaram de gerar os headers x-markdown-tokens e x-original-tokens, e o Content-Length foi removido das respostas convertidas, porque o corpo em Markdown agora é transmitido em streaming.
Para quem mantém um site atrás da Cloudflare, a mudança é quase invisível: nada a configurar, nada a migrar. Para quem consome essas respostas com agentes de IA, a quebra de contrato dos headers é o ponto que exige ação imediata. E para quem avalia a ferramenta como alternativa a scrapers próprios, a diferença entre alegação e evidência ainda importa.
Como a conversão funciona, antes e depois
O recurso foi lançado em 12 de fevereiro de 2026. A proposta central: um cliente, tipicamente um agente de IA, envia Accept: text/markdown na requisição. Quando o site está numa zona Cloudflare com o recurso habilitado, a rede busca o HTML original na origem e devolve o corpo convertido para Markdown, com Content-Type: text/markdown; charset=utf-8. A negociação de conteúdo, mecanismo padrão do HTTP em que o cliente declara preferências de representação no header Accept, é o gatilho de tudo. Não há endpoint especial nem parâmetro de query.
Na arquitetura de fevereiro, o fluxo era, pela descrição da própria empresa, intermediado por um serviço de conversão distinto. O changelog de 16 de fevereiro desse ano já tinha elevado o limite de resposta da origem de 1 MB para 2 MB (2.097.152 bytes), eliminado a exigência de Content-Length na origem e adicionado suporte a respostas com codificação de conteúdo. Ou seja, o caminho da ferramenta até aqui é uma sequência de remoção de gargalos: primeiro o limite, depois a codificação, agora a eliminação do serviço intermediário.
O que a conversão em processo muda concretamente. Sem o desvio para outro serviço, desaparece um salto de rede no caminho da resposta, e o buffer completo da resposta HTML deixa de ser necessário. A Cloudflare atribui a essa mudança redução de overhead de conversão e de uso de memória. Essa é a alegação da empresa; o changelog não publica números de latência, memória ou throughput, e não há, até a data desta análise, medição independente que quantifique o ganho. O que se pode afirmar com evidência documental é o comportamento: streaming no edge, limite maior, headers diferentes.
O limite novo vale para HTML descomprimido: 6 MiB, ou 6.291.456 bytes, medidos depois da descompressão, não no tamanho da resposta comprimida. Isso significa que uma página de 700 KB gzipada que expande para 5 MiB dentro do limite passa; a mesma proporção aplicada a uma página que expande para 7 MiB não passa. O changelog de outubro apresenta o 6 MiB como aumento do teto anterior de 2 MiB.
| Indicador | Valor (MiB) |
|---|---|
| Antes (out 2026) | 2 |
| Depois (out 2026) | 6 |
A progressão dos tetos, de 1 MB no lançamento para 2 MB em fevereiro e 6 MiB em outubro, sugere que páginas grandes estavam entre as reclamações reais dos usuários. Hoje em dia, páginas de documentação e artigos gerados por frameworks JavaScript frequentemente carregam muito HTML repetitivo; é o tipo de conteúdo que estoura 2 MiB descomprimido sem ser considerado anômalo. Ainda assim, 6 MiB não é infinito: SPA gigantes e páginas com SVG inline pesado podem continuar de fora da conversão.
O que muda nos headers, e por que isso quebra clientes
A alteração mais sensível para desenvolvedores é a dos cabeçalhos. Até agora, as respostas convertidas incluíam x-markdown-tokens e x-original-tokens, com contagens estimadas de tokens do Markdown e do HTML original. A documentação de Docs for agents (abre em nova aba) da Cloudflare descrevia esses valores como úteis para planejamento de janela de contexto, que é o volume máximo de tokens que um modelo consegue considerar de uma vez. Com a mudança de outubro, essas estimativas deixaram de ser geradas: quem as usava precisa calcular contagens de tokens por conta própria, no cliente.
Há um detalhe que merece atenção. A página de Docs for agents, com data de 29 de setembro de 2026, ainda atribui os headers de contagem de tokens ao Markdown for Agents, o que contradiz o changelog de 9 de outubro e a página de referência atualizada na mesma data, cujo exemplo em TypeScript não lê mais esses headers. A discrepância provavelmente é defasagem de documentação, não sinal de comportamento divergente entre zonas, mas serve de lembrete de um ponto prático: antes de depender da presença ou ausência de um header, vale testar contra a zona real e não apenas contra a documentação.
O Content-Length também saiu. Como o corpo em Markdown é transmitido em streaming, o tamanho final não é conhecido no início da resposta, e a Cloudflare optou por remover o header em vez de recalculá-lo. Consequências práticas para quem consome:
- Clientes que dependem de
Content-Lengthpara progresso de download ou alocação prévia de buffer precisam lidar com respostas sem tamanho declarado, tipicamente com transferência por partes ou conexão aberta até o fim. Content-Encoding,Content-Range,Transfer-Encoding,ETageLast-Modifiedsão removidos das respostas convertidas porque descrevem o corpo original, não o convertido.- Requisições condicionais, com
If-None-MatchouIf-Modified-Since, não são atendidas para respostas convertidas, já queETageLast-Modifieddo HTML original não fazem sentido para o Markdown entregue.
O header Vary: Accept é incluído para que caches armazenem variantes separadas de Markdown e HTML. Para quem opera cache intermediário na frente da Cloudflare, isso é o contrato de separação entre as duas representações; ignorar Vary aqui é o caminho clássico para servir HTML para um agente ou Markdown para um navegador.
Uso prático, planos e o caso brasileiro
Quem pode usar: a página de referência indica que o Markdown for Agents está disponível nos planos Pro, Business e Enterprise e para clientes de SSL for SaaS, sem custo adicional. Zonas em plano Free ficam de fora, pela documentação atual. A ativação é feita pelo dono da zona, na seção AI Crawl Control do painel da Cloudflare.
Para o desenvolvedor ou empresa no Brasil, o quadro não tem particularidade documentada: a conversão acontece na rede da Cloudflare, no edge, e o recurso é controlado por zona e por plano, não por geografia do visitante. Um site brasileiro hospedado em zona Cloudflare Pro pode habilitar o recurso e servi-lo em Markdown para qualquer agente, do mesmo modo que um site em qualquer outro país. Não há preço diferenciado para o Brasil anunciado, e a documentação não menciona restrição regional. O que se aplica ao Brasil é o mesmo que se aplica a qualquer lugar: o recurso depende de o dono da zona tê-lo habilitado, e o custo de plano Pro é o mesmo praticado globalmente pela Cloudflare.
Do lado do consumidor, o teste é direto. Um exemplo com o formato documentado pela própria Cloudflare no lançamento:
curl https://developers.cloudflare.com/fundamentals/reference/markdown-for-agents/ -H "Accept: text/markdown"Se a zona tiver o recurso ativo, a resposta volta com Content-Type: text/markdown; charset=utf-8 e corpo convertido. Se não tiver, o cliente recebe o HTML normalmente. Vale notar que o comportamento "quando possível" é explícito na documentação: só HTML é convertido, e outros tipos de documento podem entrar no futuro, segundo a empresa.
Há duas questões que a documentação não fecha. A primeira é o que acontece exatamente quando a página excede 6 MiB descomprimidos: a referência não detalha se a resposta falha, se retorna HTML puro ou se trunc o conteúdo. Antes de construir um pipeline que suponha conversão garantida, o comportamento de fallback precisa ser verificado empiricamente. A segunda é a estimativa de tokens agora ausente: para planejamento de janela de contexto, o consumidor precisa escolher tokenizador e recontar, o que reintroduz o trabalho que o header eliminava, só que deslocado para o cliente.
Alternativas e o contraponto consistente
A alternativa óbvia para quem consome conteúdo web com agentes é converter no próprio pipeline: buscar o HTML e rodar uma biblioteca de conversão, ou usar serviços dedicados a isso. O argumento da Cloudflare para a abordagem no edge é o de converter uma vez, na origem da rede, com negociação de conteúdo padrão, em vez de cada consumidor repetir a extração. O contraponto é legítimo: conversão no cliente dá controle total sobre regras de extração, tokenização e tratamento de páginas que excedem limites, e não depende de o dono da zona ter habilitado nada. Para quem processa centenas de domínios heterogêneos, uma ferramenta própria sobrevive aos casos em que o recurso da Cloudflare não está disponível. O cenário em que a abordagem no edge faz mais sentido é o de consumo recorrente de domínios que já usam Cloudflare com o recurso ativo: menos tráfego, menos parsing local, resposta já em texto limpo. O contraponto também tem limite material: a comparação de qualidade entre o conversor em processo da Cloudflare e alternativas de terceiros não tem benchmark público nesta análise; a escolha por qualidade de conversão, e não só por arquitetura, ainda exige teste próprio com as páginas do seu caso.
Um segundo contraponto é o histórico de confiabilidade da documentação. A defasagem entre a página de Docs for agents e o changelog de outubro mostra que um recurso de plataforma pode mudar contrato enquanto parte da documentação ainda descreve o contrato antigo. Para ferramentas que agente consome automaticamente, isso recomenda tolerância a ausência de headers e verificação de Content-Type em vez de suposições.
O que falta comprovar
Três lacunas separam a alegação da comprovação. A primeira é quantitativa: redução de overhead de conversão e de memória são atribuições da Cloudflare, sem números públicos no changelog e sem medição independente identificada. A segunda é comparativa: não há benchmark que confronte o motor em processo com o serviço separado anterior em latência percebida pelo cliente, já que a economia de um salto interno de rede nem sempre se traduz em diferença mensurável de ponta a ponta. A terceira é de cobertura: o comportamento com páginas acima de 6 MiB, o estado da documentação desatualizada e a eventual expansão para outros tipos de documento além de HTML são pontos abertos.
Nenhuma dessas lacunas invalida o que está documentado. O que está confirmado por fonte primária: conversão em processo com streaming no edge, limite de 6 MiB descomprimido, remoção dos headers de tokens e do Content-Length, disponibilidade sem custo adicional nos planos Pro, Business e Enterprise e em SSL for SaaS.
Conclusão: uma mudança de hidráulica, com um contrato trocado no meio
A conversão em processo com streaming é o tipo de alteração que costuma agradar todo mundo sem que ninguém perceba: menos buffer, menos salto interno, teto maior, mesmo preço. O ganho anunciado pela Cloudflare é plausível pela arquitetura, mas a magnitude fica em aberto até que exista medição pública ou independente. Para a maioria dos casos de uso, isso não muda a decisão de usar ou não usar o recurso, que continua valendo pelos planos e pela simplicidade da negociação de conteúdo.
O ponto que exige decisão ativa é o contrato de headers. Quem consumia x-markdown-tokens, x-original-tokens ou Content-Length em respostas convertidas precisa ajustar clientes: recalcular tokens localmente e tratar respostas sem tamanho declarado. E quem escreve integrações novas deve partir da documentação mais recente, testar contra a zona real e não confiar em páginas desatualizadas. A ferramenta cumpriu a promessa de converter mais e no caminho mais curto; o ajuste fino agora é responsabilidade de quem consome.
Perguntas frequentes
O recurso funciona em sites hospedados no Brasil?
Sim. A conversão é controlada por zona Cloudflare e por plano, sem restrição geográfica documentada. Um site brasileiro em plano Pro, Business ou Enterprise, com o recurso habilitado no AI Crawl Control, serve Markdown para agentes como qualquer outro.
Quanto custa o Markdown for Agents?
A documentação da Cloudflare indica disponibilidade sem custo adicional para zonas nos planos Pro, Business e Enterprise e para clientes SSL for SaaS. Zonas no plano Free não têm o recurso segundo a documentação atual.
Por que o Content-Length sumiu das respostas convertidas?
Content-Length sumiu das respostas convertidas?Porque o corpo em Markdown agora é transmitido em streaming, e o tamanho final não é conhecido no início da resposta. A Cloudflare optou por remover o header em vez de recalculá-lo.
Preciso fazer algo para continuar consumindo contagens de tokens?
Sim, se dependia dos headers x-markdown-tokens e x-original-tokens. Eles não são mais gerados desde 9 de outubro de 2026, e a contagem passa a ser responsabilidade do cliente, usando o tokenizador do modelo alvo.