Coste por tarea de un agente de IA: fórmula, ejemplo y medición en Android

Mide el coste por tarea completada

El coste por tarea de un agente de IA debe medirse por resultado terminado, no por una llamada aislada al modelo. Una tarea cuenta como completada cuando el resultado esperado queda verificado: un borrador visible en la app correcta, una nota creada, un evento guardado, una ruta abierta o una acción Android compatible revisada por el usuario.

La fórmula base es sencilla: coste total medido dividido entre tareas completadas y verificadas. El coste total puede incluir uso del modelo, lecturas de caché, escritura o almacenamiento de caché si el proveedor lo cobra, herramientas externas, suscripción o créditos consumidos, y tiempo humano si decides monetizarlo. No mezcles todo por defecto: si una cuota ya cubre cierto uso, no lo vuelvas a sumar como coste variable.

En FoneClaw, la ejecución en Android puede cambiar cuántos pasos se repiten y cuánto contexto se envía, pero no convierte automáticamente una tarea en gratuita ni local. El modelo configurado ayuda a interpretar y planificar; FoneClaw ejecuta acciones Android compatibles con permisos, estado visible y revisiones necesarias.

Construye un libro de costes con el uso del proveedor

El libro debe partir de categorías separadas. Para el modelo, usa totales disjuntos: entrada no cacheada, lecturas de caché y salida facturable. Después añade solo lo aplicable: creación de caché, almacenamiento de caché, herramientas del proveedor, grounding, servicios externos, suscripción o créditos consumidos. La documentación de Gemini explica que el uso puede incluir entrada, salida, pensamiento y contexto cacheado; también indica que texto, imágenes y otras modalidades se tokenizan en su guía de conteo de tokens.

La fórmula reutilizable para el modelo es: coste de modelo = (tokens de entrada no cacheada / un millón × tarifa de entrada por millón) + (tokens de lectura de caché / un millón × tarifa de lectura de caché por millón) + (tokens de salida facturable / un millón × tarifa de salida por millón). Usa conteos brutos del proveedor para cada categoría y mantén los reintentos dentro de esos totales medidos, sin añadirlos otra vez como una partida separada.

Para precios reales, no uses tasas inventadas de otro artículo: toma el modelo, modalidad y nivel de servicio actuales de tu proveedor. La página de precios de Gemini API muestra que las categorías pueden variar por modelo, modalidad, caché, almacenamiento o herramientas. En Claude, el prompt caching separa escrituras de caché, lecturas de caché y entrada ordinaria; la reutilización depende de condiciones de contenido y plataforma, como explica la documentación de prompt caching de Claude.

Evita doble conteo. Si una imagen ya se transformó en tokens de entrada, no añadas una segunda partida genérica por imagen salvo que el proveedor cobre otra categoría aparte. Si la salida facturable ya incluye tokens de pensamiento, no los sumes otra vez. Si un reintento ya aparece en los totales de uso, no añadas “reintentos” como otra línea de coste: úsalo como explicación operativa, no como cargo duplicado.

Recalcula un lote hipotético

Este ejemplo usa tasas hipotéticas en dólares para enseñar el cálculo; no son precios actuales de Google, Claude, FoneClaw ni otro proveedor. Supón un lote de 100 tareas intentadas, con todas las llamadas y reintentos ya incluidos en el uso medido:

El coste por tarea completada es 3,34 USD dividido entre 90, es decir, aproximadamente 0,0371 USD por tarea verificada. Las 10 tareas fallidas no desaparecen: su uso ya está dentro del coste total. Si un proveedor también cobrara escritura de caché, almacenamiento, una herramienta de búsqueda o una cuota no incluida, tendrías que añadirlo como línea separada. Si el lote tuviera cero tareas completadas, la métrica de coste por completado no sería cero; sería indefinida y habría que diagnosticar el flujo antes de compararlo.

Qué puede cambiar la ejecución en el teléfono

La ejecución en el teléfono puede cambiar el coste porque cambia la tarea, no porque garantice ahorro. Una acción Android compatible puede reducir explicaciones repetidas, evitar que el usuario copie pasos manualmente o permitir reutilizar una secuencia estable. Un flujo guardado puede conservar pasos de herramientas admitidas, pero los modelos, llamadas reales y facturación deben medirse cada vez que importen.

En FoneClaw, una tarea de borrador puede leer el estado visible compatible, preparar texto y rellenar un campo editable identificado. Ese paso no envía, no publica y no pulsa Enter. Si la pantalla cambia, se debe volver a comprobar el estado visible antes de seguir. Si la tarea usa un modelo online configurado, el contexto suministrado puede procesarse según las condiciones de ese proveedor.

No conviene afirmar que un árbol de interfaz siempre cueste menos que una captura, ni usar capturas como sustituto genérico para encontrar controles que la accesibilidad no expone. Capturas de pantalla, texto, historial, caché y salida deben contarse según la forma en que el proveedor facture la modalidad y el uso real. Para entender mejor qué significa una acción compatible y verificable en Android, consulta Controlar un teléfono Android con agente de IA: de intención a acción verificada.

Ejecuta una prueba pequeña y repetible

Para comparar configuraciones, usa una prueba corta y de bajo riesgo. Elige 10 tareas iguales, por ejemplo preparar un borrador en una nota o en una conversación de prueba sin enviarlo. Mantén el mismo teléfono, app, idioma, texto de entrada, política de aprobación y definición de éxito. Una tarea puede contar como completada solo si el borrador correcto aparece en el campo correcto y el usuario puede revisarlo.

1. Registra entrada no cacheada, lecturas de caché, salida facturable y herramientas externas desde el proveedor cuando estén disponibles.
2. Anota intentos, reintentos, fallos, tareas completadas, tiempo de revisión y motivo de cada fallo.
3. Separa el tiempo humano del coste del modelo. Si lo monetizas, usa una tasa clara y aplícala igual a todos los flujos.
4. Mide energía incremental aparte si te importa: Wh adicionales dividido entre 1000 y multiplicado por tu coste por kWh.
5. Divide coste total entre tareas completadas verificadas, no entre tareas intentadas.

Este protocolo no afirma que una configuración gane siempre. Sirve para ver dónde se gasta el dinero: contexto repetido, caché que no se reutiliza, reintentos, salida larga, herramientas externas o revisión humana. Para secuencias Android más amplias, Automatizar tareas Android de varios pasos con IA, confirmación y recuperación ayuda a definir qué cuenta como una tarea completa.

Reduce desperdicio sin quitar comprobaciones

Reducir coste no significa eliminar permisos ni confirmaciones. Las mejores reducciones suelen venir de entradas más claras, historiales acotados, instrucciones estables, caché confirmada por los campos de uso del proveedor y diagnóstico antes de repetir una acción fallida.

Si una tarea falla, revisa primero el estado real de la app. Reintentar sin saber si el borrador quedó escrito, enviado o descartado puede duplicar coste y riesgo. Para ese tipo de recuperación, Cómo depurar y recuperar fallos de un agente móvil Android sin repetir acciones peligrosas ofrece una ruta más detallada.

También separa confianza de facturación. La ejecución en Android y el procesamiento en la nube pueden coexistir; esa frontera se explica en Confianza en agentes de IA: control local en Android frente a seguridad en la nube. Para revisar el alcance actual de nuestras acciones Android, consulta las funciones de FoneClaw.