Custo por tentativa: o que o registro precisa provar?

O total pode estar certo e a conta continuar inexplicável. Para confiar em um orçamento de IA por tarefa, a empresa precisa demonstrar o custo por tentativa: quais tentativas tiveram uso cobrável, como o preço foi aplicado, se o registro sobrevive a falhas e como o valor interno se compara à cobrança do provedor.

Quando uma solicitação é reenviada ou muda de rota, o painel pode apresentar a soma correta sem identificar a tentativa. O total atende ao financeiro, mas não resolve a investigação de uma divergência ou de uma política de fallback.

A tese é simples: custo por tentativa não é uma tarifa nova. É uma exigência de evidência antes de transformar um total em limite operacional para o período analisado.

Uma solicitação mostra todas as tentativas?

Uma solicitação pode incluir várias tentativas e ainda aparecer como uma única linha no relatório. Se essa linha incluir corretamente todos os custos, o total não está errado. O limite é outro: sem atribuição por tentativa, a empresa não consegue separar o efeito de cada envio.

Tarefa é o trabalho que precisa chegar a um resultado aceito. Solicitação é uma chamada lógica feita para cumprir parte desse trabalho. Tentativa é cada envio que procura atender à solicitação. Uma tarefa pode envolver várias solicitações; uma solicitação pode ter retentativas de chamadas de IA ou recorrer a outra rota. Essas unidades não são intercambiáveis.

Ao consultar as convenções HTTP do OpenTelemetry, a equipe deve verificar quais spans a instrumentação emite por envio e para a operação superior, além de conferir como preenche o atributo http.request.resend_count, inclusive em redirecionamentos. O campo não deve ser usado como prova de cobrança.

As convenções HTTP do OpenTelemetry recomendam um span para cada tentativa de envio e admitem um span para a operação superior quando a instrumentação não consegue emitir um por tentativa. São granularidades diferentes. No exemplo de redirecionamento das convenções, uma resposta 302 precede outro envio, cujo http.request.resend_count é 1. Antes de atribuir custo ao envio, a equipe precisa identificar a granularidade emitida e verificar o uso e as condições de cobrança aplicáveis.

Timeout também não é recibo. Após um timeout, a equipe deve verificar o uso e as condições de cobrança aplicáveis. Até a apuração, o valor pode permanecer desconhecido; o erro não prova gratuidade nem gasto.

O trace de chamada de LLM ajuda a examinar rota, chamada e política. A pergunta seguinte: o que sustenta a cobrança e como ela volta a coincidir com as demais visões após uma falha?

O que o registro de custo por tentativa em IA precisa preservar?

O registro precisa permitir que alguém identifique a tentativa, entenda o uso conhecido e reconstrua o preço aplicado naquele momento. Também precisa sobreviver à falha do processo que o consulta. Esses são critérios de avaliação, não a descrição obrigatória de uma única arquitetura.

Uma cobrança identificável deve apontar para a solicitação e a tentativa, com o estado da apuração. Um identificador estável ajuda a distinguir novo lançamento de reapresentação. A ausência de uso confirmado precisa permanecer explícita: custo desconhecido não é custo zero.

O preço também é prova. Para explicar a conta, é preciso preservar modelo usado, provedor, unidade de cobrança, moeda, vigência e condições contratuais relevantes. Se a regra aplicável mudou depois da chamada, recalcular o passado com a tabela atual pode produzir um valor diferente sem que o consumo original tenha mudado.

Ao avaliar os atributos de IA generativa do OpenTelemetry, a equipe deve verificar se a instrumentação emite operação, modelo e tokens, e se os atributos usados estão movidos ou depreciados. Também deve comparar a estimativa com a evidência de faturamento, sem confundir as duas.

O registro GenAI marca gen_ai.usage.prompt_tokens como depreciado e aponta gen_ai.usage.input_tokens como substituto, movido para o repositório de convenções GenAI. O nome do campo importa. A equipe precisa conferir a versão e a emissão efetiva da instrumentação antes de usar a contagem para reconstruir uma estimativa histórica, que ainda depende da regra de preço aplicável.

Preservar uma estimativa não a transforma em cobrança confirmada. A comparação com os dados de uso ou a fatura do provedor exige escopo, período e moeda compatíveis. Se a evidência externa não detalha a tentativa, a divergência continua aberta nesse nível.

O que acontece quando o relatório falha?

Uma falha no relatório não deveria apagar uma cobrança já registrada nem liquidá-la duas vezes. O comprador deve testar como o sistema identifica trabalho pendente, retoma o processamento e protege cada consumidor contra repetição. Orçamento e relatório podem ter estados diferentes enquanto a recuperação está em andamento.

Um desenho possível começa na tentativa, captura o uso conhecido e associa a cobrança ao contexto de preço. Depois, um registro durável dá suporte à liquidação do orçamento e à atualização do relatório. Os consumidores podem avançar em momentos diferentes. A figura abaixo representa um critério genérico de avaliação, não a implementação de um produto.

Se a atualização do relatório falhar depois da liquidação, o teste deve mostrar a pendência e a retomada sem novo débito para a mesma cobrança já liquidada. O inverso também merece inspeção: um relatório atualizado não deve ser confundido com uma liquidação já concluída. A proteção contra duplicação precisa ser verificada em cada consumidor; ela não demonstra entrega exatamente uma vez em todo o sistema.

Reserva ativa não é gasto liquidado. A reserva separa capacidade para uma operação em curso; a liquidação registra o valor apurado. A política de admissão considera gasto liquidado, reservas ativas e exposição pendente, sem contar duas vezes a mesma parcela e com atualização ou coordenação segura sob concorrência. Quando o custo máximo ou o uso de uma tentativa é desconhecido, uma reserva conservadora exige um limite justificável; sem ele, a política bloqueia a admissão ou mantém a operação pendente. Ajustar ou liberar a reserva exige verificar o estado e o uso conhecido, sem apagar uma cobrança ainda sujeita à conciliação.

Ao consultar as transações do PostgreSQL, a equipe deve verificar o escopo das garantias de atomicidade e persistência e testar a reconciliação e a deduplicação entre consumidores. Uma transação no banco, isoladamente, não comprova a coordenação entre componentes.

O tutorial de transações do PostgreSQL 18 descreve uma operação atômica: para as demais transações, as alterações ocorrem por completo ou não ocorrem. O tutorial descreve persistência após a confirmação, mas a durabilidade depende da configuração e do domínio de falha testado. Com synchronous_commit=off, o servidor pode confirmar antes da gravação durável do WAL, e um crash pode perder transações recentemente confirmadas. O comprador precisa conferir synchronous_commit, as garantias de armazenamento e, quando aplicável, replicação e failover. A fronteira importa. O reconhecimento do banco não prova durabilidade sob toda configuração, coordenação entre consumidores, retomada do relatório ou conciliação com a cobrança externa.

Um total por solicitação pode ser suficiente?

Sim, para acompanhamento agregado, desde que o total inclua corretamente as tentativas dentro do escopo medido. Essa visão tem utilidade para acompanhar gasto de um conjunto de solicitações. Ela não substitui a atribuição por tentativa quando a decisão exige explicar uma cobrança ou avaliar uma rota.

A objeção ao registro detalhado é legítima: há custo de armazenamento, integração e manutenção. Se a equipe só precisa acompanhar o total de um serviço, exigir uma investigação por tentativa para toda decisão pode ser desproporcional. A escolha muda quando a organização precisa responder por que um orçamento foi consumido, comparar políticas de fallback ou contestar uma diferença com o provedor, usando os dados externos de cobrança disponíveis.

Sistemas internos podem concordar e ainda divergir da fatura se partirem do mesmo dado incompleto. A conciliação registra diferenças e ajustes. Registra também os itens sem correspondência.

O que falta para calcular custo por tarefa?

O custo atribuído a uma tarefa individual reúne seus custos relevantes, inclusive fora do gateway, independentemente de sucesso, rejeição ou abandono. A ligação atravessa solicitações sucessivas sem confundir tentativa com tarefa. Essa conta não exige resultado aceito; exige uma regra de atribuição.

A média por tarefa aceita é outra métrica: soma dos custos relevantes da coorte declarada, dividida pelo número de tarefas aceitas da mesma coorte. Sem tarefas aceitas, não há média calculável. A política deve declarar como trata os custos das tarefas rejeitadas e abandonadas; omiti-los sem declarar isso distorce a interpretação da média. Também deve definir período, escopo e regra de atribuição, além de qual resultado é aceito, por quem e quando. A média não é a única métrica válida.

O exemplo de retentativas HTTP do OpenTelemetry mostra uma solicitação recebida seguida de três envios do cliente, dois com resposta 500 e um com resposta 200. É um trace, não uma tarefa concluída. Os spans ilustram a multiplicidade de envios; não estabelecem qual resultado a aplicação aceita, nem quanto foi cobrado, nem como os envios se vinculam à tarefa de negócio.

O escopo precisa ser declarado. A equipe deve verificar se chamadas fora do gateway aparecem nos registros, por quais fontes e como são atribuídas. Se forem relevantes e não constarem dos registros, precisam de outra fonte e de atribuição. As análises de custo real da aplicação além do preço por token e de preço do token e custo por tarefa ampliam a decisão econômica; aqui, o ponto é a prova que sustenta a conta.

Quando o uso permanece desconhecido, ambas as contas devem apontar a parcela pendente e não apresentar o total ou a média como completos até a apuração. Preencher a lacuna com zero melhora a aparência do relatório e piora a decisão.

Como o comprador testa a promessa?

O teste precisa seguir uma cobrança desde a tentativa até as visões internas e a evidência disponível do provedor, para que o comprador possa comparar os registros e verificar se a recuperação preserva a cobrança. O painel não basta. Uma falha controlada revela os estados depois da retomada.

1. Reconstrução do preço histórico. O comprador deve escolher uma cobrança cujo uso e condições estejam disponíveis, conferir modelo, unidade, moeda e vigência e pedir a reprodução do cálculo sem substituir a regra antiga pela atual.
2. Inspeção das tentativas. Para uma solicitação com reenvio ou troca de rota, a equipe deve comparar o total com as tentativas registradas. A análise separa custo confirmado, zero justificado e uso desconhecido, além de conferir o que a instrumentação realmente emite.
3. Interrupção do relatório. Em ambiente de teste, a equipe deve comprovar o estado inicial, com cobrança registrada e orçamento já liquidado, e então provocar a falha do relatório. A pendência deve ficar identificável. Após a retomada, a equipe reapresenta a mesma identidade e verifica uma única liquidação e uma atualização recuperada do relatório.
4. Repetição em cada consumidor. A equipe deve reapresentar a identidade a cada consumidor e provocar falha entre a aplicação do efeito e a marcação do identificador como processado. Após a recuperação, deve comprovar um único efeito e demonstrar atomicidade entre os dois ou proteção equivalente, sem exigir uma arquitetura específica nem alegar entrega exatamente uma vez de ponta a ponta.
5. Reservas concorrentes. A equipe deve testar admissões simultâneas, ajuste e liberação de reservas e uso ainda desconhecido, conferindo se a exposição permanece coberta, sem duplicação, conforme a política. O resultado precisa mostrar como a coordenação impede admissões concorrentes acima do teto nas condições testadas.
6. Comparação com o provedor. O comprador deve alinhar período, moeda e escopo com os dados externos disponíveis e registrar diferenças e limites de detalhamento. Se não houver evidência externa suficiente, a conciliação por tentativa permanece pendente.

O teste exige uma explicação que outra pessoa consiga verificar.

Perguntas frequentes

As dúvidas envolvem o custo de uma retentativa, a confiança em um relatório atrasado e a forma como reservas entram na conta, mas a resposta depende do estado de cada cobrança e das evidências disponíveis. O resultado exibido pela aplicação não basta para classificar a cobrança.

Toda retentativa de chamada de IA é cobrável?

Não se deve presumir que toda retentativa seja cobrada nem que seja gratuita. A classificação exige verificar o uso e as condições do provedor para cada tentativa. A identificação da tentativa permite auditoria posterior. Um erro ou timeout, isoladamente, não resolve essa classificação.

Atraso no relatório significa perda de cobrança?

Não necessariamente. A cobrança pode estar registrada enquanto o relatório aguarda processamento. A equipe precisa verificar a pendência, a retomada e a proteção contra duplicação, além de identificar cobranças que ainda não têm confirmação suficiente. Enquanto a confirmação não chega, o valor deve permanecer separado do total conciliado.

Reserva e gasto liquidado são a mesma coisa?

Não. Reserva é capacidade de orçamento separada para uma operação; gasto liquidado é o valor apurado conforme as regras adotadas. O ajuste da reserva não elimina a necessidade de conferir o uso e a cobrança daquela operação. O comprador deve perguntar qual dos dois números aparece no relatório.

Custo por solicitação é igual a custo por tarefa?

Não necessariamente. Uma tarefa pode envolver várias solicitações, tentativas e custos fora do gateway. O custo de uma tarefa individual independe da aceitação; a média por tarefa aceita exige critério de aceitação e coorte declarados. A conta deve incluir o gasto relevante de tarefas rejeitadas quando a política de cálculo as abranger.

Referências e Leitura Complementar

As referências distinguem convenções de telemetria, propriedades de transações e decisões de custo, enquanto as duas leituras da Nexforce tratam do trace da chamada e da diferença entre preço do token e custo por tarefa. A fatura exige conferência própria.

• OpenTelemetry: convenções para spans HTTP.
• OpenTelemetry: atributos de IA generativa.
• PostgreSQL: transações.

Os exemplos citados estão nestas seções das fontes:

• OpenTelemetry: exemplo de retentativas HTTP.
• PostgreSQL 18: tutorial de transações.
• PostgreSQL 18: configuração de WAL e synchronous_commit.

As leituras internas complementam a análise técnica e a decisão de orçamento:

• Trace de chamada de LLM.
• Preço do token e custo por tarefa.

Qual evidência deve preceder o limite?

O próximo passo é pedir uma cobrança verificável, não outro gráfico. A equipe precisa explicar a tentativa, recuperar o preço histórico, testar a retomada após a falha e comparar o registro com a evidência de cobrança disponível. A condição importa.

Um teto só pode ser garantido dentro das hipóteses e limites efetivamente demonstrados; fora deles, é controle ou estimativa, não garantia absoluta.

O Nexforce Router reúne roteamento, fallback, retentativas, tetos por chave ou projeto e observabilidade. Essas capacidades ajudam a governar chamadas, mas não demonstram por si as quatro provas contábeis discutidas aqui. Para qualquer implementação, o comprador deve verificar o que está efetivamente registrado, como os estados são reconciliados e quais custos ficam fora desse alcance. Um limite é uma decisão; a evidência diz se a decisão merece confiança.