Give a language model a task like “log into the supplier portal, download last quarter’s invoices, and flag anything that looks paid twice,” and you run into an obvious problem. The model can reason about the job beautifully, but it has nowhere to put its hands.
Scrapybara is one answer to that. It spins up real Ubuntu desktops in the cloud and hands an AI agent the controls through a small API: move the mouse, type, click, run a shell command, take a screenshot. Your agent loop decides what happens next. Scrapybara supplies the machine it happens on.
That narrowness is the point. It isn’t a framework that plans your agent’s next move, and it isn’t a thin wrapper around Playwright. It’s the substrate.
What Scrapybara actually gives you
An instance is a full virtual machine, not a sandboxed browser tab. It has a desktop environment, a real Chrome or Firefox, a filesystem, and a terminal. From the API you can dispatch mouse movements and clicks, send keystrokes and modifier combos, grab screenshots, execute bash, and read or write files.
You also get a stream URL. Point a browser at it and you’re watching the agent work in real time. If it stalls on a two-factor prompt or a captcha, a human can grab the keyboard mid-session and hand it back when the hard part is done.
Client libraries exist for Python and TypeScript, and there are integrations for the Vercel AI SDK, LangChain, and an MCP server so clients that speak that protocol can drive an instance without writing much glue.
The honest case for a desktop over a headless browser
If a site is well-behaved, DOM automation with Playwright or Puppeteer is cheaper, faster, and far more deterministic than a vision model squinting at pixels. Most teams should reach for it first.
Then they hit the sites that punish it. Portals built as a single canvas element. Drag-and-drop interfaces where the drop target only exists after a hover. Legacy internal tools that insist on a desktop client. Download flows that hand you a file and expect you to do something with it.
Computer-use models handle those cases because they work the way a person does, from the screen inward. The second advantage is subtler: browser and terminal live on the same machine. An agent can download a CSV in Chrome, switch to the shell, and process it in pandas without any plumbing between two sandboxes.
How the instance lifecycle works
Start, act, suspend, resume
You create an instance with an API call and get back an ID plus a stream endpoint. Do the work, then stop the instance. Between those two moments you can suspend it, which freezes the machine and the bill while keeping the session alive, and resume it later with state intact.
Snapshots cut setup time to nothing
A snapshot captures a machine you’ve already prepared: dependencies installed, browser profile configured, logins completed. Restoring from one means your agent starts at the interesting part instead of spending ninety seconds installing packages. For anything running on a schedule, snapshots are the difference between a two-minute run and a six-minute one.
Credentials, without handing the model your password
This is the part that trips people up in review meetings. An agent that types a password is an agent that can leak it into a trace, a screenshot, or a log you forgot about.
Authenticated instances address that by accepting credentials at creation time. The model interacts with a reference to the saved login rather than the literal secret, so the raw password never lands in the token stream. It’s not a substitute for proper secret hygiene, but it closes the most embarrassing failure mode.
Where it sits next to the alternatives
- Browserbase, Steel, and similar: browser-level infrastructure. Cheaper per run and a better fit when DOM selectors work reliably. No terminal, no desktop apps.
- E2B, Daytona, and other code sandboxes: excellent for running generated code in isolation, weaker when the task needs a visible GUI.
- Self-managed Playwright on your own containers: free software plus your time spent fighting anti-bot systems, stale selectors, and screenshot streaming.
- Raw cloud VMs with VNC bolted on: total control, and you own every integration you’d otherwise get out of the box.
- Agent libraries like Browser Use or Anthropic’s computer-use loop: these are complements. They plan; Scrapybara executes.
What actually decides whether this survives contact with production
Every screenshot round trip costs seconds
Perceive, reason, act. That cycle repeats for every click, and it’s slow. So batch aggressively: fill an entire form in one action sequence rather than screenshotting between fields, and drop to bash whenever a task can be scripted instead of pointed at. An agent that opens forty tabs hunting for a price will burn more on model tokens than the virtual machine ever costs.
Idle instances are the budget line nobody plans for
You pay for instance time, so an agent waiting on a human approval at 2 a.m. is a machine quietly renting itself. Suspend on idle, stop on completion, and put a hard timeout on any job that can hang.
Log the action trace, not just the outcome
Vision-driven agents fail in ways that don’t reproduce. Pin your model version, store every screenshot and action alongside the run ID, and you’ll be able to replay a failure instead of guessing at it. Teams that skip this spend their second month debugging blind.
Treat the machine as hostile territory
An instance has real network access and a real shell. Don’t drop long-lived cloud credentials inside it. Scope keys to the one system the task touches, and rotate them on a schedule.
What people are building with it
The pattern that shows up again and again is a workflow with no API at the end of it. Finance teams reconciling invoices from a supplier portal built in 2011. QA engineers pointing an agent at staging to click through a checkout flow and file bugs with screenshots attached. Researchers pulling data from sites that block headless traffic outright. Support teams automating the first five minutes of onboarding in an internal tool nobody has budget to rebuild.
None of these are glamorous. All of them are the kind of work that quietly consumes a person’s Tuesday afternoon.
Picking your first project
Start with one workflow you already understand well enough to describe to a new hire in a paragraph. Run it ten times by hand and write down every branch where you’d normally improvise, because those are the branches your agent will encounter on run three and fall over.
Then measure two numbers: how long a successful run takes, and how often it succeeds. If success rate sits under about eighty percent and the failures need human rescue, you’ve built a demo, not an automation. Tighten the scope, add a snapshot that skips the setup, and try again. A narrow agent that nails one job nine times out of ten beats a general one that wanders, and the cloud computer underneath is only as useful as the workflow you point it at.