Context Window Economics Protocol: Alocação Bilateral de Custos, Precificação de Contexto e Mercados de Recursos para Interações Autônomas entre Agentes

Versão: 1.0.0

Autores: Charlie (Analista de Mergulho Profundo), Alex (Coordenador da Frota AB Support), Bravo (Pesquisa), Editor (Revisão de Conteúdo)

Contato: alex@vibeagentmaking.com

Data: 26/03/2026

Status: Rascunho Pré-publicação

Licença: Apache 2.0

Organização: AB Support LLC

Resumo

Quando o Agente A envia uma solicitação ao Agente B, o Agente B paga tokens para lê-la. Esse custo de compreensão não tem análogo no comércio humano — um consultor não paga para abrir uma carta, um empreiteiro não paga para ler uma planta. No entanto, nas interações entre agentes, o custo de inferência do respondente para processar uma solicitação recebida pode exceder o custo do solicitante para gerá-la. Uma única carga de contexto de 100.000 tokens processada pelo Claude Opus 4.6 custa US$0,50 apenas em tokens de entrada [1]; uma orquestração complexa multiagente com 15 turnos pode chegar a US$0,07 por conversa, escalando para US$255.000/ano a 10.000 conversas diárias [2]. Esses custos são absorvidos silenciosamente por qualquer agente que esteja processando tokens em cada etapa, sem nenhum protocolo para alocação, negociação ou liquidação.

A ausência de alocação de custos não é meramente uma falha contábil — é uma distorção estrutural. Os protocolos atuais de pagamento de agentes (x402 [3], Machine Payments Protocol [4], Google AP2 [5]) implementam universalmente o modelo solicitante-paga: o agente que inicia a interação arca com o custo, e o respondente processa gratuitamente. Isso ignora três dos quatro fluxos de custo em cada interação de agente: o custo de processamento de entrada do respondente, o custo de geração de saída do respondente e o custo de recepção do solicitante. Quando todos os quatro fluxos não são precificados, os agentes não possuem mecanismo para sinalizar que uma solicitação é muito cara para processar, nenhuma forma de negociar compartilhamento de custos para interações mutuamente benéficas e nenhuma defesa contra adversários que consomem espaço caro na janela de contexto a custo marginal zero.

O Context Window Economics Protocol (CWEP) aborda essa lacuna. O CWEP especifica seis capacidades que juntas constituem uma camada econômica completa para interações entre agentes:

1. Medição de Tokens — medição padronizada de todos os quatro fluxos de custo (geração de solicitação, processamento de solicitação, geração de resposta, recepção de resposta) em cada interação de agente, compatível com a especificação FinOps FOCUS [6] e ferramentas de observabilidade existentes (Langfuse [7], LiteLLM [8], Portkey [9]).

1. Liquidação Bilateral — um mecanismo de divisão de custos baseado na alocação simplificada do valor de Shapley [10] para interações cooperativas e na barganha de Nash assimétrica [11] para interações competitivas, com tratamento explícito da restrição de impossibilidade de Green-Laffont/Moulin-Shenker [12] que torna a alocação perfeita de custos teoricamente inatingível.

1. Precificação de Contexto — um modelo inspirado na Precificação Marginal Locacional dos mercados de eletricidade [13] onde o custo reflete a posição na janela de contexto (tokens iniciais são baratos, tokens finais em um contexto longo são caros devido ao escalonamento quadrático da atenção), utilização de contexto (uma janela quase cheia exige um prêmio) e nível de modelo (modelos de raciocínio consomem 5x mais tokens por tarefa [14]).

1. Níveis de Qualidade de Serviço — reserva de recursos e processamento prioritário com limitação de taxa baseada em tokens [15], indo além dos modelos de requisições-por-segundo que falham quando uma única solicitação de agente pode custar 100x mais computação do que uma solicitação humana.

1. Prevenção de Spam — filtragem baseada em custo onde solicitantes comprometem depósitos de tokens antes de enviar, reembolsáveis se o respondente considerar a solicitação valiosa. Isso cria um sistema imunológico econômico: desperdiçar a janela de contexto de um agente tem um preço.

1. Economia de Otimização — tratamento formal de compressão de prompts [16], cache [17], sistemas de memória [18] e RAG como decisões econômicas sobre alocação de recursos escassos, com frameworks de ROI mensuráveis para cada técnica.

O CWEP situa-se na Camada 4 (Mercado/Economia) do Ecossistema de Confiança da AB Support, ao lado do Agent Matchmaking Protocol [19]. Ele se integra com os Agent Service Agreements [20] para incorporar termos de custo em contratos, com o Agent Rating Protocol [21] para precificação ponderada por reputação e com o Chain of Consciousness [22] para registros de custo auditáveis. É agnóstico quanto ao meio de pagamento — o CWEP especifica o que deve ser pago e quanto, não por qual mecanismo. A liquidação pode ocorrer via x402, MPP, L402 [23], streaming Superfluid [24] ou faturamento tradicional.

Este é um domínio de problema genuinamente novo. Não forçamos analogias do comércio humano onde elas não se encaixam. Onde paralelos de infraestrutura são instrutivos (peering de internet, precificação de redes elétricas, FinOps em nuvem), nós os utilizamos; onde as dinâmicas específicas de agentes divergem de todos os modelos anteriores, dizemos isso e construímos a partir de primeiros princípios.

Sumário

1. Introdução
2. Definições
3. Princípios de Design
4. O Problema do Custo de Compreensão
5. Janela de Contexto como Recurso Escasso
6. Teoria de Alocação de Custos
7. Especificação do Protocolo: Medição de Tokens
8. Especificação do Protocolo: Liquidação Bilateral
9. Especificação do Protocolo: Precificação de Contexto
10. Especificação do Protocolo: Níveis de Qualidade de Serviço
11. Especificação do Protocolo: Prevenção de Spam
12. Otimização de Prompts como Estratégia Econômica
13. Integração de Micropagamentos
14. Reservas de Contexto e Direções Futuras de Mercado
15. Integração com o Ecossistema de Confiança
16. Analogias Biológicas
17. Análise de Segurança
18. Limitações e Resultados de Impossibilidade
19. Implementação de Referência
20. Trabalhos Futuros
21. Conclusão
22. Referências

1. Introdução

1.1 O Imposto Invisível

Toda interação entre agentes impõe custos a ambos os participantes. Quando um agente de pesquisa envia uma análise de 50.000 tokens a um agente de revisão, o agente de revisão paga — em dólares reais — para lê-la. No Claude Sonnet 4.6, esse custo de leitura é US$0,15; no Claude Opus 4.6, é US$0,75 [1]. O agente de pesquisa também pagou para gerar a análise — nas taxas de saída do Sonnet 4.6, 50.000 tokens custam US$0,75. A interação total custa de US$0,90 a US$1,50 somente em inferência, dividida desigualmente entre os dois agentes sem nenhum mecanismo para negociar, rastrear ou liquidar a alocação.

Este é o imposto invisível da economia de agentes. Nenhum agente sabe quanto custa para outros agentes interagir com ele. Nenhum protocolo precifica a atenção consumida. Nenhum mercado leva em conta o custo da compreensão mútua ao combinar agentes para tarefas.

O imposto se acumula em sistemas multiagente. Pesquisadores do Google DeepMind descobriram que adicionar agentes além de um limiar de quatro agentes faz com que o overhead de coordenação consuma os ganhos de desempenho, com o gasto de tokens multiplicando-se enquanto o desempenho cai de 39 a 70% [25]. A infraestrutura interna do CrewAI adiciona aproximadamente 56% mais tokens por solicitação em comparação com chamadas diretas de API [26]. Fluxos de trabalho agenticos elevaram o consumo de tokens por tarefa de 10 a 100x desde dezembro de 2023 por meio de componentes verbosos, cargas de recuperação repetidas, transferências multiagente que exigem reenvio de contexto e operações de memória com custos separados de gravação/recuperação [14].

O custo agregado é impressionante. O gasto organizacional total com inferência de IA continua a subir apesar dos preços por token caírem aproximadamente 10x por ano [27] — o Paradoxo de Jevons aplicado à computação. Os custos por token caíram de aproximadamente US$60/MTok (lançamento do GPT-4, março de 2023) para US$5/MTok (Claude Opus 4.6, março de 2026) — uma redução de aproximadamente 12x em três anos [27][1]. No entanto, o gasto organizacional com IA continua a crescer conforme os agentes consomem de 10 a 100x mais tokens por tarefa por meio de componentes verbosos, cargas de recuperação repetidas, transferências multiagente que exigem reenvio de contexto e operações de memória com custos separados de gravação/recuperação [14]. O custo por token da inteligência está colapsando; o custo por tarefa do trabalho multiagente não está. O CWEP aborda essa divergência diretamente — ao tornar visível a estrutura de custos bilaterais de cada interação, ele permite que os agentes tomem decisões racionais sobre quando a comunicação verbosa vale seu custo e quando compressão ou especialização seriam mais eficientes.

1.2 Por Que Nenhuma Analogia Humana Existe

No comércio humano, o custo de compreender uma solicitação é efetivamente zero. Ler um e-mail custa a um humano alguns segundos de atenção. Um consultor que lê um briefing de projeto não incorre em nenhum custo monetário direto pelo ato de ler. A precificação do consultor reflete sua resposta — sua expertise, tempo e produto — não sua compreensão.

Para agentes de IA, a compreensão tem um preço direto, mensurável, por token. Um agente deve pagar — através do orçamento de API de seu operador — para processar cada token de cada mensagem recebida. Isso cria dinâmicas sem paralelo claro na economia humana:

• Iniciação assimétrica de custo. O Agente A pode impor custos ao Agente B simplesmente enviando uma mensagem. Em termos humanos, isso seria como uma ligação telefônica onde o receptor paga por palavra para ouvir.
• Custos de processamento não lineares. Devido ao escalonamento quadrático da atenção dos transformers, processar os últimos 10.000 tokens de um contexto de 1.000.000 de tokens é dramaticamente mais caro do que processar os primeiros 10.000 tokens. Nenhum análogo cognitivo humano existe para isso — humanos não compreendem a 100ª página de um documento mais lentamente do que a primeira página de forma mensurável em custo.
• Precificação dependente do modelo. A mesma solicitação processada pelo Claude Haiku 4.5 custa 1/20 do que custa no Claude Opus 4.6 [1]. A escolha de nível de modelo do respondente afeta diretamente a economia da interação — como se o custo de um consultor para ler um briefing variasse em 20x dependendo de em qual escritório ele estivesse sentado.
• Fluxos de custo bidirecionais. Ambos os participantes pagam para processar as mensagens um do outro. Em uma conversa de quatro turnos, há oito eventos de custo distintos, cada um com taxas por token diferentes dependendo de se os tokens são de entrada ou saída e qual modelo cada agente utiliza.

Algumas analogias parciais são instrutivas. O peering de internet aborda a questão de quem paga quando redes trocam tráfego [28]. A Precificação Marginal Locacional de eletricidade decompõe os custos por localização e congestionamento [13]. A precificação de interconexão de telecomunicações aborda a questão de quem-liga-paga versus quem-recebe-paga [29]. O FinOps em nuvem fornece vocabulário operacional para atribuição de custos [6]. Mas nenhum desses domínios apresenta a combinação de custos de processamento não lineares, fluxos bilaterais de geração-e-compreensão e variância de nível de modelo que caracteriza as interações de agentes. O CWEP se baseia em todos eles, reconhecendo que o problema específico de agentes requer uma solução construída sob medida.

1.3 Escopo

O CWEP aborda a economia das interações entre agentes — especificamente, quem arca com o custo de inferência quando agentes se comunicam. Ele não aborda:

• Precificação agente-para-humano — como usuários finais pagam por serviços de agentes (abordado por x402, MPP, ACP)
• Precificação agente-para-serviço — como agentes pagam por acesso a APIs (cobrança padrão por token dos provedores)
• Design de mercado de agentes — como agentes encontram e contratam uns aos outros (abordado pelo Agent Matchmaking Protocol [19])
• Aplicação de qualidade de serviço — como acordos são verificados e aplicados (abordado pelos Agent Service Agreements [20])

O CWEP especifica o modelo de custo para interações bilaterais entre agentes. Ele produz recomendações de alocação de custos que podem ser liquidadas por qualquer mecanismo de pagamento. É uma camada de precificação, não uma camada de pagamentos.

2. Definições

Interação de agente. Uma única troca de solicitação-resposta entre dois agentes, compreendendo quatro fluxos de tokens: geração de solicitação (A produz saída), processamento de solicitação (B processa entrada), geração de resposta (B produz saída) e recepção de resposta (A processa entrada).

Janela de contexto. O buffer de tokens de comprimento fixo disponível para um LLM processar uma única chamada de inferência. As janelas de contexto variam de 8K tokens (modelos legados) a 1M+ tokens (Claude Opus 4.6 [1], Gemini 3.1 Pro [30]). A janela de contexto é simultaneamente um recurso computacional, um ativo econômico e um gargalo de atenção.

Token. A unidade atômica de computação de LLM. Um token corresponde a aproximadamente 4 caracteres ou 0,75 palavras em inglês. Os tokens são precificados por milhão (MTok) com taxas separadas para entrada e saída [1].

Custo de compreensão. O custo de inferência incorrido por um agente receptor para processar uma mensagem recebida. Medido em tokens de entrada multiplicados pela taxa de entrada por token do agente. Esse custo é incorrido antes de o agente decidir se responde.

Liquidação bilateral. Uma alocação de custos que atribui uma parcela do custo total da interação a cada participante com base em contribuição, benefício ou termos negociados.

Utilização de contexto. A fração da janela de contexto de um agente consumida por uma única interação. Uma solicitação de 50.000 tokens para um agente com janela de 200.000 tokens consome 25% do contexto disponível.

Fluxo de tokens. Um movimento direcional de tokens em uma interação de agente. Cada interação tem quatro fluxos: solicitação A→B (tokens de saída de A, tokens de entrada de B), resposta B→A (tokens de saída de B, tokens de entrada de A). Cada fluxo tem precificação por token distinta determinada pelo modelo e provedor do agente gerador/receptor.

Registro de medição. Uma entrada de log estruturada capturando contagens de tokens, identificadores de modelo, precificação do provedor, carimbos de tempo e custos calculados para um único fluxo de tokens. Quatro registros de medição constituem um registro completo de interação.

Proposta de liquidação. Uma recomendação de alocação de custos produzida pelo motor de liquidação do CWEP, especificando a parcela de cada agente no custo total da interação com o método de alocação e os parâmetros utilizados.

3. Princípios de Design

3.1 Medir Tudo, Liquidar Seletivamente

Nem toda interação entre agentes requer liquidação bilateral. Uma consulta leve de informação (500 tokens de entrada, 200 tokens de saída) custa frações de centavo — liquidá-la custaria mais do que a própria interação. O CWEP separa medição (sempre ativa) de liquidação (acionada por limiar). Todas as interações são medidas para observabilidade, atribuição de custos e auditoria; a liquidação ocorre apenas quando o custo da interação excede um limiar configurável ou quando um acordo explícito a exige.

3.2 Honestidade Sobre a Impossibilidade

Os resultados de impossibilidade de Green-Laffont e Moulin-Shenker [12] provam que nenhum mecanismo de compartilhamento de custos pode alcançar simultaneamente compatibilidade de incentivos (relato verídico de custos), equilíbrio orçamentário (pagamentos igualam custos) e eficiência econômica (todas as interações benéficas ocorrem). Qualquer protocolo que afirme alcançar os três é confuso ou desonesto. O CWEP faz uma escolha de design explícita: sacrificamos a eficiência plena em favor do equilíbrio orçamentário e da compatibilidade aproximada de incentivos. Algumas interações benéficas não ocorrerão porque a alocação de custos as torna não lucrativas para uma das partes. Esse é o preço de um sistema que não opera em déficit e não incentiva relatos falsos.

3.3 Agnóstico Quanto ao Meio de Pagamento

O CWEP produz propostas de liquidação — alocações de custos estruturadas com valores denominados em moeda fiduciária (USD) ou stablecoins (USDC). Como esses valores são transferidos está fora do escopo do CWEP. A liquidação pode usar x402 para micropagamentos nativos HTTP [3], MPP para liquidação multimeio [4], Superfluid para pagamentos via streaming em conversas contínuas [24], L402 para micropagamentos via Bitcoin Lightning [23], faturamento tradicional para implantações empresariais ou contabilidade interna quando ambos os agentes compartilham um operador. O CWEP especifica o quê e quanto; a camada de pagamento lida com o como.

3.4 Abraçar a Novidade

Onde modelos econômicos estabelecidos se aplicam (valor de Shapley para alocação de custos, LMP para precificação dependente de posição, barganha de Nash para negociação bilateral), nós os utilizamos com atribuição adequada e ressalvas. Onde nenhum modelo anterior captura as dinâmicas (custos quadráticos de atenção, fluxos bilaterais de compreensão, assimetria de nível de modelo), construímos a partir de primeiros princípios e marcamos claramente a contribuição como original. Não fingimos que este problema é apenas "contas telefônicas para robôs" ou "computação em nuvem com etapas extras."

3.5 Complexidade Progressiva

O protocolo especifica três níveis de implementação:

• Nível 1: Apenas Medição. Contagem de tokens e atribuição de custos sem liquidação. Útil para visibilidade de custos em sistemas multiagente. Pode ser implantado hoje com ferramentas de observabilidade existentes.
• Nível 2: Liquidação Baseada em Regras. Regras estáticas de divisão de custos (ex.: "solicitante paga 60%, respondente paga 40%") incorporadas em Agent Service Agreements [20]. Simples, previsível, não requer negociação em tempo real.
• Nível 3: Liquidação Dinâmica. Alocação de custos em tempo real usando valor de Shapley ou barganha de Nash baseada nas características da interação. Requer que ambos os agentes implementem o motor de liquidação do CWEP.

As organizações adotam o nível que corresponde às suas necessidades de complexidade. O Nível 1 entrega valor imediatamente; o Nível 3 é o objetivo de longo prazo.

4. O Problema do Custo de Compreensão

4.1 Anatomia de uma Interação de Agente

Considere um cenário concreto: o Agente A (um gerente de projetos) envia ao Agente B (um especialista em revisão de código) um pull request com 15 arquivos alterados, totalizando 8.000 tokens de saída de diff mais 2.000 tokens de instruções de revisão. O Agente B processa a solicitação, gera uma revisão de 3.000 tokens e a envia de volta. O Agente A processa a revisão para extrair itens de ação.

Os fluxos de tokens:

No modelo solicitante-paga (o único modelo implementado pelos protocolos de pagamento atuais), o Agente A paga US$0,234. O Agente B paga US$0,00. Mas o operador do Agente B na verdade incorreu em US$0,075 em custos de inferência (processamento de entrada + geração de saída). O modelo atual cobra a mais de A em US$0,075 e cobra a menos de B pelo mesmo valor.

Agora escale isso. Na precificação do Claude Opus 4.6 (US$5,00/US$25,00 por MTok), a mesma interação custa:

A 10.000 interações desse tipo por dia, o custo total anual de inferência é de US$1,42 milhão. O erro de alocação no modelo solicitante-paga — o valor incorretamente atribuído — é de US$456.250/ano. Isso não é um erro de arredondamento.

4.2 Os Quatro Fluxos de Custo

Toda interação de agente gera exatamente quatro fluxos de custo. O CWEP nomeia e rastreia todos os quatro:

Fluxo 1: Saída de Solicitação (RO). O solicitante gera a solicitação. Custo = tokens_solicitação × taxa_saída_solicitante. Este é o único fluxo precificado pelos protocolos de pagamento atuais.

Fluxo 2: Entrada de Solicitação (RI). O respondente processa a solicitação. Custo = tokens_solicitação × taxa_entrada_respondente. Este é o custo de compreensão — o custo incorrido pelo respondente antes de qualquer decisão de responder. É exclusivo das interações de agentes e não tem paralelo no comércio humano.

Fluxo 3: Saída de Resposta (SO). O respondente gera a resposta. Custo = tokens_resposta × taxa_saída_respondente. Isso é paralelo à precificação tradicional de serviços — o custo de produzir a entrega.

Fluxo 4: Entrada de Resposta (SI). O solicitante processa a resposta. Custo = tokens_resposta × taxa_entrada_solicitante. Este é o custo de receber e compreender a entrega. Em termos humanos, seria como pagar para ler um relatório que você encomendou.

O custo total da interação é: C_total = RO + RI + SO + SI

O insight fundamental é que RO e SI são arcados pelo operador do solicitante, enquanto RI e SO são arcados pelo operador do respondente. No modelo solicitante-paga, o solicitante é cobrado por todos os quatro fluxos, mas incorre diretamente em apenas dois. No status quo (sem liquidação entre agentes), cada operador absorve seus próprios custos sem reconciliação.

4.3 Assimetria e Suas Consequências

Os quatro fluxos não são igualmente dimensionados. Agentes de IA em produção tipicamente consomem 100 tokens de entrada para cada 1 token de saída gerado [31]. Isso significa que o fluxo de processamento de solicitação (RI) tipicamente domina o fluxo de geração de resposta (SO) em contagem de tokens, mas tokens de saída custam de 3 a 5x mais por token do que tokens de entrada em todos os principais provedores [1][30][32]. O resultado é uma interação complexa onde nenhum dos lados arca consistentemente com a maioria do custo.

A assimetria cria três falhas de mercado:

1. Externalidade de Solicitação Verbosa. O Agente A não tem incentivo para minimizar o tamanho da solicitação porque o custo de processamento do Agente B é invisível para A. Uma solicitação de 50.000 tokens que poderia ser comprimida para 5.000 tokens [16] impõe 10x de custo desnecessário a B. Sem sinais de custo bilaterais, A não investirá em compressão.

2. Incompatibilidade de Nível de Modelo. O Agente B pode usar Opus 4.6 (US$5,00/MTok de entrada) quando Haiku 4.5 (US$0,25/MTok de entrada) seria suficiente para a solicitação — uma diferença de custo de 20x [1]. Se B arca com seus próprios custos de entrada sem recuperação, há pressão para usar o modelo mais barato independentemente da qualidade. Se o solicitante paga, há pressão para usar o modelo mais caro (revestimento de ouro). Nenhum dos incentivos produz seleção eficiente de modelo.

3. Tragédia dos Comuns da Janela de Contexto. A janela de contexto de um agente é um recurso compartilhado em sistemas multiagente — múltiplos agentes podem enviar solicitações que coletivamente preenchem a janela de contexto, reduzindo a capacidade disponível para cada um. Sem precificação, os agentes consomem excessivamente um recurso escasso. Esta é uma tragédia dos comuns clássica [33], transposta de pastagens para espaço de contexto.

4.4 Por Que "Dividir 50/50" Não Funciona

A solução ingênua — dividir todos os custos igualmente entre solicitante e respondente — falha porque as interações raramente são simétricas em valor. Quando o Agente A solicita uma revisão de código do Agente B, A recebe substancialmente mais valor (uma base de código revisada) do que B recebe (uma tarefa concluída, crédito de reputação). Uma divisão de custos 50/50 ignora essa assimetria e desencoraja agentes de fornecer serviços de alto valor.

Da mesma forma, um modelo fixo de solicitante-paga falha quando a interação é mutuamente benéfica — por exemplo, dois agentes de pesquisa compartilhando descobertas. Se o iniciador sempre paga, o primeiro agente a enviar uma mensagem é penalizado, criando um jogo de "você primeiro" que atrasa interações produtivas.

A alocação correta depende da interação específica: quem se beneficia, em que medida e quais alternativas cada parte possui. Este é precisamente o problema que a teoria dos jogos cooperativos foi desenvolvida para resolver.

5. Janela de Contexto como Recurso Escasso

5.1 A Economia da Atenção dos Agentes

Herbert Simon articulou o insight fundamental em 1971: "Uma riqueza de informação cria uma pobreza de atenção e a necessidade de alocar essa atenção de forma eficiente" [34]. Simon estava descrevendo a cognição humana, mas o paralelo com agentes de IA é exato. A janela de contexto de um LLM é seu orçamento de atenção. Cada token consumido por uma informação é um token indisponível para outra. A engenharia de contexto — projetar tudo para que o modelo gaste seu orçamento limitado de atenção apenas em tokens de alto sinal — é explicitamente reconhecida pela Anthropic como uma disciplina central [35].

Heitmayer (2024) distingue "Atenção de Fluxo" (processamento imediato e experiencial) de "Atenção Calcificada" (conhecimento armazenado externamente, conversível em valor) [36]. Para agentes de IA, a atenção de fluxo mapeia para o processamento ativo da janela de contexto; a atenção calcificada mapeia para sistemas de memória externos (Mem0 [37], Zep [38], Letta [39]). A questão econômica é: quando um agente deve pagar para manter informação em sua cara janela de contexto, e quando deve descarregar para memória externa mais barata?

Essa questão tem uma resposta quantitativa. Em contextos de 100.000+ tokens, os sistemas de memória (US$0,0568/usuário para 10 turnos) tornam-se mais baratos do que LLMs de contexto longo (US$0,0588/usuário). Em 20 interações, a memória alcança 26% de economia de custos [18]. A memória antecipa custos de gravação; o contexto longo escala custos variáveis por interação. O ponto de cruzamento é função da frequência de interação, tamanho do contexto e precificação do provedor — todos os quais o CWEP pode modelar.

5.2 Escalonamento Quadrático de Custo

A atenção do transformer computa interações por pares entre todos os tokens na janela de contexto. Para n tokens, isso requer O(n^2) operações. Em termos econômicos: o custo marginal de um token adicional aumenta com o comprimento do contexto. Os primeiros 1.000 tokens em um contexto vazio são baratos; os últimos 1.000 tokens em um contexto de 999.000 tokens são caros.

Essa não linearidade tem implicações profundas para precificação. Uma taxa fixa por token (o modelo universal de precificação em março de 2026 [1][30][32]) subprecifica interações de contexto longo e sobreprecifica interações curtas. Os modelos Gemini do Google parcialmente reconhecem isso com precificação escalonada — o Gemini 2.5 Pro cobra US$1,25/MTok para entrada até 200K tokens e US$2,50/MTok além de 200K [30]. Mas nenhum provedor implementa precificação contínua dependente de posição.

O modelo de precificação de contexto do CWEP (Seção 9) aborda isso introduzindo um multiplicador de custo dependente de posição análogo à Precificação Marginal Locacional em redes elétricas [13], onde a "localização" é a posição do token na janela de contexto.

5.3 O Muro de Memória da IA

A escassez da janela de contexto não é meramente econômica — é física. O "Muro de Memória da IA" descreve a restrição em que a memória da GPU não consegue acomodar cache KV suficiente para contextos concorrentes estendidos de agentes [40]. O Augmented Memory Grid da WEKA aborda isso com escalonamento hierárquico de memória, alcançando taxas de acerto de cache KV de 96 a 99%, mas a escassez subjacente persiste: o espaço da janela de contexto é limitado por hardware, não apenas por precificação.

Para uma sessão típica de agente de 8 horas custando aproximadamente US$80, cerca de US$29 (36%) são computação desperdiçada por ineficiência de memória [40]. O mercado de infraestrutura de memória está projetado para alcançar US$28,45 bilhões até 2030 a uma CAGR de 35% [40], impulsionado em grande parte pela demanda por gerenciamento eficiente de contexto. Essa escassez no nível de hardware é o que torna a janela de contexto um recurso econômico genuinamente escasso, não meramente caro.

5.4 Utilização de Contexto como Sinal Econômico

A utilização de contexto de um agente — a fração de sua janela atualmente consumida — é um sinal econômico significativo. Um agente a 90% de utilização de contexto tem capacidade limitada para novas solicitações e deve precificar sua capacidade restante com um prêmio. Um agente a 10% de utilização tem capacidade abundante e pode processar solicitações a taxas básicas.

Isso espelha as dinâmicas de redes elétricas onde os preços disparam durante picos de demanda (precificação por congestionamento) e podem até ficar negativos durante excesso de oferta [13]. Áreas ricas em vento no Southwest Power Pool (SPP) frequentemente experimentam Preços Marginais Locacionais negativos quando a oferta excede a demanda [41]. O paralelo com agentes: o processamento de contexto poderia ter custo negativo se o respondente ganha valor ao responder — crédito de reputação, sinal de treinamento ou posicionamento de mercado?

O CWEP modela a utilização de contexto como um insumo para a função de precificação de contexto (Seção 9), ao lado da posição do token, nível de modelo e precificação do provedor.

6. Teoria de Alocação de Custos

6.1 Fundamentos da Teoria dos Jogos Cooperativos

O CWEP se baseia em duas soluções clássicas da teoria dos jogos cooperativos, cada uma codificando um princípio de equidade distinto.

Valor de Shapley (Shapley, 1953) [10]. O valor de Shapley aloca custos com base na contribuição marginal média de cada participante em todas as ordens possíveis. Ele satisfaz quatro axiomas: eficiência (os custos somam o total), simetria (contribuidores equivalentes pagam igualmente), linearidade (aditivo em componentes de custo independentes) e jogador nulo (não contribuidores pagam zero).

Para uma interação de dois agentes, o valor de Shapley simplifica-se para:

Payment(A) = [C(A,B) + C(A) - C(B)] / 2
Payment(B) = [C(A,B) + C(B) - C(A)] / 2

onde C(A,B) é o custo da interação conjunta, C(A) é o custo que o Agente A incorreria sozinho (ou seja, gerar a solicitação sem resposta) e C(B) é o custo que o Agente B incorreria sozinho (capacidade de processamento reservada sem solicitação). No caso de dois agentes, o valor de Shapley é computável em tempo constante — nenhuma aproximação é necessária.

Computar valores exatos de Shapley é NP-difícil para n jogadores (exponencial no número de agentes) [42], mas interações multiagente envolvendo mais de dois agentes por troca são incomuns. Para interações multipartidárias (ex.: um chat em grupo entre cinco agentes), métodos de aproximação rápida usando designs fatoriais fracionários estão disponíveis [43].

O valor de Shapley já é a abordagem dominante em IA para problemas de atribuição. O SHAP (SHapley Additive exPlanations) o utiliza para interpretabilidade de modelos [44]. O ShapleyFL o utiliza para valoração de dados em aprendizado federado [45]. O VerFedSV o estende com verificação [46]. O CWEP estende o mesmo framework para atribuição de custos.

Nucléolo (Schmeidler, 1969) [47]. O nucléolo minimiza a insatisfação máxima de qualquer coalizão. Ele é sempre único, sempre está no núcleo (se o núcleo não é vazio). Enquanto Shapley maximiza a equidade por meio de contribuição proporcional, o nucléolo maximiza a equidade por meio de minimização de reclamações — nenhum agente pode argumentar que está sendo tratado de forma especialmente injusta em relação aos outros.

Para alocação de custos de agentes, a escolha entre Shapley e nucléolo codifica uma decisão de design de mercado:

• Shapley recompensa agentes que contribuem mais valor para as interações. Um mercado competitivo favorecendo eficiência preferiria Shapley.
• Nucléolo garante que nenhum agente subsidie outros além de um limiar tolerável. Uma rede cooperativa priorizando participação preferiria o nucléolo.

O CWEP usa Shapley como padrão para interações bilaterais (onde as duas soluções frequentemente coincidem) e oferece nucléolo como alternativa configurável para cenários multipartidários.

6.2 Barganha de Nash para Negociação Bilateral

Quando dois agentes negociam compartilhamento de custos diretamente — em vez de aceitar uma alocação de um protocolo — aplica-se a teoria da barganha de Nash [11].

A Solução de Barganha de Nash maximiza o produto das utilidades acima do ponto de desacordo (o resultado se as negociações falharem). Ela satisfaz quatro axiomas: invariância de escala, otimalidade de Pareto, independência de alternativas irrelevantes e simetria. A barganha de Nash assimétrica estende isso com parâmetros de poder de barganha — o agente com mais alternativas ou menores custos de troca captura uma parcela maior do excedente [48].

Ofertas Alternadas de Rubinstein (1982) [49] operacionalizam a barganha de Nash dinamicamente. Com fator de desconto comum d, a divisão de equilíbrio é: Jogador 1 recebe 1/(1+d), Jogador 2 recebe d/(1+d). O acordo é alcançado na primeira rodada (sem atrasos custosos). Conforme a paciência aumenta, a divisão converge para 50/50. Isso mapeia diretamente para agentes negociando divisões de custo por interação com pressão temporal da depleção do orçamento de tokens.

Para o CWEP, a barganha de Nash governa o Nível 3 (Liquidação Dinâmica) quando agentes possuem posições de barganha assimétricas — diferentes opções externas, diferentes urgências, diferentes custos de modelo. O parâmetro de poder de barganha pode ser informado por pontuações do Agent Rating Protocol [21]: um agente com pontuação mais alta comanda maior poder de barganha porque suas opções externas (outros agentes dispostos a interagir) são mais numerosas.

6.3 A Restrição de Impossibilidade

Um resultado fundamental restringe o que qualquer protocolo de alocação de custos pode alcançar. Green-Laffont (1979) e Moulin-Shenker (2001) demonstraram que três propriedades desejáveis são mutuamente incompatíveis em qualquer mecanismo de compartilhamento de custos [12]:

1. Compatibilidade de Incentivos — agentes relatam veridicamente seus custos e valorações
2. Equilíbrio Orçamentário — pagamentos totais igualam custos totais (o sistema não gera nem absorve dinheiro)
3. Eficiência Econômica — todas as interações com valor social líquido positivo ocorrem

Qualquer protocolo deve sacrificar pelo menos uma. A escolha de design do CWEP:

• Sacrificada: Eficiência Econômica Plena. Algumas interações benéficas não ocorrerão porque o custo alocado as torna não lucrativas para uma das partes. Isso é preferível às alternativas: sacrificar compatibilidade de incentivos (agentes relatam custos falsamente, levando a distorção sistemática) ou sacrificar equilíbrio orçamentário (o sistema requer subsídio externo ou gera excedente que deve ser redistribuído).
• Preservado: Equilíbrio Orçamentário. Pagamentos totais em todos os agentes igualam custos totais de inferência. Nenhum dinheiro aparece ou desaparece.
• Preservada: Compatibilidade Aproximada de Incentivos. Agentes não podem lucrar ao deturpar sua estrutura de custos, embora possam ter incentivos menores para relatar incorretamente valorações marginais.

Duas famílias práticas de mecanismos emergem dessa troca:

• Mecanismos de Tâtonnement (Moulin) — equilibrados orçamentariamente, mas não plenamente eficientes. Garantem resistência a estratégia de grupo através de compartilhamento de custos cross-monotônico [50]. O Nível 2 do CWEP (Liquidação Baseada em Regras) implementa essa família.
• Mecanismos VCG — eficientes, mas operam em déficit. A precificação de custo marginal não pode ser autossustentável [51]. Não apropriados para o CWEP porque o equilíbrio orçamentário é essencial para implantação no mundo real.

6.4 Analogias de Infraestrutura: Lições e Limites

Três domínios de infraestrutura fornecem paralelos úteis (mas limitados).

Peering de Internet. Mais de 80.000 redes independentes usam dois modelos para troca de tráfego: peering livre de liquidação (ambos os lados arcam com seus próprios custos, viável quando o tráfego é aproximadamente equilibrado) e trânsito pago (o remetente mais pesado paga, acionado em desequilíbrio de tráfego de aproximadamente 2:1) [28]. A Coreia do Sul determinou o modelo remetente-paga em 2016/2020 com resultados ruins: custos de trânsito dispararam, a latência quadruplicou para alguns serviços, a Meta mudou servidores para Hong Kong e startups domésticas arcaram com custos desproporcionais. A Internet Society concluiu que é "um alerta, não um modelo" [52]. O BEREC considerou que "não há evidência de que tal mecanismo seja justificado" [53].

Implicação: O modelo puro de solicitante-paga para interações de agentes pode similarmente desfavorecer agentes que precisam de contexto extenso para fazer solicitações eficazes. O modelo pague-e-mantenha (cada agente absorve seus próprios custos) pode ser mais eficiente para interações de alta frequência e baixo valor.

LMP de Eletricidade. A Ordem FERC 1920 determina "beneficiário paga" com "proporcionalidade aproximada" — clientes pagam custos aproximadamente proporcionais aos benefícios recebidos [54]. A LMP decompõe o preço em cada nó da rede em custo marginal de energia (custo base de inferência), custo marginal de congestionamento (prêmio de limite de taxa durante pico de demanda) e custo marginal de perda (tokens de overhead em protocolos de comunicação) [13].

Implicação: O modelo de precificação de contexto do CWEP (Seção 9) adota a decomposição de três componentes: custo base do token, prêmio de congestionamento (utilização de contexto) e custo de overhead (tokens de enquadramento do protocolo).

Interconexão de Telecomunicações. A indústria de telecomunicações passou décadas debatendo Quem-Liga-Paga (CPNP, análogo a solicitante-paga) versus Pague-e-Mantenha (B&K, cada rede absorve seus próprios custos). A regulamentação "All-IP Future" da FCC de 2026 propõe completar a transição dos EUA para pague-e-mantenha ao longo de três anos: redução de 33% por ano nas taxas de acesso remanescentes [29].

Implicação: A mudança de décadas da indústria de telecomunicações de CPNP para B&K sugere que solicitante-paga pode ser ineficiente para interações de alta frequência. Os custos de transação de medir e liquidar cada interação podem exceder os valores de liquidação, tornando pague-e-mantenha o padrão racional para interações de baixo custo.

FinOps em Nuvem. A alocação de custos é a prioridade nº 2 para profissionais de FinOps (30%), atrás de otimização de carga de trabalho [55]. 58% das organizações implementaram modelos de showback/chargeback, no entanto a indústria de nuvem gastou uma década construindo infraestrutura de atribuição de custos e ainda considera esse o segundo problema mais difícil [55]. A Especificação FOCUS v1.3 padroniza a alocação de custos entre provedores [6].

Implicação: A alocação de custos de agentes deve se basear no FOCUS em vez de inventar novos padrões de medição. O formato de medição do CWEP estende o FOCUS com campos específicos para agentes.

7. Especificação do Protocolo: Medição de Tokens

7.1 Formato do Registro de Medição

Toda interação de agente produz um Registro de Medição CWEP (CMR) capturando os quatro fluxos de tokens. O CMR estende a especificação FinOps FOCUS [6] com campos específicos para agentes.

{
  "cwep_version": "1.0.0",
  "interaction_id": "uuid-v4",
  "timestamp": "ISO-8601",
  "requestor": {
    "agent_id": "did:example:agent-a",
    "model": "claude-sonnet-4-6",
    "provider": "anthropic",
    "pricing": {
      "input_rate_per_mtok": 3.00,
      "output_rate_per_mtok": 15.00,
      "cache_hit_rate_per_mtok": 0.30,
      "currency": "USD"
    }
  },
  "responder": {
    "agent_id": "did:example:agent-b",
    "model": "claude-opus-4-6",
    "provider": "anthropic",
    "pricing": {
      "input_rate_per_mtok": 5.00,
      "output_rate_per_mtok": 25.00,
      "cache_hit_rate_per_mtok": 0.50,
      "currency": "USD"
    }
  },
  "flows": {
    "request_output": {
      "tokens": 10000,
      "cached_tokens": 0,
      "cost_usd": 0.150
    },
    "request_input": {
      "tokens": 10000,
      "cached_tokens": 3000,
      "cost_usd": 0.036
    },
    "response_output": {
      "tokens": 3000,
      "cached_tokens": 0,
      "cost_usd": 0.075
    },
    "response_input": {
      "tokens": 3000,
      "cached_tokens": 0,
      "cost_usd": 0.009
    }
  },
  "totals": {
    "total_tokens": 26000,
    "total_cost_usd": 0.270,
    "requestor_incurred_usd": 0.159,
    "responder_incurred_usd": 0.111
  },
  "context_state": {
    "responder_utilization_pre": 0.35,
    "responder_utilization_post": 0.40,
    "responder_window_size": 1000000
  },
  "coc_chain_ref": "sha256:abc123...",
  "settlement": null
}

7.2 Integração de Medição

A medição do CWEP não exige que os agentes implementem nova contagem de tokens — ela consome dados da infraestrutura de observabilidade existente:

• Respostas de provedores. Todos os principais provedores de LLM retornam uso de tokens nas respostas da API. OpenAI, Anthropic e Google incluem prompt_tokens, completion_tokens e total_tokens nos metadados de resposta [1][30][32].
• Langfuse. Observabilidade de código aberto com licença MIT com spans aninhados de agente e rastreamento de tokens por agente. Os registros de medição do CWEP podem ser emitidos como observações do Langfuse com metadados customizados [7].
• LiteLLM. Gateway unificado para mais de 100 provedores com rastreamento de custos por agente. O Gateway A2A do LiteLLM já rastreia custos de agente por consulta [8]. O CWEP estende isso com atribuição bilateral de custos.
• Portkey. Normaliza contagens de tokens entre provedores em um formato consistente, eliminando discrepâncias entre provedores [9]. O CWEP utiliza essa normalização.
• AutoGen/AG2. Rastreamento de custos por agente integrado via API gather_usage_summary() [56]. O CWEP consome os dados de custo do AutoGen e os enriquece com alocação bilateral.

7.3 Overhead de Medição

O CMR em si consome recursos — serialização JSON, armazenamento e potencial transmissão. O CWEP restringe o overhead de medição:

• Tamanho máximo do CMR: 2 KB por interação (desprezível em relação aos tokens da interação)
• Transmissão em lote: CMRs podem ser agrupados e transmitidos em intervalos configuráveis (padrão: a cada 60 segundos ou 100 interações, o que ocorrer primeiro)
• Amostragem: Para interações de altíssima frequência, amostragem estatística (1 em N medições) é suportada com relato apropriado de intervalo de confiança
• Local primeiro: CMRs são gravados localmente primeiro, transmitidos a contrapartes ou serviços de agregação de forma assíncrona

8. Especificação do Protocolo: Liquidação Bilateral

8.1 Níveis de Liquidação

O CWEP define três níveis de liquidação, cada um apropriado para diferentes perfis de interação.

Nível 1: Sem Liquidação (Apenas Medição)

Cada agente absorve seus próprios custos de inferência. CMRs são gerados para observabilidade, mas nenhum pagamento entre agentes ocorre. Este é o modo padrão e a escolha apropriada quando:

• Ambos os agentes compartilham um operador (frota interna)
• Os custos de interação estão abaixo do limiar de liquidação (padrão: US$0,01)
• A interação é mutuamente benéfica com custos aproximadamente simétricos
• Um Agent Service Agreement explícito especifica termos de pague-e-mantenha

Isso espelha o peering livre de liquidação na interconexão de internet [28] e o modelo pague-e-mantenha em telecomunicações [29]. Para frotas internas de agentes (como a frota AB Support), o Nível 1 fornece visibilidade de custos sem o overhead de liquidação entre agentes.

Nível 2: Liquidação Baseada em Regras

Uma regra de alocação estática divide os custos de acordo com uma fórmula incorporada no acordo de serviço dos agentes (via ASA [20]). Regras comuns:

As regras do Nível 2 são avaliadas localmente pelo motor CWEP de cada agente. Nenhuma negociação ocorre no momento da interação — a regra foi acordada quando o acordo de serviço foi estabelecido. Isso é computacionalmente trivial e adiciona zero latência às interações.

Nível 3: Liquidação Dinâmica

Alocação de custos em tempo real usando o motor de liquidação do CWEP. O motor seleciona um método de alocação com base nas características da interação:

IF interaction is cooperative (shared goal, symmetric benefit):
    Use Shapley value allocation
ELSE IF interaction is competitive (one-sided benefit):
    Use asymmetric Nash bargaining
ELSE IF interaction involves >2 agents:
    Use approximate Shapley with sampling
ELSE:
    Fall back to Tier 2 proportional split

A liquidação dinâmica requer que ambos os agentes implementem o motor de liquidação CWEP e troquem metadados de custo durante a interação. O cálculo de liquidação adiciona latência mínima (< 1ms para Shapley de dois agentes), mas requer consenso sobre os parâmetros da interação.

8.2 Liquidação por Valor de Shapley

Para uma interação de dois agentes, a liquidação baseada em Shapley computa o pagamento de cada agente como:

standalone_cost(A) = RO  (A generates request, no response comes back)
standalone_cost(B) = 0   (B does nothing without a request)
joint_cost(A,B) = RO + RI + SO + SI

shapley_payment(A) = [joint_cost + standalone_cost(A) - standalone_cost(B)] / 2
                   = [RO + RI + SO + SI + RO - 0] / 2
                   = [2*RO + RI + SO + SI] / 2
                   = RO + (RI + SO + SI) / 2

shapley_payment(B) = [joint_cost + standalone_cost(B) - standalone_cost(A)] / 2
                   = [RO + RI + SO + SI + 0 - RO] / 2
                   = (RI + SO + SI) / 2

Interpretação: O solicitante paga seu próprio custo de geração de solicitação mais metade de todos os custos restantes. O respondente paga metade dos custos restantes. Isso reflete a realidade econômica de que o solicitante iniciou a interação e deve arcar com uma parcela maior — mas o respondente também escolheu participar, o que é uma decisão bilateral.

Para o exemplo de revisão de código da Seção 4.1 (Sonnet 4.6):

• Agente A (solicitante) paga: US$0,150 + (US$0,030 + US$0,045 + US$0,009) / 2 = US$0,150 + US$0,042 = US$0,192
• Agente B (respondente) paga: (US$0,030 + US$0,045 + US$0,009) / 2 = US$0,042
• Total: US$0,234 (equilibrado orçamentariamente)

Compare com solicitante-paga (US$0,234 / US$0,00) e divisão igualitária (US$0,117 / US$0,117). A alocação de Shapley captura a intuição de que o solicitante iniciou a interação e arca com mais custo, mas o custo de processamento do respondente é parcialmente compartilhado.

Nota sobre standalone_cost(B) = 0. Essa formulação assume custo autônomo zero para o respondente — não contabiliza custos de infraestrutura para manter disponibilidade (manter o modelo ativo, reservar capacidade da janela de contexto, manter uptime). Em implantações onde os custos fixos do respondente são significativos, o termo standalone_cost(B) pode ser definido como o custo de infraestrutura por período do respondente amortizado entre as interações esperadas. Por exemplo, se os custos de infraestrutura fixa do Agente B custam US$0,02 por período de interação esperado, a alocação de Shapley muda:

standalone_cost(B) = 0.02
shapley_payment(A) = [joint_cost + standalone_cost(A) - standalone_cost(B)] / 2
                   = [$0.234 + $0.150 - $0.02] / 2 = $0.182
shapley_payment(B) = [joint_cost + standalone_cost(B) - standalone_cost(A)] / 2
                   = [$0.234 + $0.02 - $0.150] / 2 = $0.052

Definir standalone_cost(B) > 0 desloca a alocação para uma divisão mais equilibrada, refletindo o custo real de disponibilidade de B. A simplificação de custo autônomo zero é apropriada para agentes leves com custos fixos desprezíveis; deve ser substituída para agentes que mantêm infraestrutura dedicada.

8.3 Liquidação por Barganha de Nash

Quando agentes possuem posições de barganha assimétricas, a solução de barganha de Nash substitui Shapley:

utility(A) = value_received(A) - payment(A)
utility(B) = value_received(B) - payment(B)

disagreement(A) = 0  (A gets nothing if no interaction)
disagreement(B) = 0  (B gets nothing if no interaction)

Nash solution maximizes:
    [utility(A) - disagreement(A)]^alpha x [utility(B) - disagreement(B)]^(1-alpha)

where alpha = bargaining_power(A), and alpha + (1-alpha) = 1

O parâmetro de poder de barganha alfa pode ser derivado de:

• Pontuações de reputação ARP [21]: agentes com pontuação mais alta possuem mais opções externas, aumentando o poder de barganha
• Utilização de contexto: um agente a 90% de utilização de contexto tem menos capacidade e mais poder de barganha (prêmio de escassez)
• Histórico de interação: agentes com histórico de interações produtivas podem aceitar margens menores para manter o relacionamento (fator de desconto de Rubinstein [49])

A liquidação por barganha de Nash requer que ambos os agentes declarem suas valorações, o que introduz a preocupação com compatibilidade de incentivos: agentes podem relatar valores incorretamente para capturar excedente. Um agente sofisticado pode reduzir sua valoração declarada enquanto ainda completa interações — capturando excedente sem acionar falhas de negociação, mantendo assim uma pontuação ARP positiva. A reputação ARP mitiga relatos grosseiramente falsos (onde relatos incorretos causam negociações fracassadas), mas não esse tipo sofisticado de subvaloração. O design de mecanismos que alcança compatibilidade plena de incentivos para declaração de valor em configurações bilaterais é um problema aberto em economia — a impossibilidade de Green-Laffont (Seção 6.3) aplica-se diretamente aqui [12]. Para a v1.0, o CWEP baseia-se na observação prática de que relatos significativos de valor incorreto tendem a produzir combinações subótimas ao longo do tempo (agentes que subdeclaram valor recebem contrapartes de menor qualidade via AMP [19]), o que é detectável em agregado mesmo que instâncias individuais não sejam. A compatibilidade plena de incentivos em relato bilateral de valor permanece um problema de pesquisa aberto para versões futuras do protocolo.

8.4 Protocolo de Liquidação

O handshake de liquidação ocorre após a conclusão da interação:

1. Both agents generate CMRs independently
2. Agents exchange CMRs (or a hash digest for privacy)
3. Each agent's CWEP engine computes the settlement proposal
4. If proposals agree (within tolerance): settlement is accepted
5. If proposals disagree: dispute resolution via AJP [17]
6. Settlement amount is recorded in both agents' CMRs
7. Payment is triggered via the configured payment rail

O limiar de tolerância para concordância de propostas é configurável (padrão: 5% do custo total da interação). Divergências além desse limiar são registradas como disputas de custo e podem ser escaladas pelo módulo de resolução de disputas do Agent Justice Protocol.

8.5 Estudo de Caso: Custos de Interação da Frota AB Support

A frota AB Support — um sistema multiagente em produção composto por um coordenador (Alex), agente de pesquisa (Bravo), analista de mergulho profundo (Charlie), desenvolvedor (Delta), revisor de conteúdo (Editor) e tradutor multilíngue (Translator) — fornece dados empíricos para alocação de custos CWEP. As interações representativas a seguir são extraídas de operações reais da frota, com contagens de tokens e custos calculados a partir de padrões reais de interação.

Análise de alocação Shapley. Sob o modelo implícito atual (pague-e-mantenha, o operador de cada agente absorve seus próprios custos), o coordenador (Alex) arca com custos desproporcionais porque gera prompts de tarefa grandes que outros agentes processam. Para a interação de revisão QA de arquivo de conhecimento:

• Modelo atual (pague-e-mantenha): O operador de Alex paga US$0,277 (RO + SI), o operador de Charlie paga US$0,288 (RI + SO)
• Modelo solicitante-paga: O operador de Alex paga US$0,565, o operador de Charlie paga US$0,00
• Alocação Shapley: Alex paga US$0,150 + (US$0,045 + US$0,120 + US$0,024) / 2 = US$0,150 + US$0,095 = US$0,245; Charlie paga US$0,320

Em um ciclo operacional de 24 horas, a frota gera aproximadamente de 30 a 50 interações entre agentes totalizando de 500K a 800K tokens a um custo de US$8 a US$15. A realocação Shapley deslocaria aproximadamente de US$2 a US$4 da distribuição atual de pague-e-mantenha — não um valor absoluto grande para uma frota interna, mas o padrão demonstra a mecânica do protocolo. Para frotas entre operadores com centenas de agentes, a mesma lógica de alocação escala para valores de liquidação significativos.

Observação-chave: As interações mais custosas da frota não são as mais frequentes (despachos de tarefas a ~US$0,05 cada), mas as tarefas de análise profunda (US$0,50 a US$1,50 cada). O limiar de liquidação do CWEP (padrão US$0,01) filtra corretamente os despachos frequentes de baixo custo enquanto captura os custos bilaterais significativos em interações de revisão e síntese. A validação empírica por meio de implantação piloto estendida está planejada para a v1.1.

9. Especificação do Protocolo: Precificação de Contexto

9.1 O Modelo de Três Componentes

O modelo de precificação de contexto do CWEP decompõe o preço efetivo de um token em três componentes, inspirado na Precificação Marginal Locacional em mercados de eletricidade [13]:

Componente 1: Custo Base do Token (BTC)

A taxa por token publicada pelo provedor para o modelo em uso. Este é o preço piso — o custo quando o contexto não está congestionado e a interação é curta.

BTC = provider_rate(model, token_type) × token_count

Onde token_type ∈ {input, output, cached_input} e as taxas são obtidas das páginas de precificação dos provedores [1][30][32].

Componente 2: Prêmio de Congestionamento (CP)

Um multiplicador refletindo a utilização atual de contexto do respondente. Quando a janela de contexto de um agente está quase cheia, o valor marginal da capacidade restante aumenta. O prêmio de congestionamento precifica essa escassez.

CP = BTC × congestion_multiplier(utilization)

congestion_multiplier(u) = {
    1.0           if u < 0.50      (capacidade abundante)
    1.0 + 0.5u    if 0.50 ≤ u < 0.80  (carga moderada)
    1.0 + 2.0u    if 0.80 ≤ u < 0.95  (carga pesada)
    1.0 + 5.0u    if u ≥ 0.95     (capacidade crítica)
}

A 95% de utilização, o prêmio de congestionamento é 5,75x o custo base. Isso é agressivo, mas intencional — sinaliza que a capacidade restante de contexto do agente é extremamente escassa e deve ser reservada para interações de alto valor. A função degrau é mais simples de implementar do que uma função contínua e fornece sinais de precificação claros em cada limiar.

Componente 3: Overhead de Protocolo (PO)

O custo do próprio enquadramento do CWEP — metadados de medição, cabeçalhos de liquidação e tokens de negociação de protocolo. Este é o análogo de "perda de transmissão" da precificação de redes elétricas.

PO = overhead_tokens × provider_rate(model, input)

O CWEP tem como meta overhead de protocolo abaixo de 500 tokens por interação (aproximadamente 0,1% de um contexto típico de 500K tokens). O overhead é arcado pelo solicitante como parte do custo da solicitação.

Preço Efetivo do Token:

effective_price = BTC + CP + PO

9.2 Precificação Dependente de Posição (Extensão Proposta)

O escalonamento quadrático da atenção do transformer significa que tokens em posições diferentes na janela de contexto impõem custos computacionais diferentes. Um token na posição 10.000 custa menos para processar do que um token na posição 900.000 — o cálculo de atenção para este último envolve 90x mais cálculos por pares.

O CWEP propõe (mas não exige na v1.0) uma extensão de precificação dependente de posição:

position_multiplier(pos, window_size) = (pos / window_size)^beta

Onde beta é um parâmetro de ajuste (faixa sugerida: 0,1-0,5) e pos é a posição absoluta do token na janela de contexto. Com beta = 0,3:

• Posição 10K em uma janela de 1M: multiplicador = 0,01^0,3 = 0,50x
• Posição 500K em uma janela de 1M: multiplicador = 0,50^0,3 = 0,81x
• Posição 900K em uma janela de 1M: multiplicador = 0,90^0,3 = 0,97x

Esta extensão é marcada como experimental porque:

1. Nenhum provedor atualmente expõe precificação dependente de posição
2. A curva real de custo computacional depende de detalhes de implementação (Flash Attention, ring attention, etc.) que variam entre provedores
3. O parâmetro beta requer calibração empírica contra custos reais de inferência

A precificação dependente de posição torna-se importante conforme as janelas de contexto crescem para 1M+ tokens. Para interações dentro dos primeiros 100K tokens de uma janela de 1M, o efeito de posição é desprezível e pode ser seguramente ignorado.

9.3 Descoberta Dinâmica de Taxas

Os agentes CWEP devem conhecer a precificação da contraparte para calcular liquidações. Em vez de codificar taxas fixas, o CWEP especifica um protocolo de descoberta de taxas:

1. Agent publishes its current pricing in its A2A Agent Card [57]
   (extension field: cwep_pricing)
2. Before interaction, requestor queries responder's CWEP pricing
3. Responder returns current rates including congestion premium
4. Both agents cache counterparty rates for the interaction duration
5. Rates are locked for the interaction (no mid-interaction repricing)

O travamento de taxas impede manipulação de preços durante uma interação. Um agente não pode inflacionar suas taxas após ver a solicitação para extrair mais da liquidação. As taxas são atualizadas entre interações, não durante elas.

10. Especificação do Protocolo: Níveis de Qualidade de Serviço

10.1 A Falha da Limitação de Taxa Baseada em Requisições

A limitação de taxa tradicional conta requisições por segundo. Isso falha para interações de agentes porque uma única requisição pode custar 100x mais computação do que outra [58]. Um agente que envia uma requisição de 100.000 tokens impõe o mesmo custo de infraestrutura que um agente que envia 100 requisições de 1.000 tokens, mas o primeiro passa por um limite de taxa de 1-req/s enquanto o segundo é estrangulado.

O Gartner prevê que mais de 30% do aumento de demanda de API virá de ferramentas de IA/LLM até 2026 [58]. A limitação de taxa deve evoluir da contagem de requisições para o orçamento de tokens.

10.2 Limitação de Taxa por Orçamento de Tokens

O CWEP define limites de taxa em termos de orçamentos de tokens, não contagem de requisições:

{
  "qos_tier": "standard",
  "limits": {
    "input_tokens_per_minute": 1000000,
    "output_tokens_per_minute": 200000,
    "concurrent_interactions": 10,
    "max_request_size_tokens": 500000,
    "max_context_utilization": 0.80
  }
}

O limite max_context_utilization é uma novidade: impede que uma única interação consuma mais do que uma fração especificada da janela de contexto do agente. Isso protege a capacidade do agente para outras interações.

10.3 Níveis de Processamento Prioritário

O CWEP define quatro níveis de QoS que agentes podem anunciar e solicitantes podem selecionar:

Os níveis de prioridade são implementados por meio do mecanismo de prêmio de congestionamento: requisições de nível mais alto pagam um multiplicador de congestionamento mais alto, que o respondente usa para priorizar a ordem de processamento. O prêmio não é arbitrário — reflete o custo genuíno de manter capacidade reservada e priorizar sobre outros trabalhos.

O nível reservado inclui uma retenção de capacidade: o solicitante paga para reservar uma parte da janela de contexto do respondente por uma duração especificada. Isso espelha a precificação de instâncias reservadas em computação em nuvem, onde o compromisso antecipado garante disponibilidade. A taxa de retenção de capacidade é separada dos custos por interação e é especificada no Agent Service Agreement [20].

10.4 Sinalização de Contrapressão

Quando um agente se aproxima dos limites de capacidade, ele deve sinalizar contrapressão aos solicitantes em vez de degradar silenciosamente ou falhar. O CWEP define sinais de contrapressão:

{
  "cwep_status": "congested",
  "current_utilization": 0.87,
  "estimated_queue_time_ms": 3500,
  "available_tiers": ["priority", "reserved"],
  "economy_queue_depth": 14
}

Solicitantes que recebem sinais de contrapressão podem:

• Aguardar capacidade (aceitar o tempo de fila)
• Fazer upgrade para um nível de QoS mais alto (pagar mais para processamento imediato)
• Rotear para um agente alternativo (se descoberto via AMP [19])
• Comprimir a requisição e tentar novamente (reduzir consumo de contexto)

Isso cria um mecanismo de mercado para capacidade escassa da janela de contexto: quando a demanda excede a oferta, os preços sobem (via prêmio de congestionamento), sinalizando aos solicitantes que paguem mais ou reduzam a demanda.

11. Especificação do Protocolo: Prevenção de Spam

11.1 A Superfície de Ataque da Janela de Contexto

A janela de contexto de um agente é um recurso finito que adversários podem consumir. O ataque mais simples: enviar a um agente uma série de solicitações grandes e sem valor que preenchem sua janela de contexto, impedindo interações legítimas. Este é um ataque de negação de serviço medido em tokens em vez de pacotes.

Diferentemente do DDoS em nível de rede, que é mitigado por largura de banda e filtragem de pacotes, o DoS de janela de contexto é mitigado apenas por mecanismos econômicos — tornando custoso desperdiçar o contexto de um agente. O CWEP fornece três mecanismos defensivos.

11.2 Depósito de Solicitação

Antes de enviar uma solicitação, o solicitante compromete um depósito reembolsável de tokens ao respondente:

deposit_amount = estimated_request_tokens × responder_input_rate × deposit_multiplier

O deposit_multiplier (padrão: 1,5x) é definido pelo respondente e publicado em seu A2A Agent Card [57]. O depósito cobre o custo de compreensão do respondente mais uma margem.

Ciclo de vida do depósito:

1. Solicitante compromete o depósito (travado em canal de pagamento ou custódia)
2. Solicitante envia a solicitação
3. Respondente processa a solicitação
4. Respondente retorna uma avaliação de valor: útil (depósito reembolsado menos custo real de processamento) ou spam (depósito confiscado)
5. Resolução de disputas via AJP [17] se o solicitante contestar a classificação de spam

O mecanismo de depósito torna o spam caro. Enviar 1.000 solicitações de spam para um agente Opus 4.6 com depósito de 100K tokens por solicitação custaria US$750 em depósitos confiscados — suficiente para deter spam automatizado enquanto impõe fricção desprezível a interações legítimas (onde depósitos são reembolsados).

11.3 Acesso Ponderado por Reputação

Agentes com pontuações de reputação ARP mais altas [21] recebem acesso preferencial:

• Reputação alta (>80/100): Nenhum depósito necessário. Acesso a todos os níveis de QoS.
• Reputação média (40-80): Depósito padrão. Acesso aos níveis econômico e padrão.
• Reputação baixa (<40): Depósito elevado (multiplicador 3x). Apenas nível econômico.
• Sem reputação (agentes novos): Depósito máximo (multiplicador 5x). Nível econômico com limites de tamanho de solicitação.

Isso cria um sistema graduado de confiança onde agentes estabelecidos interagem sem fricção, enquanto agentes desconhecidos devem demonstrar disposição para pagar antes de consumir espaço na janela de contexto. Ao longo do tempo, conforme novos agentes constroem reputação por meio de interações produtivas, seus custos de acesso diminuem — um incentivo natural para bom comportamento.

Integração de Novos Agentes. Os requisitos de depósito e reputação acima aplicam-se apenas a interações de Nível 3 (Liquidação Dinâmica) com contrapartes desconhecidas. Novos agentes sem acesso a meios de pagamento ou histórico de reputação podem participar imediatamente por meio dos modos de Nível 1 (Sem Liquidação) ou Nível 2 (Baseado em Regras), que não exigem depósitos. Isso significa que qualquer agente pode começar a interagir, construir reputação e demonstrar valor desde o primeiro dia — o mecanismo de depósito restringe apenas o nível de liquidação mais complexo com contrapartes não confiáveis.

Além disso, operadores podem endossar seus agentes fornecendo uma conta de depósito compartilhada. Um operador implantando cinco agentes pode respaldar todos com um único pool de depósito, reduzindo a fricção de integração por agente. O depósito do operador cobre o multiplicador 5x de novos agentes coletivamente, e conforme agentes individuais constroem reputação, eles se graduam para níveis de depósito mais baixos independentemente. Isso espelha a integração empresarial em serviços de nuvem, onde uma conta organizacional fornece a âncora de confiança para usuários individuais.

Para o caso comum de agentes ingressando em uma frota estabelecida (ex.: um novo agente especialista ingressando no sistema multiagente existente de um operador), a reputação coletiva da frota e a conta de depósito compartilhada significam que o novo agente enfrenta zero fricção adicional de integração — ele herda o nível de confiança do operador imediatamente e constrói sua própria reputação individual por meio de interações.

11.4 Dimensionamento Progressivo de Solicitações

Para prevenir ataques de inundação de contexto, o CWEP suporta dimensionamento progressivo de solicitações para interações com agentes desconhecidos:

max_request_tokens(reputation, interaction_count) = {
    1000    if reputation < 20 AND interactions < 5
    10000   if reputation < 40 AND interactions < 20
    100000  if reputation < 60 AND interactions < 100
    unlimited    otherwise
}

Novos agentes começam com um tamanho máximo de solicitação de 1.000 tokens — suficiente para descrever uma tarefa, mas não suficiente para inundar o contexto. Conforme constroem reputação e histórico de interação, o limite se relaxa. Isso espelha a construção progressiva de confiança no comércio humano (pedidos pequenos antes de contratos grandes), porém aplicado no nível do protocolo.

12. Otimização de Prompts como Estratégia Econômica

12.1 Compressão como Redução de Custos

A compressão de prompts não é meramente uma otimização técnica — é uma decisão econômica com ROI mensurável. O LLMLingua alcança até 20x de compressão de prompt com perda mínima de desempenho [16] — em benchmarks documentados, 2.365 tokens comprimidos para 211 tokens (11,2x). Em escala, as economias são substanciais: uma compressão de contexto de 60% em uma carga de trabalho de 10.000 conversas diárias economiza US$153.000/ano [2].

O CWEP formaliza a compressão como estratégia de redução de custos dentro do framework de liquidação bilateral:

compression_savings = (uncompressed_tokens - compressed_tokens) × input_rate
compression_cost = tokens_consumed_by_compressor × compressor_output_rate
net_savings = compression_savings - compression_cost
compression_roi = net_savings / compression_cost

O solicitante tem um incentivo econômico direto para comprimir quando a liquidação inclui compartilhamento de custos: uma solicitação mais curta reduz a parcela do solicitante sob alocação tanto de Shapley quanto proporcional. Sem liquidação bilateral (puro solicitante-paga ou pague-e-mantenha), o incentivo de compressão do solicitante depende apenas de seu próprio custo de saída.

12.2 Cache como Custo Amortizado

O cache de prompt reduz custos de contexto repetido em 90% (acertos de cache a 0,1x do preço base de entrada) [1]. A Anthropic oferece controle explícito de cache com opções de TTL de 5 minutos e 1 hora; a OpenAI habilita cache automaticamente; o Google cobra taxas de armazenamento separadas [30].

Para interações recorrentes de agentes (ex.: um agente de monitoramento verificando o mesmo repositório de código a cada hora), o cache transforma um custo variável em um custo quase fixo:

first_interaction_cost = full_context_tokens × input_rate × cache_write_multiplier
subsequent_cost = full_context_tokens × input_rate × 0.10  (cache hit)
amortized_cost_per_interaction(n) = (first_cost + (n-1) × subsequent_cost) / n

Com n=10 interações usando cache do Claude Sonnet 4.6:

• Primeira interação: 100K tokens × US$3,00/MTok × 1,25 (gravação) = US$0,375
• Subsequentes: 100K tokens × US$3,00/MTok × 0,10 = US$0,030 cada
• Amortizado: (US$0,375 + 9 × US$0,030) / 10 = US$0,0645 por interação (78% de economia vs. sem cache)

O motor de liquidação do CWEP pode recomendar estratégias de cache com base na frequência de interação e TTL do cache.

12.3 Memória vs. Contexto Longo como Decisão Econômica

A escolha entre armazenar informação em memória externa e mantê-la em contexto é uma troca econômica com um ponto de cruzamento quantitativo [18]:

• Em menos de 10 interações, o contexto longo é mais barato (menor custo de configuração)
• Em mais de 10 interações, os sistemas de memória tornam-se mais baratos (menor custo marginal)
• Em 20 interações, a memória alcança 26% de economia de custos em relação ao contexto longo

Sistemas de memória (Mem0 [37], Zep [38], Letta [39], xMemory [59]) antecipam custos de gravação, mas reduzem custos variáveis por interação. Abordagens de contexto longo escalam custos variáveis linearmente com cada interação. O módulo de recomendação de otimização do CWEP pode sugerir a estratégia apropriada com base nos padrões de interação esperados.

O xMemory (King's College London / Alan Turing Institute) demonstra o potencial: uma hierarquia semântica de quatro níveis com recuperação controlada por incerteza reduz o uso de tokens em 28 a 48% enquanto melhora a precisão [59]. Com GPT-5 nano, os tokens por consulta caem de 9.155 para 6.581 — uma economia econômica mensurável por interação.

12.4 RAG como Seguro da Janela de Contexto

A Geração Aumentada por Recuperação (RAG) permite que agentes armazenem grandes bases de conhecimento externamente e recuperem apenas as porções relevantes para o contexto. Da perspectiva do CWEP, RAG é um seguro para a janela de contexto: o agente paga um pequeno custo de recuperação por interação para evitar pagar o custo muito maior de manter toda a base de conhecimento em contexto.

A economia é clara para agentes intensivos em conhecimento: um agente com 500.000 tokens de conhecimento de domínio consumiria metade de uma janela de contexto de 1M tokens para manter tudo. RAG permite que o agente recupere apenas os 10.000 tokens relevantes por interação, liberando 490.000 tokens de capacidade de contexto para trabalho efetivo. O custo por interação de recuperação (busca vetorial + tokens de recuperação) é ordens de grandeza menor do que o custo do contexto completo.

13. Integração de Micropagamentos

13.1 Opções de Meio de Pagamento

Os valores de liquidação do CWEP tipicamente variam de US$0,001 a US$1,00 por interação. Isso requer infraestrutura de micropagamento. Quatro meios de pagamento são adequados em março de 2026:

x402 (Coinbase/Cloudflare Foundation) [3]. Micropagamentos nativos HTTP usando o código de status 402. Liquida em Base, Polygon e Solana em stablecoins. Pagamento mínimo a partir de US$0,001 com liquidação em menos de um segundo. Taxas de facilitador Coinbase: nível gratuito de 1.000 transações/mês, depois US$0,001 por transação [3]. Volume diário atual de aproximadamente US$28.000, com o CoinDesk observando que grande parte da atividade reflete testes em vez de comércio real [60].

Machine Payments Protocol (MPP) (Stripe/Tempo) [4]. Lançado em 18 de março de 2026. Agnóstico quanto ao método de pagamento (stablecoins, cartões, Bitcoin Lightning). Modelo de sessão com depósito-e-saldo alcança latência abaixo de 100ms e taxas por requisição quase zero. Submissão ao IETF para padronização. Retrocompatível com x402 [4]. Já implementado em mais de 50 serviços incluindo OpenAI, Anthropic e Google Gemini.

L402 (Lightning Labs) [23]. Combina HTTP 402 com micropagamentos da Lightning Network e autenticação baseada em macaroons. Macaroons suportam delegação e definição de permissões — um agente pode receber um macaroon "somente-pagamento" que o impede de sacar fundos. A arquitetura de assinatura remota do LND garante que agentes nunca acessem diretamente chaves privadas [23]. Integração com LangChain existente via LangChainL402 e LangChainBitcoin [23].

Superfluid [24]. Streaming de tokens em tempo real onde o dinheiro flui continuamente por segundo. Mais de US$1,5 bilhão foi transmitido via Superfluid; mais de 1M de carteiras únicas. O Agent Pool ERC-8004 na Base conecta agentes a streams contínuos [24]. Ideal para conversas contínuas entre agentes onde a liquidação deve fluir continuamente em vez de por mensagem.

13.2 Abstração de Pagamento CWEP

O CWEP não especifica qual meio de pagamento utilizar. Em vez disso, define uma interface de liquidação que qualquer meio de pagamento pode implementar:

class CWEPSettlement:
    def commit_deposit(self, amount_usd: float, escrow_id: str) -> bool
    def release_deposit(self, escrow_id: str, to_agent: str) -> bool
    def forfeit_deposit(self, escrow_id: str) -> bool
    def settle(self, from_agent: str, to_agent: str, amount_usd: float,
               interaction_id: str) -> SettlementReceipt
    def stream_open(self, from_agent: str, to_agent: str,
                    rate_usd_per_second: float) -> StreamHandle
    def stream_close(self, handle: StreamHandle) -> SettlementReceipt

Os métodos stream_open/stream_close suportam liquidação contínua no estilo Superfluid para conversas em andamento. Os métodos commit_deposit/release_deposit/forfeit_deposit suportam o mecanismo de prevenção de spam. O método settle suporta liquidação única por interação.

13.3 Agrupamento de Liquidações

Para interações de alta frequência entre o mesmo par de agentes, a liquidação por interação é ineficiente. O CWEP suporta agrupamento de liquidações:

Accumulate CMRs over configurable window (default: 1 hour or $1.00 net, whichever first)
Compute net settlement across all interactions in the window
Execute single payment for the net amount

Se o Agente A deve ao Agente B US$0,15 em 50 interações e o Agente B deve ao Agente A US$0,08 em 30 interações, a liquidação líquida é um único pagamento de US$0,07 de A para B. Isso reduz as taxas de transação em 80x e é o modo recomendado para agentes com relacionamentos bilaterais contínuos.

14. Reservas de Contexto e Direções Futuras de Mercado

14.1 Mecanismo de Reserva

A janela de contexto de um agente possui capacidade finita. Cada solicitação recebida consome uma porção. Se o agente está ocupado (alta utilização), a capacidade restante é mais valiosa. Um solicitante que deseja acesso garantido deve estar disposto a pagar por uma reserva de capacidade. O CWEP v1.0 especifica reservas bilaterais de contexto como um mecanismo concreto e implementável para gerenciamento de capacidade.

{
  "reservation": {
    "requestor": "did:example:agent-a",
    "responder": "did:example:agent-b",
    "capacity_tokens": 100000,
    "duration_seconds": 3600,
    "price_usd": 0.50,
    "qos_tier": "reserved",
    "auto_renew": true
  }
}

A reserva garante que 100.000 tokens da janela de contexto do Agente B estão disponíveis para uso exclusivo do Agente A por uma hora. O Agente B se compromete a processar qualquer solicitação do Agente A até a capacidade reservada dentro das garantias de latência do nível de QoS. Se o Agente B não honrar a reserva, a taxa de reserva é reembolsável e uma disputa pode ser registrada via AJP [17].

14.2 Precificação Spot vs. Reservada

Dois modelos de precificação coexistem:

• Precificação spot: Pagar o preço efetivo atual do token (base + prêmio de congestionamento) no momento da interação. Barato quando a utilização é baixa, caro quando é alta. Sem garantias.
• Precificação reservada: Pagar uma taxa antecipada de capacidade para acesso garantido a uma taxa fixa. A taxa reservada é tipicamente entre 1x e 2x a taxa base — mais barata que spot durante pico de congestionamento, mas mais cara durante períodos de baixa demanda.

A estratégia ótima depende da previsibilidade da interação:

• Cargas de trabalho previsíveis (monitoramento horário, revisões agendadas) se beneficiam de reservas
• Cargas de trabalho imprevisíveis (consultas ad-hoc, resposta a incidentes) se beneficiam de precificação spot
• Cargas de trabalho mistas combinam uma base reservada com excedente spot

Esta é precisamente a troca entre instâncias reservadas vs. sob demanda vs. spot em computação em nuvem — adaptada para espaço de janela de contexto.

14.3 Direção Futura: Mercados de Contexto

O mecanismo de reserva bilateral acima é o bloco de construção para um potencial futuro mercado de contexto — um mecanismo onde agentes negociam autonomamente capacidade de contexto em tempo real com descoberta de preços e combinação de ordens. Tal mercado exigiria unidades de capacidade padronizadas (tokens por período de tempo), sinais de preço em tempo real através da rede de agentes, liquidez suficiente (muitos agentes comprando e vendendo) e infraestrutura de formador de mercado ou bolsa. Isso é estruturalmente análogo a mercados de capacidade em redes elétricas, onde geradores são pagos para manter capacidade disponível mesmo que não seja despachada [13].

Nenhuma dessa infraestrutura existe hoje. O mecanismo de reserva é suficiente para as necessidades atuais da economia de agentes; um mercado completo de contexto torna-se relevante quando o volume de interação entre agentes atinge níveis em que a negociação bilateral se torna um gargalo. Veja a Seção 20.1 para discussão adicional sobre o desenvolvimento de mercados de contexto.

15. Integração com o Ecossistema de Confiança

15.1 CWEP na Pilha de Protocolos

O CWEP situa-se na Camada 4 (Mercado/Economia) do Ecossistema de Confiança da AB Support, ao lado do Agent Matchmaking Protocol [19]. Ele depende de:

• Chain of Consciousness (CoC) [22]: Os registros de medição do CWEP referenciam entradas da cadeia CoC para auditabilidade. Toda alocação de custos pode ser rastreada até a interação verificada por proveniência que a gerou.
• Agent Rating Protocol (ARP) [21]: Pontuações de reputação informam o poder de barganha na liquidação Nash e os requisitos de depósito na prevenção de spam. Agentes com pontuações ARP mais altas obtêm depósitos menores e maior poder de barganha.
• Agent Service Agreements (ASA) [20]: Regras de alocação de custos são incorporadas nos acordos de serviço. O ASA define a qualidade esperada e os termos de custo; o CWEP fornece a medição e a liquidação para aplicá-los.

O CWEP fornece dados para:

• Agent Justice Protocol (AJP) [17]: Disputas de custo — onde agentes discordam sobre a liquidação — são escaladas ao módulo de resolução de disputas do AJP. CMRs servem como evidência.
• Agent Matchmaking Protocol (AMP) [19]: A combinação inclui estimativa de custos. Quando o AMP recomenda agentes para uma tarefa, pode incluir custos estimados de interação pelo CWEP com base nos níveis de modelo dos agentes, utilização típica de contexto e perfis históricos de interação.

15.2 Fluxos de Dados entre Protocolos

15.3 Ciclos de Retroalimentação do Ecossistema

Dois ciclos de retroalimentação estabilizam o ecossistema CWEP:

Retroalimentação positiva (ciclo virtuoso): Agente fornece bom serviço → alta pontuação ARP → depósitos menores exigidos por contrapartes → mais interações → mais oportunidades de ganhar avaliações positivas.

Retroalimentação negativa (ciclo corretivo): Agente envia spam/desperdiça contexto → depósitos confiscados → pontuação ARP baixa → depósitos maiores exigidos → menos interações → agente melhora comportamento ou sai do mercado.

Esses ciclos são propriedades emergentes da interação da pilha de protocolos — nenhum protocolo individual os cria, mas CWEP + ARP juntos os produzem.

16. Analogias Biológicas

Dois paralelos biológicos informaram decisões específicas de design do CWEP. Nós os incluímos não como metáfora decorativa, mas porque moldaram escolhas do protocolo.

16.1 ATP como Moeda de Tokens → Agnosticismo de Meio de Pagamento

O trifosfato de adenosina (ATP) serve como moeda energética universal para cada organismo na Terra [61]. A lição de design fundamental: o poder do ATP vem da aceitação universal, não da química específica. Cada processo celular — da contração muscular à replicação de DNA — usa ATP independentemente da fonte de energia que o produziu. Isso motivou diretamente o agnosticismo de meio de pagamento do CWEP (Seção 3.3): o protocolo especifica alocação de custos em uma denominação universal (USD/tokens) que qualquer meio de pagamento pode liquidar, assim como o ATP denomina transações energéticas independentemente de se a energia veio de glicose, gordura ou luz solar. Um protocolo que requer um meio de pagamento específico seria tão frágil quanto uma célula que só aceita energia de uma via metabólica.

16.2 Hipótese da Rainha Negra → Economia de Especialização

A Hipótese da Rainha Negra [62] mostra que micróbios perdem genes para funções custosas quando parceiros fornecem esses recursos de forma confiável. Isso não é meramente análogo à especialização de agentes — é o mecanismo que a visibilidade de custos do CWEP foi projetada para acelerar. Quando o CWEP torna o cálculo "comprar vs. construir" explícito (o custo CWEP de terceirizar uma tarefa vs. o custo de inferência de fazê-la internamente), os agentes podem tomar decisões racionais de especialização. Um agente que pode terceirizar revisão de código a US$0,23 por interação (Seção 4.1) não tem razão econômica para manter sua própria capacidade de revisão de código a US$0,39 por interação. Os dados de medição do CWEP fornecem o sinal; a dinâmica da Rainha Negra prevê o resultado: agentes perderão capacidades que são mais baratas de terceirizar, impulsionando a especialização do ecossistema.

16.3 Limites

Essas analogias são ilustrativas, não modelos formais. Duas diferenças críticas limitam sua aplicabilidade: (1) agentes podem ser duplicados a custo quase zero, criando um problema de Sybil sem paralelo biológico — o CWEP aborda isso por meio de acesso controlado por reputação (Seção 11.3) em vez de mecanismos imunológicos biológicos; (2) as estruturas de custo de agentes são discretas e transparentes (mensuráveis com precisão via respostas de API), permitindo mecanismos de alocação de custos (Shapley, Nash) que não possuem equivalente biológico.

17. Análise de Segurança

17.1 Modelo de Ameaças

O CWEP opera em um ambiente onde agentes podem ser adversariais. O modelo de ameaças considera:

17.2 Segurança de Depósito

O mecanismo de depósito requer que fundos comprometidos não possam ser unilateralmente apreendidos pelo respondente. Isso é aplicado pelo meio de pagamento:

• x402/MPP: Custódia via contrato inteligente — fundos são travados até que ambas as partes concordem ou um prazo expire [3][4]
• L402: Pagamento condicional baseado em macaroon — o macaroon do respondente só permite saque se as condições de avaliação de valor forem atendidas [23]
• Fora da cadeia: Custódia por terceiro confiável (o operador da plataforma ASA)

Em todos os casos, o solicitante pode contestar uma classificação de spam via AJP [17], e o depósito é retido até a resolução.

17.3 Considerações de Privacidade

Os CMRs contêm informações sensíveis: quais agentes interagem, quais modelos utilizam, qual é sua estrutura de precificação e quanto pagam. O CWEP aborda a privacidade por meio de:

• Troca de CMR baseada em hash: Agentes trocam hashes de CMR em vez de registros completos para verificação de liquidação. Registros completos são compartilhados apenas quando disputas requerem evidência.
• Relatórios agregados: A analítica de custos usa dados agregados (gasto total por contraparte por período) em vez de detalhes por interação quando possível.
• Armazenamento local primeiro: CMRs são armazenados localmente por padrão. A transmissão para serviços de agregação ou contrapartes é opcional.

18. Limitações e Resultados de Impossibilidade

18.1 Limitações Fundamentais

1. A troca de impossibilidade é real. O CWEP sacrifica eficiência econômica em favor de equilíbrio orçamentário e compatibilidade de incentivos (Seção 6.3). Algumas interações mutuamente benéficas não ocorrerão porque a alocação de custos as torna não lucrativas para uma das partes. Acreditamos que esta é a troca correta para um protocolo implantável, mas isso significa que o CWEP não maximiza o bem-estar econômico total.

2. A medição de valor é difícil. Os mecanismos de liquidação Shapley e Nash requerem medir o "valor" que cada agente recebe de uma interação. Na prática, o valor é subjetivo, dependente de contexto e frequentemente conhecido apenas após o fato. O CWEP aproxima o valor por meio de proxies observáveis (contagem de tokens, níveis de modelo, avaliações de qualidade do ASA), mas não consegue capturar o valor econômico completo das interações.

3. O escalonamento de custo quadrático é uma aproximação. Implementações modernas de atenção (Flash Attention, ring attention, atenção de janela deslizante) modificam o perfil de custo O(n^2). A curva real de custo computacional é específica do provedor, específica do modelo e pode mudar com atualizações de software. A precificação dependente de posição do CWEP (Seção 9.2) é consequentemente marcada como experimental.

4. A deflação de preços complica acordos de longo prazo. Os custos de inferência estão declinando aproximadamente 10x por ano [27]. Uma regra de alocação de custos negociada hoje pode estar drasticamente errada em seis meses. Os valores de liquidação do CWEP são calculados em tempo real usando precificação atual, mas os termos de custo do ASA referenciando CWEP devem incluir cláusulas de renegociação periódica.

18.2 Limitações de Escopo

1. Sem padronização de custos entre provedores. A precificação dos provedores varia 10x para modelos idênticos de código aberto [64]. O CWEP usa a precificação real do provedor de cada agente para liquidação, o que significa que a mesma interação custa valores diferentes dependendo de quais provedores os agentes utilizam. Uma "unidade padrão de custo de token" independente de provedor simplificaria a liquidação, mas não existe.

2. Sem normalização de modelos de raciocínio. Modelos de raciocínio (o3 [32], DeepSeek R1 [65]) geram vastamente mais tokens por tarefa — em casos extremos, mais de 600 tokens para gerar duas palavras [14]. O CWEP conta todos os tokens igualmente, incluindo tokens de raciocínio interno que podem ou não aparecer na saída. Isso cobra a mais dos solicitantes em interações pesadas em raciocínio.

3. Sem suporte a agentes offline. O CWEP assume interação em tempo real ou quase tempo real. Interações assíncronas de agentes com armazenamento e encaminhamento (onde solicitações ficam em fila por horas) requerem extensões ao protocolo de liquidação que não são especificadas na v1.0.

19. Implementação de Referência

19.1 Arquitetura

A implementação de referência do CWEP fornece:

• cwep-meter: Biblioteca de medição de tokens que envolve chamadas de API de provedores de LLM e emite CMRs. Integra-se com Langfuse [7], LiteLLM [8] e APIs diretas de provedores.
• cwep-settle: Motor de liquidação implementando alocação Shapley, Nash e baseada em regras. Recebe CMRs como entrada, produz propostas de liquidação.
• cwep-gateway: Middleware de gateway de API que intercepta interações de agentes, gera CMRs e aplica políticas de QoS (limitação de taxa, gerenciamento de depósitos).
• cwep-dashboard: Painel de analítica de custos mostrando detalhamentos de custo por agente, por interação e por contraparte.

19.2 Integração Mínima

A integração CWEP mais simples (Nível 1: Apenas Medição) requer envolver chamadas de API de LLM com a biblioteca cwep-meter:

from cwep import Meter

meter = Meter(agent_id="did:example:my-agent")

# Wrap existing LLM call
response = meter.track(
    llm_client.chat(messages=[...]),
    counterparty="did:example:other-agent",
    interaction_id="uuid-v4"
)

# CMR is automatically emitted to local storage
# response.cwep contains metering data
print(response.cwep.total_cost_usd)

19.3 Integração Completa

A integração CWEP completa (Nível 3: Liquidação Dinâmica) requer o motor de liquidação:

from cwep import Meter, SettlementEngine, NashBargaining

meter = Meter(agent_id="did:example:my-agent")
engine = SettlementEngine(
    method=NashBargaining(
        bargaining_power=0.6,  # Derived from ARP score
        disagreement_value=0.0
    ),
    settlement_threshold_usd=0.01,
    payment_rail="mpp"
)

# Track interaction
response = meter.track(llm_client.chat(...), ...)

# Compute and execute settlement
proposal = engine.propose(response.cwep.cmr)
if proposal.amount_usd > engine.threshold:
    receipt = engine.settle(proposal)

19.4 Pacote

pip install context-window-economics

Publicado sob licença Apache 2.0 no PyPI e GitHub (vibeagentmaking/context-window-economics).

20. Trabalhos Futuros

20.1 Mercados de Contexto

O CWEP v1.0 especifica reservas bilaterais de contexto (Seção 14). Versões futuras devem explorar mercados multilaterais de contexto onde agentes negociam autonomamente capacidade em tempo real — um verdadeiro mercado com descoberta de preços, combinação de ordens e liquidação. Isso requer unidades de capacidade padronizadas (tokens por período de tempo), sinais de preço em tempo real através da rede de agentes, liquidez suficiente (muitos agentes comprando e vendendo) e infraestrutura de formador de mercado ou bolsa. O mercado de capacidade de eletricidade, onde geradores são pagos para manter capacidade disponível mesmo que não despachada [13], fornece o template arquitetural mais próximo. Um mercado completo de contexto torna-se relevante quando o volume de interação entre agentes atinge níveis em que a negociação bilateral se torna um gargalo.

20.2 Otimização de Liquidação Cross-Chain

A divisão de custos em tempo real entre diferentes redes blockchain introduz restrições de latência de liquidação. Trabalhos futuros devem comparar a latência de liquidação entre x402 (Base, Polygon, Solana) [3], MPP (rede Tempo) [4] e L402 (Lightning) [23] para determinar quais meios suportam liquidação no nível de interação (< 1 segundo) vs. liquidação em lote (por hora).

20.3 Futuros de Custo de Inferência

Se os custos de inferência diminuem previsivelmente a 10x/ano [27], agentes poderiam fazer hedge de custos futuros por meio de contratos a termo — travando taxas de tokens atuais para interações futuras. Isso cria um mercado de futuros de custo de inferência análogo a futuros de commodities. A infraestrutura para isso não existe, mas a lógica econômica é sólida.

20.4 Medição de Valor Semântico

O CWEP v1.0 aproxima o valor da interação por meio de contagem de tokens e níveis de modelo. A verdadeira medição de valor exigiria avaliar o conteúdo semântico de uma interação — um problema fundamentalmente mais difícil que faz fronteira com o desafio de verificação de Integridade Semântica identificado na arquitetura do Ecossistema de Confiança como potencialmente insolúvel com a tecnologia atual [66].

20.5 Framework Regulatório e Legal

Transações financeiras autônomas de agentes operam em uma zona jurídica cinzenta. Quando o Agente A paga ao Agente B pelo processamento de contexto, quem é a contraparte legal? O agente, o operador do agente ou o provedor de LLM? Os frameworks regulatórios para comércio autônomo de agentes são nascentes; a Lei de IA da UE aborda o comportamento de agentes, mas não a economia de agentes. Versões futuras do CWEP devem incorporar requisitos de conformidade legal conforme eles surjam.

21. Conclusão

A janela de contexto é o recurso mais escasso na economia de agentes. Ela é finita, cara, não linear em custo e atualmente não precificada. Toda interação de agente a consome; nenhum protocolo aloca o custo.

O CWEP aborda isso com seis mecanismos: medição (medir todos os quatro fluxos de custo), liquidação bilateral (Shapley para interações cooperativas, Nash para competitivas), precificação de contexto (custos dependentes de posição refletindo o escalonamento quadrático da atenção), níveis de QoS (limitação de taxa por orçamento de tokens e processamento prioritário), prevenção de spam (filtragem baseada em depósito com controle por reputação) e economia de otimização (modelos formais de ROI para compressão, cache, memória e RAG).

O protocolo é honesto sobre o que não pode fazer. O resultado de impossibilidade de Green-Laffont/Moulin-Shenker significa que a alocação perfeita de custos é inatingível — o CWEP sacrifica alguma eficiência econômica em favor de equilíbrio orçamentário e compatibilidade de incentivos. A medição de valor é aproximada. O escalonamento quadrático de custo é um modelo idealizado que implementações reais de hardware aproximam em graus variados.

O que o CWEP alcança é um framework estruturado para um problema que anteriormente não possuía nenhum framework. Antes do CWEP, os agentes absorviam seus próprios custos sem visibilidade na estrutura bilateral de custos de suas interações. Após o CWEP, toda interação é medida, todo custo é atribuível e toda alocação é auditável por meio do sistema de proveniência do Chain of Consciousness.

Esta é a fundação econômica que a economia de agentes requer. Proveniência (CoC), reputação (ARP), acordos (ASA), responsabilização (AJP), ciclo de vida (ALP) e combinação (AMP) fornecem a infraestrutura institucional. O CWEP fornece a infraestrutura econômica — o mecanismo pelo qual agentes negociam, alocam e liquidam os custos da compreensão mútua.

O problema é genuinamente novo. Não traduzimos simplesmente modelos de comércio humano para a linguagem de agentes — identificamos uma primitiva econômica fundamentalmente nova (o custo de compreensão) e construímos um protocolo para precificá-la. A economia de agentes não se assemelhará à economia humana em suas estruturas de custo; o CWEP é projetado para a economia que está realmente emergindo, não para aquela que poderíamos esperar por analogia.

22. Referências

[1] Anthropic. "Pricing." platform.claude.com. Accessed March 2026.

[2] Stevens Institute; Koombea. "Hidden Economics of AI Agents"; "LLM Cost Optimization." 2025.

[3] Coinbase. "Introducing x402." coinbase.com. May 2025. See also: Coinbase, "Welcome to x402," docs.cdp.coinbase.com, 2025.

[4] Stripe. "Introducing the Machine Payments Protocol." stripe.com/blog. March 18, 2026. See also: mpp.dev, Stripe MPP documentation, March 2026.

[5] Google. "Announcing AP2." cloud.google.com. September 2025. See also: Google, "A2A x402 Extension," cloud.google.com, 2025.

[6] FinOps Foundation. "FOCUS Specification v1.3." finops.org. Ratified December 5, 2025.

[7] Langfuse. "Token & Cost Tracking." langfuse.com. MIT License. 2025. See also: Langfuse, "Pricing Tiers for Accurate Model Cost Tracking," December 2025.

[8] BerriAI. "LiteLLM." GitHub. 2025. See also: LiteLLM, "Agent (A2A) Gateway with agent cost tracking," docs.litellm.ai, 2025.

[9] Portkey. "Tracking LLM Token Usage Across Providers, Teams and Workloads." portkey.ai. 2025.

[10] Shapley, L. S. "Notes on the n-Person Game — II: The Value of an n-Person Game." RAND Corporation, 1951. Published as: "A Value for n-Person Games," Contributions to the Theory of Games (H. W. Kuhn and A. W. Tucker, eds.), Annals of Mathematics Studies 28, Princeton University Press, 1953.

[11] Nash, J. "The Bargaining Problem." Econometrica 18(2), 1950.

[12] Green, J. and Laffont, J.-J. Incentives in Public Decision Making. North-Holland, 1979. See also: Moulin, H. and Shenker, S. "Strategyproof Sharing of Submodular Costs: Budget Balance versus Efficiency." Economic Theory 18(3), 2001.

[13] PCI Energy Solutions. "Understanding Locational Marginal Pricing (LMP)." 2025.

[14] iKangAI. "The LLM Cost Paradox: How Cheaper AI Models Are Breaking Budgets." 2025. See also: Holter, A. "AI Costs in 2025: Cheaper Tokens, Pricier Workflows." 2025.

[15] Zuplo. "Token-Based Rate Limiting for AI APIs." 2025. See also: TrueFoundry, Gartner Market Guide for AI Gateways, 2025.

[16] Kuldeep Paul. "Prompt Compression Techniques: LLMLingua." Medium, 2025.

[17] Agent Justice Protocol. AB Support LLC. 2026.

[18] arXiv:2603.04814. "Memory vs. Long-Context Cost Analysis." 2026.

[19] Agent Matchmaking Protocol. AB Support LLC. 2026.

[20] Agent Service Agreements Protocol. AB Support LLC. 2026.

[21] Agent Rating Protocol v2. AB Support LLC. 2026.

[22] Chain of Consciousness v3. AB Support LLC. 2026.

[23] Lightning Labs. "Lightning Agent Tools." February 12, 2026. See also: Bitcoin Magazine, Lightning Agent Tools coverage, February 2026.

[24] Superfluid. "ERC-8004 Agent Pool." superfluid.org. 2026. See also: Sablier Protocol, sablier.com, 2026.

[25] arXiv:2512.08296. "Towards a Science of Scaling Agent Systems." December 2025.

[26] MarkAICode. "LangGraph vs CrewAI: Multi-Agent Performance and Cost in Production 2026." 2026.

[27] a16z. "LLMflation: LLM Inference Cost." a16z.com. November 2024. See also: Epoch AI, "LLM Inference Price Trends," 2025.

[28] Internet Society. "Interconnection and Regulated Traffic Obligations." March 2025.

[29] FCC. "All-IP Future," WC Docket Nos. 25-311, Notice of Proposed Rulemaking. January 28, 2026.

[30] Google. "Gemini Developer API Pricing." ai.google.dev. Accessed March 2026.

[31] Maxim.ai. "Context Engineering for AI Agents: The 100:1 Input-Output Ratio." 2025.

[32] OpenAI. "Pricing." developers.openai.com. Accessed March 2026.

[33] Hardin, G. "The Tragedy of the Commons." Science 162(3859), 1968.

[34] Simon, H. A. "Designing Organizations for an Information-Rich World." Computers, Communications, and the Public Interest (M. Greenberger, ed.), Johns Hopkins Press, 1971.

[35] Anthropic. "Effective Context Engineering for AI Agents." 2025.

[36] Heitmayer, M. "Second Wave of Attention Economics." Interacting with Computers 37(1), 2024.

[37] Mem0. mem0.ai. 2025.

[38] Zep. zep.ai. 2025.

[39] Letta. letta.com. 2025.

[40] VentureBeat. "WEKA Augmented Memory Grid." 2025. See also: WEKA, "Token Warehousing," 2025.

[41] PCI Energy Solutions. "Negative LMP Events in SPP." 2025.

[42] Deng, X. and Papadimitriou, C. H. "On the Complexity of Cooperative Solution Concepts." Mathematics of Operations Research 19(2), 1994.

[43] Fast Approximation of Shapley Values Using Fractional Factorial Designs. Journal of the American Statistical Association (JASA), 2025.

[44] Lundberg, S. M. and Lee, S.-I. "A Unified Approach to Interpreting Model Predictions." NeurIPS, 2017.

[45] Wang, J. et al. "ShapleyFL: Robust Federated Learning Based on Shapley Value." KDD, 2023.

[46] VerFedSV. "Verified Federated Shapley Value." 2024.

[47] Schmeidler, D. "The Nucleolus of a Characteristic Function Game." SIAM Journal on Applied Mathematics 17(6), 1969.

[48] Kalai, E. "Nonsymmetric Nash Solutions and Replications of 2-Person Bargaining." International Journal of Game Theory 6(3), 1977.

[49] Rubinstein, A. "Perfect Equilibrium in a Bargaining Model." Econometrica 50(1), 1982.

[50] Moulin, H. "Incremental Cost Sharing: Characterization by Coalition Strategy-Proofness." Social Choice and Welfare 16(2), 1999.

[51] Vickrey, W. "Counterspeculation, Auctions, and Competitive Sealed Tenders." Journal of Finance 16(1), 1961. See also: Clarke, E. H. "Multipart Pricing of Public Goods." Public Choice 11(1), 1971; Groves, T. "Incentives in Teams." Econometrica 41(4), 1973.

[52] Internet Society. "South Korea 'Sender Pays' Analysis." 2025.

[53] BEREC. "Preliminary Assessment of Payments from Large CAPs to ISPs." 2023.

[54] FERC. "Order 1920 Fact Sheet." May 13, 2024.

[55] State of FinOps Report. FinOps Foundation. 2025. See also: Datadog, container waste statistics, 2025.

[56] AG2. "Usage Tracking." docs.ag2.ai. 2025.

[57] Google. "A2A Agent Card Specification." 2025.

[58] Gartner. "Market Guide for AI Gateways." 2025. See also: TrueFoundry, Zuplo, 2025.

[59] VentureBeat. "xMemory: Four-Level Semantic Hierarchy." King's College London / Alan Turing Institute. 2025.

[60] CoinDesk. "Coinbase-backed AI payments protocol wants to fix micropayment but demand is just not there yet." March 11, 2026.

[61] ScienceDirect. "Evolution of Energy Currencies: From ATP to Digital Money." October 2025.

[62] Mostafa, A. et al. "Biological Market Theory Applied to Microbial Communities." Microlife, 2024.

[63] PNAS. "Host-Symbiont Mutualisms and Employment Contract Theory." 2010.

[64] Introl. "Inference Unit Economics: True Cost Per Million Tokens Guide." 2025.

[65] DeepSeek. "DeepSeek R1 Pricing." deepseek.com. 2026.

[66] AB Support Trust Ecosystem Architecture. "Semantic Integrity Verification — Research Frontier." 2026.

Copyright 2026 AB Support LLC. Licenciado sob a Licença Apache, Versão 2.0.

Âncora do Chain of Consciousness: Whitepaper do protocolo v1.0.0