Custo por tarefa de agente de IA: fórmula, exemplo e medição no Android
Calcule custo por tarefa concluída em agentes de IA com entradas, cache, saídas, novas tentativas, taxas externas e verificação de resultado no Android.
- Custo por tarefa de agente de IA deve ser medido por resultado concluído, não por chamada isolada ao modelo.
- A fórmula precisa separar entrada comum, leituras de cache, saída faturável, taxas de ferramentas, assinatura ou créditos aplicáveis e tentativas falhas já incluídas no uso.
- Execução no telefone pode mudar contexto, novas tentativas e passos reutilizáveis, mas não prova inferência local, uso gratuito ou economia fixa.
- Na FoneClaw, ações Android suportadas ajudam a medir um fluxo real: rascunho visível, permissões adequadas, aprovação conforme política e verificação do resultado antes de repetir.
Meça custo por tarefa concluída
O custo por tarefa de agente de IA deve começar pelo resultado, não pelo preço de uma única chamada. Uma tarefa concluída pode ser “rascunho colocado no campo certo e revisado”, “evento criado e aberto para conferência” ou “rota aberta com destino correto”. Se a tarefa falha, ela ainda consumiu entrada, saída, cache, contexto de tela, tempo de revisão e talvez taxas externas.
A fórmula prática é: custo total medido dividido por tarefas verificadas como concluídas. O total pode incluir uso de API, assinatura ou crédito quando aplicável, ferramentas externas, tentativas repetidas e custo humano se você decidir monetizar tempo. Não dobre valores já incluídos no plano ou no relatório do provedor. Se a assinatura já cobre certo uso, registre como alocação interna; se o provedor cobra por chamada, token, cache ou ferramenta, use as categorias reais de cobrança.
Para comparar fluxos Android, defina primeiro o que conta como conclusão. Em uma tarefa com FoneClaw, por exemplo, preencher um campo editável identificado no app pode ser conclusão do rascunho, mas não é envio. Para definir tarefas completas e etapas suportadas, veja Automatizar tarefas de várias etapas no Android com FoneClaw.
Monte um registro a partir do uso do provedor
Monte um registro com categorias que não se sobrepõem. Use entrada sem cache, leitura de cache, saída faturável e taxas externas separadas. A documentação do Gemini sobre contagem de tokens mostra que texto e outras modalidades, incluindo imagens, entram na contagem. A página de preços da API Gemini também separa custos por modelo, modalidade, serviço e, em alguns casos, cache, armazenamento, grounding ou tokens de raciocínio incluídos na saída.
A fórmula reutilizável para o subtotal do modelo é: tokens de entrada sem cache ÷ um milhão × taxa de entrada por milhão, mais tokens de leitura de cache ÷ um milhão × taxa de leitura de cache por milhão, mais tokens de saída faturável ÷ um milhão × taxa de saída por milhão. Depois some taxas extras separadas, como criação ou armazenamento de cache, ferramenta externa, grounding, assinatura alocada ou créditos consumidos, apenas quando isso se aplicar ao seu provedor.
Em provedores com cache, confirme se houve leitura real de cache. A documentação do Claude sobre cache de prompts separa gravações de cache, leituras de cache e entrada comum. Isso importa porque conteúdo repetido só reduz custo quando atende às regras do provedor e aparece nos campos de uso medido.
Uma planilha mínima pode usar esta estrutura:
| Categoria | Como medir | Cuidado |
|---|---|---|
| Entrada sem cache | Total de tokens de entrada não atendidos por cache | Não misture com leituras de cache |
| Leitura de cache | Tokens lidos de cache e cobrados como leitura de cache | Confirme no relatório de uso do provedor |
| Saída faturável | Tokens de resposta cobrados, incluindo raciocínio se o provedor incluir | Não cobre “pensamento” duas vezes |
| Imagem ou tela | Conforme contagem do provedor para imagens ou contexto visual | Não adicione taxa extra se já virou token de entrada |
| Ferramenta externa | Taxa de serviço, busca, armazenamento, grounding ou chamada paga | Some só quando aplicável |
Recalcule um lote hipotético
Este exemplo é hipotético e usa taxas didáticas em dólar, não preços atuais de Google, Anthropic, FoneClaw ou qualquer outro fornecedor. O objetivo é mostrar a matemática.
| Item | Uso no lote | Taxa hipotética | Custo |
|---|---|---|---|
| Entrada sem cache | 1,0 milhão de tokens | US$ 2,00 por milhão | US$ 2,00 |
| Leituras de cache | 0,2 milhão de tokens | US$ 0,20 por milhão | US$ 0,04 |
| Saída faturável | 0,15 milhão de tokens | US$ 8,00 por milhão | US$ 1,20 |
| Subtotal do modelo | Todas as chamadas do lote | Inclui novas tentativas já ocorridas | US$ 3,24 |
| Taxa externa hipotética | Uma ferramenta paga no lote | Valor fixo didático | US$ 0,10 |
| Total | 100 tentativas | 90 conclusões verificadas | US$ 3,34 |
O custo por tarefa concluída é US$ 3,34 dividido por 90, ou cerca de US$ 0,0371 por conclusão verificada. As 10 falhas não são excluídas: o uso delas já está dentro dos totais. Também não se adiciona nova tentativa de novo em outra linha, porque o lote já contou todas as chamadas.
Neste exemplo, não há taxa de criação de cache, armazenamento, assinatura, energia ou tempo humano. Em uma medição real, adicione apenas o que o seu provedor ou sua operação realmente cobra. Se o lote tiver zero conclusões verificadas, a métrica de custo por conclusão fica indefinida, não zero.
O que a execução no telefone pode mudar
Execução no telefone e inferência do modelo são coisas diferentes. A FoneClaw executa ações Android suportadas enquanto o modelo configurado ajuda a interpretar e planejar. Isso pode reduzir contexto repetido, novas tentativas e etapas manuais em alguns fluxos, mas não prova que não houve chamada ao modelo, que tudo rodou localmente ou que a economia será fixa. Se um modelo online configurado for usado, o contexto da tarefa fornecido pelo usuário pode ser processado pelo provedor escolhido.
Um exemplo positivo é rascunho em campo visível. A FoneClaw pode ler o estado acessível atual de um app suportado, identificar o campo editável correto e inserir o texto revisado. Essa inserção não envia, não submete e não pressiona Enter. O usuário ainda verifica destinatário, conteúdo e resultado. As aprovações dependem das configurações globais e por ferramenta, especialmente em ações com consequência.
Ferramentas de tela também não são equivalentes. Leitura de interface e captura de imagem têm custos e utilidades diferentes conforme o provedor e a tarefa; não há regra universal de que uma árvore textual sempre custa menos do que uma imagem. Para entender como ações suportadas são verificadas no telefone, veja Controlar telefone Android com agente de IA: da intenção à ação. Para a diferença entre controle local e processamento em nuvem, veja Confiança em agentes de IA: controle local no Android ou IA em nuvem.
Rode uma medição pequena e repetível
Antes de tirar conclusões de custo, rode uma verificação pequena. Escolha 10 tarefas idênticas e de baixo risco, no mesmo aparelho, app, conta e idioma. Por exemplo: preparar um rascunho de resposta para um contato de teste, sem enviar. Defina conclusão como “texto correto no campo certo, conversa certa aberta, usuário aprovou o rascunho”.
- Registre o prompt, o app, o aparelho e o modelo usado.
- Registre uso do provedor: entrada comum, cache, saída, imagens, ferramentas e novas tentativas.
- Marque cada tentativa como concluída, falha, abandonada ou incerta.
- Meça tempo de revisão humana separadamente.
- Se quiser medir energia, registre consumo incremental em Wh e calcule Wh dividido por 1000 vezes a tarifa local por kWh.
- Some todos os custos medidos e divida apenas pelas conclusões verificadas.
Mantenha permissões e confirmações necessárias durante o teste. Reduzir custo removendo revisão de destinatário, aprovação de envio ou checagem de campo cria uma comparação ruim: parece mais barato porque pula a proteção que a tarefa exige. Quando uma tentativa falhar, diagnostique antes de repetir; o guia Como depurar e recuperar falhas de agentes de IA no celular Android ajuda a investigar tela, permissão e resultado incerto.
Reduza desperdício sem remover checagens
As melhores reduções de custo vêm de entradas claras, histórico limitado ao necessário, cache confirmado pelo provedor e diagnóstico antes de novas tentativas. Se a tela mudou, leia o estado atual antes de agir. Se o envio ficou incerto, confira o app real antes de tentar de novo. Se o fluxo é recorrente e suportado, um fluxo salvo pode guardar etapas reutilizáveis, mas as chamadas ao modelo e a cobrança ainda precisam ser medidas.
Também separe custo de modelo, tempo humano e energia. Monetize cada um de forma consistente ou mantenha colunas separadas. Não use economia de bateria, cache ou execução no telefone como promessa automática.
Na FoneClaw, tratamos o telefone como local de execução Android suportada, com permissões, estado visível e resultado revisável. Os recursos atuais ficam em recursos da FoneClaw. A forma rigorosa de reduzir desperdício é manter as checagens certas e medir custo por tarefa realmente concluída.