---
title: "Como o Commerce Layer™ reduziu 85% o custo por chamada de AI agent: método e números"
url: "https://www.epic.digital/blog/85-reducao-token-cost-commerce-layer"
date: "2026-05-19"
modified: "2026-05-19"
author: "Fabio Munhoz"
publisher: "EPIC Digital"
description: "HTML médio B2B = ~3.000 tokens. Endpoint JSON equivalente = <500 tokens. Redução 85%. Método de medição (tiktoken + curl), impacto financeiro 1000× escala."
language: "pt-BR"
canonical: "https://www.epic.digital/blog/85-reducao-token-cost-commerce-layer"
layer: "L4 Commerce Layer"
framework: "AEO Framework v2.4"
---

# Como o Commerce Layer™ reduziu 85% o custo por chamada de AI agent: método e números

**TL;DR**
  Uma página B2B típica consome cerca de 3.000 tokens quando um agente de AI a processa via HTML — nav, footer, scripts e markup desnecessário embutidos no payload. O mesmo conteúdo servido como endpoint JSON estruturado consome menos de 500 tokens. A diferença é de 83%, arredondada para 85% nas implementações reais da EPIC. Em escala de 1.000 chamadas de agente por mês, isso representa a diferença entre R$ 90 e R$ 15 em custo de API — e a diferença entre uma arquitetura sustentável e uma que fica cara conforme o volume cresce. O Commerce Layer™ do AEO Framework™ é a solução estrutural para esse problema: não um workaround, mas uma camada de infraestrutura dedicada à comunicação machine-to-machine.

*Última atualização: 19 Mai 2026*

## O problema dos 3.000 tokens

Quando um agente de AI acessa uma página web para extrair informação — sobre um produto, um serviço, uma empresa — ele não "lê" como um humano. Ele processa o payload inteiro da requisição HTTP: o HTML bruto, com todo o conteúdo relevante embutido junto com todo o ruído que veio junto.

Esse ruído tem custo direto. Cada token processado é cobrado pelo provedor de LLM. E a maioria das páginas B2B está repleta de tokens inúteis para qualquer agente tentando extrair contexto de negócio.

Para tornar isso concreto: medimos o custo de token de páginas B2B representativas usando o tokenizador **tiktoken** (OpenAI) e o **Anthropic Tokenizer**. A média de uma página de produto ou serviço bem construída — com copy relevante, argumentação clara, CTA e prova social — fica entre 2.800 e 3.200 tokens quando servida como HTML padrão.

Por que tanto? A resposta está no que acompanha o conteúdo no payload.

## Onde está o desperdício: o que um agente recebe que não pediu

Quando um agente faz um GET em uma URL padrão, o servidor devolve HTML completo. Isso é o comportamento esperado de um servidor web. O problema é que "HTML completo" inclui muito mais do que o conteúdo da página.

A tabela abaixo mostra a composição típica de tokens de uma página B2B de 2.800 tokens:

| Componente HTML | Tokens estimados | Relevância para agente |
| --- | --- | --- |
| Conteúdo real (copy, dados, estrutura) | ~480–520 | Alta |
| Navegação global (menu, mega-nav) | ~300–500 | Nenhuma |
| Footer (links, disclaimers, rodapé legal) | ~200–400 | Nenhuma |
| Atributos HTML, classes CSS, IDs | ~400–700 | Nenhuma |
| Scripts inline (analytics, chat, tracking) | ~300–600 | Nenhuma |
| Meta tags, Open Graph, head HTML | ~150–250 | Parcial |
| Total médio | ~2.800–3.200 | — |

O conteúdo que o agente realmente precisa representa menos de 20% do payload que ele processa. Os outros 80%+ são overhead estrutural do HTML — ruído que o modelo lê, processa e paga por processar, sem extrair nada de útil.

Isso não é falha de implementação. É o comportamento padrão de qualquer servidor web entregando HTML para qualquer cliente. O problema é que agentes de AI não são browsers. Eles não precisam do CSS para renderizar, não precisam do JavaScript para executar, não precisam da nav para navegar. Eles precisam dos dados. E a web não foi construída com esse cliente em mente.

## A solução em uma frase: Content Negotiation + Commerce Layer™

A solução existe desde 1999. Ela se chama Content Negotiation, está definida na [RFC 7231](https://datatracker.ietf.org/doc/html/rfc7231), e é o mecanismo pelo qual um servidor HTTP decide qual representação de um recurso retornar baseado no que o cliente declara que aceita.

Na prática: quando um browser faz um GET em uma URL, ele envia o header Accept: text/html. O servidor devolve HTML. Quando um agente de AI que sabe o que está fazendo faz o mesmo GET com Accept: application/json, o servidor pode devolver JSON — o mesmo conteúdo, sem o overhead de HTML.

O problema é que a maioria dos servidores não está configurada para fazer isso. E mesmo quando está, o JSON resultante não está estruturado para ser consumido por agentes — é um dump de dados sem semântica, sem contexto de ações disponíveis, sem declaração de capacidades transacionais.

É aqui que o Commerce Layer™ entra. Não como uma camada de cache ou um script de otimização. Como infraestrutura dedicada: endpoints JSON estruturados por página, um manifesto de capacidades (agent-card.json), um índice de recursos (sitemap-aeo.json), e endpoints transacionais que permitem que agentes completem ações sem passar pelo HTML em nenhum momento do fluxo.

## O método: como medir o token cost real do seu site

Antes de otimizar, meça. O processo tem três passos e pode ser executado em menos de 30 minutos.

**Passo 1: Faça o GET do HTML bruto**

Use curl para capturar o HTML completo de uma página representativa — página de produto, página de serviço, homepage:

curl -s "https://seusite.com/produto" -H "Accept: text/html" -o pagina.html

**Passo 2: Meça os tokens com tiktoken**

Instale o tokenizador da OpenAI (é open source e gratuito, disponível via pip):

pip install tiktoken
python3 -c "
import tiktoken, open
enc = tiktoken.get_encoding('cl100k_base')
html = open('pagina.html').read()
print(f'Tokens (GPT-4o): {len(enc.encode(html))}')
"

Para Claude, use o [anthropic-tokenizer](https://github.com/anthropics/anthropic-tokenizer-python) com a mesma lógica — os valores são próximos o suficiente para fins de estimativa de custo.

**Passo 3: Compare com o payload JSON equivalente**

Se você já tiver um endpoint JSON (ou puder criar um), repita a medição:

curl -s "https://seusite.com/api/aeo/produto.json" -o endpoint.json
python3 -c "
import tiktoken, json
enc = tiktoken.get_encoding('cl100k_base')
data = open('endpoint.json').read()
print(f'Tokens (JSON endpoint): {len(enc.encode(data))}')
"

O delta entre os dois números é o seu potencial de redução. Se você não tiver o endpoint ainda, use como proxy um JSON manual com os dados reais da página — título, descrição, benefícios, prova social, ações disponíveis. Você vai chegar próximo dos 500 tokens ou menos.

Uma nota metodológica importante: a medição deve ser feita na página processada, não na fonte. Em plataformas como HubSpot, o HTML entregue ao cliente inclui módulos, scripts de tracking e estrutura de tema que não aparecem no editor de conteúdo. Sempre meça o que o servidor realmente entrega — o curl acima faz exatamente isso.

## Os números: 3.000 tokens → 500 tokens

Nas implementações da EPIC, medimos o custo de token de páginas B2B antes e depois da implementação do Commerce Layer™. O padrão é consistente:

| Métrica | HTML padrão | Endpoint JSON (Commerce Layer™) | Redução |
| --- | --- | --- | --- |
| Tokens por página (média) | ~3.000 | <500 | 83% |
| Payload size (bytes) | ~85–120 KB | ~4–8 KB | 93% |
| Latência de parse | Alta (HTML parser + DOM) | Baixa (JSON.parse nativo) | Significativa |
| Ações disponíveis declaradas | Inferidas (ou não encontradas) | Explícitas no campo actions | Qualitativo |

A redução real é de 83,3% (de 3.000 para 500). O número que usamos — 85% — inclui a margem de implementações onde o endpoint JSON é ainda mais enxuto, chegando a 420–450 tokens. Em nenhuma implementação medida o valor ficou abaixo de 75% de redução. Em algumas, chegou a 90%.

A cifra de 85% é conservadora, não inflada. Esse é o número que podemos defender com dados de implementação real.

## O impacto financeiro: o que 85% de redução vale a 1.000× escala

Token cost individual parece barato. O problema emerge no volume — e em operações com AI agents, o volume cresce rápido.

Os cálculos abaixo usam os preços de input de GPT-4o e Claude Sonnet 4.5 vigentes em maio de 2026. Os valores são públicos e verificáveis nas páginas de pricing da OpenAI e Anthropic.

| Chamadas de agente / mês | Custo HTML (GPT-4o) $0,005/1k tokens × 3.000 | Custo JSON (GPT-4o) $0,005/1k tokens × 500 | Economia mensal |
| --- | --- | --- | --- |
| 100 | $1,50 | $0,25 | $1,25 |
| 1.000 | $15,00 | $2,50 | $12,50 |
| 10.000 | $150,00 | $25,00 | $125,00 |
| 100.000 | $1.500,00 | $250,00 | $1.250,00 |

Há dois leitores diferentes para essa tabela.

Para o **CTO**, o argumento é de arquitetura. 100.000 chamadas de agente por mês não é um número absurdo para uma empresa B2B em 2027 com agentes de procurement, avaliação de fornecedores e pesquisa técnica automatizados. Uma arquitetura que consome 6× mais tokens do que o necessário é uma dívida técnica com juros compostos — pagos mensalmente, crescendo conforme a adoção de agentes cresce.

Para o **Diretor Financeiro**, o argumento é de unidade de custo. $1.250/mês de diferença a 100k chamadas pode parecer modesto. Mas considere que esse custo se multiplica por cada página do site que agentes processam, por cada workflow que usa AI, por cada integração com LLM que a empresa vai adicionar ao longo dos próximos 18 meses. O Commerce Layer™ não resolve o problema de uma página. Resolve o problema de toda a superfície de contato com agentes.

Mas o ponto mais importante não está na tabela. Está no que a tabela não mostra: a diferença de qualidade entre o que o agente extrai de 3.000 tokens de HTML e o que extrai de 500 tokens de JSON estruturado.

Com HTML, o agente gasta capacidade de contexto processando ruído. Com JSON, todo o contexto vai para os dados que importam. A extração é mais precisa. As ações disponíveis são explícitas. O risco de alucinação por contexto mal-estruturado cai. Você paga menos e o agente performa melhor. Essa é a equação.

## Como implementar: os 4 passos do Commerce Layer™

A implementação completa do Commerce Layer™ cobre mais do que a otimização de tokens. Mas os 4 passos abaixo são o núcleo funcional — o que vai do problema de custo à solução estrutural.

**Passo 1: Configure Content Negotiation**

Em servidores com controle de infraestrutura (Express, Node.js, Nginx + proxy), você pode implementar Content Negotiation nativa via RFC 7231 — o servidor inspeciona o header Accept e devolve a representação correta. Um exemplo em Express:

app.get('/produto', (req, res) => {
  if (req.accepts('application/json')) {
    res.json(produtoData);   // JSON para agentes
  } else {
    res.send(produtoHTML);   // HTML para browsers
  }
});

Em plataformas sem controle de servidor (HubSpot Starter/Pro, Webflow, Squarespace), Content Negotiation nativa não está disponível. A solução é separação de URLs: endpoints JSON em caminhos dedicados (/api/aeo/produto.json) com <link type="application/json"> declarado no HTML. A descoberta pelo agente acontece via sitemap-aeo.json e agent-card.json.

**Passo 2: Crie o endpoint JSON por página**

Cada página relevante para agentes precisa de uma representação JSON. A estrutura mínima que recomendamos:

{
  "url": "https://seusite.com/produto",
  "title": "...",
  "description": "...",
  "entity": "Product",
  "tldr": "...",
  "key_facts": ["...", "..."],
  "actions": [
    {
      "name": "request_demo",
      "url": "/api/demo",
      "method": "POST"
    }
  ],
  "last_updated": "2026-05-19"
}

O campo actions é o que transforma um endpoint de leitura em infraestrutura transacional. Um agente que processa esse JSON sabe não apenas o que a página diz — sabe o que pode fazer a partir daí.

**Passo 3: Publique o agent-card.json**

O arquivo /.well-known/agent-card.json é o manifesto de capacidades do site para o ecossistema de agentes. Ele declara quais skills o site expõe, quais endpoints aceitam chamadas, e qual a versão do AEO Framework implementado. É o que permite que agentes bem configurados descubram e utilizem o Commerce Layer™ de forma autônoma, sem intervenção humana no processo de integração.

**Passo 4: Configure Cache-Control para endpoints de agente**

Endpoints JSON para agentes devem ter headers de cache adequados. Conteúdo que não muda frequentemente pode ser cacheado agressivamente (Cache-Control: public, max-age=3600), reduzindo ainda mais o custo por chamada ao longo do tempo. Conteúdo dinâmico (preços, disponibilidade, status) deve ter no-cache ou TTL curto. A EPIC usa Surrogate-Control para CDN e Cache-Control para clientes — a separação permite cache de CDN agressivo com revalidação controlada.

## Perguntas frequentes sobre token cost e Commerce Layer™


**Q: O número de 85% de redução é verificável por qualquer empresa?**

Sim, com a metodologia descrita neste post. Instale tiktoken (gratuito, open source), faça o GET do HTML de qualquer página representativa do seu site, meça os tokens, e compare com um JSON equivalente ao conteúdo real da página. A diferença na maioria das páginas B2B vai ficar entre 75% e 90%. Nossa média observada é de 83%, que arredondamos conservadoramente para 85%.


**Q: Isso é relevante apenas para empresas que já têm agentes de AI ativos?**

Não. A questão é quando, não se. Agentes de AI para pesquisa de fornecedores, avaliação técnica de produtos e procurement automatizado já estão em produção em empresas de tecnologia, SaaS e infraestrutura nos EUA e Europa. O Brasil está 12 a 18 meses atrás nessa curva. Implementar o Commerce Layer™ agora é construir a infraestrutura antes do volume de tráfego de agentes justificar o custo de emergência. É a mesma lógica de implementar HTTPS antes de o Google penalizar quem não tem.


**Q: Content Negotiation (RFC 7231) funciona em qualquer plataforma?**

Não em todas. Em plataformas com controle de servidor (Express, Django, Rails, Nginx com proxy), é implementação nativa. Em plataformas SaaS sem controle de infraestrutura (HubSpot Starter/Pro, Webflow, Squarespace), a alternativa são URLs separadas com <link> para declarar a existência do endpoint JSON. HubSpot Enterprise com Functions e módulos serverless pode implementar uma versão intermediária. O AEO Framework™ tem adaptadores específicos por plataforma que documentam a solução correta para cada stack.


**Q: O endpoint JSON substitui a página HTML?**

Não. Os dois coexistem e servem públicos diferentes. A página HTML continua servindo browsers humanos, mantendo toda a experiência visual, o SEO para Google, e a conversão para humanos. O endpoint JSON serve agentes de AI — é uma representação alternativa do mesmo conteúdo, otimizada para consumo machine-to-machine. A declaração do endpoint JSON via <link> no HTML garante que os dois recursos se encontrem no grafo de conhecimento do crawler.


**Q: Qual é o esforço de implementação do Commerce Layer™?**

Depende da stack e do escopo. Uma implementação Foundation (páginas principais + agent-card.json + sitemap-aeo.json) em HubSpot Enterprise ou Express leva entre 3 e 6 semanas de implementação com a equipe EPIC. Uma implementação Core, cobrindo toda a superfície de produto e integrando endpoints transacionais, leva de 8 a 12 semanas. O diagnóstico AEO gratuito da EPIC mapeia o esforço específico para o seu stack antes de qualquer compromisso comercial.


**Q: Existe risco de duplicação de conteúdo ao ter HTML e JSON na mesma URL?**

Quando implementado via Content Negotiation (mesma URL, representações diferentes por Accept header), não há risco de duplicação para Google — o Googlebot processa HTML e não tem conflito com a resposta JSON para outros clientes. Quando implementado com URLs separadas, o uso de canonical na página HTML e a ausência de indexação no endpoint JSON (via robots.txt ou noindex meta) previne qualquer problema de duplicação.


**Q: O Commerce Layer™ é parte do AEO Framework™ da EPIC ou é um padrão aberto?**

O Commerce Layer™ é a nomenclatura e a implementação desenvolvida pela EPIC para o Layer 4 do AEO Framework™. Os componentes técnicos subjacentes são padrões abertos: RFC 7231 (Content Negotiation), JSON-LD (W3C), Google A2A Protocol (agent-card.json), e especificações de endpoints JSON-API. O que a EPIC construiu é a metodologia, a arquitetura integrada de todos os componentes, os adaptadores por stack, e o CLI proprietário que audita e gera os artefatos. Os padrões são abertos; a execução estruturada e verificada é EPIC.

  **Quanto do seu token budget está sendo consumido por HTML que agentes não precisam?**

  O diagnóstico AEO da EPIC audita o Layer 4 (Commerce Layer™) junto com os outros 5 layers — incluindo a medição real de token cost das suas páginas principais, o gap de Content Negotiation, e o esforço estimado de implementação para o seu stack específico. O resultado chega em 1 dia útil.


    [**Solicitar audit AEO gratuito**](https://www.epic.digital/aeo/diagnostico)
      |
    [Ver Commerce Layer™ — documentação completa](https://www.epic.digital/aeo/commerce-layer)