A Cloudflare adicionou taxas de token de leitura e gravação de cache à contabilidade de custos personalizada do AI Gateway, um pequeno item do changelog com grandes consequências de faturamento para equipes que revendem, encaminham ou reconciliam o uso do modelo entre provedores.
A atualização de 9 de setembro significa que os desenvolvedores agora podem transmitir valores per_cache_read_token e per_cache_write_token no cf-aig-custom-cost cabeçalho. Quando uma taxa específica de cache está presente, a Cloudflare diz que o AI Gateway ativa o preço do token de cache e considera as diferenças de provedor para que o mesmo uso de cache não seja contado duas vezes.
Isso parece limitado. Não é. O preço do cache se tornou uma das partes mais difíceis do faturamento unificado da API de IA, especialmente porque os provedores usam nomes, unidades e regras de cobrança diferentes para contexto reutilizado. Tratar cada token armazenado em cache como um token de entrada normal pode ser simples, mas pode ser errado o suficiente para apagar a margem do revendedor ou enganar os clientes sobre quais cargas de trabalho são realmente caras.
O que mudou
O AI Gateway já permitia que dados de custos personalizados fossem anexados às solicitações, dando às equipes uma maneira de representar taxas negociadas ou catálogos de preços internos, em vez de confiar apenas nos preços do fornecedor público. A nova mudança estende esse mecanismo para categorias de token específicas de cache.
Na prática, um operador de gateway agora pode informar à Cloudflare não apenas quanto custa um token de entrada ou saída, mas também quanto custa uma leitura ou gravação de cache. Essa distinção é importante porque os provedores valorizam cada vez mais o cache imediato como sua própria camada econômica. Uma gravação em cache pode custar mais do que uma leitura em cache. Uma leitura de cache pode ser dramaticamente mais barata que uma nova entrada. Alguns provedores podem expor a criação e a recuperação de cache de maneira diferente nos registros de uso.
A observação da Cloudflare de que ela lida com diferenças de provedor para evitar contagem dupla também é importante. Os campos de cache nem sempre são separados de forma clara dos totais de token de entrada. Se um sistema de cobrança adicionar ingenuamente tokens de cache ao uso de entrada relatado pelo provedor, ele poderá sobrecarregar os clientes ou inflar os custos internos. Se ignorar os campos de cache, poderá subestimar o custo de aplicativos de contexto longo que frequentemente criam entradas de cache.
Por que a contabilidade de cache agora é importante
O cache de prompt costumava ser um detalhe de otimização. Para muitas cargas de trabalho de produção, agora faz parte da arquitetura de preços.
Prompts longos do sistema, contexto aumentado de recuperação, repositórios de agentes de codificação, pacotes de documentos legais e bases de conhecimento de suporte, todos se beneficiam da reutilização do contexto. Quanto mais contexto repetido um sistema envia, mais o preço do cache altera a economia unitária real. Duas solicitações com contagens de tokens semelhantes podem ter custos muito diferentes se uma estiver gravando uma entrada de cache e outra lendo ela.
Isso torna a visibilidade do cache uma questão financeira, não apenas uma questão de engenharia. Uma equipe que executa agentes internos pode precisar saber se um novo fluxo de trabalho é caro porque gera muitos prompts novos, perde o cache ou grava grandes blocos de cache com muita frequência. Um revendedor pode precisar mostrar aos clientes por que o uso faturado de um aplicativo é menor do que o esperado, mesmo que o tamanho aparente do prompt seja grande. Um fornecedor de gateway pode precisar preservar campos de cache em logs, análises e registros contábeis para que a reconciliação de final de mês corresponda às faturas do fornecedor.
É também aqui que a análise de custos da API de IA se torna mais exigente. O custo agregado da solicitação não é mais suficiente. As equipes precisam ver o comportamento de entrada, saída, gravação de cache e leitura de cache separadamente e, em seguida, conectar essas categorias a chaves de API, clientes, modelos e rotas.
Quem é afetado
O público imediato são os usuários do Cloudflare AI Gateway que dependem de custos personalizados em vez de preços públicos padrão. Isso inclui empresas com taxas de modelo negociadas, plataformas que marcam o uso do provedor para os clientes e equipes que usam a Cloudflare como um plano de controle compartilhado entre vários provedores de modelo.
Os revendedores estão especialmente expostos. Se um revendedor cobrar dos clientes usando um modelo de token simplificado enquanto paga aos provedores com preços com reconhecimento de cache, a diferença pode acumular-se silenciosamente. A cobrança insuficiente de gravações de cache ou a sobrecarga de leituras de cache podem não aparecer em uma única solicitação, mas podem ser importantes em sessões de agente, processamento em lote ou cargas de trabalho de recuperação de alto volume.
Os desenvolvedores que criam camadas de gateway compatíveis com OpenAI são afetados mesmo quando não usam a Cloudflare diretamente. A mudança reflecte uma direcção mais ampla no mercado: as superfícies de facturação dos fornecedores estão a tornar-se mais granulares, enquanto os clientes ainda esperam uma factura limpa e relatórios de utilização previsíveis.Produtos como o Model Gate precisam tratar os campos de token de cache como dados contábeis de primeira classe se quiserem relatórios precisos no escopo do cliente, limites de uso e análise de margem em vários provedores.
Consequências práticas
As equipes do Gateway devem revisar como seus registros de solicitações, calculadoras de custos e faturas representam a atividade de cache. Se as leituras e gravações do cache forem reduzidas a tokens de prompt comuns, a análise poderá parecer mais simples do que a conta subjacente. Se os registros de uso do provedor contiverem campos de cache que são descartados durante a ingestão, a reconciliação posterior será difícil.
Os mecanismos de precificação também precisam oferecer suporte a mais de uma taxa por direção. A antiga divisão entre entradas e saídas não é mais suficiente para modelos de contabilidade avançados. Um modelo de registro confiável agora precisa de espaço para novos tokens de entrada, tokens de saída, gravações de cache, leituras de cache e possivelmente variantes específicas do provedor dessas categorias.
Os painéis voltados para o cliente devem expor essas distinções cuidadosamente. A maioria dos usuários não deseja ler a telemetria bruta do provedor, mas precisam entender por que os custos mudam quando um aplicativo começa a reutilizar o contexto de forma mais eficaz. A melhor interface pode ser um detalhamento de custos que mostre a economia de cache e os custos de criação de cache sem forçar os clientes a aprender a terminologia de cada provedor.
Também há implicações operacionais para alertas e limites. Um limite de orçamento do cliente baseado apenas no total de tokens pode não conseguir capturar uma carga de trabalho que grava entradas de cache caras. Um alerta de margem baseado apenas na contagem de solicitações pode deixar passar uma incompatibilidade de preços do fornecedor. Para equipes que vendem acesso por meio de chaves por cliente, a contabilidade com reconhecimento de cache deve estar vinculada aos mesmos identificadores de cliente, projeto ou aplicativo usados para controles de gastos.
O que permanece em aberto
O changelog estabelece suporte para taxas personalizadas de leitura e gravação de cache, mas não resolve todas as questões de implementação para operadores de gateway. As equipes ainda precisam testar como seus provedores específicos relatam o uso de cache, como os custos calculados da Cloudflare aparecem nos registros e nas exportações e como as faturas existentes devem ser comparadas com os novos campos de custos personalizados.
No entanto, a direção mais ampla é clara. O faturamento do gateway de IA está passando de um simples medidor de token para um registro de uso detalhado. O preço do cache agora faz parte desse livro-razão. As equipes que preservarem os detalhes terão uma reconciliação mais limpa e melhores análises dos clientes. As equipes que o eliminam podem não perceber o problema até que a fatura do fornecedor e a fatura do cliente parem de contar a mesma história.