Browser Use vs Skyvern

Browser Use

The hosted cloud accepts x402 top-ups in USDC on Base with no account or API key, and publishes prices, rate limits and three OpenAPI documents. The privacy policy says inputs are used to train Browser Use's models, API keys have no documented scopes, and no prompt-injection guidance was found in the docs.

Skyvern

The hosted MCP server annotates every tool as read-only or destructive and can advertise a 29 or 32-tool subset in place of 114, and the API has a written six-month deprecation policy. Every key and OAuth token carries full organisation authority, with no read-only or scoped credential, and no request rate limits are documented.

Browser Use

1. Send the key as X-Browser-Use-API-Key with no Bearer prefix. A Bearer header returns 401
2. Stop browsers with PATCH /api/v4/browsers/{id} and {"action":"stop"}. Closing CDP or the SDK client leaves the browser billing
3. Poll GET /runs/{id}/status, not the full run, and wait for the returned Retry-After on 429, which can be 300 seconds at the edge
4. Before resubmitting after a timeout, read the existing run's status. The server keeps running and may already have submitted a form
5. With a wallet and no key, call x402.api.browser-use.com on /api/v2 or /api/v3 routes. A task stops with INSUFFICIENT_CREDITS if credit runs out mid-run

Skyvern

1. Connect to https://api.skyvern.com/mcp/x/lean or /x/operate, or send X-Skyvern-Scope, so the client loads 32 or 29 tools. The scope filters the list and does not limit permissions
2. Use a separate Skyvern organisation for each blast radius. Any key or OAuth token can read and write stored credentials and delete workflows
3. Never pass passwords to skyvern_act or skyvern_type. Store them as credentials and call skyvern_login
4. Set max_steps on tasks, or x-max-steps-override on agent runs, to cap credits. A run that reaches the cap ends as timed_out
5. On 503 from POST /v1/run/agents, wait Retry-After seconds. No run was created, so resubmitting is safe