Custo por tokens em agentes de IA: por que agir no Android pode economizar

O custo de um agente começa antes da resposta

Quando alguém calcula o custo de um agente de IA, normalmente olha para o preço do modelo por entrada e saída. Isso é importante, mas incompleto. Uma tarefa de telefone com várias etapas não consome apenas a pergunta do usuário e a resposta final. Ela pode incluir contexto do app, histórico da conversa, descrição das ferramentas disponíveis, estado do telefone, confirmações, erros e tentativas repetidas.

As páginas de preços da API da OpenAI e de preços do Vertex AI mostram um padrão estável do mercado: custo de IA em nuvem costuma variar por modelo, volume de entrada, volume de saída, modalidade e uso. Não precisamos inventar números para entender a lógica. Quanto mais contexto o agente precisa enviar e reenviar, mais caro fica o processo.

Em tarefas simples, isso pode passar despercebido. Em um comando como “resuma este texto”, o custo é relativamente direto. Em um comando de telefone, como “responda esta mensagem, abra o app certo e me avise se faltar permissão”, o agente precisa raciocinar sobre o estado do aparelho. Se ele não consegue agir localmente, pode ficar descrevendo o problema várias vezes sem concluir.

Na FoneClaw, nós tratamos custo como custo total da tarefa, não apenas custo do modelo. Tokens importam, mas tempo do usuário, erros, retrabalho e suporte também custam. Um agente barato por chamada pode sair caro se faz a pessoa corrigir tudo manualmente.

Onde os tokens escapam em tarefas de telefone

O desperdício aparece primeiro no contexto longo. Um agente precisa saber o que o usuário pediu, que app está envolvido, quais passos já foram tentados e quais permissões existem. Se cada nova tentativa reenviar tudo, o custo cresce. Isso piora quando a tarefa usa capturas de tela, listas de ferramentas ou descrições longas de estado.

Outro vazamento vem das correções. O usuário diz “não era esse contato”, “não envie ainda”, “abra o outro app”, “esse botão não apareceu”. Cada correção adiciona contexto e força o agente a repensar. Em uma tarefa mal desenhada, a conversa vira uma sequência de tentativa e erro. O usuário perde tempo, e o sistema consome tokens para explicar falhas que poderiam ser evitadas com ações mais previsíveis.

Descrições de ferramentas também pesam. Um agente que precisa escolher entre muitas ferramentas, sem saber quais realmente funcionam no telefone, pode gastar tokens comparando opções que não servem. Isso acontece quando o produto promete controle amplo, mas não conhece bem os caminhos suportados. Quanto mais genérico o agente, maior a chance de planejar demais e agir de menos.

É por isso que o tema se conecta ao guia Como automatizar tarefas no Android com um comando de voz. Quando uma tarefa Android é bem delimitada, com entrada clara, ação suportada e ponto de confirmação, o agente não precisa redescobrir tudo a cada rodada.

Por que um agente só em nuvem pode gastar mais para agir menos

Um agente em nuvem pode raciocinar muito bem sobre uma tarefa e ainda assim não conseguir mudar o estado do telefone. Ele pode explicar como abrir uma configuração, sugerir um texto, listar etapas ou interpretar uma captura. Mas, se não tem um caminho confiável para acionar o Android, o usuário continua fazendo a parte difícil manualmente.

Esse é um custo invisível. O agente gasta tokens descrevendo o que deveria acontecer, o usuário tenta executar, algo muda na tela, o agente precisa de novo contexto e a tarefa volta ao início. Em vez de uma ação curta, nasce uma conversa longa. O problema não é a nuvem em si; é usar raciocínio remoto para compensar falta de controle local suportado.

Também há risco de contexto sensível. Para descrever o estado do telefone, o usuário pode enviar tela, notificações ou texto de apps. A documentação de privacidade e segurança do Android lembra que permissões e controles do sistema existem para limitar acesso a dados e recursos sensíveis. Reenviar contexto para a nuvem sem necessidade aumenta custo e exposição.

Essa é a razão pela qual discutimos Confiança em agentes de IA: controle local no Android ou IA em nuvem. A escolha não é ideológica. Há tarefas em que a nuvem ajuda. Há tarefas em que o telefone precisa agir localmente, com permissão clara, para evitar conversa longa e pouco resultado.

Quando agir no Android reduz repetição

Agir localmente no Android pode reduzir custo quando a tarefa é conhecida e suportada. Se o agente sabe abrir um fluxo, preparar uma mensagem, consultar um estado permitido ou orientar uma configuração, não precisa gastar tokens descrevendo cada botão. Ele usa um caminho previsível e pede confirmação quando há impacto real.

Isso não significa que tudo deve rodar no aparelho. Algumas tarefas exigem raciocínio amplo, pesquisa, análise de documentos ou modelos maiores. Nesses casos, a nuvem pode ser a melhor rota. O ponto é separar raciocínio de ação. Use nuvem quando o problema é entender; use o telefone quando o problema é agir em algo que o Android suporta.

A economia vem de evitar replanejamento desnecessário. Uma ação suportada não deve ser tratada como enigma novo a cada uso. Se o usuário pede para preparar uma resposta, o produto deve saber a diferença entre rascunho e envio. Se pede para abrir um app, o produto deve saber quando isso é possível. Se falta permissão, deve pedir de forma específica.

Para ambientes mais exigentes, essa lógica também aparece em Segurança de agentes de IA empresariais: como avaliar agentes locais no celular. Menos ambiguidade reduz tanto risco quanto custo operacional. Quando a ação é previsível, há menos erro, menos suporte e menos conversa para corrigir.

Nossa visão na FoneClaw: ações suportadas não devem ser replanejadas sempre

Na FoneClaw, nós não medimos economia apenas como “menos tokens”. Medimos como menos voltas para concluir uma tarefa suportada. Se o usuário pede uma ação comum no Android, o agente não deveria reconstruir a estratégia do zero toda vez. Ele deve reconhecer o tipo de tarefa, verificar permissões, conduzir a ação suportada e mostrar o resultado.

Nosso limite também é parte dessa economia. Não prometemos controlar todos os apps, burlar permissões ou concluir etapas sensíveis sem aprovação. Promessas amplas aumentam custo porque geram tentativas falhas. Preferimos mapear ações suportadas com clareza e dizer quando algo não pode ser feito.

Registro também reduz custo. Quando o agente deixa claro o que tentou, onde parou e qual confirmação falta, o usuário não precisa explicar tudo de novo. O sistema também evita repetir a mesma etapa. Em tarefas de telefone, um bom histórico economiza tokens e paciência.

Essa visão não elimina a nuvem. Ela organiza o papel da nuvem. O raciocínio remoto pode ajudar em linguagem, análise e planejamento complexo. A ação Android suportada deve ficar o mais próxima possível do aparelho e do usuário, com permissão, confirmação e resultado visível.

Checklist para estimar o custo total de um agente

Antes de avaliar um agente só pelo preço por token, estime a tarefa inteira. Quantas vezes o modelo precisa ler o contexto? Quantas ferramentas precisa considerar? Quantas tentativas costuma fazer antes de acertar? Quanto tempo o usuário gasta corrigindo? Quantas ações viram suporte depois?

Use este checklist:

• O agente envia contexto longo para cada tentativa?
• Ele precisa de capturas de tela repetidas para entender o telefone?
• As ações comuns são suportadas ou sempre planejadas do zero?
• Há confirmação clara antes de etapas sensíveis?
• O histórico ajuda a retomar a tarefa sem repetir tudo?
• Quando uma ação falha, o produto explica o motivo ou tenta de novo sem direção?
• A nuvem é necessária para raciocinar ou está compensando falta de ação local?

Também separe custo de modelo de custo humano. Se o usuário precisa revisar cinco respostas ruins, o custo real subiu. Se a equipe de suporte precisa explicar por que o agente falhou, o custo real subiu. Se o sistema consome muitos tokens para terminar em “faça manualmente”, o custo real subiu.

A nossa conclusão é prática: reduzir AI agent token cost exige desenhar tarefas melhores, não apenas escolher um modelo mais barato. Para ações Android suportadas, FoneClaw busca diminuir repetição, preservar controle do usuário e evitar que a nuvem seja usada para descrever uma tarefa que o telefone pode conduzir com mais clareza.