Conducir un navegador con un LLM mediante modelos de uso de computadora puede costar unas 45 veces más que resolver la misma tarea con una API estructurada.
Esta guía explica de dónde sale esa diferencia, cuándo el uso de computadora sigue teniendo sentido y cómo diseñar una ruta estructurada con Apidog para reducir coste, latencia y fallos. El marco aplica a OpenAI Operator, computer use de Anthropic, agentes de navegador, Skyvern y cualquier herramienta basada en bucles de capturas de pantalla.
Si construyes APIs para agentes de IA, también conviene leer la guía sobre cómo escribir archivos agents.md. Esas convenciones ayudan a que la ruta de API estructurada sea el comportamiento por defecto para tus agentes.
TL;DR
- Uso de computadora: el LLM analiza capturas de pantalla y responde con clics, teclas y desplazamientos.
- APIs estructuradas: el LLM emite llamadas JSON a herramientas que tu backend ejecuta.
- Para la misma tarea, el uso de computadora suele consumir 30-50x más tokens por capturas, reintentos y pasos intermedios.
- Usa uso de computadora solo si no existe API, la API no cubre el flujo o la autenticación impide automatizarlo de forma estable.
- Usa APIs estructuradas para pagos, búsquedas, CRM, herramientas internas y cualquier operación que puedas describir con OpenAPI.
- En producción, lo habitual es un enfoque híbrido: APIs estructuradas para el 90% de operaciones y navegador para la cola larga.
- Con Apidog puedes diseñar esquemas JSON, simular endpoints y reproducir tráfico antes de gastar créditos de agente.
Por qué la brecha de costos es tan grande
La diferencia de 45x no depende de un benchmark específico. Sale de cómo cada enfoque consume tokens.
Una llamada a una API estructurada normalmente incluye:
- Prompt del usuario.
- Esquema de la herramienta.
- Respuesta JSON del modelo.
- Ejecución de una llamada HTTP.
Ejemplo de flujo:
Usuario -> LLM -> JSON tool call -> Backend -> API externa
En cambio, un bucle de uso de computadora repite este ciclo:
Usuario -> captura de pantalla -> LLM -> clic/tecla -> nueva captura -> LLM -> ...
Una tarea como “reservar un vuelo” o “buscar pagos fallidos” puede requerir entre 12 y 30 rondas. Cada captura puede rondar los 1.500 tokens con resoluciones habituales. A eso se suman clics incorrectos, banners de cookies, scrolls fallidos, cambios de UI y reintentos.
La documentación de uso de computadora de Anthropic detalla el coste de los tokens de captura. El hilo de HN Computer Use is 45x more expensive than structured APIs sitúa la penalización típica entre 30x y 50x, una cifra consistente con lo que se observa al reproducir el mismo flujo por ambas rutas en Apidog.
Cuándo gana la API estructurada
Por defecto, usa APIs estructuradas si se cumple cualquiera de estas condiciones.
1. Existe una especificación o documentación
Si el proveedor publica OpenAPI, GraphQL, REST o incluso una página de documentación con ejemplos JSON, el LLM puede generar llamadas de herramienta tipadas.
El fallo, cuando ocurre, suele ser barato de detectar:
{
"error": "missing_required_field",
"field": "customer_id"
}
Eso se puede validar, registrar y reintentar. Un clic fallido en un navegador es mucho más ambiguo.
2. La tarea cabe en uno o dos endpoints
Estos flujos no deberían pasar por navegador:
- Crear un cliente en Stripe.
- Actualizar una oportunidad en HubSpot.
- Publicar un mensaje en Slack.
- Lanzar una ejecución de CI.
- Consultar pagos fallidos.
- Crear un ticket de soporte.
Si existe un endpoint, automatizarlo con clics es añadir coste y fragilidad sin necesidad.
3. El flujo se ejecuta sin supervisión
Cron jobs, webhooks y workers de cola necesitan comportamiento predecible. Un bucle de navegador puede quedarse atascado en:
- Un modal inesperado.
- Un cambio de layout.
- Un selector de fechas distinto.
- Una sesión expirada.
- Un captcha o MFA.
Una llamada estructurada es más fácil de validar, observar y reintentar.
4. La latencia importa
Una llamada HTTP estructurada puede responder en 200-800 ms. Un flujo de navegador con 15 rondas puede tardar 30-90 segundos.
Si el usuario está esperando una respuesta, casi siempre conviene usar API.
5. Necesitas probar antes de desplegar
Simular un endpoint JSON en Apidog toma minutos. Simular un navegador con capturas, sesiones, estados visuales y fallos de UI es mucho más costoso.
Cuándo el uso de computadora sí vale la pena
El uso de computadora no es inútil. Es una herramienta para casos donde no hay una interfaz de máquina razonable.
Portales legacy sin API
Algunos portales de compras, transporte, seguros o beneficios viven detrás de sesiones de ASP.NET, formularios antiguos y pantallas sin endpoints públicos.
Si la alternativa es mantener un script de Selenium que se rompe cada trimestre, pagar más tokens puede ser aceptable.
Herramientas internas que no puedes modificar
Ejemplos:
- Un CRM comprado en 2014.
- Un ERP heredado.
- Un panel de SharePoint.
- Una herramienta interna sin equipo disponible para crear integración.
Si no puedes exponer una API y el volumen es bajo, el navegador puede cubrir el hueco.
Tareas únicas o exploratorias
Un flujo como “investiga estos 50 competidores y resume hallazgos en Notion” quizá no merece un contrato estructurado si se ejecutará una sola vez.
Ahí el coste por ejecución puede ser menos importante que el tiempo de implementación.
Scraping contra términos de servicio
Evítalo. Si la automatización viola los términos del proveedor, el coste de tokens es el menor de los problemas.
Marco de decisión
Antes de usar computadora, pasa la tarea por estas verificaciones:
| Verificación | Si es sí | Si es no |
|---|---|---|
| ¿Existe una API documentada? | Usa la API. | Continúa. |
| ¿Puedes crear un adaptador server-side que envuelva un endpoint privado? | Construye el adaptador y expón JSON. | Continúa. |
| ¿La tarea es única o de bajo volumen (<100 ejecuciones/día)? | El uso de computadora puede ser aceptable. | Continúa. |
| ¿Aceptas pagar 30-50x más tokens por ejecución? | Usa computadora. | Detente y negocia acceso a API. |
En la práctica, la mayoría de flujos deberían resolverse en la primera o segunda verificación.
Cómo se ve una API estructurada en un agente
Supongamos que quieres obtener los pagos fallidos de ayer.
La versión estructurada define una herramienta con JSON Schema:
import json
from openai import OpenAI
client = OpenAI()
tools = [
{
"type": "function",
"function": {
"name": "list_failed_payments",
"description": "List failed payments in a date range",
"parameters": {
"type": "object",
"properties": {
"start": {
"type": "string",
"format": "date"
},
"end": {
"type": "string",
"format": "date"
}
},
"required": ["start", "end"]
}
}
}
]
resp = client.chat.completions.create(
model="gpt-5.5",
messages=[
{
"role": "user",
"content": "Show yesterday's failed payments."
}
],
tools=tools,
tool_choice="auto"
)
call = resp.choices[0].message.tool_calls[0]
args = json.loads(call.function.arguments)
payments = stripe.PaymentIntent.list(
created={
"gte": args["start"],
"lte": args["end"]
},
limit=100
)
El agente no necesita abrir el dashboard de Stripe. Solo genera argumentos válidos:
{
"start": "2026-01-14",
"end": "2026-01-15"
}
El equivalente con uso de computadora sería:
- Abrir navegador.
- Iniciar sesión.
- Capturar dashboard.
- Hacer clic en filtros.
- Seleccionar rango de fechas.
- Capturar de nuevo.
- Buscar estado “Fallido”.
- Hacer scroll.
- Leer datos desde píxeles o tabla.
- Reintentar si algo cambia.
Cada paso añade tokens, latencia y probabilidad de fallo.
Diseñar la ruta estructurada con Apidog
El problema no suele ser que el uso de computadora sea barato o caro. El problema es que nadie diseñó una superficie de herramienta clara para el agente.
Con Apidog, puedes convertir operaciones de negocio en endpoints documentados y simulables.
Paso 1: modela las operaciones como endpoints
Empieza con las acciones que el agente necesita ejecutar:
POST /payments/failed/search
POST /deals/{deal_id}/stage
POST /messages/slack
POST /invoices/search
No necesitas exponer todo tu backend. Diseña una capa pequeña y orientada al agente.
Ejemplo de contrato:
{
"endpoint": "POST /payments/failed/search",
"body": {
"start": "2026-01-14",
"end": "2026-01-15",
"limit": 100
}
}
Apidog puede generar OpenAPI 3.1 desde la vista de diseño.
Paso 2: conecta OpenAPI al framework del agente
OpenAI tools, Anthropic tool_use y loaders OpenAPI de frameworks como LangChain pueden consumir esquemas tipados.
El objetivo es que el modelo vea una herramienta clara:
{
"name": "search_failed_payments",
"description": "Search failed payments by date range",
"parameters": {
"type": "object",
"properties": {
"start": { "type": "string", "format": "date" },
"end": { "type": "string", "format": "date" },
"limit": { "type": "integer", "default": 100 }
},
"required": ["start", "end"]
}
}
Paso 3: activa el servidor de simulación
Antes de conectar producción, usa el mock server de Apidog.
Esto permite:
- Ejecutar el agente end-to-end.
- Validar argumentos.
- Probar errores.
- Evitar llamadas reales.
- Reducir coste de tokens durante iteración.
El mismo patrón aparece en la guía de desarrollo contract-first de Apidog.
Paso 4: reproduce el tráfico
Registra cada request y response generada por el agente:
tool_call -> request body -> response -> decisión siguiente
Esto facilita depurar casos como:
- El agente eligió la herramienta equivocada.
- Faltó un campo requerido.
- El endpoint devolvió un error no modelado.
- La respuesta no tenía suficiente contexto para el siguiente paso.
Paso 5: publica y versiona
El proyecto de Apidog puede funcionar como:
- Documentación pública o interna.
- Contrato OpenAPI.
- Mock server.
- Base para QA.
- Referencia para observabilidad.
Trata la superficie de herramientas como tratarías una API pública: con versiones, revisión y compatibilidad.
Híbrido: cuando necesitas ambos caminos
En producción, muchos agentes terminan con una arquitectura híbrida:
- 90% de operaciones por herramientas estructuradas.
- 10% por uso de computadora para portales legacy.
- Un router decide qué ruta usar.
Ejemplo de regla de enrutamiento:
Si la operación existe en known_tools, llama a la herramienta.
Si no existe, deriva al agente de navegador.
Pseudocódigo:
known_tools = {
"list_failed_payments",
"update_deal_stage",
"send_slack_message"
}
def route(operation_name: str):
if operation_name in known_tools:
return "structured_tool"
return "browser_agent"
Claude 4.5, GPT-5.5 y DeepSeek V4 pueden manejar este tipo de enrutamiento. Para ver la forma de solicitud en DeepSeek, consulta cómo usar la API de DeepSeek V4.
Monitoriza ambas rutas por separado:
structured_tools:
volume: alto
cost: bajo
latency: baja
computer_use:
volume: bajo
cost: alto
latency: alta
Una señal de alerta sería que el fallback de navegador empiece a crecer. Eso suele indicar que falta un endpoint en la superficie estructurada.
Errores comunes
Omitir el esquema
No dependas solo de prompts en lenguaje natural.
Mal:
Cuando el usuario pida pagos fallidos, llama a la API correcta.
Mejor:
{
"type": "object",
"properties": {
"start": { "type": "string", "format": "date" },
"end": { "type": "string", "format": "date" }
},
"required": ["start", "end"]
}
Un JSON Schema estricto mejora precisión y reduce ambigüedad.
Dejar que el agente diseñe el esquema en runtime
El esquema es una superficie de producto. Debe diseñarse, revisarse y versionarse.
No permitas que el agente invente contratos distintos en cada ejecución.
Medir tokens pero no coste real
Los tokens de imagen pueden facturarse distinto. Revisa la consola de facturación del proveedor, no solo tu trazador interno.
Confundir uso de computadora con RPA
RPA ejecuta pasos programados sobre elementos conocidos. Uso de computadora decide en cada captura qué hacer.
- RPA: barato y repetible, pero frágil ante cambios.
- Uso de computadora: flexible, pero caro y más lento.
- API estructurada: preferible si existe.
Ignorar la latencia
El coste en tokens importa, pero la latencia puede importar más. Un flujo de 60 segundos rompe la experiencia si el usuario está esperando.
Alternativas antes de usar computadora
Si no hay API pública, considera estas opciones.
Playwright o Puppeteer
Scripts de navegador sin interfaz pueden ser más baratos por ejecución. El coste está en mantenimiento cuando cambia la UI.
Zapier, Make u otros conectores
Si el proveedor ya tiene un conector iPaaS, quizá sea más rápido pagar la licencia que construir integración propia.
APIs privadas
Muchos dashboards usan endpoints JSON internos. Puedes inspeccionarlos en DevTools y documentarlos en Apidog como semiestables.
Hazlo con cuidado y respetando términos de servicio. Este enfoque se menciona también en pruebas de API sin Postman.
Casos de uso reales
Un equipo de cumplimiento financiero reemplazó un informe de Stripe basado en seis pasos de navegador por tres llamadas estructuradas. El coste de tokens bajó un 92% y la ejecución pasó de 41 segundos a 2.
Un agente de soporte B2B SaaS conservó uso de computadora para un único portal de compras sin API. El resto se movió a herramientas OpenAPI diseñadas en Apidog. El gasto mensual de tokens bajó de 4.200 USD a 310 USD.
Un fundador independiente usaba uso de computadora una vez por semana para actualizar Notion desde un ERP heredado. El coste 45x era de unos pocos centavos por ejecución. Construir una integración completa habría tomado semanas. Ese es un buen caso para uso de computadora.
Conclusión
La diferencia de 45x es suficientemente grande como para cambiar la arquitectura de tus agentes.
Por defecto:
- Diseña una API estructurada.
- Documenta el contrato con OpenAPI.
- Simula antes de llamar a producción.
- Versiona el esquema.
- Usa navegador solo como fallback.
Cinco ideas clave:
- El uso de computadora suele costar 30-50x más tokens que una API estructurada equivalente.
- Un endpoint documentado con JSON Schema gana en coste, latencia y fiabilidad.
- Los stacks híbridos son normales: estructura el 90% y deja navegador para el 10% legacy.
- Simular la superficie de herramientas reduce coste y acelera iteración.
- Monitorizar rutas por separado ayuda a detectar cuándo falta un endpoint.
Siguiente paso: abre Apidog, crea un proyecto para las herramientas de tu agente y activa el servidor de simulación. En una hora puedes saber si el flujo que ibas a resolver con uso de computadora puede convertirse en dos llamadas estructuradas.
Preguntas frecuentes
¿El uso de computadora puede ser más barato que una API estructurada?
No por ejecución. Las capturas de pantalla dominan el coste. Puede ser más barato en coste total solo si el volumen es muy bajo y construir la integración cuesta más que años de ejecuciones.
¿Cómo simulo una superficie JSON para un agente?
Diseña los endpoints en Apidog, activa el servidor de simulación y apunta el agente a la URL mock. Cada request devuelve JSON realista sin tocar producción. El flujo completo se cubre en herramientas de prueba de API para ingenieros de QA.
¿Puedo usar OpenAPI para llamadas a herramientas en cualquier modelo?
Sí. OpenAI tools, Anthropic tool_use y endpoints de tool calling en modelos como DeepSeek V4 pueden trabajar con esquemas OpenAPI 3.1. Apidog exporta el esquema para conectarlo al framework del agente. Consulta cómo usar la API de DeepSeek V4.
¿GPT-5.5 sigue soportando uso de computadora?
OpenAI ofrece uso de computadora mediante Operator y la API de Responses. El perfil de coste es similar al de Anthropic: cada captura añade tokens. La recomendación de priorizar APIs estructuradas aplica independientemente del proveedor.
¿Qué pasa con Skyvern, agentes de navegador y proyectos open source?
La matemática es parecida. Pueden reducir coste usando modelos más baratos, pero siguen necesitando múltiples rondas y capturas. Donde existe una API, una llamada estructurada suele ganar por margen amplio.
¿Cómo detecto que falta un endpoint para una tarea del agente?
Observa cuándo el agente intenta recurrir al navegador. Si ocurre repetidamente para la misma operación, falta una herramienta estructurada. Añade el endpoint en Apidog, regenera el esquema y enruta esa operación por API.
Top comments (0)