Show HN: Letting Claude automate fleets of browser sandboxes(twitter.com)
twitter.com
Show HN: Letting Claude automate fleets of browser sandboxes
https://twitter.com/steeldotdev/status/2028855809233526799
1 comments
FWIW I work at Steel (not the OP). While we’ve been iterating on the “right shape” for agent tooling, I’ve been building a benchmark harness to measure how different surfaces affect real web task completion: raw API context, CLI-only, opinionated “skills” (structured outputs + artifact capture), and combinations.
If you’ve run agents on the open web, I’d love suggestions for nasty-but-representative workflows to include in the benchmark.
If you’ve run agents on the open web, I’d love suggestions for nasty-but-representative workflows to include in the benchmark.
I was trying to set up openclaw on railway and quickly bumped up against issues with a lack of browser access, a core component of the system. Agents like OpenClaw and CC are super good at using browsers but, similar to code sandboxes, they should be able to control these browser in the background, in parallel, without getting blocked by captchas.
So I reworked agent-browser, the most popular cli for browser agents, to navigate Steel cloud browser sessions to they can run at scale and unhindered.
It's a relatively crude implementation right now as we just embed agent-browser's binaries directly into the CLI and have a higher-level TS parser to route/modify commands, but it works surprisingly well; the demo video in the link worked first shot, I just copied/pasted for the video.
GitHub Repo: https://github.com/steel-dev/cli/
Would love any feedback or thoughts on what capabilities you'd like to see shipped here!