A real browser,
driven through an API.

Operator provisions a cloud browser, runs the task your agent submits, and reports the result on the wire. A person can watch the session live or take the wheel, and the device sleeps and wakes without losing what was signed in.

Get your API key
Devices, tasks, live view, audit·Keys are self-serve·one credential, scoped and shown once
the first task on live infrastructure · recorded 2026-08-01
# a real browser, provisioned through the API POST /v1/devices 201 dev_… status: active # the agent submits the work POST /v1/devices/dev_…/tasks 202 {"prompt":"open example.com, report the page title"} # the task runs, and the answer comes back on the wire GET /v1/tasks/task_… 200 status: succeeded result: "The page title of example.com is: \"Example Domain\". No login or session-persistence prompts appeared."
Recorded from the first end-to-end task on live infrastructure: provisioned, submitted, succeeded, with the result as the API returned it.

Provision, run, read the record.

1

Provision

One call creates a device: a real browser in a sandboxed machine, answering on the API as active. A failed provision cleans up after itself.

2

Run

Submit a task with a prompt. The device reaches a terminal state either way, and a failed task carries its reason in the same field the answer would have used.

3

Read the record

The result comes back on the wire, in the same field a failure would use for its reason. The audit trail has its own read scope, nothing more.

Exercised against live infrastructure.

Sleep and wake

A device slept and woke through the API, and the session survived. The run above finished with no login prompt, because the browser kept what it had.

Live view and takeover

Mint a session in watch or control mode and a person sees the browser over a socket on the public API. Control is a separate, higher scope.

Failure says why

A failed task returns its reason in result, not a bare status. That field is on the wire because debugging without it cost a live session five layers of digging.

Cancel that lands

Cancellation is honored by the worker that owns the task, and the task record shows cancelled once it has actually stopped, not before.

Stated plainly.

Proven live

  • A device provisioned to active through the public API
  • Sleep and wake, with the signed-in session intact
  • A task ran end to end and returned its answer
  • Failure reasons surfaced on the wire; cancels reach a terminal state
  • Live view sessions minted in watch and control modes

Access today

  • Create a key from workspace settings — shown once, scoped, revocable
  • Every key is scoped: devices, tasks, sessions, audit are separate grants
  • Billing is fail-closed. No subscription is required for the API, but an org needs a funded wallet before its first task

Not claimed

  • Webhook delivery has not been verified end to end
  • Operator browser time is metered but not yet charged to the wallet
  • No uptime promises. The record above is what has been proven

Put a browser behind your agent.

Create a key in workspace settings, scope it to the calls you need, and start against the API base below.

Get your API keyAPI basehttps://api.omegas.dev/v1