Browser Use SDK

Why it's ranked here

The breadth is credible: both ecosystems expose synchronous or asynchronous clients, generated models, and several API generations. The rough edge is version navigation. Defaults still point to generation two while newer surfaces require separate imports or entry points.

What's good

The public surfaces expose request models, response models, status unions, and error types. Python supports synchronous and asynchronous use. TypeScript ships CommonJS and ES modules with declarations and source maps. Compatibility stubs protect older Python consumers from immediate import failures.

Tradeoffs

The supplied documentation is extremely thin and offers no usage examples. Three API generations coexist, with different concepts and naming. Python defaults to generation two, while later generations require explicit imports. Compatibility modules are already marked for future removal.

How to use it well

Choose it when a Python or TypeScript service already targets Browser Use Cloud and benefits from typed resource models. Pin the API generation deliberately and isolate SDK calls behind an application boundary. It does not provide evidence here of a standalone local browser engine or command-line workflow.

Observed

Languages

Python and TypeScript SDK packages

Packaging

Python package on PyPI and TypeScript package on npm

Interface

Versioned client libraries for the Browser Use Cloud API

Module formats

TypeScript build targets CommonJS and ES modules

Python clients

Synchronous and asynchronous client surfaces

API generations

Repository exposes v2, v3, and v4 SDK surfaces

Type generation

Public request and response models are re-exported from generated schemas