# Steel

> Steel is an open-source cloud browser infrastructure platform for AI agents. It gives your agent a real browser that can navigate pages, fill forms, solve CAPTCHAs, persist auth, and extract content from modern websites. Steel is the fastest remote browser in independent benchmarks: 0.89s average lifecycle, 1.7x to 9x faster than alternatives.

## Who Steel is for

- **AI agent builders** who need reliable, authenticated web access in production.
- **Scraping and data extraction teams** who want managed browser infrastructure without running headless Chrome themselves.
- **Automation engineers** migrating Playwright, Puppeteer, or Selenium scripts to the cloud.
- **Teams that need persistent browser state**: login sessions, cookies, credentials, and extensions that survive across runs.

## Quick reference

- Install: `npm install steel-sdk` (Node.js) or `pip install steel-sdk` (Python)
- CLI: `curl -sSf https://setup.steel.dev | sh`
- Auth header: `steel-api-key: <your-key>`
- Auth env var: `STEEL_API_KEY`
- API base URL: `https://api.steel.dev`
- WebSocket: `wss://connect.steel.dev?apiKey=<key>&sessionId=<id>`

## For coding agents

- [Install guide](https://setup.steel.dev/install.md): Install the Steel CLI, add the `steel-browser` skill, authenticate, and verify with `steel scrape`.
- [Agent setup prompt](https://steel.dev/agent-prompt): The full instructions for setting Steel up in a project, as plain text.
- [Steel CLI](https://docs.steel.dev/overview/steel-cli): The terminal workflow, `steel browser` commands, and agent skill setup.
- [Steel Skills](https://docs.steel.dev/overview/skills/available-skills): Choose the skill that matches your agent's workflow.
- [Steel Browser skill](https://docs.steel.dev/overview/skills/available-skills/steel-browser): The skill for agents that operate a live Steel browser.

## Why Steel

- **Performance**: 0.89s avg browser lifecycle (p95: 1.09s). 25.6% control-plane tax, the lowest measured in independent testing.
- **Open source**: Core browser runtime at [github.com/steel-dev/steel-browser](https://github.com/steel-dev/steel-browser). Benchmark code at [github.com/steel-dev/browserbench](https://github.com/steel-dev/browserbench).
- **Self-hostable**: Run Steel in your own infrastructure with [Docker](https://docs.steel.dev/overview/self-hosting/docker) or [Railway](https://docs.steel.dev/overview/self-hosting/railway) one-click deploy. No vendor lock-in.
- **Framework agnostic**: Works with Playwright, Puppeteer, and Selenium. Native Node and Python SDKs.
- **Production ready**: Profiles for persistent auth, CAPTCHA solving, stealth/proxy tooling, agent traces, and live session debugging.

## Key features

- Steel runs isolated cloud browser sessions through an API, CLI, and SDKs.
- Steel can return page content as HTML, markdown, screenshots, and PDFs.
- Steel can persist browser state across runs with profiles, cookies, credentials, extensions, and auth context.
- Steel includes anti-bot tooling: proxies, stealth settings, CAPTCHA solving, and mobile-mode browsing.
- Steel includes debugging and observability tools: live sessions, past session embeds, recordings, WebRTC streaming, and agent traces.
- Steel supports cloud, self-hosted, and local runtime workflows.

## SDKs

- [Node SDK](https://github.com/steel-dev/steel-node): `steel-sdk` on npm, for JavaScript and TypeScript projects.
- [Python SDK](https://github.com/steel-dev/steel-python): `steel-sdk` on PyPI, for Python projects.
- [Node SDK blog post](https://steel.dev/blog/steel-node-sdk): Deep dive on the Node SDK.
- [Python SDK blog post](https://steel.dev/blog/steel-python-sdk): Deep dive on the Python SDK.

## Core docs

- [Intro to Steel](https://docs.steel.dev/overview/intro-to-steel): Product overview and why AI agents need browser infrastructure.
- [Sessions API](https://docs.steel.dev/overview/sessions-api/overview): Create and control cloud browser sessions.
- [Profiles API](https://docs.steel.dev/overview/profiles-api/overview): Reuse auth, cookies, extensions, credentials, and browser settings across sessions.
- [Credentials API](https://docs.steel.dev/overview/credentials-api/overview): Store credentials for users or agents.
- [Files API](https://docs.steel.dev/overview/files-api/overview): Upload, download, and manage files during active sessions.
- [Extensions API](https://docs.steel.dev/overview/extensions-api/overview): Add Chrome extensions to browser sessions.
- [CAPTCHAs API](https://docs.steel.dev/overview/captchas-api/overview): Detect and solve CAPTCHAs during browser automations.
- [Browser Tools](https://docs.steel.dev/overview/browser-tools/overview): One-shot endpoints for scraping pages, capturing screenshots, and generating PDFs.
- [Agent Traces](https://docs.steel.dev/overview/agent-traces/overview): Observability for browser agents: what they did, step by step.
- [Human-in-the-loop](https://docs.steel.dev/overview/sessions-api/human-in-the-loop): Let users take control of a running session.
- [Stealth: Proxies](https://docs.steel.dev/overview/stealth/proxies): Configure IP and location-aware browsing.
- [Stealth: CAPTCHA solving](https://docs.steel.dev/overview/stealth/captcha-solving): How Steel handles CAPTCHA workflows.
- [Self-hosting](https://docs.steel.dev/overview/self-hosting/docker): Run Steel Browser in your own infrastructure.
- [Open-source Steel Browser](https://github.com/steel-dev/steel-browser): Self-hosted open-source browser/API runtime.
- [Pricing/Limits](https://docs.steel.dev/overview/pricinglimits): Pricing and usage limits reference.
- [Need Help?](https://docs.steel.dev/overview/need-help): Support, GitHub, Discord, and dashboard links.

## Getting started

- [Sessions API quickstart](https://docs.steel.dev/overview/sessions-api/quickstart): Start your first Steel session.
- [Beginner's Guide to Steel](https://steel.dev/blog/beginner-s-guide-to-steel): End-to-end walkthrough for new users.
- [Happy Path for Automating the Web](https://steel.dev/blog/happy-path-for-automating-the-web-with-steel): Recommended workflow for web automation with Steel.
- [Connect with Playwright](https://docs.steel.dev/cookbook/playwright): Drive Steel sessions from Playwright.
- [Connect with Puppeteer](https://docs.steel.dev/cookbook/puppeteer): Drive Steel sessions from Puppeteer.
- [Connect with Selenium](https://docs.steel.dev/cookbook/selenium): Drive Steel sessions from Selenium.
- [Auth Context Starter](https://docs.steel.dev/cookbook/auth-context-starter): Persist login state for authenticated workflows.
- [Credentials API Starter](https://docs.steel.dev/cookbook/credentials-starter): Bootstrap credential-backed automations.
- [Files API Starter](https://docs.steel.dev/cookbook/files-starter): Handle uploads and downloads in-session.
- [Extensions API Starter](https://docs.steel.dev/cookbook/extensions-starter): Start automations that require browser extensions.
- [Self-Hosting Guide](https://steel.dev/blog/self-hosting-steel-browser): Deploy Steel Browser on your own infrastructure.

## Integrations

- [Claude Code](https://docs.steel.dev/integrations/claude-code): Give Claude Code a Steel browser.
- [Claude Agent SDK](https://docs.steel.dev/integrations/claude-agent-sdk): Build agents on the Claude Agent SDK that browse with Steel.
- [Claude Computer Use](https://docs.steel.dev/integrations/claude-computer-use): Run Claude computer-use workflows on Steel.
- [OpenAI Agents SDK](https://docs.steel.dev/integrations/openai-agents-sdk): Build typed agents on the OpenAI Agents SDK that browse with Steel.
- [OpenAI Computer Use](https://docs.steel.dev/integrations/openai-computer-use): Run OpenAI computer-use agents on Steel browsers.
- [Gemini Computer Use](https://docs.steel.dev/integrations/gemini-computer-use): Run Gemini computer-use workflows on Steel.
- [Browser Use](https://docs.steel.dev/integrations/browser-use): Connect Browser Use to Steel sessions.
- [Stagehand](https://docs.steel.dev/integrations/stagehand): Run natural-language browser automation on Steel.
- [Notte](https://docs.steel.dev/integrations/notte): Run Notte tasks in live cloud browsers.
- [CrewAI](https://docs.steel.dev/integrations/crewai): Build multi-agent workflows that browse the web.
- [Agno](https://docs.steel.dev/integrations/agno): Add Steel browsing to Agno agents.
- [AgentKit](https://docs.steel.dev/integrations/agentkit): Orchestrate agent networks with Steel browsers.
- [Replit](https://docs.steel.dev/integrations/replit): Use Steel from Replit.
- [StackBlitz Bolt.new](https://docs.steel.dev/integrations/stackblitz-bolt.new): Use Steel from Bolt.new.

## Site

- [Pricing](https://steel.dev/pricing.md): Plans, what each includes, and a comparison of them.
- [FAQ](https://steel.dev/faq.md): Answers to common questions about Steel.
- [Blog](https://steel.dev/blog.md): Guides, engineering, comparisons, product news, and company news.
- [Brand kit](https://steel.dev/brand-kit): Steel's logo, colours, and type, to download.
- [Terms of Service](https://steel.dev/terms)
- [Privacy Policy](https://steel.dev/privacy)

## Developer resources

- [Changelog](https://docs.steel.dev/changelog): What has shipped, newest first.
- [Docs home](https://docs.steel.dev): Main documentation site.
- [Docs llms.txt](https://docs.steel.dev/llms.txt): The docs' own index for agents.
- [llms-full.txt](https://docs.steel.dev/llms-full.txt): Flattened docs index for agents.
- [API Reference](https://docs.steel.dev/api-reference): API reference.
- [Dashboard](https://app.steel.dev): Manage API keys, usage, and sessions.
- [GitHub](https://github.com/steel-dev): Open-source repos and examples.
- [Steel Browser (OSS)](https://github.com/steel-dev/steel-browser): Open-source browser runtime and self-hosted API.
- [Benchmark Code](https://github.com/steel-dev/browserbench): Open-source remote browser benchmark.
- [Cookbook](https://github.com/steel-dev/steel-cookbook): Example projects and starters.
- [Discord](https://discord.gg/steel-dev): Community support.
- [Support](mailto:team@steel.dev): Contact Steel support.
- [Legal](https://docs.steel.dev/overview/legal): Legal terms and conditions.

## Pricing

Plans and a full comparison: [Pricing](https://steel.dev/pricing).

- **Launch** ($0 per month + usage): Start for free with $30 of credits, and pay only for what your agents run. Includes $30 of credits, one time. 10 concurrent browser sessions; sessions up to 15 minutes; up to 3 seats; email and community support; no credit card needed.
- **Scale** ($250 per month + usage): Production capacity, stable identity, dedicated support. Includes $100 of credits every month. 100 concurrent browser sessions; sessions up to 1 hour; dedicated IPs at $5 each; dedicated Slack channel; SSO + HIPAA-ready BAA.
- **Enterprise** (Custom per month + usage): Your hardest workloads, with guarantees: custom rates, security and support. Includes custom usage credits. 1,000+ concurrent sessions; stealth browser; reserve browser pools; sessions up to 24 hours; support and uptime SLAs.

### Included usage

| Feature | Launch | Scale | Enterprise |
| - | - | - | - |
| Free usage credits | $30 (one time) | $100 / month | Custom |

### Rates

| Feature | Launch | Scale | Enterprise |
| - | - | - | - |
| Browser hours | $0.10 | $0.08 | Custom |
| Proxy bandwidth | $10/GB | $6/GB | Custom |
| CAPTCHA solves | $3/1k | $1/1k | Custom |
| Browser tools (/scrape) | $5/1k | $5/1k | Custom |

### Features

| Feature | Launch | Scale | Enterprise |
| - | - | - | - |
| Concurrent browser sessions | 10 | 100 | 1,000+ |
| Stealth browser | Not included | Not included | Included |
| Dedicated IPs | Not included | $5/IP | Custom |
| Max session time | 15 minutes | 1 hour | Up to 24 hours |
| Number of seats | Up to 3 | Unlimited | Unlimited |
| Reserve browser pools | Not included | Not included | Included |

### Limits

| Feature | Launch | Scale | Enterprise |
| - | - | - | - |
| Requests per minute | 60 | 600 | Custom |
| Data retention | 7 days | 14 days | Custom |

### Support

| Feature | Launch | Scale | Enterprise |
| - | - | - | - |
| Email support | Included | Included | Included |
| Community support | Included | Included | Included |
| Dedicated Slack channel | Not included | Included | Included |
| 911 email | Not included | Not included | Included |
| Support and uptime SLAs | Not included | Not included | Included |

### Security

| Feature | Launch | Scale | Enterprise |
| - | - | - | - |
| Enterprise SSO | Not included | Included | Included |
| HIPAA-ready BAA | Not included | Included | Included |

## FAQ

### What is Steel and what does it do?

Steel is cloud browser infrastructure for AI agents. It gives agents isolated cloud browser sessions with built-in anti-bot stealth, CAPTCHA solving and session persistence.

### Is Steel open source?

Yes. Steel Browser is the open-source server on GitHub that you can host yourself. Steel Cloud is the managed version, adding scale, stealth, proxies and CAPTCHA solving.

### Is Steel an AI agent or AI infrastructure?

Steel is infrastructure, not an agent. Your agent, built with the OpenAI Agents SDK, LangChain, CrewAI or your own code, connects to Steel, which handles the browser's lifecycle, stealth, session persistence and proxies.

### Can I use Steel with Playwright, Puppeteer or Selenium?

Yes. Steel works with Playwright, Puppeteer, Selenium and its own Node and Python SDKs. You connect over a standard CDP WebSocket URL, so any CDP-compatible tool works out of the box.

### How fast does Steel start a browser session?

Under a second on average, with no cold-start penalty. Each session launches into its own isolated Chromium in the cloud, with its proxy, cookies and storage already set up.

### Can I run headless browsers in the cloud for web scraping?

Yes. Steel runs managed cloud browser sessions for scraping and AI automation, and handles anti-bot stealth, CAPTCHA solving, residential proxies and session persistence in one API, through Playwright, Puppeteer or Selenium.

### Can Steel bypass CAPTCHAs?

Yes, on Steel Cloud. With CAPTCHA solving on, a session detects and solves CAPTCHAs as your agent browses, including Cloudflare Turnstile, PerimeterX press-and-hold and image CAPTCHAs, and the CAPTCHAs API reports each one's progress. Stealth and proxies keep many from appearing at all.

### Does Steel support human-in-the-loop workflows and reusing logins?

Yes. A live session viewer lets people watch or take over running sessions. Persistent browser profiles keep cookies and session tokens, so agents pick up signed-in workflows without logging in again.

### How much does Steel cost, and is there a free tier?

Launch includes $30 free credits, no monthly fee, and usage-based pricing after your one-time credits run out. Scale is $250 per month plus usage, and Enterprise pricing is custom. Steel Browser is free and open source.

## Blog: Build the agent. Don’t build its computer.

https://steel.dev/blog/build-the-agent-not-its-computer · Oct 7, 2026 · By Nikola Balic

> Should you build or buy AI agent infrastructure? Specify the computer your agent needs, test how an agent sandbox recovers, and start managed. Includes a provider map.

**TL;DR:** Teams that build agents should specify the computer the agent needs, test how it recovers, and start with managed infrastructure. Build your own only for a hard requirement no provider meets or an advantage you can name. Agent runs are series systems, so compare providers on recovery and cost per accepted result.

It answers:

- What is an agent's computer?
- Should you build or buy AI agent infrastructure?
- How do you test an agent sandbox provider?
- What is the difference between a sandbox and a persistent computer?
- What is BYOC for agent infrastructure?
- Which sandbox providers should I look at for my agent workload?

![An engineer builds a small robot while distant crews operate the compute infrastructure](https://steel.dev/blog/build-the-agent-not-its-computer/cover.png)

If your team builds agents and has no execution platform that already fits, specify the computer, test how it recovers, and start managed unless owning it makes the agent better.

![You build the agent and specify the computer it runs on](https://steel.dev/blog/build-the-agent-not-its-computer/diagram-1.svg)

You build the agent and specify the computer it runs on

**TL;DR**

- The agent is your product and its computer is infrastructure. Write down what the computer has to do, test whether a provider actually does it, and start with managed infrastructure. Build it yourself only if:
- **You have a hard requirement no provider meets**, or
- **Owning it gives you an advantage you can name.**

As we built internal agents for everything from code review to knowledge management and team communication, we kept running into the same question: where should they run, and how do we manage them at scale?

An agent that works in a demo still needs a computer to keep working. It needs a browser that stays signed in, files that survive until tomorrow, tools, access rules, and a way to continue after something breaks. Teams answer that need in one of three ways:

1. They run the agent on **a laptop or a single server** until the agent outgrows that setup.
2. They **build their own platform** for agent computers.
3. Or they **buy one from a provider** and test that it does the job.

This article argues for the third, with a middle ground for teams that must keep compute inside their own network.

Take a **competitive-intelligence agent**. Every morning it opens ten competitors’ pricing pages, changelogs, and docs. It signs in to the few that sit behind a login, downloads their PDFs, compares everything with yesterday, and posts what changed to Slack. The demo works because the browser is already signed in, the files are on one machine, and someone is watching.

Then it has to run again tomorrow. It needs yesterday’s snapshots to compare against and the same signed-in sessions, and **a saved browser profile does not guarantee a valid login.** When a login expires or a site starts to block it, a person must fix that without throwing away the morning’s work. And it must not post the same change to Slack twice.

You could build that environment yourself. As more agents and users arrive, you would also allocate capacity, keep sessions apart, maintain images, investigate failed starts, and explain which work survived a failure.

**Your team would own a second product:** the service that supplies computers to its agents. Every hour spent on provisioning, isolation, snapshots, scheduling, and recovery is an hour not spent on the agent.

### What we mean by an agent’s computer

An **agent’s computer** is the working environment it can operate: its browser, files, tools, processes, access, and the state its task needs to continue.

![Browser, files, tools, access, and state form the working environment](https://steel.dev/blog/build-the-agent-not-its-computer/diagram-2.svg)

The working environment

To learn how other teams solve these problems, we kept notes on the agents that companies build for their own work. The notes grew into the [Internal Agents Map](https://internal-agents.com/), which we now share as a public catalog. Its [definition of an internal agent](https://internal-agents.com/definitions) explains why the computer matters:

> An internal agent is one that “works with company context and tools to carry out the organization’s own work.”
>
> “A model alone doesn’t know the codebase, follow the processes, or reach the tools. The organization supplies those.”

The computer is where the agent reaches them. For the competitive-intelligence agent, the browser must reach the right pages with the right session. A tool must compare today’s snapshot with yesterday’s. The result must stay available for review with its source attached. The environment connects those steps with the right access.

This environment may span several services, such as sandboxes, browser services, storage, or an existing development platform. It need not be a graphical desktop or a machine that runs forever. A temporary worker is enough if another service preserves the state the next worker needs.

Some workloads benefit from a **persistent computer** rather than a disposable sandbox. In [Fly’s announcement](https://fly.io/news/fly-io-launches-computers-for-agents/), investor Martin Casado of Andreessen Horowitz described Fly as “giving agents real computers instead of disposable sandboxes.”

A persistent computer can make sense **when setup is expensive or a process must keep running between steps.** Preserving more state can save setup time, but the trade-off depends on storage charges, idle billing, wake-up time, and recovery guarantees. A persistent workspace need not bill for compute while it sleeps. The tests later in this article show which one your task needs.

The **harness** is a separate part of the system. It manages model calls and tool execution, and it can run outside the environment where commands execute. Some agents need no dedicated environment because remote tools already provide everything their tasks require. [Shopify describes the same split](https://internal-agents.com/agents/shopify-internal-agents) behind River, its internal Slack agent: a durable identity, a disposable agent loop, and isolated execution, each replaceable on its own.

“The agent needs somewhere to execute code” leaves many questions open. “The agent must continue tomorrow’s comparison under the same user’s access rules” gives the team something to design and test.

### Scaling browsers is scaling computers

A browser session looks like one program. Underneath, it is a computer. In our current fleet, each browser session runs in its own microVM, with its own kernel, memory, network interface, and files. To run more browsers, we run more computers.

**A fleet of browsers needs the same capacity planning, isolation, and scheduling as any fleet of agent computers.** Small settings decide how fast an agent can start work. In our fleet, reducing each browser VM from four virtual CPUs to two improved cold starts under the same host load.

In the last six months, we started three rebuilds of this infrastructure and changed its primitives each time. We stopped one before it reached production. The first version ran on an external vendor’s platform, and it still serves some sessions. **When the vendor had problems, our customers saw failed Steel sessions.** The version we are building now runs on our bare-metal servers, which gives us much more control over the runtime, scheduling, storage, and network path.

Proxies taught us the same lesson from outside our own infrastructure. Customers reported proxy failures inside Steel sessions as Steel outages. Over 30 days, customer-supplied proxies failed to establish a tunnel about 9.0% of the time, and Steel-managed proxies about 0.4%. Those figures cover tunnel setup only. The user did not care which layer failed. They saw a task that stopped.

Reliability engineers call this a **series system**: the whole works only when every part works. An agent run is a long series. Imagine a workflow where each step usually succeeds:

![Illustrative single-attempt success rates for seven steps, from 80 to 99 percent, multiply to a 61.8 percent reliable workflow](https://steel.dev/blog/build-the-agent-not-its-computer/diagram-3.svg)

Illustrative single-attempt success rates for a seven-step workflow

Each step looks fine on its own. In this simplified example, every step must succeed, each gets one attempt, and the outcomes are independent, so the success rates multiply to 61.8%, and 38% of runs fail. Real workflows also have dependencies between steps, retries, and fallbacks, so model those too. Even so, if one layer is misconfigured, slow, or fails in a way that nobody can see, the agent’s user gets a broken product.

**Every layer is a multiplier, and your users get the product of all of them.** When any layer fails, they see a stopped task in your product, even if you bought that layer. Each layer you operate yourself is one more rate your team must keep high. Each layer you buy should show which step failed and let the agent resume from there. A capable provider also brings operating experience from many customers, so check that experience during your evaluation.

In [our proxy investigation](https://steel.dev/blog/developer-tools-come-with-an-assembly-required-sticker), we could check the health of proxies we managed and replace a failing one when changing the IP was safe. With customer-supplied proxies, blind rotation could break a session that depended on its network identity. We began work to make **each error name the active proxy, its owner, and the failure stage**, so a team can see which step in the series failed.

We made this decision ourselves, one layer down. Every agent product sits on a stack: hardware, the runtime that turns hardware into computers, the computer the agent uses, the harness, and the agent itself.

We started by buying the layer below us. We built it when we could name what owning it gives our customers: speed, density, and failure behavior that directly affect the product they use. That is the second reason to build, described later in this article. **For most teams that build agents, that layer is not the product**, and operating it creates a second product they do not need.

### Customize the environment, then choose who operates it

Your team may need a customized environment: exact package versions, a base image with your internal tools, browser profiles that stay signed in, a fixed outbound IP or proxy region, a private connection to an internal service, data that stays in one region, and access limited to one customer’s records. **You decide which requirements are necessary, wherever the environment runs.**

**Operating the service that delivers those requirements is a separate decision.** A provider can start workers and preserve specified state while your team controls the configuration. Your team owns configuration, integration, and the product result. The provider operates the service you contract for, and its experts back you up when something breaks.

![Your team decides agent behavior, environment configuration, and service operation; a provider can operate the service layer](https://steel.dev/blog/build-the-agent-not-its-computer/diagram-4.svg)

The provider operates only the service layer

For the competitive-intelligence agent, the division might look like this:

Division of responsibility

| Responsibility | What your team must decide |
| - | - |
| Agent behavior | Which competitors and pages to watch, what counts as a change, and when to alert |
| Environment configuration | Browser profiles and logins, proxy region, tools, file locations, and retention |
| Service operation | Who supplies capacity, keeps sessions isolated, and restores the saved state |

[WorkOS’s Horizon](https://workos.com/blog/project-horizon) shows this separation. WorkOS needed its complete development stack, programmatic lifecycle control, and explicit outbound network controls. It lacked an existing cloud development platform and considered building one on EC2. The team first used Codespaces for a working prototype, then selected Cloudflare as its requirements became clearer. **WorkOS retained its own orchestration outside the sandboxes.**

A service that gets the prototype running may not provide the control the eventual workload requires. That can justify changing providers without justifying an internal compute platform.

Buying the service leaves your team responsible for the product’s result. You still evaluate the outputs, decide how users access them, and decide which actions need a person’s approval.

### How to test an agent’s computer

Return to tomorrow’s work. Before choosing an environment, identify the state that must survive.

![A run is interrupted; the next run resumes from saved state](https://steel.dev/blog/build-the-agent-not-its-computer/diagram-5.svg)

The next run starts from what was saved

State that must survive

| State | What continuation requires |
| - | - |
| Files | Yesterday’s snapshots, downloads, and completed comparisons remain available |
| Browser identity | The agent can use the correct account, or a person can restore access |
| Running processes | Necessary tools resume, or restart from saved inputs |
| Agent progress | The next run knows what finished and what remains |
| External actions | The application can determine which changes already reached another system |

These states have different lifetimes. Preserving a conversation does not preserve a download. Restoring a disk does not restore a running process. An authenticated browser profile can outlive a worker while its login still expires at the website.

The [hosted sandboxes in OpenAI’s Agents API](https://developers.openai.com/api/docs/guides/agents-api/environments/openai-hosted) show how separate these lifetimes are. Workspace files persist while the sandbox exists; published output artifacts can remain after it expires. Connected sandboxes receive keep-alives between turns. If both activity and keep-alives stop for an hour, the sandbox can be deleted. **Applications must distinguish saved session information from the lifetime of their working files.**

For the competitive-intelligence agent, a temporary worker may be the right choice. It could save the snapshots and verified comparisons, then restart its tools when work resumes. If tool setup is expensive, preserve more process state. The task should determine how much state you pay to retain.

**Human intervention belongs in this test.** Let the login expire halfway through the workflow. Check whether a person can identify the problem, regain access, and return control without restarting the comparison. Decide how agent actions pause while the person acts, including what happens if their connection drops.

[Sentry’s Junior](https://internal-agents.com/agents/sentry-junior) makes this pause part of the network path. Its outbound proxy injects credentials for configured domains, or pauses the agent until a person authorizes access.

Also interrupt an external action. Suppose the agent posts the day’s changes to Slack, but loses the response before it records success. Restarting the computer cannot tell it whether a retry will post a duplicate.

An operation identifier helps only if the receiving system [uses it to deduplicate requests](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/) or lets your application reliably find the original result. Otherwise, the application needs another reconciliation method before retrying. **That remains application work even with reliable compute.**

Access requires the same care. Stephen O’Grady of RedMonk [writes](https://redmonk.com/sogrady/2026/09/16/new-new-kingmakers/) that sandboxes “exist to give the exploding number of agents more autonomy, while not trusting them.”

Isolation keeps the agent away from other workloads. **It does not limit what the credentials inside the sandbox allow.** Define what the task may read and change, then test those limits. Keeping a long-lived token outside the worker reduces one exposure; it does not settle whether an authenticated action is appropriate.

Write the expected results down as a contract. For the competitive-intelligence agent, it could look like this:

Acceptance tests

| Failure to inject | Pass when | Who is responsible |
| - | - | - |
| Replace the worker after some comparisons finish | Saved snapshots and finished comparisons are recoverable, and unfinished work is identifiable | The provider keeps the promised files; your application records progress |
| Expire the login during the run | The agent pauses affected actions, keeps its progress, and resumes after a person signs in again | The provider supports the browser handoff; your application pauses and resumes |
| Lose the response to a Slack post | The application records the outcome as uncertain and reconciles it before a retry | Your application and the receiving system, not the computer |
| Disconnect the person during a handoff | Control does not return to the agent in an unsafe or undefined state | Your application, using the provider’s session controls |

**Keep the first evaluation small.**

1. Run one typical task.
2. Disconnect the client and reconnect.
3. Separately, stop or replace the execution environment in a disposable test.
4. Attempt to continue from the state the service promises to preserve.
5. Record what resumes, what must restart, and what requires a person.
6. Check who has enough information to make each repair.

This is a smoke test. Before production, repeat it with real concurrency, injected failures, and latency distributions. **A clean pause and resume does not prove recovery from an abrupt host failure.**

**Measure time until useful work**, including authentication and tool setup. A fast machine start has limited value if the agent spends its next minute rebuilding the environment. [Stripe avoids most of that rebuild](https://internal-agents.com/agents/stripe-minions) by starting its Minions in pre-warmed devboxes that already hold recent copies of its main repositories. Include retries and review effort when you calculate cost per accepted result.

### When to build your own agent infrastructure

There are two reasons to build the service yourself:

1. A hard requirement that no provider meets, such as a network boundary or a hardware configuration.
2. An advantage in the infrastructure itself, for your product or your economics, that is worth owning.

**Everything else starts managed.** Buy first, learn what your agent needs, and then decide whether to build. Building a platform before you understand the workload is the wrong order. AI coding agents make a platform look quick to build, and **that is the trap**: the code is the small part, and operating it is the second product described at the start of this article.

A requirement about where the computer runs does not always mean you must build the service. Two middle options keep the compute inside your network:

- With **managed BYOC** (bring your own cloud), the provider operates its service inside your cloud account: Northflank can run sandboxes in your account, and Steel can operate its browsers in yours.
- With **self-hosting**, your team operates someone else’s software: Microsandbox is an open-source microVM runtime that you can run on your own hardware, and [Steel’s open-source browser API](https://docs.steel.dev/overview/self-hosting/docker) can be self-hosted.

**Where the compute runs and who operates it are separate questions.** Before you compare these options, specify who owns patching, capacity, backups, recovery, and incident response. Try them before you build the full service.

An existing internal platform is a special case, because you already own it. Compare the work to extend and support it with the integration a provider would require. [Airbnb](https://internal-agents.com/agents/airbnb-airchat) is one example. Its Dev AI team spent months on an internal agent orchestrator that never shipped, then moved to a thin wrapper over vendor coding agents. Those agents run in AirDev, Airbnb’s existing remote development workspaces. **Airbnb bought the agent and kept the computer it already operated.**

[Sierra built the infrastructure for Pinecone](https://sierra.ai/blog/pinecone-harnessing-the-wisdom-of-the-workforce), its internal cloud agent. Different roles needed different combinations of tools, data, and permissions, and Sierra says it **could not find a suitable cloud agent provider** at the time. The same infrastructure also supports Ghostwriter, its customer-facing agent product.

Sierra had both reasons: a requirement no provider met, and a second product that uses the same infrastructure.

“We could build it” is not a reason.

![Three options: buy a managed service, run it in your own cloud through managed BYOC or self-hosting, or build the service yourself](https://steel.dev/blog/build-the-agent-not-its-computer/diagram-6.svg)

Three ways to get an agent computer

**Before taking ownership, name the requirement and the engineer or team responsible for operating the service.** Include maintenance after the original authors move on. At sufficient utilization, the economics may justify that commitment; at low utilization, staffing can dominate the cost.

**Before you sign, ask the provider:**

- where browser profiles, files, logs, and backups live
- who can access them
- who handles upgrades and incidents
- what recovery it promises
- what evidence you get when something fails
- what you can export or delete when you leave

**If you buy, plan your exit.** Keep environment recipes and accepted results in forms you can move. Test what happens to unfinished work when you recreate its environment elsewhere. A different SDK is manageable; discovering that essential state cannot leave is a larger problem.

We build browser infrastructure and list Steel in the map below, so we have a commercial stake in this recommendation. Any service, including ours, should earn its place by meeting your workload’s requirements and reducing what your team has to operate.

### A map of agent sandbox providers

The tests above show that there is no single best provider. **The best one fits your workload**: the agent, the state it must keep, and the result it must deliver. Some providers optimize for inexpensive short-lived execution. Others optimize for persistent workspaces, many parallel sandboxes, development environments, GPUs, or real browsers. The categories below are **starting points, not rankings**, and they overlap.

Where to start, Q4 2026

| If you care most about | Providers to look at | Why |
| - | - | - |
| Low-cost CPU execution in ComputeSDK’s model | Sandbox0, Upstash Box, Isorun | These three are the lowest-cost options in [ComputeSDK’s displayed pricing scenario](https://www.computesdk.com/compare): 60 seconds on an 8 vCPU, 16 GiB sandbox. That is a modeled compute price, not a measured cost to finish your workload. Re-price your own workload before you choose. |
| A general-purpose managed sandbox | E2B, Daytona, Blaxel, Vercel Sandbox, Cloudflare Sandbox, CreateOS | Start here when the agent needs to run code in an isolated Linux environment with a shell, files, processes, networking, and an API-managed lifecycle, and your team does not want to operate the worker fleet. All six appear in [ComputeSDK’s sandbox benchmarks](https://www.computesdk.com/benchmarks/sandboxes). |
| Coding and software-engineering agents | Daytona, Runloop, Namespace, Together Code Sandbox | Look here when the agent clones repositories, installs dependencies, compiles, runs tests, or starts development servers. Together Code Sandbox is built on CodeSandbox’s microVM technology. |
| Long-running or stateful agents | Isorun, Sail, Archil, Sandbox0, Fly Sprites | Evaluate these when work must survive long gaps, setup is too expensive to repeat, or sandboxes must sleep and resume. Check what each one keeps. Isorun and Archil document that files, memory, and running processes survive a pause. By default, a Sandbox0 pause keeps the filesystem but not processes, memory, sockets, or live sessions; a mode that also keeps memory is experimental. Fly Sprites keep their disk while they sleep, and their checkpoints capture the full filesystem; a restore rewinds files but does not resume a paused process. |
| Many parallel sandboxes | Modal, Northflank | Look here when every user, task, rollout, or branch needs its own environment. Modal cites more than 100,000 concurrent sandboxes; Northflank cites more than 10,000 isolated workloads. These are vendor-reported figures, so check your account limits and the resource size behind them. |
| GPUs or compute-heavy work | Modal, Beam, Northflank, Daytona | Start here when the workload needs GPUs for inference, fine-tuning, or other compute-heavy work. Each lets you attach GPUs to a sandbox. Daytona’s GPU sandboxes are ephemeral and use up to 8 GPUs. |
| Control over where the sandbox runs | Northflank, Microsandbox | Consider these when the infrastructure boundary is itself a requirement. Northflank can run sandboxes in your own cloud account. Microsandbox is an open-source microVM runtime that runs locally; its managed cloud is in private beta, and your own cloud or hardware is available on request. |
| Cloud browsers for agents that use real websites | Steel, Browserbase, Kernel | Look here when the agent must use real websites: sign in, keep a session, download files, and get through bot protection. Steel is our product. Its browser API is [open source](https://github.com/steel-dev/steel-browser), so you can read the code and self-host it. Steel also offers managed BYOC, where Steel operates the browsers in your cloud account. Browserbase is a managed service and maintains the open-source Stagehand framework. Kernel is a managed browser service that also publishes open-source browser infrastructure. |

This table is not complete, and it does not replace a test. A provider can look right on a feature page and still have the wrong lifecycle for your task.

Public benchmarks measure narrow things, such as how fast many sandboxes start at once or how long one build takes. None of them tells you whether your agent can continue tomorrow. **Run your own benchmark on your real workload.**

When you have two or three possible providers, run the tests from the previous section. Interrupt a real task and resume it. Check the files, processes, credentials, network access, agent progress, and external actions that matter to the result. Then **compare cost per accepted result, not cost per second of compute**, and buy the least infrastructure that reliably gives the agent the environment its job requires.

### Frequently asked questions

#### What is an agent’s computer?

An agent’s computer is the working environment the agent operates: its browser, files, tools, processes, access, and the state its task needs to continue. It can span several services, such as sandboxes, browser services, and storage. A temporary worker is enough if another service keeps the state the next worker needs.

#### What is an agent sandbox?

An agent sandbox is an isolated environment where an agent runs code, often code that a model wrote, away from other workloads. It covers code execution; the browser, files, and saved state are other parts of an agent’s computer. Isolation does not limit what the credentials inside the sandbox allow, so define what the task may read and change, and test those limits.

#### Should you build or buy AI agent infrastructure?

Most teams should buy it. Start with a managed service, and build your own only when no provider meets a hard requirement, such as a network boundary or a hardware configuration, or when owning the infrastructure gives you an advantage you can name. Building a platform before you understand the workload is the wrong order.

#### What is the difference between a sandbox and a persistent computer?

A persistent computer keeps its state between steps, and a disposable sandbox is thrown away after the work. Persistence makes sense when setup is expensive or a process must keep running. It can save setup time, but compare storage charges, idle billing, wake-up time, and recovery guarantees first.

#### What is BYOC?

BYOC means bring your own cloud. With managed BYOC, the provider operates its service inside your cloud account, so the compute stays in your network and your team does not build the service. Self-hosting is the other middle option: your team runs someone else’s software, such as an open-source microVM runtime.

#### How do you test an agent sandbox provider?

Start with one typical task. Disconnect the client and reconnect it, then stop or replace the environment in a disposable test and try to continue from the state the service promises to keep. Record what resumes, what has to restart, and what needs a person. When you compare providers, use cost per accepted result rather than cost per second of compute.

### For the browser layer

For the browser part of your environment, start with Steel’s examples for [authentication context](https://docs.steel.dev/cookbook/auth-context), [files](https://docs.steel.dev/cookbook/files), and [computer use](https://docs.steel.dev/cookbook/claude-computer-use). Each example covers one capability. Run the acceptance tests above against any browser layer you consider, including ours.

## Blog: Developer tools come with an assembly required sticker

https://steel.dev/blog/developer-tools-come-with-an-assembly-required-sticker · Jul 30, 2026 · By Graham Losee, Michael Spina

> Customer-supplied proxies failed 22x more often than managed ones; the harder problem was explaining that inside our own product.

**TL;DR:** Over 30 days, customer-supplied proxies failed to establish a tunnel about 9% of the time, against 0.4% for Steel-managed proxies: a 22x gap. Steel does not retry customer proxies because it lacks their semantics, so its errors will name the proxy, its owner, the failing stage and a next step.

It answers:

- Why do customer-supplied proxies fail more often than managed proxies?
- Why doesn't Steel retry or rotate customer-supplied proxies?
- What causes a proxy tunnel to fail to establish?
- What should a proxy connection failure error tell the user?

**TL;DR**

- Failures in customer-owned components still feel like product failures.
- Better diagnosis can matter more than automatic recovery.
- Product observability must cover the full assembled system, not just what you operate.

Steel runs browser infrastructure for AI agents. Every session assembles parts from at least two companies: our browsers and network on one side; the customer’s harness, credentials, and sometimes proxies on the other. When the assembled system fails, the error appears on our screen regardless of whose part broke.

This is the story of one error, **“Proxy Connection Failed,”** and an investigation into whose failure it actually was.

We came out with clear data, a partial fix, and questions we still can’t answer. We’re writing it up because every developer tool that requires assembly has a version of this problem, and we’d like to compare notes.

### Investigating the Root Cause of Proxy Connection Failures

Customers kept hitting “Connection Failed” inside Steel sessions. From where they sat, the evidence was damning: a Steel session, a Steel error screen, a dead workload. Tickets treated it as a Steel outage. That was fair. The product gave them no reason to think anything else.

```jsx nocopy
Customer’s agent
      │
      ▼
Steel browser ───► Proxy ───► Target website
     Steel            ?             ?
     owns         customer or
                  Steel-managed
```

We pulled 30 days of tunnel-establishment data across the fleet and all customers.

Customer-supplied proxies failed to establish a tunnel about **9% of the time.** Steel-managed proxies failed about **0.4%** of the time: a **22x gap across thousands of browser workers.**

The cleanest comparison came from customers running both modes against the same targets on the same days. Their proxies failed on nearly every session. Ours failed on essentially none. Inside the failing pools, some IPs were blocked by one or two sites, other pools were blocked across hundreds of domains, and in the clearest cases the proxy couldn’t reach a basic IP-echo endpoint. It was down.

So, mostly, it wasn’t us. Sheesh, crisis mildly averted.

```jsx nocopy
Tunnel-establishment failure rate

Customer-supplied proxies   ██████████████████████  9.0%
Steel-managed proxies       █                       0.4%

                            22× higher
```

### Why Customer-Supplied Proxies Are Difficult to Diagnose

A customer hands us a proxy as a URL: scheme, host, port, credentials. The URL doesn’t say whether it points at a rotating residential network, a fixed datacenter server, or a sticky session whose exit IP has to survive for the workload to make sense.

The failure says little more. A tunnel that never establishes could mean rejected credentials, an unreachable host, or an upstream that dropped the CONNECT. A tunnel that dies mid-session could mean rotation, rate limits, or a destination blocking the exit IP.

We sit in the middle of that connection and often can’t tell these cases apart. The customer, one layer further out, has even less to go on. Both sides end up staring at the same screen holding the same incomplete signal.

### Why Managed and Customer-Supplied Proxies Behave Differently

Steel-managed proxies get a resilience layer: we health-check endpoints, track pool quality, swap bad proxies, and retry, because we know what each proxy URL represents and when a new IP is safe.

Customer-supplied proxies get none of that. The first failed connection kills the session.

We still think that asymmetry is the right call. Blind rotation of a proxy we don’t understand could be useless (rotating within a dead pool), expensive (burning the customer’s metered bandwidth), or destructive (breaking a sticky session the workload depends on). Retrying safely requires semantics we don’t have.

The trouble is what this reasonable decision produces: a customer with a bad proxy gets a generic failure inside our product, with no pointer toward their own infrastructure. Their vendor flaked; we returned the confusion.

### Better Error Attribution Is a Product Responsibility

We already had every fact the investigation needed: which proxy was active, who supplied it, where the tunnel died. Once we knew to look, the analysis was easy.

Knowing to look was the problem. Nothing in our monitoring flagged these failures; a customer had to report them. The customer took just as long to notice. The failures dissolved into the volume of sessions they were running.

The facts existed the whole time. Neither side’s tooling surfaced them. We’re changing the failure path so they show up where the failure does: the error names the active proxy and its owner, the failing stage when it’s distinguishable, and a concrete next step. When the CONNECT gets a 407, the error should say “the proxy rejected your credentials” and point at the provider.

The principle underneath: we can’t always recover from a failure in a component we don’t run, but we can always describe it.

![](https://steel.dev/assets/framerusercontent.com/images/F7YNv62mqhBf4IRuCprut8XgA.png)

### Open Questions About Monitoring Customer-Owned Infrastructure

This is where a blog post would usually present the solution. Instead, here are the questions we’re stuck on. They sound proxy-shaped because proxies are where we got burned this time, but each one applies to any component a customer brings, including ones that don’t look like components until they fail.

##### **1. How do you notice a failure in a component you don’t run?**

Our trigger was a customer report, and it arrived late; an elevated failure rate reads as noise while the successes keep coming. A proxy-health baseline would have caught this one, but only because we now know proxies are worth watching. The next weak component won’t announce itself.

##### **2. Should a vendor actively test the parts customers bring?**

A health check from our fleet would let us say “your proxy is down” before a workload dies. It would also spend the customer’s metered bandwidth, hit their provider’s rate limits, and exercise their credentials outside any session they started. The same tension applies to testing a customer’s harness or their LLM provider. We haven’t found where that line is.

##### **3. Should customers describe the parts they bring?**

A declared semantic like rotating, static, or sticky would tell us which proxy retries are safe. Generalized, that means asking customers to document a contract for every component they plug in: more configuration burden, and a wrong declaration produces worse behavior than none.

**Where does attribution actually change behavior?** We can name the failing component on the error screen, in the API response, in a webhook, or on the dashboard. We don’t yet know which surface makes a customer check their own infrastructure instead of filing a ticket with us.

### The Reliability Blind Spot in Composable Developer Tools

The uncomfortable part of the data wasn’t the 22x gap. It was that our dashboards looked healthy the whole time: sessions starting, traffic flowing, and 9% of customer proxy tunnels quietly dying underneath. **Usage looked like success and wasn’t.**

This time the weak part was proxies. Next time it could be the harness, the LLM driving it, or the router a cleaning crew unplugged at the customer’s office. Any developer tool that requires assembly has this blind spot somewhere: a component the vendor doesn’t run, failing inside an experience the vendor owns.

If you’ve drawn this responsibility line in your own product, especially if you’ve decided whether to probe infrastructure your customers bring, we’d like to hear how you did it.

And if enough of us are traumatised with the same thing, we’ll open a #couch-support channel in the Steel Discord and work through it together.

## Blog: Steel now ships as a browser plugin for Hermes Agent

https://steel.dev/blog/hermes-steel-plugin · Jul 22, 2026 · By Nikola Balic

> Give Hermes Agent a Steel cloud browser in two commands, with live session viewing, page extraction, and per-site proxy and CAPTCHA controls built in.

**TL;DR:** A standalone plugin for Hermes 0.18.0 and newer routes Hermes Agent's existing browser tools through a Steel cloud browser over CDP. Two commands install it; it returns a live session URL, adds steel_scrape for one-shot page extraction, and lets Hermes turn on residential proxies or CAPTCHA solving. Sessions cap at 30 minutes.

It answers:

- How do I use Steel as the browser for Hermes Agent?
- Which Hermes version does the Steel plugin need?
- How does the Hermes Steel plugin connect Hermes to a browser?
- Can Hermes use residential proxies and CAPTCHA solving through Steel?
- Does the Hermes Steel plugin work with self-hosted Steel?

[Hermes](https://github.com/NousResearch/hermes-agent), Nous Research's open-source personal AI agent, can now run web tasks through Steel browser. The standalone plugin routes Hermes' existing browser tools through a cloud browser and adds live session viewing and page extraction. Hermes can take on trickier parts of the web, while you watch what it sees.

Back in April, [we wired Steel into Hermes and sent it through Google Travel and Booking.com](https://steel.dev/blog/steel-is-now-a-native-browser-provider-in-hermes). Hermes found a hotel, gave us a live view of the session, and built a skill from the run. Trying it yourself meant running our Hermes branch.

Hermes now has a plugin interface for browser providers. We moved the integration into its own repo and released it for Hermes 0.18.0 and newer.

You need:

- Hermes 0.18.0 or newer
- A [Steel API key](https://app.steel.dev/settings/api-keys). The free plan is enough to start.

```sh
hermes plugins install steel-dev/hermes-steel --enable
hermes config set browser.cloud_provider steel
```

The installer asks for your API key. The config command selects Steel; without it, Hermes keeps using local Chromium.

Then give Hermes a task:

```js nocopy
Navigate to news.ycombinator.com, summarize the front page, and give me the live session URL.
```

The first browser result includes a link like `https://app.steel.dev/sessions/<id>`. Open it and you can see the page the agent sees, which is usually where the answer is when a run gets weird.

### How Hermes browser calls reach Steel

Instead of teaching Hermes a second browser toolset, the plugin swaps the provider beneath the tools it already knows.

On the first browser call, `SteelBrowserProvider` creates a Steel session and returns its [Chrome DevTools Protocol (CDP)](https://chromedevtools.github.io/devtools-protocol/) WebSocket URL. Hermes' existing browser stack connects to that URL, so `browser_navigate`, `browser_click`, `browser_screenshot`, and the rest of the agent loop do not need Steel-specific versions.

The result hook adds the backend name and live-viewer URL to the first successful browser response. Hermes can pass both back to you instead of making you dig through logs or the Steel dashboard.

### Read a page without opening a browser

Not every page needs a browser. `steel_scrape` calls Steel's scrape API directly and returns markdown, HTML, readability output, or cleaned HTML. It avoids starting a browser when Hermes only needs to read.

Anything that clicks, types, or submits still uses the browser tools. `steel_scrape` is for one-shot extraction, such as reading a list of documentation pages before Hermes writes a summary.

### Session options and timeouts

For interactive pages, Hermes stays in the browser. If a site blocks the session or asks for verification, Hermes can call `steel_session_options`, enable a residential proxy or CAPTCHA solving, and try again. These options are set when the browser starts, so changing either one closes the current session and the next browser call creates a new one.

Sessions get a 30-minute cap by default. A separate 10-minute inactivity timeout catches sessions left behind when a Hermes process disappears.

### Why it lives in its own repo

We took two runs at adding Steel to Hermes itself. [PR #5555](https://github.com/NousResearch/hermes-agent/pull/5555) proved out the provider. By [PR #21182](https://github.com/NousResearch/hermes-agent/pull/21182), Hermes had a proper interface for browser-provider plugins, so we rebuilt on that.

We moved the code into its own repo and cut [v1.0.0](https://github.com/steel-dev/hermes-steel/releases/tag/v1.0.0) against that interface.

The separate package now tests against Hermes' real plugin loader and the live Steel API without adding Steel-specific code to their repo.

### A few edges

Residential proxies and CAPTCHA solving are off by default. They require a verified Steel Launch account: [add at least $10 in paid balance](https://app.steel.dev/settings/billing) to verify the account, and that balance goes toward usage. If either feature is unavailable, the session still starts and Hermes tells you what was dropped.

The plugin also supports self-hosted Steel through `STEEL_BASE_URL`. An API key is optional for a custom endpoint, and the plugin sends no credentials when one is not configured.

### Try it

Install the [Steel plugin for Hermes](https://github.com/steel-dev/hermes-steel) and run the example above.

Humans use Chrome. Agents use Steel.

## Blog: Steel Browser is live in Stripe Projects

https://steel.dev/blog/steel-browser-is-live-in-stripe-projects · Jul 15, 2026 · By Nikola Balic

> Steel Browser is live in Stripe Projects, giving agents on-demand cloud browser sessions for live web work.

**TL;DR:** Steel joins the Stripe Projects developer preview as a co-design and launch partner. Running stripe projects add steel/browser creates a Steel org, project and scoped API key in .env, giving agents cloud browser sessions with live view and recordings, billed through Stripe Projects. Free pay-as-you-go and paid plans exist.

It answers:

- How do I add Steel to a Stripe project?
- What does stripe projects add steel/browser create?
- How is Steel billed through Stripe Projects?
- What can agents do with Steel browser sessions in Stripe Projects?

Today, Steel joins the [Stripe Projects](https://projects.dev/) developer preview as a co-design and launch partner.

If you haven't used Stripe Projects yet, it provisions the services your app needs, things like databases, auth, hosting, and analytics, from the terminal or your coding agent. One command creates the account, provisions the resource, and syncs the credentials to your environment: no signing up for each service by hand, no copy-pasting keys between dashboards. Your whole stack comes from one place, and every account and resource stays in an account you own.

Steel is the piece that reaches past those services to the rest of the web.

Run `stripe projects add steel/browser` and your projects get cloud browser sessions for the live web. Start one session or run many in parallel.

The command creates a Steel project, writes Steel API key, and gives your agents browser sessions they can use for real web work: login flows, site verification, vendor workflows with no API, and runs you need to inspect when they break.

The hard part is giving agents the things they need around the code: credentials, state, a browser session, and evidence when something goes wrong.

That is what Steel adds.

> "Agents are becoming the newest and soon-to-be biggest users of the web. We'll be able to delegate any task that we can do online to our agents so we can focus on the biggest needle movers. With Steel in Stripe Projects, agents can get access to browser environments as a true utility to work, research, and purchase for us without a human in the loop."
>
> Hussien Hussien, CEO & co-founder, Steel

![Run stripe projects add steel/browser and your projects get cloud browser sessions for the live web. ](https://steel.dev/assets/framerusercontent.com/images/VKQOnII1FehcHnnbmSLZaJNUrY.png)

### Steel Browser in Stripe Projects

We built the Steel provider integration for the Agentic Provisioning Protocol, so an agent can provision cloud browser sessions the same deterministic way it provisions a database or an auth service.

```md
# 0. install the Stripe CLI
https://docs.stripe.com/stripe-cli/install

# 1. scaffold your project
stripe projects init my-app

# 2. add Steel
stripe projects add steel/browser
```

The credentials point at a Steel org that's yours: your sessions and API keys live in your own Steel account, billed through the payment method you authorized in Stripe Projects.

> "Agents need deterministic setup as much as deterministic execution. In Stripe Projects, adding Steel creates the org, project, scoped key, and dashboard handoff in one path, so browser sessions are provisioned like infrastructure, not handled as a manual setup step."
>
> Nasr Mohamed, CTO & co-founder, Steel

### How Stripe Projects provisions Steel browser sessions

Two handoffs happen.

**First:** Stripe Projects gives your app a Steel key and writes it into `.env`.

**Second:** Steel gives the run a browser session with memory: a session that can stay logged in, a live view while it runs, and a recording when it breaks. Your agent can run one session or many in parallel when the job needs more than one browser. For login-walled sites, Steel's Credentials API can inject secrets into the session while keeping them out of the model's context and off the live viewer.

With Steel you can watch the click, the page, the pause, and the exact place where the web pushed back.

### Agent workflows that need a real browser

Steel is useful when the work has to happen inside a website.

Think vendor portals, invoices behind dashboards, login flows with site verification steps, and internal tools that were never built for agents.

In those cases, the browser is the integration.

### Steel is the open browser you actually own

Steel is built on ownership, transparency, and openness: an Apache-2.0 runtime you can inspect and self-host, with your sessions, profiles, and credentials living in an account you control.

### Add Steel Browser to a Stripe project

Steel is in the Stripe Projects developer preview on a free pay-as-you-go plan and a paid plan for higher limits. See [pricing and limits](https://docs.steel.dev/overview/pricinglimits) for current rates, or follow the [Stripe Projects setup guide](https://docs.steel.dev/overview/stripe-projects) for provisioning, credentials, and SDK usage.

Now your agents can reach the rest of the web, one command inside Stripe Projects.

```md
stripe projects add steel/browser
```

## Blog: Launch Week v3: everything we shipped

https://steel.dev/blog/launch-week-v3-recap · Jun 29, 2026 · By Nikola Balic

> Launch Week v3 recap: Stealth Browser, Dedicated IPs, native Rust and Go SDKs, Atlas, and pricing updates for production agent workloads running on Steel.

**TL;DR:** Steel Launch Week v3 shipped Stealth Browser (a Chromium fork for agents), Dedicated IPs at $5 per IP per month on Scale, native Rust and Go SDKs, the open-source Atlas deep research harness, and new pricing with Launch, Scale and Enterprise plans. Signups rose 26% and sessions 18%.

It answers:

- What did Steel ship in Launch Week v3?
- How much do Steel Dedicated IPs cost?
- Which languages have native Steel SDKs?
- What is Atlas from Steel?
- What are Steel's pricing plans?

Launch Week v3 is done. Five days, five releases.

Shipping all of it on a tight, self-imposed schedule was not easy. We loved it anyway. By the looks of it, you did too: signups rose 26%, sessions rose 18%, and resurrected organizations rose 28%. Thank you for making our calendar look slightly less unreasonable.

Agents are workloads now. A demo succeeds once. A workload has to succeed on Monday and again on Tuesday, with the same identity, inside the same budget. You see what it spent.

This week shipped those parts.

### Stealth Browser, a Chromium built for agents

On Day 1, we shipped [Stealth Browser](https://steel.dev/blog/stealth-browser), our fork of Chromium for agents that run the web, not just click through it. The profile loads inside the browser process at startup, before page JavaScript reads navigator, screen, WebGL, fonts, and the rest.

It also cuts stock-Chromium code a headless agent never touches. Available now for enterprise customers on request.

[Video on YouTube](https://www.youtube.com/watch?v=7EjchdTlG0Q)

### Dedicated IPs, a fixed home for browser agents

On Day 2, we launched [Dedicated IPs](https://steel.dev/blog/dedicated-ips), a stable network origin for production agents. Lease a stable IP, attach it to a profile, and let the agent return as the same signed-in visitor every run.

They are self-serve on Scale at $5 per IP per month, with custom Enterprise pricing. Reserve up to 25. Pin one to a session, or let Steel write one from your pool to the profile.

[Video on YouTube](https://www.youtube.com/watch?v=mOF1NADON_U)

### Rust and Go SDKs, native clients in four languages

On Day 3, we added [native Rust and Go SDKs](https://steel.dev/blog/rust-go-sdks), so you can drive Steel from the stack your agents already run in. Steel now has native clients alongside TypeScript and Python.

The session flow stays the same: create a session, set profile and proxy options, hand the WebSocket URL to your CDP tool, then release the session from that client. Rust is async-first. Go is context-first.

[Video on YouTube](https://www.youtube.com/watch?v=cZjEM5PFXJs)

### Atlas, a deep research harness you can own

On Day 4, we open-sourced [Atlas](https://steel.dev/blog/atlas-sdk), a deep research harness (`@steel-dev/atlas`) with your models, sources, and domain tools. It runs a research loop, not a single prompt: plan, gather evidence, synthesize, audit, patch gaps, then ground citations.

The ledger sits outside the model's context window. Atlas can use Steel for JS-rendered or login-gated pages. EDGAR, PubMed, arXiv, or internal docs can come in through `researchTool`.

Find Atlas on [GitHub](https://github.com/steel-dev/atlas).

[Video on YouTube](https://www.youtube.com/watch?v=8HzzKsAVrWI)

### Simpler pricing, built for how agents run

On Day 5, we [rebuilt pricing](https://steel.dev/blog/pricing-update) for how agents actually run, with metered rates and visible usage. The three plans are Launch ($0 + usage), Scale ($250 + usage), and Enterprise (custom). Launch includes a one-time $30 usage credit. Scale includes $100 each month.

The dashboard shows spend by meter. Existing customers can keep their legacy plan.

[Video on YouTube](https://www.youtube.com/watch?v=47-aqXBpRTA)

### What it adds up to

Together they are what an agent needs after the demo: a place to run that does not drift, the same identity each time, a stack you build in, output you check, and cost you can see before the bill lands.

That is the week. Agents run like workloads now, and the way you pay for them matches.

### What's next

We are already working on the next set of improvements for agents. If there is a feature, workflow, or rough edge you want us to prioritize, send it our way.

Join us in [Discord](https://discord.gg/steel-dev), tag us on X [@steeldotdev](https://twitter.com/steeldotdev), or reply with the feature request you want Steel to build next.

→ [**Start a project**](https://app.steel.dev/)

See the full week at [steel.dev/launch-week](https://steel.dev/launch-week).

## Blog: Simpler pricing, built for how agents run

https://steel.dev/blog/pricing-update · Jun 26, 2026 · By Hussien Hussien

> Steel pricing now has Launch, Scale, and Enterprise plans with metered browser rates, usage credits, visible usage, and plan limits for agent workloads.

**TL;DR:** Steel pricing now has three plans on one metering model: Launch ($0 plus usage, a one-time $30 credit), Scale ($250 plus usage, $100 credit each month, 100 concurrent sessions) and custom Enterprise. CAPTCHA solving unlocks on Launch with a $10 deposit. A dashboard shows spend by meter.

It answers:

- What are Steel's pricing plans and what do they cost?
- What are the limits on Steel's Launch, Scale and Enterprise plans?
- How do I get CAPTCHA solving on Steel without a subscription?
- What usage credit do Steel plans include?
- Do existing Steel customers have to move to the new pricing?
- What does Steel meter and charge for?

> Launch Week v3 -> Day 05 / 05

Today we're launching simpler pricing: three plans on one metering model, rates you can read before an agent runs, and a dashboard that shows where every dollar goes.

It's the biggest change to how Steel is priced since we started.

The old pricing got in the way of the one thing agents are for: doing the work. Anti-bot, the part that makes Steel useful, was locked behind a monthly subscription. So the builder pointing an agent at a task couldn't watch it work before paying for it. And the fixed bundles underneath never matched how agents run, with usage that spikes one week and goes quiet the next.

Here's the moment it used to break. You send an agent to do a job for you, and partway through it hits a CAPTCHA. On the old plan, solving it meant upgrading before you'd seen the workflow run, so you closed the tab. Now Launch gives you `$30` in credits to try Steel without a subscription. If your agent needs CAPTCHA solving, you unlock it with a `$10` deposit, and your credits cover the work. You prove Steel works on your hardest use case before committing.

One customer put it plainly: "I didn't want another subscription. I just want to pay for what I use." This is us agreeing.

So we rebuilt it.

You pay for what you run.

Pricing closes Launch Week v3. After [Stealth Browser](https://steel.dev/blog/stealth-browser) for runtime, [Dedicated IPs](https://steel.dev/blog/dedicated-ips) for identity, [Rust and Go SDKs](https://steel.dev/blog/rust-go-sdks) for backend services, and [Atlas](https://steel.dev/blog/atlas-sdk) for deep research. Pricing has to keep up.

### The new pricing model

The base meters (browser hours, proxy bandwidth, CAPTCHA solves, and `/scrape`) are all on the [pricing page](https://steel.dev/pricing).

![](https://steel.dev/assets/framerusercontent.com/images/jurDil3Zfhwo7G9dygDnEmxyQZM.png)

The limits are visible: Launch starts with 10 concurrent browser sessions, 15-minute max sessions, up to 3 seats, 60 requests per minute, and 7-day data retention. Scale moves to 100 concurrent sessions, 1-hour sessions, unlimited seats, 600 requests per minute, 14-day retention, dedicated support, Enterprise SSO, and Dedicated IPs at `$5 / IP`. Enterprise is custom, with 1,000+ concurrent sessions, sessions up to 24 hours, reserved browser pools, Stealth Browser, custom Dedicated IP pricing, and support and uptime SLAs.

### Usage credit is explicit

Launch includes a one-time `$30` usage credit, valid for 90 days. Scale includes `$100` in usage credit each month. Enterprise is custom.

You see the credit up front, then monitor it. Browser hours and proxy bandwidth each show up as their own meter.

### A real usage dashboard

When the spend is real, you want to see it. The dashboard breaks it down by meter: session time, proxy bandwidth, CAPTCHA solves, and your remaining balance. No waiting for an invoice to find out where the money went. Top up credits, or turn on auto top-up so a run never stalls for lack of balance.

[Video](https://steel.dev/assets/framerusercontent.com/images/N8kQIbeBRSKUAOYS6nz9fg898.mp4)

### Why we priced it this way

We matched the model to how AI builders buy infrastructure: start on usage, watch what you spend, then move up when the workload needs it.

Scale's **$250** buys capacity. CAPTCHA solves, proxy bandwidth, and browser hours all cost less on Scale. It gets you 100 concurrent sessions, hour-long sessions, Dedicated IPs, Enterprise SSO, and dedicated support. It fills the gap teams used to fall into: past the entry limits, not ready for a custom contract. Enterprise covers high-volume and regulated workloads that need custom limits, Stealth Browser, reserved pools, and SLAs.

We win on being open source, on showing you the bill, and on the hard problems (anti-bot, proxies, CAPTCHA) that we actually solve. And when something breaks, we answer.

### If you're already a customer

No forced migration. Existing Starter, Developer, and Startups customers see their legacy plan in the dashboard and can switch when they choose.

### Get started

- [Pricing and limits](https://docs.steel.dev/overview/pricinglimits)
- [Dashboard](https://app.steel.dev/)

Questions? [Discord](https://discord.gg/steel-dev) or [@steeldotdev](https://twitter.com/steeldotdev).

> This post is Day 5 of Steel Launch Week v3. See the full week at [steel.dev/launch-week](https://steel.dev/blog/launch-week-v3-recap).

[Video on YouTube](https://www.youtube.com/watch?v=47-aqXBpRTA)

## Blog: Atlas: a deep research harness you can own

https://steel.dev/blog/atlas-sdk · Jun 25, 2026 · By JunHyoung Ryu

> Atlas is an open-source deep research harness that turns web evidence into cited reports, with a ledger for coverage, audit, and citation grounding.

**TL;DR:** Atlas is an open-source deep research harness (npm install @steel-dev/atlas) that turns a question into a cited report through a ledger of slots: plan, gather, synthesize, audit, patch and ground citations. On Perplexity's DRACO benchmark it scores level with Perplexity Sonar on GPT-5.5 and near Exa on Opus 4.8.

It answers:

- What is Atlas by Steel?
- How does Atlas ground citations in deep research reports?
- How does Atlas score on the DRACO benchmark?
- How do I add a custom domain source like PubMed to Atlas?
- How do I install the Atlas deep research SDK?
- How much does an Atlas research run cost?

> Launch Week v3 -> Day 04 / 05

[Atlas](https://github.com/steel-dev/atlas) is an open-source deep research harness you can run, fork, and bend around your own domain. It gives you the loop in one SDK: ask a question, gather evidence across the open web, and get back a cited report. Before it lands, Atlas checks the draft against the ledger and grounds the citations.

The job is simple: stop every team from rebuilding the same brittle research loop, while leaving the knobs exposed. Swap models, search providers, browser fetches, and domain sources.

This is the next step in Launch Week v3: [Stealth Browser](https://steel.dev/blog/stealth-browser) for the browser runtime, [Dedicated IPs](https://steel.dev/blog/dedicated-ips) for stable network identity, [Rust and Go SDKs](https://steel.dev/blog/rust-go-sdks) for the services doing the work, and Atlas for the research layer.

Install it:

```sh
npm install @steel-dev/atlas
```

Then bring your model provider, wire in search or browser fetches, and start shaping the loop around your domain.

![](https://steel.dev/assets/framerusercontent.com/images/tdyEZ4Ks5MDtnbdoNvUliqi0RE.png)

### Why deep research is hard to build

A lot of teams are putting deep research agents inside their products. Some already use Steel for the browser side. The painful part is everything around it: planning the search, keeping sources straight, tracking what’s still unanswered, and staying inside a budget.

The common failure is quieter than a fake source. A long run reads a pile of pages, the early evidence gets summarized away, the writer drops a real fact it found twenty turns ago, and the final report looks clean while quietly missing the thing you asked for. Atlas is built around that failure.

### How Atlas works

A single run is a loop built around a ledger.

The ledger is a coverage contract. Atlas breaks the question into slots: the things the answer has to cover. A slot pairs a question with its eventual grounded finding. Atlas strips numeric literals out of slot phrasing, so the planner has to earn the answer from evidence. As evidence arrives, each slot becomes grounded, computed from other slots, or marked exhausted with a reason.

The run moves through the ledger like this:

- **Plan.** Seed the ledger with slots from the question.
- **Gather.** A research agent searches, fetches, and reads, closing slots as it lands grounded answers.
- **Synthesize.** Write the full report from what’s been gathered.
- **Audit.** Walk the draft back against the ledger and find the gaps: open slots, facts the writer gathered then dropped.
- **Patch and reconcile.** Fetch what’s missing, fill the gaps, then a final pass using only sources already in the store.
- **Ground.** Renumber every citation, validate that each `[n]` points at a real fetched source, and surface any sentence whose citation doesn’t hold up.

The audit step is where the ledger pays for itself. Atlas checks the finished draft against what it meant to answer, then catches dropped facts, unanswered slots, and citations that point nowhere. Because grounding happens last, the result includes `result.unsupportedSentences`: the sentences whose citations did not survive.

### How it scores on DRACO

DRACO is Perplexity's open deep research benchmark: 100 real-world tasks across 10 domains, each graded against \~39 weighted criteria where wrong answers count against you. We ran a simple setup of Atlas on it next to the commercial agents.

![](https://steel.dev/assets/framerusercontent.com/images/PoqTzghGLRsxuEm2Bl3OwDVcdr0.png)

The band is tight. Atlas on GPT-5.5 lands level with Perplexity Sonar, a hair above on Perplexity's own benchmark, and at lower cost. Atlas on Opus 4.8 sits next to Exa. Nobody runs away with it.

That is the point: an open harness you can fork and aim at your own sources scores in the same range as the closed products, not a tier below them.

### Watch one run

Here’s a real run: Claude Opus 4.8 at `balanced` effort, reading a single SEC filing. The question asks Atlas to analyze a margin shift and adjust it for a one-time relocation loss:

> Analyze how Rubber Leaf’s strategic shift from direct to indirect supply models has affected underlying profitability by examining gross margin performance across Q1 2023 and Q1 2024 \[…] then determine what Rubber Leaf’s Q1 2024 gross margin would be when excluding the factory relocation loss from total cost of sales.

Atlas turned that into a 15-slot ledger. A sample:

| ask | shape | importance |
| - | - | - |
| Year-over-year change in gross margin from Q1 2023 to Q1 2024 (in percentage points) | `value` | central |
| Rubber Leaf’s adjusted Q1 2024 gross margin excluding the factory relocation loss | `value` | central |
| How the indirect supply model alters cost structure and margin economics versus the direct model | `causal` | central |
| Verdict on whether margin pressure is driven by fundamental challenges in the indirect model or by temporary relocation costs | `verdict` | central |
| Other one-time or non-recurring items affecting Q1 2024 cost of sales beyond the relocation loss | `split` | peripheral |

The asks avoid guessing the values. They name what Atlas has to establish. Each one closes as **grounded** with a value, quote, and source, or **computed** with `run_code` or synthesis across sources.

The report starts with the computed result: gross margin fell from **+2.86%** to **-6.65%**, a 9.52-point drop. Stripping out the **$190,703** one-time relocation loss lifts it only to **-0.20%**. The more interesting part is what the run caught on the way:

> the 10-Q’s MD\&A “Gross profit margin” table states Total margins of 7% (2024) and 3% (2023) \[…] Those stated percentages do not reconcile with the negative gross profit reported on the company’s own income statement and appear to be a misstatement; the analysis below uses the gross profit and revenue figures from the consolidated statement of operations.

Atlas caught the contradiction in the filing and recomputed from the primary statements.

The whole run took about four minutes, and **zero** sentences failed citation grounding:

| phase | time |
| - | - |
| seed (ledger) | 9.8s |
| gather | 89s |
| synthesize | 44s |
| coverage audit | 5.8s |
| patch | 24s |
| reconcile | 16s |

Three pages fetched, one cited, the filing itself.

### Orchestrate researchers

By default, a run follows one spine. When a question needs more than one angle, you can register multiple researchers. Atlas decomposes the question, routes each sub-task to the best-fit worker (`query → report`), runs them in isolation, then synthesizes one cited report.

```ts
import { Atlas, exa, perplexity, parallel } from "@steel-dev/atlas";
import { anthropic } from "@ai-sdk/anthropic";

const atlas = new Atlas({
  model: anthropic("claude-fable-5"),
  researchers: {
    exa: exa.agent(),
    perplexity: perplexity.agent(),
    parallel: parallel.agent(),
  },
});

await atlas.research("Compare X across academic and shopping angles");
```

Any `query → report` worker plugs in: Exa deep research, Perplexity Sonar, parallel.ai, or your own. `atlas.asResearcher(describe)` exposes an Atlas instance as a worker, so fan-out can recurse. Omit `researchers` and Atlas stays on the single-spine path.

### Uses Steel for browser fetches

Atlas can use Steel for browser fetches, so the loop reaches pages a basic fetch misses: JavaScript-rendered sites, sessions that need login state, pages that need a real browser to stay alive long enough to be useful.

Atlas can start with direct extraction and fall back to a Steel browser scrape when the page needs it. Search can come from Exa, Tavily, Brave, or the model provider’s own web search, so a run can use more than one source path.

![](https://steel.dev/assets/framerusercontent.com/images/vCdZ9GCmgYX2WRLKFTGvtSqG6I.png)

### The parts builders ask about

A single `model` runs everything. If you want more control, override `research` and `write`; unset roles fall back to the lead model.

```ts
import { Atlas, exa, steel, basic } from "@steel-dev/atlas";
import { anthropic } from "@ai-sdk/anthropic";
import { openai } from "@ai-sdk/openai";

const atlas = new Atlas({
  model: anthropic("claude-fable-5"),
  models: { research: openai("gpt-5-mini") },
  search: exa.search(),
  fetch: [basic.fetch(), steel.fetch({ proxy: true })],
});
```

Every model goes through the same wrapper: budget accounting, retries, caching, tracing, and the provider quirks that would otherwise leak into your code.

**It keeps a trail.** Atlas records searches and dead-end fetches so a later step can pick a new angle after a query goes nowhere. The trail is a plain record of what already wasted time.

**It streams.** Start a run and subscribe to events: `report.delta` carries the draft as it’s written, `report.reset` precedes each rewrite, `source.fetched` fires as pages come in. Await the final result when you want it.

```ts
const run = atlas.start(question, { effort: "balanced" });

for await (const e of run.events()) {
  if (e.type === "report.reset") preview = "";
  if (e.type === "report.delta") preview += e.text;
}

const result = await run.result();
```

**It resumes.** Journaled runs replay completed model, search, and fetch calls at no cost after a crash or deploy.

**It returns structured output.** Pass a `schema` and Atlas runs a final extraction pass over the finished report. You get a typed object alongside the markdown, on the single-spine path or the orchestrated path.

```ts
import { z } from "zod";

const r = await atlas.research("Acme's latest annual revenue and CEO?", {
  schema: z.object({ revenue: z.string(), ceo: z.string() }),
});

r.object;
r.report;
```

### Safety

Atlas treats untrusted web content as data. Fetches pass SSRF guards. `run_code` runs in a memory-capped V8 isolate with no network, filesystem, or host access. Direct fetch honors robots.txt. Treat the SSRF guard as defense-in-depth; for hostile targets, run behind network-level egress controls. The [README](https://github.com/steel-dev/atlas) has the full picture.

### Built with agents

Most of Atlas was written through AI pair-programming. The structural decisions are human: the shape of the loop, where the audit sits, what the ledger holds. The code came fast. The hard part was choosing what lives outside the model: the ledger, the budget meter, the trail of searches, the point where the run stops and checks its own work.

### Built for verticals

Generic research tools hit a ceiling fast. Atlas is meant to be extended into a domain: a finance researcher that reads filings, a health researcher that works through clinical literature, a workflow with its own weird sources and review rules.

`researchTool` is for that. If the right source is EDGAR, PubMed, arXiv, OpenAlex, ClinicalTrials.gov, or your internal docs, wire it in directly; anything you add through `ctx.addSource` flows into the same source store, the same report, and the same grounding pass.

For a full example, the [Atlas public company research demo ](https://github.com/steel-experiments/atlas-demo)shows the pattern applied to public biotech research with SEC filings, trial registries, PubMed, and optional Steel browser fetches.

```ts
import { Atlas, researchTool } from "@steel-dev/atlas";
import { z } from "zod";

const atlas = new Atlas({
  model,
  tools: {
    pubmed_search: researchTool({
      description: "Search PubMed.",
      inputSchema: z.object({ query: z.string() }),
      execute: async ({ query }, ctx) => {
        const studies = await pubmed.search(query, { signal: ctx.signal });
        for (const s of studies)
          ctx.addSource({ url: s.url, title: s.title, content: s.abstract });
        return studies.map((s) => `- ${s.title}`).join("\u000a");
      },
    }),
  },
});
```

![](https://steel.dev/assets/framerusercontent.com/images/948ZTWl3y3PDXl5lGwQsOLV7Wo.png)

### Where Atlas needs care

Atlas grounds and audits. Weak sources still produce weak evidence; paywalled, missing, or contradictory sources still need a human’s judgment. The better you know your domain’s sources and failure modes, the better you can tune Atlas around them.

It also costs real money. A balanced run targets a couple of dollars, so runs need explicit budgets and caps. `maxUSD` is a best-effort target; provider calls can still land above it. If you bring a custom model, pass its `pricing` so the budget math stays honest.

Before you spend real money tuning a vertical, use the [Browser Agent Leaderboards](https://leaderboard.steel.dev/) to narrow the model list. [DRACO](https://leaderboard.steel.dev/leaderboards/draco/) is the closest fit for Atlas because it grades full research reports across 100 expert-scored tasks, not short answers. Treat it as a filter, not a verdict: each row mixes a model, harness, judge, budget, and tool setup.

### Get started

- Install: `npm install @steel-dev/atlas`
- Package: [@steel-dev/atlas on npm](https://www.npmjs.com/package/@steel-dev/atlas)
- [GitHub](https://github.com/steel-dev/atlas)
- [Quickstart](https://github.com/steel-dev/atlas#readme)
- [CLI example](https://github.com/steel-dev/atlas/blob/main/examples/cli.ts)
- [Local web UI example](https://github.com/steel-dev/atlas/blob/main/examples/serve.ts)
- [Domain tool examples](https://github.com/steel-dev/atlas/tree/main/examples)
- [Evals](https://github.com/steel-dev/atlas/tree/main/evals)
- [Browser Agent Leaderboards](https://leaderboard.steel.dev/)
- [Public company research demo](https://github.com/steel-experiments/atlas-demo): a biotech-company memo workflow using SEC EDGAR, ClinicalTrials.gov, PubMed, optional web search, and optional Steel browser fetches.

Questions? [Discord](https://discord.gg/steel-dev) or [@steeldotdev](https://twitter.com/steeldotdev).

> This post is Day 4 of Steel Launch Week v3. See the full week at [steel.dev/launch-week](https://steel.dev/blog/launch-week-v3-recap).

[Video on YouTube](https://www.youtube.com/watch?v=8HzzKsAVrWI)

## Blog: Steel Speaks Rust and Go

https://steel.dev/blog/rust-go-sdks · Jun 24, 2026 · By JunHyoung Ryu

> Native Rust and Go SDKs for Steel: drive the browser and the computer from the stacks where agent infrastructure already runs.

**TL;DR:** Steel shipped native Rust and Go SDKs as typed API clients for sessions, profiles, credentials, files, extensions, screenshots, scraping, PDFs and the computer endpoint. They create and release sessions and hand the WebSocket URL to CDP tools such as chromiumoxide, chromedp or rod. Cookbook examples ship alongside.

It answers:

- Does Steel have a Rust SDK?
- Does Steel have a Go SDK?
- How do I create and release a Steel session from Rust or Go?
- Which CDP libraries work with the Steel Rust and Go SDKs?
- What do the Steel Rust and Go SDKs cover?

> Launch Week v3 -> Day 03 / 05

A lot of agent infrastructure is written in Rust and Go: edge runtimes, orchestration layers, services where latency matters, the backend jobs that have to run again tomorrow. Until now, if you lived in that world, you had to maintain your own bindings against the Steel API.

Not anymore. Steel now has **native Rust and Go SDKs.**

This is where Launch Week v3 has been heading: [Stealth Browser ](https://steel.dev/blog/stealth-browser)for the runtime, [Dedicated IPs](https://steel.dev/blog/dedicated-ips) for stable network identity, and now Rust and Go SDKs for the services doing the work.

### Why we built native SDKs

We felt the gap ourselves. We rewrote [our own CLI ](https://steel.dev/blog/steel-cli-and-agent-skill)in Rust, and we kept running into the same thing our customers did: Rust and Go both have real browser tooling, *chromiumoxide* on the Rust side and *chromedp* or *rod* on the Go side, but there was no Steel client for either. So we built both.

![](https://steel.dev/assets/framerusercontent.com/images/QMziEa5muy2w5s18ajX4atP28.png)

### How the SDKs work

The latest Rust and Go SDKs are typed API clients for Steel. They cover the resources a workload usually needs: sessions, profiles, credentials, files, extensions, screenshots, scraping, PDFs, and the session computer endpoint.

![](https://steel.dev/assets/framerusercontent.com/images/23ruAutD9Q1EDnotHXDCfxTS7g.png)

The SDK handles the Steel side of the loop. Create a Steel session from Rust or Go, set profile and proxy options in the same client, then pass the returned WebSocket URL to the CDP tool you already use: chromiumoxide, chromedp, rod, or something else. When the run is done, release the session from that same SDK.

Both also plug into our computer API, so CUA agents can use OS-level actions through the same client.

In Rust, the session lifecycle stays in one client:

```rust
use steel::Steel;

let client = Steel::new(std::env::var("STEEL_API_KEY")?);
let session = client.sessions().create(steel::SessionCreateParams::default()).await?;

println!("CDP: {}", session.websocket_url);
client.sessions().release(&session.id, steel::SessionReleaseParams::default()).await?;
```

The Go version keeps the same shape, with context and explicit errors:

```go
client := steel.NewClient(os.Getenv("STEEL_API_KEY"))
session, err := client.Sessions.Create(ctx, steel.SessionCreateParams{})
if err != nil {
	return err
}

fmt.Println("CDP:", session.WebsocketURL)
_, err = client.Sessions.Release(ctx, session.ID, steel.SessionReleaseParams{})
```

Rust is async-first. Go is context-first. Both keep session, proxy, and response config typed. If you’ve used the TypeScript or Python SDK, the loop will feel familiar. It does not cover every helper yet; v1 is about creating sessions, configuring them, handing off the CDP URL, and releasing them without leaving Rust or Go.

### Cookbook examples are live

We also shipped the examples around the SDKs, because the client alone is not where the integration work ends.

#### Browser automation

These show the handoff from a Steel session to the CDP tool, then release the session from the SDK.

- [chromedp](https://docs.steel.dev/cookbook/chromedp) in Go
- [rod](https://docs.steel.dev/cookbook/rod) in Go
- [Playwright](https://docs.steel.dev/cookbook/playwright#go) in Go
- [chromiumoxide](https://docs.steel.dev/cookbook/chromiumoxide) in Rust
- [headless_chrome](https://docs.steel.dev/cookbook/headless-chrome) in Rust

#### Direct Steel APIs

These cover the parts people usually had to wrap themselves: logged-in state, credential fill, extension attachment, file upload, screenshot, PDF, and scrape.

- scrape in [Rust](https://docs.steel.dev/cookbook/scrape#rust) and [Go](https://docs.steel.dev/cookbook/scrape#go)
- profiles in [Rust](https://docs.steel.dev/cookbook/profiles#rust) and [Go](https://docs.steel.dev/cookbook/profiles#go)
- auth context in [Rust](https://docs.steel.dev/cookbook/auth-context#rust) and [Go](https://docs.steel.dev/cookbook/auth-context#go)
- credentials in [Rust](https://docs.steel.dev/cookbook/credentials#rust) and [Go](https://docs.steel.dev/cookbook/credentials#go)
- extensions in [Rust](https://docs.steel.dev/cookbook/extensions#rust) and [Go](https://docs.steel.dev/cookbook/extensions#go)
- files in [Rust](https://docs.steel.dev/cookbook/files#rust) and [Go](https://docs.steel.dev/cookbook/files#go)

#### Agent frameworks

- [Genkit](https://docs.steel.dev/cookbook/genkit) in Go
- [Eino](https://docs.steel.dev/cookbook/eino) in Go
- [LangChainGo](https://docs.steel.dev/cookbook/langchaingo) in Go
- [Google ADK](https://docs.steel.dev/cookbook/google-adk#go) in Go
- MCP in [Rust](https://github.com/steel-dev/steel-cookbook/tree/main/examples/mcp-rs) and [Go](https://github.com/steel-dev/steel-cookbook/tree/main/examples/mcp-go)
- [Rig](https://docs.steel.dev/cookbook/rig) in Rust
- [Swiftide](https://docs.steel.dev/cookbook/swiftide) in Rust

#### Computer use

- Claude in [Rust](https://docs.steel.dev/cookbook/claude-computer-use#rust) and [Go](https://docs.steel.dev/cookbook/claude-computer-use#go)
- OpenAI in [Rust](https://docs.steel.dev/cookbook/openai-computer-use#rust) and [Go](https://docs.steel.dev/cookbook/openai-computer-use#go)
- Gemini in [Rust](https://docs.steel.dev/cookbook/gemini-computer-use#rust) and [Go](https://docs.steel.dev/cookbook/gemini-computer-use#go)

### Get started

- Rust package: [steel-rs on crates.io](https://crates.io/crates/steel-rs)
- Rust source: [github.com/steel-dev/steel-rust](https://github.com/steel-dev/steel-rust)
- Go package: [github.com/steel-dev/steel-go on pkg.go.dev](https://pkg.go.dev/github.com/steel-dev/steel-go)
- Go source: [github.com/steel-dev/steel-go](https://github.com/steel-dev/steel-go)
- Cookbook: [docs.steel.dev/cookbook](https://docs.steel.dev/cookbook)

Try the loop in the stack you already ship, then tell us which language support or helper surface you need next.

Questions? [Discord](https://discord.gg/steel-dev) or [@steeldotdev](https://x.com/steeldotdev).

> This post is Day 3 of Steel Launch Week v3. See the full week at [steel.dev/launch-week](https://steel.dev/blog/launch-week-v3-recap).

[Video on YouTube](https://www.youtube.com/watch?v=cZjEM5PFXJs)

## Blog: Dedicated IPs give production agents a stable network origin

https://steel.dev/blog/dedicated-ips · Jun 23, 2026 · By Dane Wilson

> Dedicated IPs give production agents a stable network origin.

**TL;DR:** Dedicated IPs give a reused browser profile the same egress IP across runs, so sites stop seeing a login jump across the world. Paid plans can lease up to 25 IPs from Settings > Network and pin a session to one, or let Steel pick one and persist it to the profile. A fixed IP suits authorized logged-in workflows, not bulk scraping.

It answers:

- How do I pin a Steel session to a dedicated IP?
- Why do logged-in browser agents get logged out when their IP changes?
- How many dedicated IPs can I lease on Steel?
- When is a fixed IP the wrong choice for a browser agent?
- Which Steel plans include dedicated IPs?

> Launch Week v3 -> Day 02 / 05

Agents that log in need a stable network origin.

If you reuse a profile across sessions, you’ve probably run into the impossible travel problem, even if you never had a name for it. Steel can save the cookies and fingerprint so the browser looks the same. Then the next run comes from a different IP. To Google, Amazon, or Discord, the account just jumped across the world between requests. That is how you end up logged out, challenged, or flagged.

Dedicated IPs close that loop. Your agent comes back from the same network origin, so the login has a fair chance to stick.

![](https://steel.dev/assets/framerusercontent.com/images/HqV2u3ZX27ZmnlJc92HsdtOGdU.png)

### How Dedicated IPs work

You can lease up to 25 dedicated IPs yourself from **Settings > Network**. If you need more, contact support. Then pin a session to a specific IP, or let Steel choose from the IPs your org owns.

```ts
// Use any of your dedicated IPs
const session = await client.sessions.create({
  useProxy: { type: "fixed" }
});

// Or pin to a specific one
const session = await client.sessions.create({
  useProxy: { type: "fixed", id: "fixed:8SdfYs77me" }
});
```

If you pass an `id`, that session uses that exact IP. If you leave `id` out, Steel chooses one at random from your pool and persists it to the profile, so the same profile reuses the same IP across runs. The load still spreads across what you own. When you no longer need an IP, release it.

### Lease and manage your IPs

The **Network** page in Settings handles the whole lifecycle: lease IPs, see each IP’s status, check available locations before you lease, and release an IP when you no longer need it.

![](https://steel.dev/assets/framerusercontent.com/images/CWVzfmaWar4Itx8yoO0GmgKwgE.png)

### Why stable IPs keep logins working

Logged-in workflows usually break in one place: the first run after you thought you were done with 2FA. Cookies and fingerprints help, but the site still sees the network origin change. The browser looks familiar. The IP does not.

Pair a Dedicated IP with a persistent profile and the boring thing happens: same browser identity, same egress IP. You log in once, then the agent can reuse that auth state across runs without a human stepping in every time. Profiles preserve browser identity. Dedicated IPs preserve network identity.

For authorized, logged-in, audited workflows, stable egress is what you want. The site sees the same returning visitor. You can allowlist a known egress IP. Your security team knows which IP belongs to which workload. If you’re reusing authentication at scale, that is the use case.

### When a fixed IP is the wrong choice

Dedicated IPs have a narrow job. For high-volume, unapproved collection, a single IP can collect negative signals quickly.

A fixed IP does not make a bad workflow acceptable. A burned account still needs remediation. Site policies still apply. The strongest pattern is the boring one: a durable profile, a dedicated IP, consistent behavior, and permission to run the workflow.

### Get started

Dedicated IPs are available on all paid plans. You can lease up to 25 self-serve from **Settings > Network**, with optional geo targeting.

- [Documentation](https://docs.steel.dev/overview/sessions-api/dedicated-ips)
- [Dashboard](https://app.steel.dev/settings/network)
- [Pricing](https://steel.dev/pricing)

Questions? [Discord](https://discord.gg/steel-dev) or [@steeldotdev](https://x.com/steeldotdev).

> This post is Day 2 of Steel Launch Week v3. See the full week at [steel.dev/launch-week](https://steel.dev/blog/launch-week-v3-recap).

## Blog: Stealth Browser: A Chromium Built for Agents

https://steel.dev/blog/stealth-browser · Jun 22, 2026 · By Jagadesh P

> Stealth Browser is Steel's custom Chromium fork for agent workloads: stable browser-level signals from startup and a lighter runtime.

**TL;DR:** Stealth Browser is Steel's own Chromium fork that applies the browser profile in the browser process, so GPU, WebGL and other fingerprint signals stay consistent from the first request instead of being patched by injected JavaScript. It is open to every enterprise customer at no additional cost, with access gated per workload.

It answers:

- What is Steel Stealth Browser?
- Why do injected JavaScript stealth patches fail against strong antibot systems?
- How does a Chromium fork help agents avoid bot detection?
- Who can use Stealth Browser and what does it cost?

> Launch Week→ Day 01

Today we're shipping **Stealth Browser**: our own Chromium fork, hardened at the source so user-permissioned agents stop getting blocked by the web's toughest antibot systems.

It's been running in production with a handful of beta customers for a few weeks. Starting today, we're opening it to every enterprise customer at no additional cost.

![](https://steel.dev/assets/framerusercontent.com/images/ARCMl8mYA5gEpIlJZd8hsUzLQI.png)

### Stealth is usually the first thing that breaks

Most agent work is mundane and authorized. Signing into an account you own, pulling a report from an internal tool, running a workflow a customer asked for.

But the open web can't tell your agent from a malicious bot. So legitimate, user-permissioned agents get challenged and blocked by sites that have no reason to block them.

For a lot of teams, this is the number one blocker. The antibot fires, the workflow stalls, and your use case doesn't matter: you're banned by default.

Our job is to get you past that. We patch the signals that tell a site you're running automation, so your agent looks like a person on a normal browser.

### Patching on top got us far, then hit a ceiling

Until today, most of that work was a layer on top of a stock browser. Start Chrome, patch the user agent, add a proxy, inject JavaScript to clean up the obvious fingerprint surfaces.

That unblocks a huge range of common sites. For most jobs, it's enough.

But the heaviest antibot systems still flagged our customers. They read browser-level signals you can't reach from an injected script: GPU and WebGL fingerprints, media devices, OS-level details.

Injected patches are also late. They race the page's own code, miss browser-level surfaces, and leave inconsistencies the challenge can detect. To get past those systems, we had to go lower.

### So we forked Chromium

Stealth Browser moves the fingerprint work out of injected JavaScript and into Chromium itself. The browser profile is applied in the browser process, before any page script can read the surfaces that describe it.

GPU and WebGL are the clearest example. Those values come from the browser, so repairing them from a script is already too late. Patch them at the source and they stay consistent from the first request.

Forking also let us strip Chromium down. We cut bloat we don't need, which keeps sessions lighter, and we fixed consistency issues that made long-running sessions flaky.

### What you get

A consistent browser state from the first request means fewer false bot signals and fewer challenges. The hardest sites get more reachable, sessions run a bit faster, and long-running jobs fail less often.

Because the evasion happens at the fingerprint level, you often clear antibot systems entirely, with no challenge left to solve.

In addition to antibot evasion, you also get a win and cost win. Captcha solving can take up to two minutes per challenge, and you pay for every browser minute it idles there. Often you'll be able to skip the solving process entirely, saving you time and money.

### Request access

Stealth Browser is an enterprise feature, and we're opening access deliberately. New access is gated because it's support-intensive. We want to understand each workload before we enable it.

If you want in, bring us your hardest job.

The fastest way in is to [book a call with our founders](https://cal.com/hussien-hussien-fjxt3x/intro-chat-w-steel-founders) - join and tell us what's breaking, and we'll get you set up.

> This post is Day 1 of Steel Launch Week v3. See the full week at [https://steel.dev/launch-week](https://steel.dev/blog/launch-week-v3-recap)

[Video on YouTube](https://www.youtube.com/watch?v=7EjchdTlG0Q)

## Blog: Introducing Projects

https://steel.dev/blog/introducing-projects · Jun 12, 2026 · By Dane Wilson

> Projects bring project-level isolation to your Steel org. Scope sessions, credentials, and profiles per project.

**TL;DR:** Steel Projects are separate namespaces inside one organization that scope sessions, credentials, profiles and API keys. Every org gets a Default project with existing resources and keys migrated, so nothing breaks. Projects start as Development and can be promoted one-way to Production; org admins manage them in the dashboard.

It answers:

- What are Projects in Steel?
- Do my existing Steel API keys still work after Projects launched?
- How do I separate dev and prod workloads in Steel?
- Can a Production project be changed back to Development?
- Can I create Steel projects through the API or SDK?

Projects are live in Steel today: separate environments and namespaces inside a single organization. Create one for dev, one for prod, one per team or product, and scope your sessions, credentials, and profiles to each.

> TL;DR Sessions, credentials, profiles, and API keys are scoped to projects. Every existing org gets a **Default project** with your current resources and keys already migrated in, so nothing breaks. Switch projects from the new **Project Selector** in the top-left nav, and promote a project from **Development** to **Production** when it's ready.

We held off on this longer than most would. Our honest opinion was that simplicity trumps complexity: one org, one bucket, nothing to configure. For a developer running agents in 2025, that was the right call.

But one bucket doesn't scale with agents. The challenge wasn't headcount, it was proliferation: one agent became a fleet, and simple scripts became multi-step workflows carrying their own credentials and profiles. All of it in the same namespace, with no line between a Tuesday experiment and the workload your customers depend on. The only way to draw one was standing up a second organization.

Projects work here the way they work everywhere else in your stack. Same org, same billing, clean boundaries.

### What a project is

A project is an independent namespace. Nothing created in one project leaks into another. Right now that covers:

- Sessions
- Credentials
- Profiles

That's the whole idea: separation without the overhead of a second organization.

![Two terminals run the same curl against /v1/sessions. The dev project key returns three dev sessions; the prod project key returns one prod session. The key decides what exists.](https://steel.dev/assets/framerusercontent.com/images/naP8pLyy35SCRbiVGbTNSaTpQUE.png)

### Your resources already moved

Every organization now has a **Default project**, and your existing resources already migrated into it. Your code keeps working. So do your keys. There's no cutover step.

Rename the Default project or leave it alone. It's where you start; after that, the dashboard reopens whichever project you used last.

![The Project Selector](https://steel.dev/assets/framerusercontent.com/images/409m9i62UCYY8b9hqF08cRIuYxk.png)

### The Project Selector

The dashboard now has a Project Selector in the top-left nav, next to the Organization Selector. Switch projects there, check each one's environment, or open Project Settings to:

- Create a project
- Rename a project
- Set a different project as default
- Promote a project to Production
- Delete a project (and revoke its API keys)

### Development and Production

Projects carry an environment designation. A new project starts as Development. Promote it and it turns Production, with a green badge.

Promotion is one-way. You can't downgrade a Production project back to Development. We chose a visible badge over silent config so you can tell prod from dev at a glance.

### Project-scoped API keys

It works as expected. Every API key belongs to one project. When you create a key, you pick its project; the UI defaults to the one you're viewing in the Project Selector.

Your existing keys moved into the Default project, so they keep working. Sessions, credentials, and profiles you create with a key land in that key's project. A key for your prod app can't reach your dev sessions.

```python
from steel import Steel

dev = Steel(steel_api_key=DEV_PROJECT_KEY)
prod = Steel(steel_api_key=PROD_PROJECT_KEY)

session = dev.sessions.create()

dev.sessions.list()   # includes the new session
prod.sessions.list()  # never will
```

Projects themselves are managed by org admins in the dashboard. The SDK and API keys can't create, promote, or delete them.

### Where this goes

Every control we want to build needs a boundary to act on, so the boundary ships first:

- Production-specific permissions and deployment safeguards
- Environment-based access controls and governance

Projects also show us something we couldn't see before: how you structure your workloads, and what "production" means for an agent running on the web. That shapes what we build next.

### Try it

Open [app.steel.dev](https://app.steel.dev/) and check the top-left nav. Your Default project is already holding everything you've built. Spin up a second project for dev, mint a project-scoped key, and point one environment at it.

## Blog: Building a Deep Research Agent That Survives Its Own Failures

https://steel.dev/blog/durable-researcher · Jun 11, 2026 · By Nikola Balic

> What we learned from making a research agent durable, routed, visible, and eval-driven.

**TL;DR:** Durable Researcher is a browser-native deep research agent that checkpoints every model step to Postgres and rebuilds state from the transcript, so crashed runs resume. Routing tasks as lookup, extraction or synthesis gave the biggest lift; a citation verifier first cut citation quality by up to 0.22 and was fixed before re-use.

It answers:

- How do you make a research agent resume after a crash?
- Why did a citation verifier make a research agent worse?
- How does Durable Researcher score on ResearchRubrics and DRACO?
- Why should a research agent classify the task before planning?
- How do you stop a research agent from looping on searches without browsing?
- What stack does Durable Researcher use?

I have been fascinated by deep research agents for a while now, studying every shape I stumble on.

In [part one](https://steel.dev/blog/claude-code-deep-research-autopsy) I took apart the deep-research harness inside Claude Code. This is what happened when I built my own and pointed real evals at it. Then rebuilt it.

> TLDR: **Durable Researcher** is a browser-native deep research agent that checkpoints every model step, rebuilds state from the transcript, routes tasks by answer shape, and uses eval failures as the product loop.

The point was to make every failure leave enough state behind that I could resume it, inspect it, and turn it into the next change. Make a better agent.

The first version was good at the wrong thing.

It wrote beautiful overviews. It planned sub-queries, browsed in parallel, took notes, checked its coverage, and produced a polished report. Ask it to survey a field and it shined. Ask it for one number, like a cash-flow figure from a filing, and it handed you a thoughtful essay about the company instead.

So I added a citation verifier. It checked every claim in the report against the agent's notes and triggered a rewrite when the evidence was thin. Clean. Obviously the kind of thing a research agent should have.

The evals said it made things worse. I switched it off.

Build what seems right. Test it on real tasks. Read the failures. And when the data turns on you, quarantine your cleverness until you understand it.

### The Durable Research Loop

Durable Researcher takes a topic, plans sub-queries, runs them in parallel against real browser sessions on [Steel](https://steel.dev/), takes structured notes, checks its own coverage, fills the gaps, and writes a report.

Steel matters because the agent needs browsers, not HTTP fetches. The useful research lives on pages that render late, redirect, block scrapers, or hide their content behind behavior. A plain fetch sees none of it.

Every model message is checkpointed to Postgres as it happens. If the agent dies, the next run resumes from the last checkpoint. The model never knows it crashed.

That is only the first layer. Notes, visited URLs, claims, and source ledgers rebuild from the transcript. Scraped pages are cached in Postgres, keyed by task and URL, so a crash does not mean paying Steel to browse the same page again. Verification attempts are checkpointed too, which means a bad rewrite leaves a trail: claim verdicts, pass rate, unsupported lines, and reasons.

The stack: Bun and TypeScript, [Pi](https://github.com/earendil-works/pi) for the agent loop, [Absurd](https://github.com/earendil-works/absurd) for durable execution, Steel for browsers, Postgres for persistence, a GLM-5.1 (cheap, fast and smart) model for reasoning, and Ink for the terminal UI.

![System architecture: User, terminal UI, Pi agent loop, Steel browser sessions, Postgres checkpoints, verifier calls, and final report.](https://steel.dev/assets/framerusercontent.com/images/JwPt5X8YOCOc4o8LOuf8twWq9jg.png)

None of it is exotic. The product lives in the fit between the pieces.

Campaign mode pushes the same idea further. Long research runs are split into bounded pulses, each with its own task ID, objective, report, judge decision, usage, and source inventory. That avoids one giant long conversation while preserving the user-visible behavior of one continuous run.

Part one found Claude Code's harness stuck in a single-pass pattern: scope once, search once, never let a finding change the next query. Mine had the same limitation until I taught it to take the second hop, which is most of what follows.

### The Numbers, With the Caveats Up Front

There are two useful academic benchmarks for this kind of system. [ResearchRubrics](https://labs.scale.com/papers/researchrubrics), from Scale AI, has 101 tasks with weighted criteria judged by an LLM. [DRACO](https://huggingface.co/datasets/perplexity-ai/draco), from Perplexity, has 100 tasks with a similar shape.

| Benchmark | Judge | Tasks | Score | How to read it |
| - | - | - | - | - |
| ResearchRubrics | Gemini default | 10/101 | `59.8%` | Promising, partial |
| DRACO | Gemini 3.1 Pro | 10/100 | `47.1%` | Paper-comparable, weak sample |

For reference, the published full-set ResearchRubrics scores are Gemini Deep Research at `61.5%`, OpenAI Deep Research at `59.7%`, and Perplexity Deep Research at `48.7%`.

The judge belongs in the headline of the metric. LLM-as-judge numbers are useful, but only if every chart clearly says which judge produced them.

So the honest claim is narrow: promising on ResearchRubrics, lower-middle on the Gemini-judged DRACO sample. The full 100-task DRACO run still matters most. But for speed of the loop I have opted for a random 10% subsample.

### Sprint One: Make Failure Resumable

The first sprint built the substrate.

Every assistant message becomes a step in the durable engine. On resume, the engine replays the completed steps and hands the conversation back to the model. There is no notes table. No visited-URL table. Tool calls and their results live in the message log, and the app rebuilds notes and URLs by walking it.

The transcript is the canonical artifact. If the log replays, the state replays.

The browse cache was the second practical piece. When a page has already been opened for a task, the content is stored with its title and raw length. On resume, the agent can reuse that page instead of pretending the crash erased the web it already saw.

That mattered more once verification entered the loop. The verifier needs source excerpts, not just a final markdown report. After a crash, the in-memory excerpt store is empty, so the agent rebuilds it from cached browse content before checking claims. Without that, a resumed run could have the right sources in its history and still fail its own citations.

On top of that I built the research loop.

![Research loop: user topic to plan, Steel prefetch, structured notes, coverage check, and either gap fill or final report.](https://steel.dev/assets/framerusercontent.com/images/xd74HJJOZW2s5QE9ASjkaj34E.png)

Planning produces sub-queries. Prefetch fans them out through Steel, searching and scraping the top results for each one in parallel. The agent reads the sources, takes structured notes, and calls an evaluation tool that summarizes coverage. Weak coverage, search again; good coverage, write.

The early version failed in boring, specific ways.

A broad query about agent-driven web automation came back with WhatsApp pages, German dictionaries, and a recipe site. The failure was retrieval, not browsing, so I added ranking signals for topic fit, URL paths, and domains that should never win. Bad candidates should lose before the browser spends time on them.

The additional tweak was to lean into what the model already knows: if we already know a relevant URL, browse it directly before searching again. Searching the open web before visiting one lets SEO fight your research before the agent has read the obvious page.

Another failure mode: search loops. The agent would fire seventeen searches in a row, tweaking keywords each time, browsing nothing. Every search cost money and taught it almost nothing.

The fix was simple: no more than two searches in a row without a browse. The exact number mattered less than the behavior it named. Searching without browsing is reading the card catalog and never opening a book, and the prompt had to say so.

Both rules are one rule with two faces: **take the second hop.** Read something and let it change what you do next, instead of firing another query into the dark. The Claude Code harness I took apart in part one never takes that hop. Most of this project was teaching mine to.

I built the eval harness too. It downloads the DRACO and ResearchRubrics benchmark datasets, runs the agent as a subprocess per task, and judges the output with an LLM. Multiple judges. Batch APIs where they exist.

The harness changed how I read metrics. Once I saw how far a score could swing on the judge alone, I stopped trusting any single number.

### The Diagnosis

After the first sprint, I had Codex review the eval outputs on its own. It named the problem better than I had:

> Durable Researcher was a good synthesizer with weak routing into exact lookup, primary-document extraction, and precision answering.

Exactly right. The agent nailed "write me a thoughtful overview of X." It flubbed "what was Apple's free cash flow in fiscal Q3 2024?" It used the same report-writing shape for both.

The roadmap was:

- classify the task before planning
- use a different first turn for exact tasks
- build a real path to primary documents
- produce an evidence table before prose for extraction tasks
- gate completion on whether required values were actually captured
- adapt the output style to the task type

Acting on it took me weeks. Routing was an architecture change.

### Sprint Two: Route Before You Research

The second sprint started from one premise: **the first turn matters more than another tool.**

Before planning, the system now classifies the prompt as `lookup`, `extraction`, or `synthesis`. The mode picks the report template and the stop condition.

1. **Lookup** answers first and cites one strong source.
2. **Extraction** produces an evidence table as the deliverable, with tight analysis underneath.
3. **Synthesis** keeps the original report shape.

I added primary-source paths too. Financial and extraction-heavy queries needed a way to reach source documents instead of drifting around the open web. PDF text extraction handles the investor reports that normal scrapers turn to garbage.

It exposed a harder truth: having the path is not enough. The agent has to choose it at the right moment.

![Without routing, every prompt produces the same five-section report. With routing, the first turn picks the output shape: one number, an evidence table, or a structured report.](https://steel.dev/assets/framerusercontent.com/images/jejeGRbeTPdEeLPVsjE3Shxos.png)

### The Citation Verifier That Made Things Worse

The verifier was supposed to be the easy quality win.

After the report was written, the system parsed every citation, found its source, pulled the supporting notes, and asked a utility model one question: do verbatim excerpts back this claim? If the pass rate dropped below a threshold, it injected a steering message and let the agent rewrite.

Each verifier attempt was committed as its own checkpoint, with the claim verdicts, pass rate, cited source numbers, and failure reasons. That made the autopsy much less mystical.

On a small eval comparison, citation quality fell by 0.19 to 0.22 absolute points on a 0-1 scale.

This was the same lesson one layer down: **a verifier can make a system worse when its failure mode is correlated with the writer's.** The lensed query expansion I had added in the same sprint, which generated definition, recency, criticism, and primary-source angles for every sub-query, was dragging the system toward tutorials and news.

The hotfixes were predictable. Source-authority weighting. Stronger source-selection prompts. The extraction heuristic. Peer-reviewed and government domains up, PR wires and thin aggregators down.

> Learning: keep measurement on, but make losing behavior easy to switch off.

The rewrite was not wrong in principle. My implementation had specific, findable bugs. Blame it on the agent.

So I fixed the verifier, not the writer: semantic matching, OR scoring for grouped citations, edit-narration stripping, a best-version guard, and a skeptic refuter at the decision boundary.

Then I turned it back on by default.

The real lesson is: **switching the losing build off gave me room to see why it lost.**

![The verifier arc: v1 regressed citation quality by 0.22, was quarantined, three bugs were found during autopsy (verbatim matching, multi-cite AND scoring, edit narration), then v2 was re-enabled with semantic matching and OR scoring.](https://steel.dev/assets/framerusercontent.com/images/zI0pwUDqUe38ZM0iuB7poleOI.png)

### Sprint Three: When The Question Is The Hard Part

Routing decided what kind of answer to produce. It did not help when the question itself was hard to interpret.

**Some questions are disguised:** a homophone, a paraphrased proper noun, or a reference buried in a casual phrase. The old planner decomposed every topic along literal research lenses, so a question in costume got searched at face value and never cracked.

Now the planner reasons about the question before it writes a single query. It lists explicit interpretations, decodes the oblique reading, and searches both the literal and the lateral version. It treats the user's stated details as fallible clues, because people misremember and approximate. And it carries a needle prior: if a question is dressed up as hard but its literal phrasing would be trivial to search, the surface reading is probably a decoy, and the lateral readings get the weight.

One bug from that work shows how these systems leak.

The planner generated the interpretations correctly. A downstream parser dropped the field before it reached the agent, and the renderer never showed it. The lateral reasoning was real, then silently thrown away. Wiring it through changed the agent's behavior more than any prompt line did.

The next problem was subtler, because it sounded like good judgment. A single reasoning chain would reach the right answer and then talk itself out of it.

On one homophone needle in the haystack problem (love the "Run Forrest Run 5k" one), the agent found the correct answer, decided it was too cute to be real, and dropped it.

Re-rolling the same chain is not a second opinion. The same model with the same framing tends to fall into the same hole. A second opinion only helps if it can fail differently from the first.

The fix was redundancy, not a better prompt. Several workers now attack the same question from different readings, each told not to self-reject, and their evidence pools so independent agreement builds into confidence. A full extra agent gets spent only on a top answer nobody has confirmed yet.

Then a separate adversarial pass judges whether the answer is correct, which is a different question from whether a citation is grounded. Skeptics vote. Abstentions are safe. Refuted answers stay in the report as a transparency block instead of vanishing.

On the needle that started all this, the chain now surfaces the right answer and lands at medium confidence with a caveat, instead of confidently wrong or confidently silent.

The last piece was depth. Routing made lookups short, which exposed the opposite problem on broad synthesis: reports that were accurate and thin.

Survey mode runs several research passes and merges them deterministically into one report, with a single global source list and every citation marker remapped to match, then spends one constrained model pass on the prose. A gap-fill loop and citation chasing push for density instead of letting the writer quit early. On by default.

![The verifier arc: v1 regressed citation quality by 0.22, was quarantined, three bugs were found during autopsy (verbatim matching, multi-cite AND scoring, edit narration), then v2 was re-enabled with semantic matching and OR scoring.](https://steel.dev/assets/framerusercontent.com/images/6mgldIfADV3LCZzfXsDV2xNZyUA.png)

### Make Agent Work Visible

At first the CLI was a wall of logs. Long stretches of nothing, and no way to tell whether the agent was thinking, browsing, stuck, or dead.

So I built a terminal UI: findings, activity stream, agent status, a token meter, streamed assistant text between tool calls, per-tool progress, a verification indicator. Once the browser work ran through Steel, the UI had to show those sessions too: searches launched, pages opened, scrapes done, failures returned.

The real win is steering. You can type a redirect mid-run, and it lands as a tagged user message before the next model turn. The system prompt teaches the model how to treat it.

![](https://steel.dev/assets/framerusercontent.com/images/ycWZEuLxj0KGlFWoxZK3gzPKo.png)

### The Dogfood Loop

The most productive workflow was not complicated:

1. Run the agent on a real, non-trivial topic.
2. Read the full log (feed it to the coding agent).
3. Compare the saved report against the scraped pages and task rows in Postgres.
4. Name each problem in one sentence.
5. Write a failing test.
6. Make the change.
7. Read the diff back as a hostile reviewer.
8. Fix what the review finds.

![Eight steps in the dogfood loop: Run, Read log, Compare, Name it, Write test, Make change, Hostile review, Fix review.](https://steel.dev/assets/framerusercontent.com/images/Ge4ap17ChTLqph4YAkTVI0W2Ac.png)

That became the discipline: plan, diff, review, fix the review. The agent helps at every step.

### What Stuck

**Routing beats tooling.** The biggest quality lift I saw came from deciding what kind of task the user asked for before running the loop. Some prompts want a number, some a table, some a report.

**Width and depth are tools, not maturity levels.** The useful system routes first, then spends parallelism, iteration, or neither based on the shape of the question.

**Durability works when the transcript is enough.** Store tool-derived state anywhere else and you end up with a second source of truth. If notes, URLs, claims, and verifier context rebuild from committed messages and caches, crashes become annoying instead of existential.

**Browser infrastructure is product infrastructure.** For a research agent, the browser is not plumbing. It decides what the model can know, and the evals only matter if they test the system against that reality.

### The Same Discipline Applies

Building one agent with help from another collapsed the line between product and tool.

Reading the research agent's outputs carefully turned out to be the same discipline as reading the coding agent's diffs carefully.

Make the work visible. Route before acting. Refuse cheap fixes. Retire features when the evidence turns on them.

Ask me again after some more work lands. Something else will have failed by then, and that is the point.

### Find the Experiment

The code, tests, eval harness, and vibes are here: [steel-experiments/durable-researcher](https://github.com/steel-experiments/durable-researcher).

It is not the final production shape. It spends tokens like it found a company card. But it survives its own failures now, and that made it finally worth improving.

## Blog: An autopsy of Claude Code's deep research

https://steel.dev/blog/claude-code-deep-research-autopsy · Jun 10, 2026 · By Nikola Balic

> Claude Code's deep-research workflow, pulled from its binary and dissected. Wide search, no second hop.

**TL;DR:** Claude Code's deep-research workflow (v2.1.170) runs five phases once: scope, parallel search, fetch and extract, three-skeptic verification, synthesis. It searches wide but never takes a second hop, unlike hybrid systems from Anthropic, OpenAI, Gemini and Perplexity. Depth costs latency and tokens, so match topology to difficulty.

It answers:

- How does Claude Code's deep research workflow work?
- Are deep research agents wide or deep?
- How do OpenAI, Gemini and Perplexity deep research differ from Claude Code's workflow?
- Why do reference research harnesses stay single-pass?
- Does majority voting by verifier agents catch research errors?
- When should a research agent go wide versus deep?

*I had Claude Code pry its own deep-research workflow out of its binary, then pointed that workflow at a question about itself. The verdict: it searches wide and never doubles back. The systems it resembles do. The whole game is that second hop.*

![Wide single-pass fan-out versus deep iterative search, where each hop feeds the next](https://steel.dev/assets/framerusercontent.com/images/19XQBJNMF6AFHVaWjDj5Ks33Ss.png)

Claude Code ships as a single compiled binary with its brain welded shut. Somewhere inside is the workflow it runs when you ask it to research the web: scope the question, fan out searches, read, vote, write.

It does not ship as a readable file, so, for research purposes, I had Claude Code reconstruct the workflow from inside its own binary. A few minutes later the tool had performed surgery on itself and handed me the deep-research.js.

I had a theory: **these "deep research" agents are not deep, they are wide.** They take your question, spray it across a handful of parallel searches, pile up the results, and stamp the word *deep* on the box. So I pointed the exact workflow at one question, *how do deep-research harnesses actually work, are they wide or deep*, and let it research its own autopsy.

What I watched it do confirmed the theory and broke it in the same run.

### What I was actually holding

This is a [Dynamic workflow](https://code.claude.com/docs/en/workflows), the kind Claude Code runs when you ask it to research the web. It executes on your own machine every time you run `/deep-research`. Everything in this piece describes the workflow as it ships in Claude Code v2.1.170; later builds may change it.

The header comment says it was "ported from a bughunter architecture," swapping `git` and `grep` for `WebSearch` and `WebFetch`. Someone built a bug-hunting agent, then noticed the same skeleton finds facts about the world as easily as it finds null-pointer dereferences.

Reference code is how patterns spread. People read it to learn the shape, then they ship the shape. So what matters is less what it does than what it teaches everyone who copies it.

### How the deep-research workflow works

Five phases. Top to bottom. Once.

![Scope, Search, Fetch, Verify, Synthesize: the five phases run once, with no arrow pointing back](https://steel.dev/assets/framerusercontent.com/images/1bIoXCo8HcE96lthLWPFNfrKM0.png)

| Phase | What it does |
| - | - |
| **Scope** | One agent splits the question into 5 angles: broad, technical, recent, contrarian, practitioner. |
| **Search** | Five agents run in parallel, one per angle, each blind to the others. |
| **Fetch + extract** | Dedup URLs, cap at 15 sources. Each source yields 2-5 *falsifiable* claims, each with a direct quote and a source-quality grade. |
| **Verify** | Three skeptics per claim, each told to refute it. Two rejections out of three and the claim dies. |
| **Synthesize** | One agent merges survivors, ranks by confidence, writes the report with a note listing what got killed. |

**The extraction step does not trust a webpage; it demands a checkable statement plus the quote that backs it.** Verification is adversarial on purpose. If you wanted to teach someone how a research agent hangs together, you could do far worse than handing them this file.

Good skeleton.

### The thing I couldn't stop looking at

Then I read the prompt the harness hands each searcher.

Every searcher is told to rank its results by relevance to *the original question*. The instruction is verbatim: *"Rank by relevance to the ORIGINAL question, not just the search query."* Every one of them starts from the same prompt the scoping agent wrote at second zero.

Nothing any searcher finds ever changes what gets searched. No agent reads a result, feels the tug of *wait, that implies something*, and forms a sharper question from it.

The orchestrator does not loop. Scope happens once. Search happens once. The report is built from whatever that single sweep dragged up off the seabed.

That is the gap between wide and deep, and it fits in one picture.

![Wide: the question fans into five queries, all derived from the original, through fetch and aggregate to a report in one pass. Deep: each search and read produces a thought that becomes the next query, hop by hop, until the report.](https://steel.dev/assets/framerusercontent.com/images/OQqox0YqfEPmvwYOj1pqsadCyNk.png)

Think about how you actually research something that matters. You search, you read, and the reading rewrites the next question.

The answer to hop one becomes the input to hop two.

A genealogist hits a misspelled surname in a parish record and that misspelling becomes the next query. A reporter notices the dates don't line up and chases the dates.

Nobody writes five queries in advance and stops.

The reference harness cannot follow a thread. That is the missing second hop.

Then I checked whether the big hosted products do the same thing under nicer branding.

### Where my theory fell over

They don't. I read their own engineering writeups, and almost every serious one is a hybrid: parallel fan-out inside a round, genuine iteration across rounds.

![Comparison table: every major system takes a second hop except the Claude Code deep-research workflow](https://steel.dev/assets/framerusercontent.com/images/oYzC7Eo9ZWdi0USsaz6rHQ52oSY.png)

Anthropic's [multi-agent research system](https://www.anthropic.com/engineering/multi-agent-research-system) looks like the most wide-open thing in the field: a lead agent spinning up three to five subagents *in parallel rather than serially*. But read the next sentence. The lead agent "synthesizes these results and decides whether more research is needed, and if so, it can create additional subagents or refine its strategy." That is a loop. Even the system that looks the most like a fan is iterating at the top.

The rest line up the same way:

- **OpenAI** [**Deep Research**](https://openai.com/index/introducing-deep-research/) is one reasoning model, trained with the same recipe as o1, browsing and "pivoting as needed in reaction to information it encounters." The second hop is baked into the weights.
- [**Gemini**](https://ai.google.dev/gemini-api/docs/deep-research) ships an explicit "Plan, Search, Read, Iterate, Output" loop and calls itself "an iterative, multi-step system, not a single-pass model."
- [**Perplexity**](https://www.perplexity.ai/hub/blog/introducing-perplexity-deep-research) "reasons about what to do next, refining its research plan as it learns more."

Open source splits down the same seam. [GPT Researcher](https://github.com/assafelovic/gpt-researcher) runs wide fan-out by default, then offers a separate recursive "Deep Research" mode for the tree. [dzhng/deep-research](https://github.com/dzhng/deep-research) puts `breadth` and `depth` right there as knobs and feeds each level's findings into the next level's queries. [LangChain's open_deep_research](https://docs.langchain.com/oss/python/deepagents/deep-research) goes the other way and tells its supervisor to "start with one sub-agent for most queries."

The freshest data point landed while I was editing this. Anthropic's [Claude Fable 5 system card](https://www-cdn.anthropic.com/d00db56fa754a1b115b6dd7cb2e3c342ee809620.pdf) benchmarks three multi-agent harness shapes head to head on BrowseComp, and the one that most resembles this workflow, an orchestrator that fans out subagents and blocks until they all return, loses to both non-blocking designs on latency and tokens. Their diagnosis is structural: **every round is gated by its slowest subagent, and each freshly spawned subagent pays to re-establish context.** Even at the frontier, the barrier is the tax.

So "wide, not deep" is wrong as a description of the field. What survives is more precise:

> The bundled reference harness is single-pass wide. The systems it superficially resembles are hybrid: wide within a round, deep across rounds. The whole difference is the second hop, and the second hop is the part that costs.

That last clause is the one I keep coming back to.

### Why the reference stays shallow

Why one pass and not a loop? Three reasons:

- **Depth doesn't parallelize.** A second hop has to wait on the first, so you forfeit the wall-clock win that makes fan-out attractive.
- **Depth rabbit-holes.** Left to iterate, an agent chases a tangent through a dozen queries because nothing tells it to stop.
- **Width is legible.** You can hold the whole pipeline in your head, which is exactly why it is the shape people copy.

And depth is expensive.

Anthropic reports that an agent burns roughly **4× the tokens of a chat, and a multi-agent system about 15×**. Their multi-agent setup beat a single agent by 90.2% on an internal eval, but they concede it only pays off on high-value work. (Self-reported, internal, breadth-first. Take it as direction, not fact.)

![Token cost versus a chat: 1x for chat, 4x for a single agent, 15x for multi-agent](https://steel.dev/assets/framerusercontent.com/images/KG4TISARXPM1iCH2f96JpKJe208.png)

A reference is built to be understood. Single-pass and wide is the most legible shape there is, which is why it is the one that propagates.

### The limits of adversarial verification

The harness leans hard on verification to make up for shallow search: three skeptics vote on every claim, two rejections kill it. It is the most sophisticated part of the pipeline.

But majority voting only works if the three skeptics fail *independently*. [Self-consistency](https://arxiv.org/abs/2203.11171) earns its accuracy gains exactly under that assumption: sample diverse reasoning paths, let independent errors cancel. [Recent work on deep-research agents](https://arxiv.org/pdf/2601.15808) finds the opposite. Their errors are correlated: "Errors arising in one run also tend to recur in other runs." When three skeptics share one blind spot, three votes is one vote billed three times.

So the two weaknesses are really one. The search is shallow, and the net built to catch its mistakes has the same holes the search does.

### I pointed it at real questions

To watch the shape move, I gave the harness a genuine one: does LoRA match full fine-tuning for open models in the 7B-70B range? It ran for about thirteen minutes and spawned 98 agents: five searches, sixteen fetches, seventy-five verifiers, then synthesis.

The run was on Opus 4.8. We never logged the input/output split, so the bill is an estimate, but at list prices ($5 per million tokens in, $25 out) those 2.36 million tokens can't be cheap. For one question.

![One run by the numbers: 98 agents, 533 tool calls, 2.36M tokens, about 13 minutes](https://steel.dev/assets/framerusercontent.com/images/5ykOJAX3dsQF3qJkR93Q9nfYnk.png)

The verifiers earned their keep. They killed the "new variant nearly closes the gap" claims, the easy, independent failures a skeptic can refute with one contradicting source. You can watch the whole winnowing in one chart: sources breathe in, claims breathe out, the guillotine takes the rest.

![The winnowing: 30 search results, 16 novel URLs, 77 claims extracted, 25 verified, 21 confirmed, 7 findings](https://steel.dev/assets/framerusercontent.com/images/g1tIkMs8yWiB81GJ32Y1O1BfER4.png)

But the report also flagged its own gap: the 70B evidence is thin, and the strongest claims lean on a non-peer-reviewed blog. It saw the hole and had nowhere to put it.

A deep harness would have turned that caveat into the next query. This one moved straight to synthesis, because it has no next query to make. That is the missing second hop, on a real question.

Then I ran it on a question built to break it, a needle from Perplexity's [DRACO benchmark](https://arxiv.org/abs/2602.11685): name the 5K race at California's old Great America park with "bubble gum" in its title. The answer hides in a homophone. Bubba Gump, the Forrest Gump shrimp brand, runs a "Run Forrest Run" 5K, exactly the suspiciously neat connection a single deep chain tends to find and then talk itself out of.

The harness got it, and for a structural reason. Four of the five parallel searches surfaced the homophone independently, so no lone reasoner had to trust a lucky hunch. The adversarial verifiers then kept the system from overclaiming that a shrimp brand "is" bubble gum. What it wrote was careful: the premise has a homophone error, here is the real race, medium confidence.

That careful answer is what width and skepticism produce when they fight each other. Sometimes the fan is exactly the right shape.

The Fable 5 system card puts numbers on when. Multi-agent teams posted Anthropic's highest BrowseComp score (93.3%), but the gain lives almost entirely in the hard tail: on problems most models already solve, the median multi-agent speedup was 0.8×, slower than one agent, because coordination overhead eats the parallelism.

Width is neither a free lunch nor a scam. It is a bet that your question sits in the hard tail, and the needle questions do.

### What I'd tell someone building one

- **Know which pattern you started from.** Most research agents begin life as a copied reference implementation. Ship the Claude Code deep-research shape unchanged and you ship single-pass width: cheap, fast, legible, and blind to anything that needs a second look.
- **Match topology to difficulty.** Go wide when the angles are independent and the answer is a synthesis of parallel facts. Pay for depth only when the next question genuinely depends on the last answer.
- **Budget for the second hop.** When you go deep, expect serial latency, a \~15× token bill, and a verification layer that must assume its own votes are correlated.

The frontier is not more width. It is a disciplined second hop: **knowing when to take it, when to quit, and how to trust what you find.** Nobody has cleanly solved that. It is the part we are building toward.

The harness proved its own ceiling for me. I watched it research this exact question, fan my prompt five ways, and never look back at what it found.

So I built the deep version: a research agent that routes before it searches, browses before it loops, and verifies its own claims. It got worse before it got better. The verifier I was proudest of dropped my report quality, and it took me a while to work out why. That is the next piece: *Durable Researcher: building a research agent that survives its own failures*.

I'm still thinking about the second hop. But now I have one.

## Blog: Introducing Steel Skills

https://steel.dev/blog/introducing-steel-skills · Jun 3, 2026 · By Nasr Mohamed

> Today we are launching Steel Skills, a catalog of five agent skills for the web.

**TL;DR:** Steel Skills is a catalog of five agent skills: steel-browser, steel-developer, steel-session-debugging, steel-reliability and steel-skill-creator. Each does one job and hands off to the next when the job changes. Install them with the Steel CLI, npx skills, the Claude Code marketplace or by hand.

It answers:

- What is Steel Skills?
- What are the five Steel agent skills and what does each one do?
- How do I install Steel agent skills in Claude Code?
- Why split one browser skill into several narrow skills?
- How does steel-skill-creator write a skill from real browser runs?
- Why can eval scores mislead when optimizing agent skills?

Today we are launching Steel Skills: five agent skills that give your agent a real browser, plus the judgment to know which one the job needs. Install one, or install the set, in Claude Code, Cursor, Codex, opencode, Pi, or any compatible agent.

We [shipped `steel-browser` first](https://steel.dev/blog/steel-cli-and-agent-skill), and one problem kept surfacing. With it loaded, the agent would reach for a browser even when the job was writing SDK code or debugging a failed run. Even after tuning the trigger words. One broad skill fires at the wrong moment and pulls the work sideways.

A single skill is a tool; a set of skills narrow enough to know when *not* to fire, and when to hand off, is a system.

So we split the work and built the rest.

### TL;DR

- 5 skills: `steel-browser`, `steel-developer`, `steel-session-debugging`, `steel-reliability`, `steel-skill-creator`
- Install one or the whole catalog by hand, with `npx skills`, or as a Claude Code plugin
- Each skill does one job and routes to the next when the job changes

![](https://steel.dev/assets/framerusercontent.com/images/aPWUrvMIco69UStvFqP1KNOqzx0.png)

### Why skills, why now

Agents are getting better at using computers. What still trips them up is the procedure around the task: when to open a browser instead of writing code, when to stop and inspect a failed run, when a block is a login and not a broken selector. The judgment, not the keystrokes.

A prompt tells an agent what you want once. A skill tells it how a job runs every time: when to fire, which tools to use, what to return, where to hand off.

> Skills are becoming portable operating procedures for agents.

In short time, skills went from a Claude feature to an [open format other agents read](https://agentskills.io/). Steel Skills is that, for the web.

Not one giant web skill. Not five unrelated prompts. A small system that moves the way web work moves: **operate, build, debug, recover, then compile the path you keep repeating.**

### A skill is a contract, not a prompt

A `SKILL.md` says when to act, how to run, what good output looks like, and what to do when it blocks. Less glue to rebuild per project. One path that holds across agents.

Scope was the harder call. A skill that tries to do everything triggers at the wrong moment and helps with none of it, so each of ours does one job. The narrow description is the feature. It's what makes a skill fire when it should.

What we kept coming back to was the handoff. Web work doesn't stay in one mode. You browse, it breaks, you need to know why, then you need it fixed. So `steel-browser` routes a dead session to `steel-session-debugging`, which gathers the evidence and hands it to `steel-reliability`.

We'd rather compile a skill than write one. A [Steel Agent Trace](https://steel.dev/blog/why-we-built-agent-traces) already holds the selectors, the wait points, and the input values. `steel-skill-creator` reads two real runs and writes the skill from what happened in the browser, not from what someone remembered to type.

![Steel-skill-creator reads two real runs and writes the skill from what happened in the browser.](https://steel.dev/assets/framerusercontent.com/images/ph36io2ber47BkKgCzIKeiORh8.png)

Skills execute real work, so we treat them like operational code: narrow scope, explicit failure modes, clear handoffs, no magic bypass. `steel-reliability` starts with the cheapest fix and never promises a guaranteed way past bot detection. And the `SKILL.md` is portable. Write the capability once; it follows you when your tools change.

### The five skills

New here? Start with `steel-browser` and `steel-developer`. Add the rest when you're running repeated workflows or chasing failed sessions. Less is more with skills, so feel free to optimize.

| Skill | What it does | Reach for it when |
| - | - | - |
| [`steel-browser`](https://docs.steel.dev/overview/skills/available-skills/steel-browser) | Scrapes, clicks, fills forms, takes screenshots, exports PDFs, logs in, and gets through pages that only render with JavaScript. | A live web task, right now |
| [`steel-developer`](https://docs.steel.dev/overview/skills/available-skills/steel-developer) | Writes the code instead of doing the task: SDKs, REST, Playwright, Puppeteer, Stagehand, Browser Use. | Reusable code you'll run later |
| [`steel-session-debugging`](https://docs.steel.dev/overview/skills/available-skills/steel-session-debugging) | Works backward from a failed run. Pulls the logs, traces, replay, and network calls, builds a timeline, and tells you what broke. No guessing. | A run failed and you need to know why |
| [`steel-reliability`](https://docs.steel.dev/overview/skills/available-skills/steel-reliability) | Diagnoses what's blocking you (CAPTCHA loops, proxy failures, bot detection, login state that won't stick) and works up from the cheapest fix. | You keep getting blocked |
| [`steel-skill-creator`](https://docs.steel.dev/overview/skills/available-skills/steel-skill-creator) | The strange one. Runs a task you repeat twice, diffs the runs to find which parts are inputs, writes a skill from the difference, and verifies it on a third run. | You keep doing the same flow by hand |

This was a team build: Jun made `steel-browser`, Dane wrote `steel-developer`, Nas owns both `steel-session-debugging` and `steel-reliability`, and Niko built `steel-skill-creator`.

### Install

A few ways to install a skill: the Steel CLI, `npx skills`, the Claude Code marketplace, or by hand.

Every skill drives the Steel CLI, so install and authenticate it once first:

```sh
curl -fsS https://setup.steel.dev | sh
steel login
```

**With the Steel CLI.** You just installed it, so this is the shortest path:

```sh
steel skills list
steel skills install steel-browser
```

**With** **`npx skills`.** List what is available, then add one:

```sh
npx skills add steel-dev/skills --list
npx skills add steel-dev/skills --skill steel-browser
```

**Through the Claude Code marketplace.** Add the catalog, then install skills by name:

```sh
/plugin marketplace add steel-dev/skills
/plugin install steel-browser@steel-skills
```

**By hand.** A skill is just a folder with a `SKILL.md`, so you can copy it straight into your agent's skills directory:

```sh
git clone https://github.com/steel-dev/skills
cp -r skills/steel-browser ~/.claude/skills/
```

After installing, restart your agent client so it can discover the skill, then verify it loaded:

```sh
steel skills doctor
```

### What we learned

Before we shipped, we spent real time optimizing these skills against evals, and learned how easily a score lies. A skill could return the right-looking answer while running commands that don't exist, and the eval would rank it first. Tuning the wording to win taught it to look good on cases we'd already seen. On held-out tasks, the same skill cleared barely half. What held up was checking the run itself: did the commands work, did the session do what the skill claimed. That's why `steel-skill-creator` builds from real traces.

### Try it

Install one skill. Run one real flow. Then tell us one blocker and one pass in [Discord](https://discord.gg/steel-dev).

Learn from our docs how skills help coding agents to use Steel cloud browsers correctly: <https://docs.steel.dev/overview/skills>

## Blog: Errors Are the Interface Agents Actually Read

https://steel.dev/blog/errors-are-the-interface-agents-actually-read · Jun 2, 2026 · By Nasr Mohamed

> Write API errors that correct the agent mid-failure, before the user calls it broken.

**TL;DR:** For agent-facing APIs, errors are the one surface an agent reads unfiltered at the moment it must act, so each should say what happened, which input was wrong and how to fix it. Changing Steel's session ID error to ask for a valid UUID cut that endpoint's error rate by more than half. Accepting Bearer auth may have been wrong.

It answers:

- How should API error messages be written for AI agents?
- Why are error messages important for agent-facing products?
- What auth header does the Steel API use?
- What is the difference between hard errors, soft warnings and passive context for agents?
- How much did a clearer error message reduce Steel's error rate?

> *TL;DR: Error messages are not just cleanup copy. For agent-facing products, they are one of the few places where the product gets to correct the agent while it is actively screwing up, before the user decides the whole thing is broken.*

We've been overhauling errors recently. Not as a polish pass. Not because someone found religion about microcopy. Because the logs kept showing us the same ugly thing: people were failing, agents were confidently making it worse, and our product was giving them almost nothing useful at the moment it mattered.

When an error fails to do its job, the user (or the agent acting on their behalf) walks away assuming something is broken on our end. Usually it isn't. They just couldn't tell.

The principle I keep coming back to is simple.

Every bad error message is a missed activation. Every one. The error is the first place your product talks back to someone who is, right then, deciding whether you're worth their next hour. If it sounds confused, you sound confused. If it points them at the fix, you just bought yourself a little bit of trust.

I want to walk through what we're working on right now. Including one fight I had with a coding agent that I'm reversing my position on, live, in this article.

### What we're moving every error toward

The shape we're trying to push every error into is roughly this: what happened, in the language of the user's input; which assumption or input was wrong; and how to do it correctly. Plus a link, ideally to a docs page that's structured to be parsed by an LLM as well as read by a human. Clean markdown.

We've built the mechanism to include docs links directly in JSON error responses, so when the user (or their agent) logs the failure, the link sits next to the message. Why this matters: a lot of what we were seeing came from people and agents who hadn't read the docs, or there was a page in the docs that already explained exactly what they'd hit, and they had no way to find it from inside their context.

Agents amplify that problem. They will confidently act on a bad prior unless the product corrects them at the moment of failure. That's the loop we're trying to close: the failure should carry the next useful pointer, instead of forcing the user or the agent to go hunting for it somewhere else.

Honestly though, the bigger lever has been embarrassingly simple: write the error like the person or agent reading it has never seen your docs, because they usually haven’t. Not more words. More context. A single sentence that names the cause and the fix beats a docs link the agent has to click to get to the same information.

![](https://steel.dev/assets/framerusercontent.com/images/rtCDnwZjRlyrKd5S6jFQn4OZ8.png)

### The UUID example

The cleanest before/after I have is the session ID error.

You can optionally pass [your own session ID](https://docs.steel.dev/overview/sessions-api/quickstart) when you create a session in Steel, and it has to be a UUID. Users (and increasingly, coding agents) kept passing in random strings. Our original error was something like "format incorrect." It didn't really mean anything. The agent would see it, shrug, try a different random string. Technically accurate. Functionally useless. The worst category.

We changed it to tell the user, in one line, to pass a valid UUID. That was it. The error rate on that endpoint dropped by more than half. And this was before agents got good. Even regular users were hitting that one bad sentence and bouncing.

A vague error doesn't fail safely. It fails quietly into the category I'd describe as "the user concludes the product doesn't work." A specific error turns that same moment into a one-second correction.

The happy path gets users interested. The failure path decides whether they come back.

### The Bearer fight

Steel doesn't use the `Authorization` header at all. Our [auth header](https://docs.steel.dev/api-reference) is a custom one: `steel-api-key: <your-key>`. The reason was boring and practical: Steel spends a lot of time around other people’s websites, cookies, proxies, sessions, and auth state, so we wanted our control-plane auth to be extremely explicit. `steel-api-key` is ugly in a useful way: you can see exactly what it is.

People kept sending us `Authorization: Bearer <your-key>` anyway. Mostly coding agents. The agents were confused in the most boring possible way: they had seen ten million APIs use Bearer auth, and decided ours did too. The model would confidently tell users that's how the API works, they'd paste the snippet, the request would fail. We'd see the same pattern over and over in the logs.

First push: a clear error that said we don't use `Bearer`, with a link to the docs. The error fired. It barely moved the needle. My best guess is that the model already had `Bearer` baked in deep, from an old crawl or just generic API priors, and one error wasn't going to dent it.

At that point, the practical answer looked obvious: accept what agents were already sending.

So we caved. We started accepting `Authorization: Bearer <your-key>` as a silent alias alongside the canonical header. The bet was we could remove the alias later, once the data showed people were converging on the right one. This is the kind of sentence engineers write shortly before creating permanent compatibility debt.

Note: I am now increasingly convinced this was wrong, which is annoying because I was there when we did it. Talking it through with the team changed how I think about what an error actually is.

### The last surface that doesn't get distilled

Almost everything else we ship gets quietly absorbed by the model companies on the other end.

Docs go into training dataset, then through retrieval, then through whatever summarization the agent runs before it acts. SDK examples get rewritten in whatever the model already prefers. Blog posts get compressed into one-liners long before they reach a decision.

![](https://steel.dev/assets/framerusercontent.com/images/YmjppM3575De8uyKdnMVwuzKo.png)

By the time any of that lands in the loop where the agent is choosing how to call Steel, it's been through several layers of compression.

Errors are different. The error fires inside the agent's loop in real time, because the request just failed and the agent has to decide what to do next. Nothing sits in between. No retrieval pass, no distillation, no helpful little summary. The model is reading what we actually wrote, at the moment it has to act on it.

That's a different writing surface from anything else we ship. Docs depend on training cycles. SDK examples get filtered through whatever the model already thinks your API looks like. Errors don't. They're the last place where you can still teach the model something specific about your product, and have a reasonable expectation that the message lands intact.

Which is exactly why accepting Bearer may have been the wrong call. We traded away the one surface where the product could correct the agent, in exchange for short-term ergonomics. We took ourselves out of the loop.

### Hard errors, soft errors, and the FYI channel

Once you start thinking this way, you notice that a lot of what an agent needs from you isn't even an error.

CLIs have had this pattern forever. Warning, you're probably doing this wrong, FYI, I'll still let you run it. That same shape belongs in agent-facing surfaces, and we're not doing nearly enough of it.

The agent creates a session, the request succeeds, and somewhere in the next two minutes the session is going to break because they're on a site that [needs a proxy](https://steel.dev/blog/anti-bot-defense). A passive "FYI, you probably want a proxy here" is worth more than the hard error five minutes later, when the session is already trashed.

![](https://steel.dev/assets/framerusercontent.com/images/qFzc2GmujUQ3kM92auiNimxPE4.png)

So the model in my head is roughly three channels. **The hard error:** the request failed, here's the cause and the fix, return them inline. **The soft warning:** the request worked, but you're heading somewhere you'll regret. And **passive context:** things that are just true about the environment the agent is operating in (this site, this session, this auth state) that the agent should know without having to ask.

The third one is where I think the most interesting work is.

### Agent notes, and generating errors from the data

There's a version of that third channel we've been kicking around. Internally we call them agent notes. Small, scoped pieces of context, attached at whatever level of granularity makes sense. Some are general; about sessions, about antibot. Some are per-site or per-URL. "On this page, the visible login button doesn't actually submit, click the second one." That kind of thing.

You don't have to hand-write all of them. We already capture session tags and events for the common situations users and agents end up in. Cluster those, find the recurring failure shapes, and you've got the raw material to either write better errors or generate per-context notes against the actual distribution of what's going wrong. Past a certain volume, the loop automates itself. Detect the cluster, draft the note, ship the fix.

A lot of what we've historically tried to handle with [skills](https://steel.dev/blog/steel-cli-and-agent-skill) (pre-written instructions for an agent about how to use Steel) collapses if the tool teaches well enough in the moment. The skill is doing extra work because the error isn't.

### Progressive disclosure, and the CLI logs thing

The other thing we are working on, partly in service of all of this, is real-time [CLI](https://docs.steel.dev/overview/steel-cli) logs the agent can follow, grep, tail, head. Basically consume the way a human consumes a long log file. Open one log at a time. Scan. Decide whether you need more.

It's the same shape Anthropic uses in Claude Code. A small model decides whether the doc is needed at all, then which section, then the full file if it has to. Progressive disclosure. I think that's exactly how agent-facing logs should work. The agent doesn't want everything. It wants the next useful thing, and the ability to ask for more if that's not enough.

The reason this matters for errors: the error is the entry point into that log. If the error is good, the agent might not need the log at all. If the error is bad, the log is where the agent has to go to recover. Right now, for most infra products, that path doesn't really exist.

### Why "activation" is the right word

I want to come back to why I think activation is the right frame, and not, say, developer experience, agent experience, or error UX.

When a user (or an agent) hits a confused error, the default assumption isn't "I made a mistake." It's "this product is broken."

Or, almost as bad: "this is too hard to figure out, not for me." Either way, you've lost the activation. You don't get a second chance to teach them. They leave, and honestly they're right to leave, because from where they're sitting you didn't give them any reason to stay.

A good error does the opposite. The product told them, in one line, what they got wrong and how to fix it. That sounds small, but it changes what the user assumes about the system.

### What I think we're really doing

The biggest unlock for anything agentic is the feedback loop (we already do a version of this with [Agent Traces](https://steel.dev/blog/why-we-built-agent-traces)). Close it, and the agent figures everything out on its own. Leave it open, and nothing on the prompt side rescues you.

Errors are the densest part of that loop. They're the moment the system tells the agent something it didn't already know. There's a version of the future where this gets its own channel. An **agent mailbox**, parallel to the API response, where we can push context and warnings that a human user doesn't need but an agent does.

We're not there yet. But it points at the same thing the rest of this points at. The failure path of your product is a teaching surface. And right now it's the only surface the agent actually has to read.

Try this in your own product: take the 10 most common API errors, rewrite each one as a recovery instruction, and measure whether retries improve.

## Blog: Why we built inactivity timeouts

https://steel.dev/blog/why-we-built-inactivity-timeouts · Jun 2, 2026 · By JunHyoung Ryu

> Steel's inactivityTimeout releases a session after a set window of silence, so idle and crashed runs stop billing.

**TL;DR:** Steel's inactivityTimeout releases a session when nothing is sent to the browser for a set window, so crashed or abandoned runs stop billing before the hard timeout (5 minutes by default, up to 24 hours). It is off by default, approximate, always capped by the hard timeout, and records inactivity_timeout as the reason.

It answers:

- How do I make a Steel session release itself when my agent goes idle?
- What is the difference between timeout and inactivityTimeout in Steel?
- What counts as activity for Steel's inactivity timeout?
- How do I stop paying for a browser session after my script crashes?

A Steel session can release itself when your agent goes quiet.

You set `inactivityTimeout` when you create a session, and if agent doesn't talk to the browser for that long, Steel shuts it down for you. So you stop paying for an idle browser when a run finishes or your agent quietly dies before it can clean up behind itself.

Apparently this is becoming a series. The last one was [Why we built Agent Traces](https://steel.dev/blog/why-we-built-agent-traces); this one is smaller.

### One number was doing two jobs

Every session runs through a simple [lifecycle](https://docs.steel.dev/overview/sessions-api/session-lifecycle), and the hard `timeout` you set is the longest it can stay Live before Steel releases it. Five minutes by default, up to 24 hours. Sessions are metered by the minute, so that single number ends up carrying a trade-off it was never meant to carry.

Set it short and a long task gets cut off mid-run. Set it long to be safe, and the failure flips: if your script crashes or you walk away, the browser stays Live and keeps metering until the full cap runs out. A 24-hour cap is fine right up until a dead job sits Live for 24 hours.

The honest answer was always to release the session yourself the moment you're done. And you should. But `release()` assumes your code reaches the `release()` call. Crashes don't. Hangs don't. Abandoned runs don't. The cases where you most want the session gone are the ones where your cleanup never runs.

So we built a floor that doesn't depend on your code getting there.

### A shorter fuse under the cap

```js
import Steel from 'steel-sdk';

const client = new Steel();

// Release the session after 1 minute with no CDP or input activity,
// capped at a 10-minute hard limit.
const session = await client.sessions.create({
  timeout: 600000,          // 10 minutes (hard cap)
  inactivityTimeout: 60000, // release after 1 minute of inactivity
});
```

The session stays Live as long as you keep driving it, up to the 30-minute cap. Go quiet for 60 seconds and Steel releases it.

What counts as activity is deliberately simple: anything you send the browser resets the clock. CDP commands from Puppeteer or Playwright, clicks and typing through the live view. Each one starts the count over.

What doesn't count is the browser working on its own. A slow page load, or a scrape that's just sitting on the network, sends nothing. To the timer, nothing is silence. If a quiet stretch runs longer than your window, it trips mid-task. So set the window longer than the longest gap you expect between commands.

### It's a floor, not a stopwatch

A few things to know before you lean on it. The hard `timeout` always wins, so inactivity only helps when it's the shorter of the two. It's off by default; omit it and nothing changes. And it's approximate: the check runs on the session's heartbeat, so expect "about a minute of silence," not an exact one. A session closed this way records its reason as `inactivity_timeout`, so later you can tell "we cleaned it up" apart from "it fell over."

None of this replaces releasing sessions yourself, which is still the cleanest way to stop the meter the instant you're done. Think of the hard `timeout` as how long a session may live, and `inactivityTimeout` as how long it may sit doing nothing before Steel assumes you've gone. It's a small safety net for the runs where your code never gets the chance.

### Try it

It's live in the SDKs now. Pass `inactivityTimeout` to `client.sessions.create()` alongside your existing `timeout` and give a long-running job a short idle fuse.

- [Why we built Agent Traces](https://steel.dev/blog/why-we-built-agent-traces)
- [Docs](https://docs.steel.dev/)
- [Free API key](https://app.steel.dev/sign-up)
- [Discord](https://discord.gg/steel-dev)

Humans use Chrome. Agents use Steel.

## Blog: Browser Agent Leaderboards, rebuilt

https://steel.dev/blog/browser-agent-leaderboards-rebuilt · May 29, 2026 · By Hussien Hussien

> Benchmarks go stale fast. We rebuilt the Steel agent leaderboards to track results as they land.

**TL;DR:** Steel rebuilt its Browser Agent Leaderboards (v4, at leaderboard.steel.dev) to add new results with their date, source and methodology as they land. Ten benchmarks sit on the homepage, including OSWorld, where Claude Opus 4.8 leads at 83.4%. Scores do not compare across benchmarks; use a rank to shortlist, not as a verdict.

It answers:

- What is the Steel browser agent leaderboard?
- Which AI agent ranks #1 on OSWorld?
- Why aren't scores comparable across different agent benchmarks?
- How often is the Steel leaderboard updated?
- How do I get my agent's score on the leaderboard?
- Should I pick an agent based on its leaderboard rank?

Benchmarks rot.

A paper reports a score once and freezes. The new results show up on Twitter, in model cards, in someone's blog post, and the original source never gets updated to match. Six months later the number you're citing is neither the latest nor the highest, and you'd never know.

It's worse under the surface. Methodology drifts: a model gets deprecated, a website in the task set goes offline, the scoring harness changes, and the "same" benchmark is quietly measuring something else. No two benchmarks measure the same thing, so you can't line one score up against another. And every model release reports on a different set of benchmarks, so even the model cards are hard to compare.

Instead of chasing that across a dozen sources that each went stale on a different day, we keep one current. We rebuilt the Steel leaderboards to track results as they actually land, with the source and methodology on the page, across the benchmarks that matter for browser and computer-use agents.

Live now at [leaderboard.steel.dev](https://leaderboard.steel.dev/).

[Video on YouTube](https://www.youtube.com/watch?v=JFNXJXoPnjE)

### Why we maintain it

We've kept this leaderboard running since February 2025 and reshaped it three times since. This is v4, and we're honestly still hunting for the right form.

We maintain it for a selfish reason. Every Steel project starts with the same question: which benchmark do we even trust here? Our customers ask us the other half: which agent is actually best, and how do we build on it? This is our running answer to both, in the open.

### Everything on one page

Ten benchmarks, on the homepage instead of buried a click deep: WebVoyager, BrowseComp, WebArena, SWE-bench Verified, OSWorld, GAIA, ClawBench, Online-Mind2Web, τ-bench, and AgentBench. You see the whole field the moment you land.

(The green pixel-cursor mark from the site's first release is back next to the title. Small thing. We missed it.)

### We keep it current

This is the part that rots everywhere else. When a new result lands, we add it, with its date. Claude Opus 4.8 went to #1 on OSWorld at 83.4%, and it was on the board the day it shipped. The original OSWorld paper still reports what it reported at publication.

Every result also carries where it came from: source, repo, who reported it. Self-reported or third-party verified.

### Scores don't compare across benchmarks

We put this at the top of the results page, not in a footnote: a 92% on one benchmark and an 80% on another is not a ranking. It's two different exams, with different tasks, scoring, and scope. Even inside a single benchmark, rows vary by evaluator, harness, attempt budget, tool access, or verification level.

Results is the one place to see it all: filter by category or benchmark, search by agent or company, freshest first.

### The small stuff

- Copy any results table as markdown in one click.
- A table of contents that follows you down long pages.
- Sharper share cards when you drop a link in Slack or X.

### Come add to it

The board stays current because it's maintained, not because it's finished. If you've got a verifiable score we're missing, the [contribution guide](https://github.com/steel-dev/leaderboard/blob/main/CONTRIBUTING.md) spells out exactly what evidence to bring, and there's a separate bar for proposing a whole new leaderboard.

### Go look

Live now at [**leaderboard.steel.dev**](https://leaderboard.steel.dev/). Open a benchmark that matters to your work and read past the top row.

- See the benchmark: [leaderboard.steel.dev](https://leaderboard.steel.dev/)
- Build the agent you want on the board: [get a free Steel API key](https://app.steel.dev/sign-up)
- Spot a result we missed: [Discord](https://discord.gg/steel-dev) or [@steeldotdev](https://x.com/steeldotdev)

### FAQ

**What is the Steel browser agent leaderboard?**

A public set of leaderboards at leaderboard.steel.dev tracking how AI agents and models perform across 10 benchmarks spanning browser agents, computer use, research, and coding: WebVoyager, BrowseComp, WebArena, SWE-bench Verified, OSWorld, GAIA, ClawBench, Online-Mind2Web, τ-bench, and AgentBench. Each result carries its source, repo, and reporter, and each benchmark page explains the task set and scoring.

**How often is the leaderboard updated?**

Continuously. When a new result lands, we add it with its date, rather than waiting for an original paper to revise, which it usually never does. Claude Opus 4.8, for example, was on the OSWorld board at #1 (83.4%) the day it shipped. Each row also notes when methodology drifts, like a deprecated model or a changed scoring harness, so an aging number doesn't masquerade as a current one.

**Why aren't scores comparable across different benchmarks?**

Each benchmark is a different exam. WebVoyager scores task completion across 643 web tasks evaluated by GPT-4V. OSWorld scores desktop automation across 369 tasks via execution-based validators in a VM. BrowseComp scores short-answer research questions. Different tasks, scoring, and scope, so a percentage on one says nothing about a percentage on another.

**Which AI agent ranks #1 on OSWorld?**

As of 2026-05-28, Claude Opus 4.8 leads OSWorld with 83.4%, above the 72.36% human baseline from the original paper. OSWorld measures multimodal desktop automation across 369 tasks using execution-based validators that check the final computer state after the agent acts.

**How do I get my agent's score on the leaderboard?**

Open a submission following the contribution guide on GitHub. It defines the evidence a score needs (source, reproducibility, and verification level) and the separate bar for a whole new leaderboard. Scores get listed on evidence, not announcements.

**Should I pick an agent based on its leaderboard rank?**

Treat the rank as a directional signal, not a verdict. The board shows methodology, provenance, and verification for each score, but it can't tell you about latency, cost per task, anti-bot resilience, or how an agent generalizes to your specific sites. Use it to shortlist, then test candidates on the workflows you actually run.

## Blog: Why we built Agent Traces

https://steel.dev/blog/why-we-built-agent-traces · May 28, 2026 · By JunHyoung Ryu

> Agent Traces records every browser-agent session as a replayable timeline. Inside the rebuild, and why intent is what agent observability still has to solve.

**TL;DR:** Agent Traces replaced Agent Logs, which stored raw CDP events as coordinates and key codes. Capture moved into the page, so each action records the element, its name and stable selectors, and the trace collapses raw events into readable rows. A markdown export feeds coding agents, but a trace still lacks the agent's intent.

It answers:

- What is Steel Agent Traces?
- Why did Steel rebuild Agent Logs into Agent Traces?
- Why capture browser interactions inside the page instead of through CDP?
- How does Agent Traces collapse raw input events into readable steps?
- Can one browser agent trace be turned into a reusable skill?
- How do I turn a Steel session into a script with a coding agent?

Agent Traces records what a browser agent actually did during a browsing session: every click, keystroke, and navigation, captured as a readable timeline and as a document you can hand to another agent to replay the same task.

It started as a side effect of a different problem

I was trying to extract reusable skills from real browser sessions. Give the agent a task, let it figure out the path, then turn that path into something another agent could replay. We'd been kicking the skill idea around inside Steel for almost a year, long before the current wave of skill formats. Every time I sat down to actually build it, I hit the same wall: I didn't have enough signal in the session.

What I had was Agent Logs. Agent Logs was the v0 of all this. It captured raw CDP events as they flew past, click, type, navigate, and stored them as a flat list. A click row told you a click happened at some coordinates. It didn't tell you what was clicked. Typing showed up as N rows of single-key events. There was no "the agent typed an email into the email field," because there was no notion of fields. Just coordinates and key codes.

You can't generate a reliable skill from that. You can replay it on the same page at the same viewport, but it breaks as soon as the layout shifts.

So I rebuilt it from the capture layer up.

![New session view with Agent Traces](https://steel.dev/assets/framerusercontent.com/images/Q31NvmTZJO1ut4qVWGLCgpBjdmE.png)

### Instead of scraping CDP, capture the page

The first instinct was the lazy one. We were already proxying every CDP event. Why not, when a click fires, send another CDP command back to the page to ask what element lives at those coordinates?

I tried. It works, technically. It's also slow enough that the timeline drifts under real load, and slow enough that you start missing the second event in a burst. CDP round-trips are not free, and adding one to every interaction turns the capture path into a bottleneck.

The fix was to move the point of capture into the page itself. Now each interaction is recorded the moment it happens, with the context only the page has at that instant: what the element actually was, the name a person would use for it, a few stable ways to find it again, and where it sat on the page. That's the difference between "a click landed at (x, y)" and "the agent clicked the Sign in button."

Everything else in the product is downstream of that. The readable timeline, the frame-accurate seek, the markdown export. All of it works because the capture point moved from outside the page to inside it.

It was harder to ship than I'd guessed. The injection has to survive navigations, weird frame contexts, and the various ways pages try to defend themselves against scripts they don't recognize.

### Collapsing is opinionated

Raw events are the source of truth, and we keep them. But the raw stream is just a log, and a log of human-shaped activity is unreadable.

When you type the word `apple`, that's five separate input events, one per character. Storage keeps all five. The trace layer collapses them into a single `input(len=5)` row against the email field. Two clicks on the same element within half a second collapse into a double-click, because our capture stream sees individual clicks and we'd rather show the intent than two raw rows. Gaps over ten seconds become idle dividers, so a long pause doesn't disappear into whitespace.

The collapsing rules are opinionated. Aggressive enough to be readable, conservative enough that you can still drop into the underlying raw events when you need them. The boundary lives in the backend, not in storage, which means we can change our minds later without rewriting history.

![Raw CDP events vs. a collapsed agent trace](https://steel.dev/assets/framerusercontent.com/images/kUNHrEG2OLy4i6cgeIwuvSIdOs.png)

### A trajectory is one happy path

Here's the limit you hit fast: **one trace is one path through the site.**

If you take that single trace and try to turn it into a generalizable skill, you get a script that works on exactly the conditions you captured. The cookie banner you didn't see the second time. The A/B variant you didn't get. The retry the network didn't need.

It seems a handful of trajectories is sometimes enough to start generalizing from. The first bit of signal should come from the agents themselves: they need to tell us whether a run succeeded or failed. Once we have that, a stack of traces becomes more than just recordings. One thing we're looking at is stacking several runs of the same task to see where they line up and where they diverge. The parts that repeat are the reliable spine of a skill; the parts that vary are where it has to adapt.

The interesting work sits on top of that, and it only works if the capture underneath is faithful enough to trust.

### A trace without intent can't teach an agent

The feature people keep grabbing onto is the markdown export.

Click a button, get a document built to paste into another agent: page headings, numbered steps, stable selectors per step, idle markers, redacted secrets. Paste it into Claude Code, Cursor or Codex and ask for a Steel script that reproduces the run.

![In Agent Traces now you can Copy as prompt](https://steel.dev/assets/framerusercontent.com/images/AxvVxSpwkFpmues8eCAvOqVJy8.png)

But what it gives you is the trajectory: the path the agent took, and nothing more.

The trace knows the agent clicked "Sign in." It doesn't know whether the agent meant to, or thought it was clicking something else, or which branches it weighed and dropped, or whether the run even worked.

That gap matters more than it looks.

A trajectory without intent is replayable but uneducable. Another agent can redo the exact steps, but it can't learn from them, because nothing in the trace records the reasoning that produced them.

This is the part of agent observability I think everyone is going to have to solve. Logs told us what a server did. Distributed traces told us how a request moved through a system. Agent traces have to go one further: **capture not just what the agent touched but what it was trying to do**, or they stay very detailed recordings of moves nobody can explain.

So that's what we're building next.

### Try it

Agent Traces is live in the dashboard. Open any session at [app.steel.dev](https://app.steel.dev/) and you'll find the Agent Traces tab in the session console, next to Details and Logs. Run a task, copy the session as markdown, paste it into your editor and ask for a script back.

## Blog: Agent Traces: every browser session as a prompt

https://steel.dev/blog/agent-traces · May 22, 2026 · By Nikola Balic

> Every Steel browser session is now a readable timeline synced to the video, and a markdown prompt you can paste into your coding agent.

**TL;DR:** Agent Traces turns every recorded Steel session into a readable timeline of coalesced actions, synced frame-accurately to the video via HLS program-date-time. Rows expand to element details and prioritized selectors, a session copies as a markdown prompt for coding agents, and data comes live over WebSocket or via REST.

It answers:

- What is Steel Agent Traces?
- How do I turn a browser session into a prompt for a coding agent?
- How do I reproduce a browser agent run as a script?
- What API endpoint returns the agent traces for a Steel session?
- What is the difference between the agent-traces and agent-logs endpoints?
- Can I watch agent actions live while a session runs?

Today we're shipping Agent Traces.

Open any recorded session in your dashboard and you'll find a new tab that turns the whole run into a readable timeline.

Every action the agent took, synced to the video frame by frame. Click a row, the video seeks. Click "copy as markdown" and the entire session becomes a prompt you can paste into your next agent.

[Video on YouTube](https://www.youtube.com/watch?v=dxALbPqs7Bw)

### What you see

Each row in the timeline is one coalesced activity.

Each row reads like a sentence: `click on Sign in`, `input(len=17) on Email field`, `navigate to /home`. Typing collapses into one row, not seventeen keystrokes. Idle stretches over ten seconds show up as `idle 23s` dividers.

The label is whatever a person would actually call the element. No more `<button class="x-3f9a">`.

Color-coded icons let you scan a long timeline at a glance: click, type, navigate, scroll, drag, submit, error.

### The video and the timeline are the same thing

Click any row and the video jumps to that exact moment. The seek uses HLS program-date-time, so it's frame-accurate, not a guess.

Look at the scrubber: each activity gets a small color-coded tick. You can see at a glance where the dense bursts of work were and where the agent was idle. Hover the scrubber and you get a thumbnail preview. Drag along it to scrub.

As the video plays, the row matching the current frame highlights. Hover a marker on the bar and the matching row scrolls into view. The two views stay in sync no matter which one you drive.

### The agent traces drawer

Click on a row and it expands inline. You get:

- Element details: tag, role, accessible name, every attribute that was on the element, bounding box.
- A prioritized list of selectors, in the order Steel uses internally to pick the canonical one: testId, id, aria, name, CSS, XPath.
- Pointer or keyboard details: exact x/y, button, click count, key code, modifiers.
- The page URL when this happened.
- The raw JSON of the underlying event, with a copy button.
- A thumbnail of the video frame at that instant, clickable for full-size preview.
- For coalesced runs like a typing burst or click sequence, how long the run took.

You almost never have to leave this view to figure out what happened.

### Copy as markdown, designed for agents

Hit "copy as markdown" on any session and you get a single document built to be pasted into another agent as context. It includes a built-in preamble that explains its own format.

The output reads like **a recipe an automation agent could re-execute**, and that's the explicit intent.

Paste it into Claude Code, Codex, OpenCode or Cursor with "write me a Steel script that reproduces this," and the selectors, step structure, and timing are already there. JSON export is available too if you'd rather drive it programmatically.

### Live updates

For sessions that are currently running, the timeline streams in real time over a WebSocket. New activities arrive incrementally, get deduplicated, sorted into place, and re-collapsed. Watching a live agent run feels like watching it think out loud, action by action.

When the session ends, the same data is available statically via REST.

### API

Two authenticated endpoints:

- `GET /sessions/:id/agent-traces` is the semantic timeline. Returns `{ events, total, hasMore }` where each event is an `AgentActivity` (click, input, navigate, scroll, drag, keyPress, submit, error). Use this one.
- `GET /sessions/:id/agent-logs` is the old one, raw CDP-derived events. Lower-level, retained for compatibility.

Plus a WebSocket channel for the live stream.

### What this unlocks

The first thing we keep coming back to is debugging. Instead of scrubbing video looking for the moment something went wrong, you scroll the timeline, spot the error row, click it. The video jumps to the failure. The drawer shows the element the agent was interacting with and the error message.

The second is reproducibility. Open the markdown export, paste it into your editor, ask the agent to write a script that reproduces the run. The selectors and step structure are designed for exactly this.

The third is auditing. A human-readable record of every interaction, with timestamps, in one scrollable view. Useful for trust and safety reviews, customer support investigations, and post-mortems.

### Get started

Agent Traces is generally available right now. Open any session in [app.steel.dev](https://app.steel.dev/) and you'll see the new tab next to Console Logs and Network.

Try it on a session you already have. Copy one as markdown, paste it into your favorite agent, and tell us what it builds.

- Dashboard: [app.steel.dev](https://app.steel.dev/)
- Docs: [docs.steel.dev](https://docs.steel.dev/)
- Questions or feedback: [Discord](https://discord.gg/steel-dev) or [@steeldotdev](https://twitter.com/steeldotdev)

## Blog: Eight ways to build a browser agent

https://steel.dev/blog/eight-ways-to-build-a-browser-agent · May 4, 2026 · By Nikola Balic

> New framework starters in the Steel cookbook, all solving the same browser task.

**TL;DR:** New Steel cookbook starters all run one task, github.com/trending/python, with the same four tools (open_session, navigate, snapshot, extract) and a Zod or Pydantic output schema. They cover LangGraph, Pydantic AI, OpenAI Agents, Claude Agent SDK, Mastra and Vercel AI SDK, so the only difference is the framework's agent loop.

It answers:

- Which agent frameworks have browser agent starters in the Steel cookbook?
- How do I build a browser agent with LangGraph and Steel?
- How do I get typed final output from a Vercel AI SDK ToolLoopAgent?
- Why does the OpenAI Agents SDK reject .optional() in Zod schemas?
- How do I run a Steel cookbook starter?

We landed eight new starters in the [Steel cookbook](https://github.com/steel-dev/steel-cookbook). Same task, same four tools, same typed output. Different agent loops.

If you've spent an afternoon picking between LangGraph and Pydantic AI and Mastra, you know the marketing pages don't help much. You want two files open side by side, the same task running through each, and a clear read on where each framework gets out of your way and where it doesn't.

That's the cookbook now.

### Why one task

The task is github.com/trending/python. It runs in seconds, requires no credentials, and actually needs a browser. The page renders without JavaScript, but the structured-output step makes you exercise tools, schemas, and the agent loop end-to-end. Small enough to not waste your afternoon, real enough to expose real problems.

The scaffolding is identical, so whatever differs is the framework.

The same four tools across every starter means the prompts, schemas, and failure modes are shared too. If a model forgets to open a session on one starter, it forgets on the others.

### The recipe

Four tools, same names everywhere:

```js nocopy
open_session  -> create a Steel session, connect Playwright over CDP
navigate      -> goto(url), wait for domcontentloaded
snapshot      -> readable text + visible links, capped
extract       -> rows scraped from a CSS selector, returned as JSON
```

The output is a Zod or Pydantic schema: `summary` plus an array of `{name, url, stars, description}`. The model loop runs until the schema validates or the step budget runs out (15 in most starters).

### What landed

#### Python

- [**`langgraph`**](https://github.com/steel-dev/steel-cookbook/tree/main/examples/langgraph): explicit state machine. Three nodes (`agent`, `tools`, `format`), conditional edges, `ToolNode` and `tools_condition` from the prebuilts. If you want to see the graph instead of trusting an SDK, this is the one.
- [**`pydantic-ai`**](https://github.com/steel-dev/steel-cookbook/tree/main/examples/pydantic-ai): provider-agnostic, dependency-injection style. `deps_type=BrowserDeps` threads the Playwright `Page` through every tool via `RunContext.deps`. The final turn is typed because `output_type=FinalReport` ties it to the schema.
- [**`openai-agents-py`**](https://github.com/steel-dev/steel-cookbook/tree/main/examples/openai-agents-py): `Agent(tools=[...], output_type=FinalReport)`, one `Runner.run()` call, the SDK runs the loop. Tools are plain async functions wrapped with `@function_tool`; the SDK reads the docstring for the JSON schema.
- [**`claude-agent-sdk-py`**](https://github.com/steel-dev/steel-cookbook/tree/main/examples/claude-agent-sdk-py): the engine behind Claude Code, exposed as a library. Tools live in an in-process MCP server (`create_sdk_mcp_server`). `tools=[]` and `setting_sources=[]` strip the built-ins and the `.claude/` discovery so the recipe runs identically everywhere.

#### TypeScript

- [**`mastra`**](https://github.com/steel-dev/steel-cookbook/tree/main/examples/mastra): wraps the Vercel AI SDK with typed tools, a model router, and the Mastra Studio playground. Same four tools, registered on an `Agent`, with structured output via Zod.
- [**`openai-agents-ts`**](https://github.com/steel-dev/steel-cookbook/tree/main/examples/openai-agents-ts): `@openai/agents`. One quirk: Zod compiles to OpenAI's strict JSON Schema, so `.optional()` is rejected. Use `.nullable()` instead, and drop `.url()`, same restriction.
- [**`claude-agent-sdk-ts`**](https://github.com/steel-dev/steel-cookbook/tree/main/examples/claude-agent-sdk-ts): `@anthropic-ai/claude-agent-sdk`, the Node port of the same engine. `tools: []` plus `settingSources: []` plus `allowedTools: ["mcp__steel__*"]` is the trio that turns Claude Code into a focused browser agent.
- [**`vercel-ai-sdk-ts`**](https://github.com/steel-dev/steel-cookbook/tree/main/examples/vercel-ai-sdk-ts): AI SDK v6's `ToolLoopAgent`. The terminator is a `reportFindings` tool with **no** **`execute`**: calling it stops the loop and the call's `input` is your final typed answer. This sidesteps the Anthropic-on-tools issue where forcing JSON output disables tool calling.
- [**`vercel-ai-sdk-nextjs`**](https://github.com/steel-dev/steel-cookbook/tree/main/examples/vercel-ai-sdk-nextjs): same loop, Next.js chat app. `streamText` server-side, `useChat` on the client, every tool call surfaces as a typed `tool-*` part on the message stream. A Live View iframe lights up the moment the agent opens a session, so you watch the browser in the right pane while the chat runs in the left.

### Pick one and run

```sh
git clone https://github.com/steel-dev/steel-cookbook
cd steel-cookbook/examples/<your-pick>
cp .env.example .env       # STEEL_API_KEY + your model provider key
```

Python starters use `uv` (`uv sync && uv run main.py`). TypeScript starters use `npm` (`npm install && npm start`). Each one prints a Live View URL when it opens a session. Paste that into another tab and watch the agent click around.

### Try it

- [Steel Cookbook on GitHub](https://github.com/steel-dev/steel-cookbook)
- [Steel docs](https://docs.steel.dev/)
- [Get a free API key](https://app.steel.dev/sign-up)
- [Join the Discord](https://discord.gg/steel-dev)

We restructured the whole catalog while we were in there. Basics, AI Agents, and Advanced Features, with separate views for TypeScript and Python. There's also [AGENTS.md](https://github.com/steel-dev/steel-cookbook/blob/main/AGENTS.md) at the repo root: a nav file for AI agents, so your coding assistant can find the right example without you explaining the layout.

These eight are just the framework starters. The catalog also has computer use models, Stagehand, Browser-use, and advanced features like auth context reuse and persistent profiles.

## Blog: Ship Browser Automation to Users with Steel and Convex

https://steel.dev/blog/ship-browser-automation-to-users-with-steel-and-convex · Apr 21, 2026 · By Niksa Kuzmanic

> Steel and Convex give browser automation the infrastructure it's missing: managed sessions, multi-tenancy, and real-time observability.

**TL;DR:** The Steel component (@steel-dev/convex) is live on the Convex marketplace. Convex actions call the Steel API and write results into Convex tables, queries read only from Convex, and every method is scoped by ownerId for multi-tenancy. Modules cover sessions, files, captchas, profiles, credentials, extensions and one-off scrapes.

It answers:

- How do I use Steel with Convex?
- How do I install and mount the Steel Convex component?
- How do I scope browser sessions per user with ownerId?
- How do I avoid leaking Steel sessions in Convex actions?
- What modules does the Steel Convex component include?
- How do I observe browser sessions run through Convex?

Browser automation is easy to demo. Getting it to work reliably for actual users is a different problem.

Controlling Chrome is the simple part. What kills you is the state. A server restarts and the session is gone. Nobody knows which browsers belong to which user. Something throws and a session leaks. Your app has no idea what happened because results live in server logs, not in your database.

That's infrastructure, not Puppeteer. If you're building on [Convex](http://convex.dev/), you don't have to build it from scratch. Steel handles the browser runtime. Convex handles the state.

> TL;DR: We’re excited to announce the Steel component is now live on the Convex marketplace. Run browser automation without dealing with sessions, state, or leaks. Check it out: <https://www.convex.dev/components/steel-dev>

### What Steel and Convex each do

Steel is the browser runtime. You request a session, connect Playwright or Puppeteer to the WebSocket URL it gives you, and Steel runs the actual browser. Sessions, scraping, screenshots, PDFs, captcha solving, file handling: it does all of that.

Each session also gets a debug URL where you can watch it live, which turns out to be the most useful part when something breaks.

Convex is the state layer. It's a reactive backend: writes are immediately queryable, clients subscribe to changes without polling. Convex has components, which are reusable backend modules with their own tables that you mount with one line of config. They're sandboxed and can't touch your data unless you wire them in.

`@steel-dev/convex` is one of those components. It wraps the Steel API, writes results into Convex tables, and scopes everything by `ownerId`. You end up calling browser automation from Convex actions like any other backend operation.

![](https://steel.dev/assets/framerusercontent.com/images/Qu4SI0rwqu740pGvc3n5iWwZMhY.png)

### Setting it up with your agent

Paste this into your coding agent (Claude Code, Codex, OpenCode, Pi, etc.) and let it handle the setup.

```jsx
Help me install the Steel Browser Convex Component component.

Package: @steel-dev/convex
Install: npm install @steel-dev/convex

Documentation:
- https://www.convex.dev/components/steel-dev/steel-dev.md
- https://www.convex.dev/components/steel-dev/llms.txt

Please:
1. Retrieve the install command and documentation
2. Generate an exact setup checklist for this component
3. List any required environment variables
4. Provide verification steps
```

### Setting it up yourself

Prefer to wire it yourself? Follow the steps below.

```sh
npm install @steel-dev/convex
```

Mount it:

```js
import { defineApp } from "convex/server";
import steel from "@steel-dev/convex/convex.config";

const app = defineApp();
app.use(steel);

export default app;
```

Set your Steel API key (Convex functions don't inherit shell env vars):

```sh
npx convex env set STEEL_API_KEY <your_key>
```

Three steps. You don't need a browser fleet, an orchestration service, or your own session ownership scheme.

### How it works

Steel operations go through Convex actions. Each action calls the Steel API, then writes the result into Convex tables. Queries read only from Convex, so the database is always the source of truth.

```js
const steel = new SteelComponent(components.steel, {
  STEEL_API_KEY: process.env.STEEL_API_KEY,
});

// Calls the Steel API and writes the session record to Convex
const session = await steel.sessions.create(ctx, { sessionArgs: {} }, { ownerId });

// Reads from Convex only, no Steel API call
const sessions = await steel.sessions.list(ctx, {}, { ownerId });
```

Your state doesn't live in any single server process anymore. If a process dies, the data is still in Convex and your app still works.

### Multi-tenancy

Every method takes an `ownerId`. The component enforces it everywhere, so you don't have to invent naming hacks.

```js
await steel.sessions.create(ctx, {}, { ownerId: "user-alice" });
await steel.sessions.create(ctx, {}, { ownerId: "user-bob" });

// Only returns Alice's sessions
await steel.sessions.list(
  ctx,
  {},
  { ownerId: "user-alice" },
);
```

Pass a user ID or org ID and the component handles scoping. This starts to matter once browser automation is something your users trigger, not just something you run on a cron.

### Workflow: agent backends with durable sessions

Say you're building a research agent that logs into tools on behalf of users. Or a procurement agent that checks vendor portals. The common requirement is browser state that's durable and isolated per tenant, with a history your app can query.

```js
export const agentBrowse = action({
  args: { ownerId: v.string(), taskUrl: v.string() },
  handler: async (ctx, args) => {
    const { ownerId, taskUrl } = args;

    const session = await steel.sessions.create(
      ctx,
      { sessionArgs: { timeout: 120000 } },
      { ownerId },
    );

    try {
      const result = await steel.steel.scrape(ctx, { url: taskUrl }, { ownerId });

      await ctx.runMutation(api.agentTasks.record, {
        ownerId,
        url: taskUrl,
        content: result?.content ?? "",
        completedAt: Date.now(),
      });

      return { content: result?.content };
    } finally {
      await steel.sessions.release(
        ctx,
        { externalId: session.externalId },
        { ownerId },
      );
    }
  },
});
```

The `finally` block matters. If the task throws and you don't release, the session leaks. We had a tenant hit their session limit because of a missing `finally` in one action, and it took longer to diagnose than it should have.

Results land in Convex, so your UI can subscribe to task updates without a separate API layer. The same action works for thousands of tenants because `ownerId` scopes everything.

### Workflow: screenshots, PDFs, and scrape pipelines

Not every job needs a long-lived session. Sometimes you just need a PDF of a page, a screenshot for a moderation queue, or structured data scraped into your app.

`steel.steel.scrape` and `steel.steel.screenshot` handle the full session lifecycle when it's a one-off task.

```js
export const captureSnapshot = action({
  args: { ownerId: v.string(), url: v.string() },
  handler: async (ctx, args) => {
    const screenshot = await steel.steel.screenshot(
      ctx,
      { url: args.url },
      { ownerId: args.ownerId },
    );

    await ctx.runMutation(api.snapshots.save, {
      ownerId: args.ownerId,
      url: args.url,
      imageUrl: screenshot?.url ?? "",
      capturedAt: Date.now(),
    });

    return { imageUrl: screenshot?.url };
  },
});
```

Results are in Convex, which means your UI can display them reactively. A customer triggers a snapshot, and the result appears in their dashboard without polling.

### Workflow: persisted browser identity across runs

There's a big gap between running a browser once and having a system that remembers. The component has modules for profiles, credentials, extensions, and session files that bridge it.

An authenticated scraping job doesn't need to log in every time because the profile is saved. Extensions stay loaded between runs. Files carry over. Workflows pick up where they left off instead of starting cold.

### What's in the component

| Module | What it does |
| - | - |
| `sessions` | create, refresh, release, list, get |
| `sessionFiles` | upload and download files per session |
| `captchas` | solve captchas in-session |
| `profiles` | save and reuse browser state |
| `credentials` | store and reuse login credentials |
| `extensions` | manage browser extensions |
| `steel` | one-off scrapes, screenshots, PDFs |

Every module follows the same pattern: actions call the Steel API and write results to Convex, queries read from Convex only. Everything is scoped by `ownerId`.

### Observability

Session metadata lives in Convex, so you query history in the Convex dashboard. Filter by `status` to find live sessions, or by `ownerId` to look at one tenant. It's just a database table.

Steel's `debugUrl` is the other half. Open it while a session runs and you can watch the browser click around. When something goes wrong, you see it happen instead of reconstructing from logs.

Your app's UI can show the same data because it's all in Convex. No separate monitoring setup.

![](https://steel.dev/assets/framerusercontent.com/images/m9CMsG8n1fQ9KzvcOLA7QwNyJw.webp)

### When to use this

This makes sense when browser automation is part of your product, not just a script you run. Users expect isolated sessions and queryable history, and the component handles that so you don't have to build it.

### Start building

```sh
npm install @steel-dev/convex
npx convex dev
npx convex env set STEEL_API_KEY <your_key>
npx convex run steelSmoke:run '{"ownerId":"tenant-1"}'
```

- GitHub: [source code](https://github.com/steel-dev/steel-convex)
- Demo: [see it in action](https://github.com/steel-experiments/steel-convex-demo)

## Blog: We gave Pi agent a real browser

https://steel.dev/blog/we-gave-pi-agent-a-real-browser · Apr 15, 2026 · By Nikola Balic

> We shipped @steel-dev/pi-steel, a one-command Steel extension that gives the Pi coding agent a real cloud browser.

**TL;DR:** Steel shipped @steel-dev/pi, an extension that gives the Pi coding agent a cloud browser with one install command. Pi gets tools to navigate, scrape, screenshot, make PDFs, fill forms, extract schema-based data and run Playwright computer actions, with automatic CAPTCHA handling. Demos used apple.com and OpenAI docs.

It answers:

- How do I give the Pi coding agent a browser?
- How do I install the Steel extension for Pi?
- What browser tools does the pi-steel extension add?
- How do I keep a Steel browser session alive across Pi prompts?

We shipped [`@steel-dev/pi`](https://github.com/steel-dev/pi-steel). One install command, and the Pi coding agent gets a real cloud browser: navigate, scrape, screenshot, PDF, fill forms, extract structured data, drive the page with Playwright computer actions. CAPTCHA handling is baked in, which was the part we thought would be annoying and mostly wasn't.

```sh
pi install npm:@steel-dev/pi
```

That's it. Pi picks up the extension and the browser tools show up on the next run.

Grab a free API key at [app.steel.dev](https://app.steel.dev/) and set `STEEL_API_KEY` (or run `steel login`).

[Video on YouTube](https://www.youtube.com/watch?v=c9292MtK8EA)

### Why we built it

Pi is a minimal coding agent, the one behind [OpenClaw](https://github.com/openclaw/openclaw). It's extension-first: no built-in browser, no built-in anything. You add capabilities with `pi install`, and that's the socket Steel plugs into.

Setting up Playwright and managing headless Chromium just so your agent can read a webpage is a tax nobody really wants to pay. If you're on Pi or OpenClaw, `pi-steel` hands you a browser without any of that.

### What it gives Pi

The tools we wired up, roughly in the order you'll reach for them:

- `steel_navigate` + `steel_scrape` for fetching pages as text, markdown, or HTML
- screenshots and PDFs, returned as Pi artifacts
- `steel_extract`, which takes a JSON schema and returns structured data. Worth it anytime you'd otherwise be parsing markdown for prices or specs
- `steel_fill_form` for submitting forms
- Playwright-backed computer actions (click, scroll, type) for the pages scraping can't reach
- session management: one per prompt by default, or pin with `steel_pin_session` to keep a browser alive across prompts, or flip to persistent with `STEEL_SESSION_MODE=session`
- CAPTCHA handling, automatic

We didn't tell LLM when to use which tool. It just tries something, sees what comes back, and adjusts. Watching that loop run on medium reasoning is a decent chunk of what makes this extension interesting.

### Proof: two tasks, two blockers handled

#### Apple.com: multi-page scraping and dynamic content

> Visit apple.com and compare me all recent MacBook models.

No sitemap. No hardcoded URLs. Pi read the Mac lineup page, followed the links to each model (MacBook Neo, Air 13", Air 15", MacBook Pro), and built a comparison across the lineup. Plain scraping missed chunks (sticky nav, viewport-dependent sections, Apple's usual marketing theater), so Pi switched to computer actions and screenshots to see what was actually rendered and pulled specs from there.

![](https://steel.dev/assets/framerusercontent.com/images/BMFjNn0xPH2Ft1nqSGewXXrhbQ.png)

Not training data. Whatever Apple.com had up that day.

#### OpenAI docs: getting through bot protection

> Visit OpenAI docs and tell us how can we use the latest model.

OpenAI's docs push back on scrapers. Even Codex, OpenAI's own CLI agent, ships dedicated tools just to fetch them, because the usual approach tends to fail. Steel handles the bot-protection layer, so Pi just sees a webpage.

Pi found the Responses API create endpoint, poked at reasoning effort configuration, and came back with a current code example: Responses API, not the chat completions snippet you'd get from asking a bare LLM the same question.

If you've ever had an agent confidently hand you last year's API, you know why this one mattered to us.

### What to build with it

The stuff we actually think people will do, not the stuff that sounds cool in a blog post:

- hit a competitor's pricing page every morning and diff yesterday's numbers
- `steel_fill_form` against an application portal you'd otherwise do by hand
- open-six-tabs research tasks, handed off
- any Pi or OpenClaw workflow currently stuck at "I need to look at a webpage"

Because this is just an extension, the browser is one tool among Pi's others. Scrape a page in one step, call something completely different in the next.

### Try it

```sh
pi install npm:@steel-dev/pi
```

Pick a research task and let Pi do the clicking. Go crazy, report back.

- [`pi-steel` on GitHub](https://github.com/steel-dev/pi-steel)
- [`@steel-dev/pi` on npm](https://www.npmjs.com/package/@steel-dev/pi)
- <https://pi.dev/>
- [Get a free API key](https://app.steel.dev/sign-up)
- [Join the Discord](https://discord.gg/steel-dev)

## Blog: OpenClaw + Steel Browser: Let Your AI Agent Fill the Forms

https://steel.dev/blog/openclaw-steel-browser-let-your-ai-agent-fill-the-forms · Apr 9, 2026 · By Nikola Balic

> OpenClaw can operate the web. We gave it Steel CLI, pointed it at AI Engineer World's Fair's CFP form, and watched it submit a speaker application.

**TL;DR:** With Steel CLI and the steel-browser skill, OpenClaw gets a cloud browser with stealth mode, proxies and CAPTCHA solving. Given one instruction, it found the AI Engineer World's Fair call for speakers and submitted an application in 15 minutes. Sites with more bot detection are slower; use steel profile import for logged-in sites.

It answers:

- How do I give OpenClaw a cloud browser with Steel?
- Can an AI agent fill out and submit a web form on its own?
- How do I watch or replay what OpenClaw does in the browser?
- How do I let an agent use sites where I am already logged in?

OpenClaw can shell out. Give it Steel CLI and the steel-browser skill and it has a real cloud browser: stealth mode, proxies, CAPTCHA solving, computer actions via Playwright. We pointed it at the AI Engineer World's Fair call for speakers and told it to apply.

It took 15 minutes. Swyx is probably not happy about what got submitted. OpenClaw did it.

[Video on YouTube](https://www.youtube.com/watch?v=ffqXpipBbEE)

### Setup

Install Steel CLI:

```sh
curl -LsSf https://setup.steel.dev | sh
```

Install the browser skill:

```sh
npx skills add https://github.com/steel-dev/cli --skill steel-browser
```

Get a free API key at [app.steel.dev](https://app.steel.dev/). Paste it in chat when OpenClaw asks. Better: add it as an environment variable through OpenClaw's interface so it's not sitting in your conversation history.

### What happened

We gave OpenClaw one instruction:

> I would like to submit an application for the call for speakers for AI Engineer World's Fair. Could you figure out what the fields are, what we need, and how I can apply to become a speaker?

The agent created a Steel session and started navigating. We watched from Steel's dashboard.

It found the right page on its own. Explored the form. Drafted a submission.

### Watching it work

You don't have to watch. But it's useful sometimes.

OpenClaw pipes Steel's live session URL back into its responses. Open it and you see exactly what the browser is rendering as the agent works. When it misclicks or gets stuck in a modal, you see it. Step in, say something, the agent adjusts.

When you can't watch live, you replay. Steel keeps the full session: every navigation, every click, every retry.

### OpenClaw is good at brute forcing

Works on regular web forms. The more bot-detection a site has, the slower it gets. Multi-step forms with dynamic fields or aggressive CAPTCHA checkpoints will eat sessions.

For sites where you're already logged in, don't start from scratch. `steel profile import` copies your Chrome session over and the agent picks up from there. The CFP form worked without any of that, but for Gmail, Slack, or any dashboard: use a profile.

### Try it

```sh
curl -LsSf https://setup.steel.dev | sh
npx skills add https://github.com/steel-dev/cli --skill steel-browser
```

Find a form you've been meaning to fill out. Give OpenClaw the URL and a one-sentence brief. Watch the session. Let it fight through the dropdowns. Report back.

- [Steel CLI docs](https://docs.steel.dev/overview/steel-cli)
- [Get a free API key](https://app.steel.dev/sign-up)
- [Join the Discord](https://discord.gg/steel-dev)

## Blog: Hermes Agent + Steel Browser: Let Your AI Agent Browse the Web

https://steel.dev/blog/steel-is-now-a-native-browser-provider-in-hermes · Apr 7, 2026 · By Nikola Balic

> We added Steel as a cloud browser provider in Hermes, the open source AI agent from Nous Research.

**TL;DR:** Steel is a standalone browser-provider plugin for Hermes Agent 0.18.0 or newer: install steel-dev/hermes-steel and set browser.cloud_provider to steel. Hermes then routes browser_* tools through Steel, returns the live viewer URL, requests a 30-minute session cap and adds a steel_scrape tool. Proxy and CAPTCHA solving are optional.

It answers:

- How do I use Steel as the browser provider in Hermes Agent?
- Which Hermes version does the Steel plugin require?
- How do I turn on proxies and CAPTCHA solving for Steel in Hermes?
- What does the steel_scrape tool do in Hermes?
- How long do Hermes browser sessions on Steel last?

Steel is now available for Hermes Agent as a standalone browser-provider plugin. Install it, set `STEEL_API_KEY`, and select `steel` as your cloud browser provider. Hermes routes its `browser_*` tools through Steel and adds a `steel_scrape` tool for one-shot page extraction.

> We first proposed Steel support in [PR #5555](https://github.com/NousResearch/hermes-agent/pull/5555). The second pass, [PR #21182](https://github.com/NousResearch/hermes-agent/pull/21182), rebuilt the integration around Hermes' newer browser-provider interface.
>
> Recent changes to Hermes added a supported standalone path for third-party browser providers. That gave us the right way to publish the integration without mcuh complexities.

[Video on YouTube](https://www.youtube.com/watch?v=T95B7JM4FpQ)

### Setup

You need Hermes Agent 0.18.0 or newer and a [Steel API key](https://app.steel.dev/settings/api-keys). Then run:

```sh
hermes plugins install steel-dev/hermes-steel --enable
hermes config set browser.cloud_provider steel
```

The installer prompts for your Steel API key and saves it to `~/.hermes/.env`. The second command selects Steel as the browser backend. Don't skip it: the plugin doesn't replace Hermes' local browser unless you choose `steel` explicitly.

Proxy and CAPTCHA solving are optional and off by default. They require a verified Steel account. You can set them as persistent defaults:

```sh
hermes config set browser.steel.use_proxy true
hermes config set browser.steel.solve_captcha true
```

### What happened

We ran Hermes and gave it one task:

> Find me the best hotel near Grand Central New York and show me Steel's session URL so we can observe what the agent is doing.

Agent started working. It went to google.com/travel, searched for hotels, then navigated to Booking.com on its own. Nobody told it to go there. It decided that's where the data was.

This part was slow. LLMs are slow between actions. The agent was navigating, clicking through hotels, ruminating. The web is hard. For doing anything meaningful on it, you need a proper browser.

While this was happening, the live session was visible in Steel's dashboard.

### Watching it work

You don't need to watch every click. But when something goes wrong, when the agent misclicks or gets lost in some modal, you need to see what it was looking at. That's the difference between debugging and guessing.

The integration pipes Steel's live viewer URL back into Hermes responses, so you get the link right in the agent's output. And if the agent hits bot detection, it knows to start stealth session or fall back to `steel_scrape` instead of retrying the same approach.

### The agent built its own skill

After finishing the hotel search, Hermes created a skill called "hotel search" on its own. Nobody asked it to. It had lived through the whole navigation sequence and decided to package that up for next time.

We've seen the same pattern with Claude Code and Codex. Manual run, then script, then automation. The difference here is Hermes skipped being asked and just did the second step itself.

### The scrape tool

The plugin includes `steel_scrape`, a dedicated tool for server-side content extraction. No browser session needed. It calls Steel's `/v1/scrape` API and can return markdown, HTML, readability output, or cleaned HTML.

Markdown that an agent can actually consume. Give it a list of URLs, have it ingest them, build a knowledge base. The scrape tool works separately from browser sessions, so use whichever fits.

### More than one session

This was one agent in one session. Steel runs browsers in the cloud. Let loose a fleet of agents doing parallel sessions at the same time.

Each Hermes browser task gets its own Steel session. The plugin requests a 30-minute session cap by default, so longer agent tasks aren't cut off by Steel's shorter API default. It also releases sessions when Hermes finishes with them.

Changing proxy or CAPTCHA settings closes the current session. The next browser call starts a new one with those options. If the account doesn't include a requested feature, the session still runs without it and Hermes tells you what was dropped.

### Any agent, any model

Hermes is open source. In our run, we used an open model from Z.ai. GLM 5.1 worked, and Hermes can switch models without changing the Steel browser setup.

The browser is the browser.

### Try it

Install the plugin, select Steel as the cloud provider, and give Hermes a browser task.

- [Steel plugin for Hermes Agent](https://github.com/steel-dev/hermes-steel)
- [Hermes agent](https://github.com/NousResearch/hermes-agent)
- [Steel pricing and limits](https://docs.steel.dev/overview/pricinglimits)
- [Get a Steel API key](https://app.steel.dev/settings/api-keys)
- [Join the Discord](https://discord.gg/steel-dev)

## Blog: Codex wired Steel and Resend into a daily newsletter

https://steel.dev/blog/codex-wired-steel-and-resend-into-a-daily-newsletter · Apr 4, 2026 · By Nikola Balic

> Codex can run shell commands. Steel CLI can scrape the web. Resend CLI can send email. Wire the three together and you have a personal newsletter.

**TL;DR:** Codex, using Steel CLI's steel scrape and Resend CLI, fetched the top 5 AI stories from Hacker News and emailed them with no glue code, reading each CLI's --help. It then wrote a bash script from the run, which went into cron as a daily newsletter. The argument: give agents existing CLIs instead of plugins.

It answers:

- How do I build a daily newsletter with Codex, Steel and Resend?
- Why give coding agents CLIs instead of plugins?
- How do I install Steel CLI and the steel-browser skill?
- How do I turn an agent session into a cron job?

Codex can run shell commands. Steel CLI can scrape the web. Resend CLI can send email. Wire the three together and you have a personal newsletter, no plugin marketplace required.

Instead of building a plugin for every service your agent might touch, give it CLIs that already exist. The agent composes them on its own.

We pointed Codex at Hacker News, told it to find the top 5 AI stories, email us the results, and then write a script so we never have to do it again. Took a few minutes. Most of that was the agent figuring out our email address.

[Video on YouTube](https://www.youtube.com/watch?v=XGFuj1bURJY)

### Setup

Install Steel CLI:

```sh
curl -LsSf https://setup.steel.dev | sh
```

Install the browser skill so your agent knows how to use Steel:

```sh
npx skills add https://github.com/steel-dev/cli --skill steel-browser
```

Make sure Resend CLI is available in the same environment. Codex will find it.

### What happened

We ran Codex in full-auto mode and gave it one instruction:

> $steel-browser Fetch the top 5 AI stories from Hacker News and email them to me.

It ran `steel scrape` against Hacker News and got back clean markdown. One command. Steel runs a real browser in its cloud, renders the page, returns the content. No local Chrome, no drivers, no proxies.

```sh
steel scrape https://news.ycombinator.com
```

Codex parsed the markdown, filtered for AI stories, ranked them. Then it found Resend CLI, composed an email. It didn't know our address. We told it. It sent the email.

The result itself, whatever. The part worth paying attention to: nobody wrote glue code. Codex read both CLIs' `--help` output and wired them together on its own.

### Not just Hacker News

The version we actually use hits half a dozen sites. TechCrunch for startup noise. ArXiv for papers. The OpenAI and Anthropic blogs for model drops. `steel scrape` against each one, merge, deduplicate, compose one email. We've been running this every morning.

### Session to script to cron job

After the first run, we told Codex:

> Now create a script based on what you just did.

It wrote a bash script. All the messy exploration from the first run compressed into concrete steps. It knew which flags mattered because it had just lived through the trial and error.

Then we dropped it into cron:

```sh
crontab -e
0 8 * * * /usr/local/bin/daily-newsletter.sh
# daily AI digest, zero maintenance
```

Manual run, then bash script, then cron job. Each step removes a human from the loop.

### Why CLIs, not plugins

Plugin ecosystems are bottlenecks. Someone builds the plugin. Someone else maintains it. The agent can only do what the plugin author thought to expose.

CLIs already exist for almost everything. Resend, Steel, `gh`, `aws`, `jq`, `curl`, a few hundred others. An agent that can shell out doesn't need a purpose-built integration for every service. It needs `PATH` and `--help`.

We've used this pattern for newsletters, dashboard monitoring, and competitive research. Resend has sending limits on the free tier, so check that before you point this at 1000 people.

### Try it

```sh
curl -LsSf https://setup.steel.dev | sh
npx skills add https://github.com/steel-dev/cli --skill steel-browser
```

Start with one source. Scrape it, email yourself the results, then ask the agent to write the script. Add sources when the first one works. Then cron it.

- [Steel CLI docs](https://docs.steel.dev/overview/steel-cli)
- [Get a free API key](https://app.steel.dev/sign-up)
- [Join the Discord](https://discord.gg/steel-dev)

## Blog: Give Claude Code a real browser

https://steel.dev/blog/give-claude-code-a-real-browser · Apr 2, 2026 · By Nikola Balic

> Steel CLI lets Claude Code automate real web apps like Gmail via a browser skill, turning messy sessions into reusable, self-healing scripts and skills.

**TL;DR:** With Steel CLI, the steel-browser skill and an imported Chrome profile, Claude Code checked Gmail for unread mail, read a message and sent a reply while already logged in. It then wrote a repeatable bash script from the run and turned that into a Claude Code skill that patches the script when a selector changes.

It answers:

- How do I give Claude Code a real browser?
- How do I import my Chrome profile into Steel?
- How can Claude Code read and reply to Gmail?
- How do I turn a browser session into a reusable Claude Code skill?

Claude Code can reason, write code, and run shell commands. It cannot open a browser. It can't log into Gmail, read your inbox, or send a reply. If the task requires a real web page, the agent is stuck.

We wired Steel CLI into Claude Code and pointed it at Gmail. The agent checked for unread mail, read a message, drafted a reply, and sent it. Then we asked it to write a bash script so the whole thing is repeatable. Then we turned that script into a skill.

The whole session took a few minutes. Most of that was the agent fighting Gmail's UI.

[Video on YouTube](https://www.youtube.com/watch?v=dsGtUqJYXUI)

### Setup

Install Steel CLI:

```sh
curl -LsSf https://setup.steel.dev | sh
```

Install the browser skill so Claude Code knows how to operate Steel:

```sh
npx skills add https://github.com/steel-dev/cli --skill steel-browser
```

Import your local Chrome profile:

```sh
steel profile import --name your_profile_name
```

That last command copies cookies and login state from your Chrome into Steel. Sessions started with this profile inherit your existing auth, so Gmail, Slack, whatever else you're signed into just works. No credentials in plaintext, no OAuth dance.

### What happened

We gave Claude Code one instruction:

> Check my Gmail for unread email and propose a reply.

The skill loaded. Steel started a session with the imported profile. The agent navigated to Gmail, already logged in.

It found one unread message from Colin, opened it, read the content, and composed a reply. We watched the whole thing in Steel's live session viewer, which shows you exactly what the browser is rendering in real time.

It was not smooth. The agent clicked around, missed buttons, had to recover. Gmail is a mess of overlapping modals and async-loaded elements.

You can watch, intervene, and the agent recovers. That loop (agent tries, fumbles, human nudges, agent adjusts) is what separates a workflow from a demo.

### Session to script to skill

One email reply is a demo. What matters is what you do with the experience afterward.

We asked Claude Code:

> Based on lessons learned, write a repeatable bash script for this task that we can rerun.

It wrote a script: start a Steel session with the named profile, go to Gmail, find unread messages, read them, compose replies. The manual fumbling got distilled into concrete steps.

Then:

> Create a Claude Code skill from this script.

Now the workflow is packaged. Next time, the agent loads the skill, runs the script, and if a selector changed or a button moved, it reads the error and patches the script itself. The first run was messy. The script is cleaner. The skill is reusable. And because the agent wrote the script, it knows how to fix it.

Manual run, then bash script, then agent skill. Each step strips out fragility.

### What we learned

Profile import is the thing that makes this practical. Without it, every session starts logged out and the agent has to deal with OAuth, 2FA, credential entry. That's a whole category of problems you don't need.

Live session viewing is how you debug this. You're watching a real browser in Steel's dashboard. When the agent misclicks or gets lost, you see it happen and can step in. Without that visibility, browser automation is just guessing at what went wrong after the fact.

Web is hard. Buttons shift, elements load late, the DOM is deeply nested. The agent recovered from most of it, but expect some back-and-forth on the first few runs. This is not a solved problem, and we're not going to pretend it is.

The self-healing part is the best part. Once the agent has a script, it can diff what broke against what worked and patch it. Over a few runs the loop tightens. The agent starts handling Gmail without intervention. Not perfectly. Not every time. But enough that we actually use it.

### Try it

```sh
curl -LsSf https://setup.steel.dev | sh
npx skills add https://github.com/steel-dev/cli --skill steel-browser
steel profile import --name your_profile_name
```

Start with something small. Check email, pull a report from a dashboard, monitor a page for changes. Then ask the agent to write the script. Then make the skill.

- [Steel CLI docs](https://docs.steel.dev/overview/steel-cli)
- [Get a free API key](https://app.steel.dev/sign-up)
- [Join the Discord](https://discord.gg/steel-dev)

## Blog: Why Browser Agents Fail in Production

https://steel.dev/blog/why-browser-agents-fail-in-production · Mar 11, 2026 · By Nikola Balic

> Raw browser control is a commodity. Reliable, reviewable, resumable execution under concurrency is the durable advantage.

**TL;DR:** Browser actions like click and fill are a commodity; production browser agents fail on execution at scale: session churn, flaky recovery, p95/p99 latency and failures nobody can reproduce. A platform should give a deterministic session lifecycle, resumability, reviewability, explicit contracts and predictable concurrency.

It answers:

- Why do browser agents fail in production?
- Does using CDP cause bot detection?
- What should I look for in a browser platform for production agents?
- How do I evaluate a browser automation stack before choosing one?

Stop evaluating browser stacks by asking "does it support CDP?" or "can it click?"

Ask this instead: **Can this system execute reliably when you have real load, real state, and real failure modes?**

That's the line between a browser automation demo and a production agent workflow.

#### CDP and WebDriver are not the story

Yes, WebDriver or CDP-adjacent signals can factor into bot detection. But treating detection as a single flag is a category error.

Anti-bot systems are layered. They combine network reputation, fingerprints, behavior, and challenge flows. You can "fix" one surface signal and still fail because your traffic looks wrong, your timing is unnatural, or your recovery behavior is inconsistent.

CDP is not a hack. It's a control surface used by real tooling. Playwright and Puppeteer speak to browsers through CDP under the hood. The protocol you use is usually not the root cause of production flakiness.

**Execution is.**

#### The commodity layer: actions

The feature checklist most teams start with is now table stakes:

- `open`, `click`, `fill`, `screenshot`
- Navigation + waits
- File download/upload
- Headless or remote modes

Most open source stacks and hosted browsers can do this. If that's all you need, use the simplest tool that fits your language and team.

#### The hard layer: scale

At low volume, you can brute-force success: rerun failures manually, patch selectors on the fly, babysit logins, accept flaky waits.

At 100, 1,000, or 10,000 concurrent runs, tiny issues compound:

**Session churn:** Logins expire. Cookies drift. Storage corrupts. Targets deploy UI changes mid-run.

**Flaky recovery:** A retry that works once can amplify failures under concurrency.

**Long-tail latency:** p95 and p99 step times dominate throughput and cost, not averages.

**Debugging at 2 a.m.:** If you can't reproduce what happened, you can't fix it quickly.

Multi-agent workflows raise the stakes. When many agents run in parallel, queuing and latency variance become **correctness problems**. One slow step cascades into timeouts, missed checkpoints, and session resets across the fleet.

This is why the space feels commoditized from the outside. The primitives look the same. The operational behavior is not.

#### What this looks like in practice

A 12-step workflow: log in, navigate a dashboard, hit a challenge gate, wait on a slow-loading report, extract data, and continue. It fails at step 7.

In a commodity stack, you restart the entire run. The agent re-does the login, re-navigates, re-waits, and might fail at step 7 again for the same reason.

In an execution layer, you inspect the session artifacts to see *why* step 7 failed, resume from preserved session state, and skip the six steps that already succeeded. This becomes especially powerful when agents are driving the browser. Steel exposes session-level logs and preserved session state, so an agent can detect failures, choose a recovery path, and continue without a full restart.

#### What to buy (and what not to)

You're not buying "browser control." You're buying an **execution layer.**

A production-grade agent browser platform should give you:

**Deterministic session lifecycle:** Create, attach, hand off, resume, terminate. Cleanly and predictably.

**Resumability:** Recover from partial failure without redoing the entire workflow.

**Reviewability:** Traces, artifacts, and structured outputs so humans can verify outcomes.

**Explicit contracts:** Tools that fail loudly with typed errors and predictable retries.

**Concurrency you can reason about:** Backpressure, limits, and stable performance under load.

That's the layer Steel is built around.

Steel provides cloud Sessions with persistent state, resumability, isolation, and observability so agents can recover, hand off work, and run predictably under concurrency. The goal isn't "more APIs." It's **fewer 3 a.m. pages** and faster recovery when the web changes.

#### Honest limitations

Steel won't magically solve detection if your workflow looks robotic. It won't bypass captchas without [challenge-solving infra](https://steel.dev/blog/what-is-a-captcha-solver). It won't turn bad selectors into resilient ones.

What it *will* do:

- When a site changes, you can see exactly what broke.
- When a step slows down, you can measure it.
- When a run fails halfway through, you can resume instead of restart.
- When you scale concurrency, behavior remains predictable.

If you're running a handful of workflows, a standard automation library run locally is often the right call. You'll move fast and manual reruns are fine. Steel's [open source browser](https://github.com/steel-dev/steel-browser) and cloud platform share the same API, so you can start local and scale to managed sessions when the constraint shifts to session churn, concurrency, and latency. No rewrite required.

#### Next step

Before choosing a browser stack, take one production workflow and run it 100 times at your target concurrency. Measure p95/p99 step latency, restart rate, manual interventions, and time-to-diagnose.

That's where the differences show up.

## Blog: Top 7 Headless Browser Automations That Actually Work

https://steel.dev/blog/top-7-headless-browser-automations-that-actually-work · Mar 5, 2026 · By Nikola Balic

> Learn 7 headless browser automation patterns that hold up in production, plus the retries, state handling, and debugging practices that keep them reliable.

**TL;DR:** Seven headless browser patterns that hold up in production: price monitoring, form submission, SPA scraping, AI web agents, screenshots and PDFs, mobile-mode automation and synthetic monitoring. With any vendor, each needs explicit timeouts, idempotent retries, versioned selectors, failure artifacts and region-aware execution.

It answers:

- What are common headless browser automation use cases?
- How do I connect Playwright to a Steel session over CDP?
- How do I make headless browser automation reliable in production?
- How do I keep an AI web agent from taking unsafe actions?
- How do I generate a PDF or screenshot of a page with Playwright?
- How do I run mobile-mode browser automation with touch input?

If you have tried scraping a React app with `requests`, you have seen the failure mode: an empty shell, a JavaScript bundle, and no usable data.

Headless browsers solve that part. They run a real browser engine, execute the page, and let you interact with it like a user would.

The harder part is keeping that automation alive in production.

Chrome processes hang. Sessions leak memory. Pricing changes by region. Form submissions duplicate when retries are sloppy. Synthetic checks pass while the real UI is broken.

Instead of treating browser automation like simple HTTP scripting, treat it like production infrastructure with state, retries, and observability.

This guide covers 7 patterns that show up constantly, what breaks first, and how to run them with fewer surprises.

Steel is used here as one managed-session example. It gives you cloud browser sessions you control through your existing frameworks, including Playwright, Puppeteer, and Selenium ([Sessions API overview](https://docs.steel.dev/overview/sessions-api/overview), [Playwright guide](https://docs.steel.dev/overview/guides/playwright-node), [Puppeteer guide](https://docs.steel.dev/overview/guides/puppeteer), [Selenium guide](https://docs.steel.dev/overview/guides/selenium)).

### What You Need No Matter Which Vendor You Use

Vendor choice does not remove the fundamentals.

- **Explicit timeouts**: Defaults are how pipelines stall forever.
- **Retries with idempotency**: Retrying a submit step blindly is how you create duplicate writes.
- **Selectors as contracts**: They will drift. Version them and expect maintenance.
- **Artifacts on failure**: If you cannot see what happened, you cannot fix it.
- **Region-aware execution**: Wrong geography often means wrong data.

None of this is Steel-specific. It is the job.

### Connecting to Steel with Playwright

The connection pattern is simple: create a session, connect over CDP, run Playwright.

```ts
import { chromium } from "playwright";
import { Steel } from "steel-sdk";

const steel = new Steel({ apiKey: process.env.STEEL_API_KEY });

const session = await steel.sessions.create({
  useProxy: true,
  solveCaptcha: true,
});

const browser = await chromium.connectOverCDP(
  `wss://connect.steel.dev?apiKey=${process.env.STEEL_API_KEY}&sessionId=${session.id}`
);
const page = browser.contexts()[0].pages()[0];

await page.goto("https://example.com");

await browser.close();
await steel.sessions.release(session.id);
```

Steel also supports state reuse for longer-lived authenticated flows through sessions and profiles ([session lifecycle](https://docs.steel.dev/overview/sessions-api/session-lifecycle), [reusing auth context](https://docs.steel.dev/overview/sessions-api/reusing-auth-context), [Profiles API overview](https://docs.steel.dev/overview/profiles-api/overview)).

### 1. Price Monitoring and Product Tracking

Price tracking is conceptually simple: open page, wait for the price, parse it, compare it, alert on the change.

The hard part is doing that every day for months without quietly storing garbage data.

```ts
await page.goto("https://shop.example.com/products/sku-123");
await page.waitForSelector("[data-test='price']", { state: "visible" });

const priceText = await page.locator("[data-test='price']").innerText();
const price = Number(priceText.replace(/[^0-9.]/g, ""));

if (price < TARGET_PRICE) {
  await sendAlert({ sku: "sku-123", price });
}
```

What keeps it reliable:

- **Wait for state, not time**: Prefer selector or network-state waits over static sleeps.
- **Track meaningful deltas**: Alert on a real price move, not a small fluctuation.
- **Handle null outcomes**: Out of stock, delisted, and regional variants should not crash the job.
- **Use geo-aligned routing**: Region mismatch can return a technically valid price that is still the wrong price.

Common gotcha: some retailers soft-block instead of hard-block. You still get HTML, just not the data you thought you were collecting.

Typical use case: nightly monitoring across competitor catalogs with threshold-based alerts to Slack or email.

### 2. Form Autofill and Submission Workflows

Multi-step forms are where pure HTTP approaches usually fall apart.

State moves through cookies, CSRF tokens, client-side transitions, and hidden fields that only exist after the last interaction. A browser handles that naturally. Your job is to keep the run coherent.

```ts
await page.goto("https://portal.example.com/apply");
await page.fill("#email", applicant.email);
await page.fill("#password", applicant.password);
await page.click("#sign-in");

await page.waitForSelector(".step-2", { state: "visible" });
await page.fill("#first-name", applicant.firstName);

await page.click("#submit");
await page.waitForSelector(".confirmation-number", { state: "visible" });
const confirmation = await page.locator(".confirmation-number").innerText();
```

What keeps it reliable:

- **Use one session per submission**: Keep auth, cookies, and page state together.
- **Retry steps, not whole flows**: Whole-flow retries are expensive and can trigger duplicate-submission checks.
- **Persist proof of completion**: Save the confirmation number before tearing down the session.
- **Use idempotency keys when money or accounts are involved**: Retries need guardrails.

Common gotcha: file uploads. Use framework upload APIs like `setInputFiles()` instead of trying to drive a native file picker.

Typical use case: onboarding portals, job applications, partner dashboards, or internal back-office workflows.

### 3. Dynamic Scraping for SPA Sites

For React, Vue, and Angular pages, DOM extraction often beats reverse-engineering private APIs when maintainability matters more than raw speed.

Internal APIs can be faster. They can also disappear, add signatures, or change shape without warning. Rendered DOM is slower, but it usually survives redesigns better.

```ts
await page.goto("https://listings.example/search?city=split");
await page.waitForSelector(".listing-card", { state: "visible" });

const cards = await page.locator(".listing-card").all();
const rows = await Promise.all(
  cards.map(async (card) => ({
    title: await card.locator(".title").innerText(),
    price: await card.locator(".price").innerText(),
    rating: await card.locator(".rating").innerText().catch(() => null),
  }))
);
```

What keeps it reliable:

- **Wait for the right signal**: A domain-specific selector is usually better than global `networkidle`.
- **Paginate the way the app paginates**: Infinite scroll and "Load more" patterns need deterministic loops.
- **Extract only what you need**: Full-page dumps waste memory and slow downstream processing.
- **Version selectors over time**: DOM contracts drift.

Common gotcha: lazy-loaded cards. Scroll, wait, confirm count increase, then continue.

Typical use case: marketplace aggregation, listing intelligence, or competitor catalog tracking.

### 4. AI Web Agents

Agent loops are useful when hardcoding every selector is overkill, but they still need hard boundaries.

The better pattern is not "give the model a browser and hope." It is: keep the action space small, keep untrusted page content out of the control loop when possible, and require approval before anything expensive or irreversible.

```ts
const ALLOWED_ACTIONS = [
  "goto_pricing",
  "open_login",
  "click_cta",
  "extract_pricing_table",
  "request_human_approval",
];

const plan = await planner({
  task: "Find plan names and monthly prices",
  allowedActions: ALLOWED_ACTIONS,
  maxSteps: 8,
});

for (const step of plan) {
  assertAllowed(step.action, ALLOWED_ACTIONS);

  if (step.action === "request_human_approval") {
    await waitForApproval(step.reason);
    continue;
  }

  const result = await executor.run(step);
  auditLog.append({ step, result });
}

const pricing = await extractor.readPricingTable(page);
return pricing;
```

What keeps it reliable:

- **Constrain task scope**: "Extract plan names and prices" is much better than "Research this company."
- **Constrain the action set**: Give the agent a small set of allowed moves instead of open-ended browser control.
- **Plan before execution when you can**: Freeze the action list early, then run it under orchestration.
- **Set hard step limits**: Avoid infinite loops on ambiguous UI states.
- **Separate navigation from extraction**: Trust navigation, verify facts.
- **Treat page content as untrusted**: Do not let arbitrary page text rewrite system instructions, approvals, or tool choices.
- **Minimize tainted context**: Once you have the structured signal you need, drop raw page text from the decision loop.
- **Add approval gates for risky actions**: Payment, account changes, and anything irreversible should pause for human review.
- **Log intermediate actions**: You need rollback and debugging context.

Common gotcha: broad goals plus broad permissions. That is how agents wander, loop, or take actions you did not mean to authorize.

Typical use case: exploratory navigation across many sites before a deterministic parser turns the result into structured data.

### 5. Screenshot and PDF Generation

A lot of PDF generation infrastructure is just headless Chrome with extra steps.

For invoices, statements, reports, and visual records, rendering the real page is often more stable than maintaining a separate HTML-to-PDF system.

```ts
await page.goto("https://app.example.com/invoice/1042");
await page.waitForLoadState("networkidle");

const screenshot = await page.screenshot({ fullPage: true, type: "png" });
await s3.upload({ Body: screenshot, Key: "invoices/1042.png" });

const pdf = await page.pdf({ format: "A4", printBackground: true });
await s3.upload({ Body: pdf, Key: "invoices/1042.pdf" });
```

What keeps it reliable:

- **Wait for assets**: Fonts and late-loading images will ruin otherwise valid captures.
- **Set viewport deliberately**: Stable dimensions produce stable artifacts.
- **Stream to object storage**: Avoid local temp-file cleanup jobs.
- **Handle auth before navigation**: Protected pages need preloaded session state.

Common gotcha: forgetting `printBackground: true`, which changes layout and branding in exported PDFs.

Typical use case: invoice generation, compliance archiving, and visual regression snapshots.

### 6. Mobile-Mode Automation

Mobile automation is not just a user-agent string.

Input model, viewport, touch behavior, and browser characteristics all affect the result. If the mobile checkout flow differs from desktop, test the mobile experience directly.

```ts
const session = await steel.sessions.create({
  deviceConfig: { device: "mobile" },
});
const browser = await chromium.connectOverCDP(
  `wss://connect.steel.dev?apiKey=${process.env.STEEL_API_KEY}&sessionId=${session.id}`
);
const context = await browser.newContext({
  hasTouch: true,
  isMobile: true,
  viewport: { width: 390, height: 844 },
});
const page = await context.newPage();

await page.tap("#checkout-btn");
await page.waitForSelector(".payment-sheet", { state: "visible" });
```

What keeps it reliable:

- **Prefer touch actions when relevant**: Some controls are touch-specific.
- **Test mobile and desktop separately**: They drift at both UI and API layers.
- **Watch viewport-triggered lazy loading**: Smaller screens often defer more content.

Common gotcha: `page.tap()` needs a touch-capable context. If your connected page does not support touch, create a new context with `hasTouch: true`.

Typical use case: mobile-first checkout flows, mobile-only signup variants, and responsive regression checks.

### 7. Synthetic Monitoring and Incident Alerting

Ping checks tell you the host responded. Synthetic browser checks tell you whether the path still works.

A page can return `200 OK` and still be broken: blank shell, missing CTA, JavaScript exception, or incomplete render.

```ts
const session = await steel.sessions.create();
const browser = await chromium.connectOverCDP(
  `wss://connect.steel.dev?apiKey=${process.env.STEEL_API_KEY}&sessionId=${session.id}`
);
const page = browser.contexts()[0].pages()[0];

await page.goto("https://store.example.com");

const priceVisible = await page.locator(".product-price").isVisible();
const ctaVisible = await page.locator(".add-to-cart").isVisible();

if (!priceVisible || !ctaVisible) {
  const snap = await page.screenshot({ fullPage: true });
  await s3.upload({ Body: snap, Key: `incidents/${Date.now()}.png` });
  await slack.alert("#incidents", "Homepage check failed: missing critical elements");
}

await browser.close();
await steel.sessions.release(session.id);
```

What keeps alerts useful:

- **Assert business-critical UI**: Status code alone is not enough.
- **Alert on consecutive failures**: Reduce noise from transient issues.
- **Capture artifacts automatically**: Faster incident triage.
- **Run checks outside the failure domain you are testing**: Otherwise your monitor dies with the app.

Common gotcha: monitoring from the same infrastructure stack as the product under test.

Typical use case: recurring checkout-path validation with screenshot evidence on failure.

### Limitations: Works for X, Not Yet for Y

- Works well for JS-rendered pages, multi-step forms, visual capture, and synthetic user-path checks.
- It is not a substitute for a stable official API when one already exists and latency matters most.
- CAPTCHA support should be treated as a reliability tool, not a bypass guarantee ([CAPTCHAs API overview](https://docs.steel.dev/overview/captchas-api/overview), [CAPTCHA solving guide](https://docs.steel.dev/overview/stealth/captcha-solving)).
- Mobile-mode emulation is useful for many flows, but it is not a perfect stand-in for every real-device signal ([mobile mode](https://docs.steel.dev/overview/sessions-api/mobile-mode)).

### How to Evaluate a Managed Browser Platform

Use this checklist for Steel or any alternative:

| Capability to verify | Why it matters | Evidence link (Steel) |
| - | - | - |
| Session creation and lifecycle APIs | Prevent leaked browsers and orphaned jobs | [Sessions API overview](https://docs.steel.dev/overview/sessions-api/overview), [session lifecycle](https://docs.steel.dev/overview/sessions-api/session-lifecycle) |
| CDP connectivity for your framework | Lets you keep existing automation code | [Playwright](https://docs.steel.dev/overview/guides/playwright-node), [Puppeteer](https://docs.steel.dev/overview/guides/puppeteer), [Selenium](https://docs.steel.dev/overview/guides/selenium) |
| Proxy controls | Needed for region and anti-block reliability | [Proxies](https://docs.steel.dev/overview/stealth/proxies) |
| CAPTCHA tooling | Reduces manual interruptions in long flows | [CAPTCHAs API overview](https://docs.steel.dev/overview/captchas-api/overview), [CAPTCHA solving guide](https://docs.steel.dev/overview/stealth/captcha-solving) |
| State reuse between runs | Helps with authenticated and repeat workflows | [reusing auth context](https://docs.steel.dev/overview/sessions-api/reusing-auth-context), [Profiles API overview](https://docs.steel.dev/overview/profiles-api/overview) |
| Mobile-mode support | Needed when mobile and desktop paths diverge | [mobile mode](https://docs.steel.dev/overview/sessions-api/mobile-mode) |

### Why Steel Fits This Category

You do not need Steel to write these scripts. You need something like Steel when you want to run them reliably without turning Chrome infrastructure into your real product.

Steel handles the repetitive browser-ops layer: session lifecycle, routing options, framework compatibility, and the hooks you need when flows hit CAPTCHA or auth state. You still own selectors, retries, and business logic. That is the right split.

### Start Small

The best rollout pattern is still the boring one:

1. Start with one flow and one clear success metric.
2. Add failure artifacts before scaling concurrency.
3. Expand only after retry and teardown behavior are stable.

If you want a concrete implementation baseline, start with the [Steel quickstart](https://docs.steel.dev/overview/sessions-api/quickstart), then adapt the patterns above to your own stack. You can also use the [Steel Cookbook](https://github.com/steel-dev/steel-cookbook) for working examples.

Full code with snippets from this article is available in a separate repo [here](https://github.com/nibzard/top-7-headless-browser-automations).

## Blog: Introducing Steel CLI v0.2.0: Browser Automation Built for Agents

https://steel.dev/blog/steel-cli-and-agent-skill · Mar 3, 2026 · By Hussien Hussien

> Today we are launching the Steel Browser CLI and the steel-browser skill so agents can run browser workflows and return clear outcomes with markdown, screenshots, or PDFs.

**TL;DR:** Steel CLI v0.2.0 and the steel-browser skill let agents run multi-step browser workflows with stealth, captcha solving, proxies and parallel background sessions, and return markdown, screenshots or PDFs. The CLI passes through agent-browser commands and moves the local runtime under steel dev. Install with npm i -g @steel-dev/cli.

It answers:

- How do I install the Steel CLI?
- How do I install the steel-browser agent skill?
- What is SKILL.md used for?
- How do I solve a CAPTCHA with the Steel CLI?
- How do I run Steel's browser runtime locally?
- What can the Steel CLI and steel-browser skill do for agents?

Today we're launching the new Steel CLI and `steel-browser` skill, which brings browser automation redesigned from the ground up for agents.

Agents handle code, reasoning, and tool use well enough. Then they hit a real website and everything falls apart. Login walls, dynamic content, anti-bot systems, session state that doesn't persist. A five-minute human task becomes a twenty-minute debugging session.

This release targets that gap. It's also our first serious implementation of [agent experience (AX)](https://biilmann.blog/articles/introducing-ax/): building tools where agents get clear inputs, predictable outputs, and failures they can recover from.

### TL;DR

- New agent skill and CLI
- agent-browser integration
- Stealth: captcha solving & proxies for agents
- Run background browser sessions in parallel

[Video on YouTube](https://www.youtube.com/watch?v=eKkAwi8vt4Q)

### What this actually does

The skill and CLI work together to make web tasks agents can finish reliably.

- Run multi-step flows through login and dynamic UI
- Pull clean markdown from cluttered pages
- Capture screenshots and PDFs as evidence
- Handle anti-bot measures and CAPTCHAs
- Maintain session state across longer runs
- Return structured outcomes you can verify

A working agent web run should be boring. Predictable, reviewable, debuggable. Agent starts a browser session via CLI, follows the skill contract, executes commands (open, snapshot, click, fill, type, wait), collects artifacts, returns status.

That's it. No heroics required.

![](https://steel.dev/assets/framerusercontent.com/images/mOaPI51aFVTuRmJBNWk0VACWtY.png)

### SKILL.md: A contract, not a prompt

`SKILL.md` is a specification that tells an agent how to use a capability.

For web tasks, it tells the agent:

- When to invoke the skill
- How to execute the workflow
- What shape the output takes
- How to handle blockers

The goal is simple: less prompt glue, more repeatable behavior. Instead of rebuilding web handling for every project, your team adopts one stable path that carries across agents and harnesses.

### What the steel-browser skill handles

This [`steel-browser`](https://docs.steel.dev/overview/skills/available-skills/steel-browser) skill is designed for autonomous web tasks where basic fetch tools fall short, often failing across many sites due to blocking, complexity, and other limitations.

#### Anti-bot and CAPTCHA flow

When automation is blocked, agent can use these patterns:

```sh
steel browser start --session checkout-bot-check --session-solve-captcha
steel browser open https://example.com
steel browser captcha solve --session checkout-bot-check
```

For automation-first sessions:

```sh
steel browser start --session checkout-bot-check --stealth
```

This is the difference between an agent that reports what it can't do and one that finishes the job.

### The new Steel Browser CLI workflow

The CLI is the operator layer. It handles session lifecycle and gives agents and humans a clean interface for browsing work.

#### Session lifecycle, cloud or local

The CLI manages sessions and gives agents and humans a clean interface.

![](https://steel.dev/assets/framerusercontent.com/images/mdifGeQuPc61petQDWu3YqyCI.png)

#### Passthrough commands for agent browser actions

The `steel browser` command forwards inherited from awesome [agent-browser](https://github.com/vercel-labs/agent-browser?utm_source=steel.dev) actions with a command prefix swap, including `open`, `snapshot`, `fill`, `click`, and `wait`.

#### Local runtime now lives under `steel dev`

Local runtime orchestration is now explicit and separate:

- `steel dev install`: install dependencies
- `steel dev start`: start local runtime
- `steel dev stop`: stop it

This makes it easier to develop and debug workflows locally, then run the same shape of workflow in the cloud.

### Get started

```sh
# Install and auth
npm i -g @steel-dev/cli
steel login
```

Full command reference: [Steel CLI docs](https://docs.steel.dev/overview/steel-cli).

### Install the skill

Available in the CLI repo's skills package or via [skills.sh](https://skills.sh/steel-dev/cli/steel-browser?utm_source=steel.dev):

```sh
npx skills add steel-dev/cli --skill steel-browser
```

### Where this helps

This is not about browsing for its own sake. It is about unlocking agents and workflows where the web is the source of truth.

- Competitive research with verifiable screenshots
- Lead enrichment from JavaScript-heavy sites
- Bug reproduction with session recordings
- QA testing on live interfaces
- Compliance documentation captured as PDFs
- Data extraction from gated portals

### Give your agent a real browser

Run one real workflow. Tell us what worked and what didn't.

Join our [Discord](https://discord.gg/steel-dev) and share your experience with the new skill and CLI.

## Blog: Happy Path for Automating the Web with Steel

https://steel.dev/blog/happy-path-for-automating-the-web-with-steel · Feb 24, 2026 · By Nikola Balic

> Automate real web workflows fast with Steel’s managed cloud Chrome sessions. Create a session, connect Puppeteer, run steps, extract data, and release reliably.

**TL;DR:** The core Steel pattern is create a session, connect, run automation, release. The guide installs steel-sdk and puppeteer-core, starts a cloud Chrome session, connects Puppeteer over WebSocket, extracts data from example.com with page.evaluate(), then releases the session because Steel bills by session time.

It answers:

- How do I connect Puppeteer to a Steel cloud browser?
- How do I create and release a Steel browser session?
- How do I extract data from a page with Puppeteer?
- Why should I release Steel sessions when a workflow is done?

This guide walks through automating a real browser workflow in minutes.

This is a practical web automation guide for AI agents, using a managed cloud browser API so you can replace local Puppeteer stacks and enjoy the benefits of infinite scaling.

Instead of manually opening a browser and copying data from a page, you can run the same workflow inside a dedicated cloud browser session. The session behaves exactly like Chrome on your machine, except it runs in Steel’s infrastructure and is fully controlled through code.

Steel provides programmable browser sessions designed for agents and automation. Sessions start in under a second, can run for hours, and execute web workflows reliably in production environments.

We’ll build it step by step.

### Step 1: Get Your Steel API Key

Before writing any code, you need access to Steel’s cloud browser sessions. Access is granted through an API key, which authenticates requests to the Steel control plane and authorizes session creation.

1. Go to [steel.dev](https://steel.dev/) and sign up for an account
2. Navigate to your dashboard
3. Find your **API key**, it looks something like `sk_live_abc123...`
4. Copy it somewhere safe (e.g., don’t feed it to your coding agent)

### Step 2: Set Up Your Project

Create a new project and install dependencies:

```sh
mkdir steel-automation
cd steel-automation
npm init -y
npm install steel-sdk puppeteer-core dotenv
```

These dependencies let you build browser automation with Steel's managed cloud browser infrastructure without local Chrome provisioning.

**What you just installed:**

- **steel-sdk**: Creates and manages cloud browser sessions
- **puppeteer-core**: Controls the browser (clicks, types, extracts data)
- **dotenv**: Loads environment variables from .env file

### Step 3: Store Your API Key

Create a `.env` file in your project root to keep your API key out of your code for security:

```js
STEEL_API_KEY=your_api_key_here
```

### Step 4: Write the Automation Script

Create `scrape.js`. The complete code is in the Appendix. We'll walk through that code and break down each part so you understand exactly what's happening.

#### **The Setup**

```js
require('dotenv').config();
const Steel = require('steel-sdk');
const puppeteer = require('puppeteer-core');
const steel = new Steel({ steelAPIKey: process.env.STEEL_API_KEY });
```

This initializes the Steel client using your API key. The `steel` object is your interface for creating and managing browser sessions with browser automation over CDP.

#### **Starting a Session**

```js
const session = await steel.sessions.create();
```

This call provisions a new isolated browser session in Steel’s cloud. Each session runs a real Chrome instance and returns a unique `session.id`. All subsequent commands are scoped to that session.

Sessions are independent, which means you can run multiple workflows concurrently without state collisions.

#### **Connecting Puppeteer to Your Cloud Browser**

```js
const browser = await puppeteer.connect({
  browserWSEndpoint: `wss://connect.steel.dev?apiKey=${process.env.STEEL_API_KEY}&sessionId=${session.id}`
});
```

Puppeteer connects directly to the Steel session over WebSocket. The connection string includes your API key for authentication and the session ID to route commands to the correct browser instance.

Once connected, you’re controlling a real cloud browser as if it were running locally.

#### **Opening a Page and Navigating**

```js
const page = await browser.newPage();
await page.goto('https://example.com');
```

You are now controlling the browser session. `newPage()` opens a fresh tab, and `goto()` tells it to load example.com just like clicking the address bar and hitting Enter.

**Why Steel:** Many modern websites block non-browser traffic or return incomplete responses to HTTP clients. Steel runs a full browser session, so your automation executes exactly as a real user would, including JavaScript rendering, authentication flows, and dynamic content.

#### **Extracting Data**

```js
const pageData = await page.evaluate(() => {
  return {
    h1: document.querySelector('h1')?.textContent,
    paragraph: document.querySelector('p')?.textContent,
    allLinks: Array.from(document.querySelectorAll('a')).map(a => ({
      text: a.textContent,
      href: a.href
    }))
  };
});
```

This executes JavaScript inside the browser context to extract structured data. `page.evaluate()` runs JavaScript **inside the browser page**, just like opening your browser's console and typing code there.

You're using standard web APIs:

- `document.querySelector('h1')` - Find the first `<h1>` tag
- `document.querySelectorAll('a')` - Find all `<a>` link tags
- `.textContent` - Get the visible text
- `.href` - Get the link URL

Steel works with the automation frameworks you already use. If you know Puppeteer, you already know how to run workflows on Steel. There’s no new execution model, just managed browser infrastructure behind it.

#### **Closing the Session**

```js
await browser.close();
await steel.sessions.release(session.id);
```

This closes the Puppeteer connection and releases the browser session.

Steel bills based on session time. Always release sessions when your workflow completes to ensure proper resource cleanup and cost control.

**Pro tip:** Not sure if you have sessions running? Check your [Steel dashboard](https://app.steel.dev/sessions) to view all active sessions.

### Step 5: Run Your Automation

Execute the script:

```sh
node scrape.js
```

Example output:

```js nocopy
Starting a Steel browser session...
Session created: ses_abc123xyz
Navigating to example.com...
Page loaded!
Reading page content...
Data extracted:
{
  "h1": "Example Domain",
  "paragraph": "This domain is for use in illustrative examples...",
  "allLinks": [
    { "text": "More information...", "href": "https://www.iana.org/domains/example" }
  ]
}
Closing the session...
Done! Session closed.
```

You just executed a browser workflow inside a managed cloud session without provisioning infrastructure or maintaining browser fleets.

That’s the core Steel pattern: create a session, connect, run automation, release.

### What's Next?

This example demonstrates the core session lifecycle and the browser automation foundation for scraping, form automation, and agent workflows. In production, Steel extends this execution model with:

- Managed residential proxy routing and fingerprint controls
- Built-in CAPTCHA handling (reCAPTCHA, Turnstile)
- Long-lived sessions (up to 24 hours) with persisted state
- Live session viewers and replayable traces for debugging and verification
- Structured and markdown extraction for LLM-driven workflows
- Horizontal scaling across thousands of concurrent sessions

The primitive stays the same: create → connect → execute → release. Steel handles the execution layer.

You can find more examples in [Steel's Cookbook](https://github.com/steel-dev/steel-cookbook), and you can copy the complete script from this walkthrough in one place: [Steel Happy Path appendix script](https://gist.github.com/nibzard/6a2f3911a1953b7bef363a411c45a95b).

### The Bottom Line

Steel replaces custom browser infrastructure with a managed execution layer built for agents.

You get isolated sessions, state management, observability, anti-bot handling, and long-running workflows without operating browsers yourself.

Humans use Chrome. Agents use Steel.

### Need Help?

- [Steel Documentation](https://docs.steel.dev/)
- [Discord Community](https://discord.gg/steel-dev)

## Blog: Reducing False Positives for Production Agents

https://steel.dev/blog/production-agents · Feb 19, 2026 · By Jagadesh P

> The Web Is a Busy Place (and Not All Traffic Walks on Two Legs)

**TL;DR:** Anti-bot systems combine network, fingerprint, behavior and challenge signals into a risk score, so legitimate automation gets flagged. JavaScript overrides of browser properties reveal themselves as non-native. Ethical automation respects robots.txt and rate limits, asks for whitelisting, and uses CAPTCHA solvers as a last resort.

It answers:

- Why does my crawler get blocked even when it follows the rules?
- How do anti-bot systems detect bots?
- Why do JavaScript fingerprint overrides get detected?
- How can legitimate automation reduce false positives from bot detection?
- When is it appropriate to use a CAPTCHA solver?
- What are the four layers of bot detection?

A meaningful share of web traffic does not come from humans.

Some of it comes from **search engines indexing the web**, some from **SEO tools checking metadata**, some from **automated accessibility scanners**, and some from researchers collecting **public data** for AI models.

And then there are less friendly guests:

- Credential-stuffing scripts
- Fraud bots
- Aggressive scrapers
- Automated checkout bots
- Tools pretending to be users

Because the internet doesn’t come with a giant bouncer checking IDs at the gate, websites rely on layers of bot detection to sort the “good automation” from the “bad automation.”

Here is the core problem:

> Good bots still get caught in the crossfire.

This article is not about unethical evasion. It explains how anti-bot systems work so legitimate automation can operate responsibly and reduce false positives.

By the end of this article, you’ll understand:

- Why your crawler sometimes gets blocked even when it's doing everything right
- How anti-bot systems think
- How to design automation that feels “natural” to websites
- How to avoid accidentally setting off alarms
- And how to build bots that follow the rules and blend in without deception

*This is not a how-to manual for bad behavior.*

This is a practical map for navigating the modern web as an **ethical automator**.

![](https://steel.dev/assets/framerusercontent.com/images/unBZPuwcTKQ4uH1NyNHP1sRTM.jpeg)

### A Note on Legitimacy, Responsibility, and Being a Good Internet Citizen

Automation isn’t evil.

In fact, the internet would collapse without it.

Here are just a few examples of “good bots”:

- Googlebot and Bingbot keeping search engines updated
- Accessibility tools checking ARIA roles and contrast ratios
- SEO analyzers validating structured data
- QA bots testing websites for bugs
- Research crawlers collecting **public** information
- Archiving projects preserving digital history

But because bad bots often mimic good ones, websites can’t always tell the difference.

So ethical automation must:

- Respect **robots.txt**
- Honor rate limits
- Avoid stressing servers
- Stick to publicly accessible data
- Cite sources where appropriate
- Get explicit permission when testing private systems
- Follow regional data and scraping laws

The techniques in this article are for **avoiding false positives**, not bypassing protections on private or restricted content.

### Why Anti-Bot Systems Sometimes Misclassify Good Bots

Think of anti-bot systems like airport security scanners.

They’re not perfect, and they sometimes flag harmless travelers.

Your automation might be mistaken for a bot because:

- You send requests too quickly
- Your IP is from a datacenter
- Your browser fingerprint looks unnatural
- JavaScript runs differently in headless mode
- Your script never moves a mouse or scrolls
- Your timing is “too perfect”
- You load 50 pages in two seconds

None of these behaviors are harmful on their own, but in combination they often trigger risk scoring.

### The Four Layers of Detection (The Anti-Bot Model)

Modern anti-bot systems don’t rely on one trick.

They use a **stacked decision process**, combining multiple signals into a risk score. Here’s the simplified mental model:

![The Four Detection Layers](https://steel.dev/assets/framerusercontent.com/images/bcQINJ9xhOeqrBYjWqxGtABXuIg.jpeg)

Each layer catches different kinds of bots.

To avoid false positives, ethical automation must understand how all of these layers work.

#### 1. Network-Level Adaptation: Don't Arrive Like a Stampede

Before websites look at browsers or behavior, they inspect traffic at the network level.

##### Datacenter vs Residential IPs

Many malicious bots run on datacenter IPs, so legitimate bots using cloud servers may get flagged automatically.

Ethical automation sometimes uses:

- **Residential IPs**
- **ISP-issued IP ranges**
- **Mobile carrier IPs**

But only when appropriate, such as geo-specific research or compatibility testing.

##### Traffic That Feels Human (or at Least Polite)

Good bots should:

- Avoid rapid-fire bursts
- Spread requests naturally
- Pause between pages
- Follow crawl-delay settings
- Avoid crawling high-load sections at peak times

Polite Request Frequency

#### 2. Browser Fingerprint Adaptation: Looking Like a Real Browser

When automation frameworks like Playwright or Selenium run in their default configuration, they leave a trail of tiny “runtime leaks” that websites can detect.

Some common leaks:

- Missing or empty plugin lists
- Incorrect WebGL renderer
- Strange canvas output
- Mismatched timezone or locale
- Unusual error stack traces
- Incomplete API implementations

To avoid misclassification, ethical tools try to **match real browser behavior**.

Here are some common overrides that automation tools apply to avoid an unusual or easily identifiable fingerprint.

##### Navigator & Device Metadata Override

This snippet adjusts core navigator fields that many fingerprint checks inspect first.

```js
// Override User Agent
Object.defineProperty(navigator, 'userAgent', {
get: () => "Mozilla/5.0 (XWindows NT 11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36",
configurable: true
});

// Override Hardware Concurrency
Object.defineProperty(navigator, 'hardwareConcurrency', {
get: () => 4,
configurable: true
});

// Override Platform
Object.defineProperty(navigator, 'platform', {
get: () => "Linux",
configurable: true
});

// Override Battery API
Object.defineProperty(navigator, 'getBattery', {
  value: async function() {
    return {
      charging: true,
      chargingTime: 0,
      dischargingTime: Infinity,
      level: 1.0,
      addEventListener: () => {},
      removeEventListener: () => {}
    };
  },
  configurable: true
});

// Test it
console.log("User Agent:", navigator.userAgent);
console.log("Hardware Concurrency:", navigator.hardwareConcurrency);
console.log("Platform:", navigator.platform);

navigator.getBattery().then(battery => {
  console.log("Battery Level:", battery.level);
  console.log("Battery Charging:", battery.charging);
});
```

##### WebGL Vendor & Renderer Override

This example patches WebGL identity values, which are common high-signal fingerprint inputs.

```js
// Store original getParameter
const originalGetParameter = WebGLRenderingContext.prototype.getParameter;

// Override WebGL parameters
WebGLRenderingContext.prototype.getParameter = function(parameter) {
  // UNMASKED_VENDOR_WEBGL
  if (parameter === 37445) {
    return "Intel Inc.";
  }
  // UNMASKED_RENDERER_WEBGL
  if (parameter === 37446) {
    return "Intel Iris OpenGL Engine";
  }
  return originalGetParameter.call(this, parameter);
};

// Also override for WebGL2
if (window.WebGL2RenderingContext) {
  const originalGetParameter2 = WebGL2RenderingContext.prototype.getParameter;
  WebGL2RenderingContext.prototype.getParameter = function(parameter) {
    if (parameter === 37445) return "Intel Inc.";
    if (parameter === 37446) return "Intel Iris OpenGL Engine";
    return originalGetParameter2.call(this, parameter);
  };
}

// Test it
const canvas = document.createElement('canvas');
const gl = canvas.getContext('webgl') || canvas.getContext('experimental-webgl');
if (gl) {
  console.log("WebGL Vendor:", gl.getParameter(37445));
  console.log("WebGL Renderer:", gl.getParameter(37446));
}
```

##### Screen, Timezone & Locale Override

This block aligns display and locale signals so they stay consistent with expected session context.

```js
// Override Screen dimensions
Object.defineProperty(screen, 'width', {
  get: () => 1920,
  configurable: true
});

Object.defineProperty(screen, 'height', {
  get: () => 1080,
  configurable: true
});

Object.defineProperty(screen, 'availWidth', {
  get: () => 1920,
  configurable: true
});

Object.defineProperty(screen, 'availHeight', {
  get: () => 1040,
  configurable: true
});

// Override Timezone
const originalResolvedOptions = Intl.DateTimeFormat.prototype.resolvedOptions;
Intl.DateTimeFormat.prototype.resolvedOptions = function() {
  const options = originalResolvedOptions.call(this);
  options.timeZone = "America/New_York";
  options.locale = "en-US";
  return options;
};

// Test it
console.log("Screen Width:", screen.width);
console.log("Screen Height:", screen.height);
console.log("Timezone:", Intl.DateTimeFormat().resolvedOptions().timeZone);
console.log("Locale:", Intl.DateTimeFormat().resolvedOptions().locale);
```

##### Language and Plugins Override

This section covers language and plugin fields that scripts often use for quick client validation.

```js
// Override Languages
Object.defineProperty(navigator, 'language', {
  get: () => "en-US",
  configurable: true
});

Object.defineProperty(navigator, 'languages', {
  get: () => ["en-US", "en"],
  configurable: true
});

// Override Plugins (appear as if Chrome with standard plugins)
// Note: Chrome typically shows 3-5 PDF-related plugins
// For realistic spoofing, you can create actual plugin objects like:
// - "PDF Viewer" (internal-pdf-viewer)
// - "Chrome PDF Viewer"
// - "Chromium PDF Viewer"
// Each plugin should have: name, filename, description, length, item(), namedItem()
// And contain MimeType objects with: type, suffixes, description, enabledPlugin
Object.defineProperty(navigator, 'plugins', {
  get: () => {
    return {
      length: 3,
      item: (i) => null, /
      namedItem: (name) => null,
      refresh: () => {}
    };
  },
  configurable: true
});

// Test it
console.log("Language:", navigator.language);
console.log("Languages:", navigator.languages);
console.log("Plugin count:", navigator.plugins.length);
```

These overrides must run before page load so the site sees these values during fingerprint checks. This is only a small part of the full surface area.

##### The Hidden Problem With Overrides: JavaScript Reveals the Patch

Overrides like this look simple:

```js
WebGLRenderingContext.prototype.getParameter = function(parameter) {
  if (parameter === 37445)
    return "Intel Inc.";
  if (parameter === 37446)
    return "Intel Iris OpenGL Engine";
  return originalGetParameter.call(this, parameter);
};
```

But the moment you change a browser property, JavaScript starts revealing clues.

Here is what the WebGL `getParameter()` function looks like **in a real browser** versus **after an override**:

- **`WebGLRenderingContext.prototype.getParameter.toString()`**
  - **Native:** `"function getParameter() { [native code] }"`
  - **Override:** `"function(param) { if (param === 37445) return 'Intel Inc.'; ... }"`
- **`WebGLRenderingContext.prototype.getParameter.name`**
  - **Native:** `"getParameter"`
  - **Override:** `""`
- **`Function.toString.call(WebGLRenderingContext.prototype.getParameter)`**
  - **Native:** `"function getParameter() { [native code] }"`
  - **Override:** `"function(param) { if (param === 37445) return 'Intel Inc.'; ... }"`

Even though the override returns believable GPU values, the function no longer looks like a native browser function, so fingerprinting scripts catch it immediately.

So you fix one leak, another appears, and maintenance cost rises fast. At that point, you are effectively playing whack-a-mole with the JavaScript runtime.

#### 3. Behavioral Simulation: Acting Less Like a Script, More Like a Person

Humans:

- Scroll slowly
- Hesitate before clicking
- Move unpredictably
- Pause to read text

Bots do none of that by default.

Ethical automation uses *natural interaction patterns* to reduce aggressive traffic patterns and avoid stressing servers.

##### Human-Like Delays & Interaction

This snippet adds bounded waits and interaction pacing to avoid perfectly timed action patterns.

```js
// Human-like behavior module
const humanBehavior = {

  // Random delay between actions
  async wait(min = 80, max = 200) {
    const time = min + Math.random() * (max - min);
    return new Promise(resolve => setTimeout(resolve, time));
  },

  // Move mouse to a random point inside the element
	async moveToElement(el) {
	  const box = el.getBoundingClientRect();

		// Starting pint
	  const sX = Math.random() * window.innerWidth;
	  const sY = Math.random() * window.innerHeight;

		// Targent pint
	  const tX = box.left + Math.random() * box.width;
	  const tY = box.top + Math.random() * box.height;

	  const steps = 12; // Number of movements

	  for (let i = 0; i < steps; i++) {
	    const progress = i / steps;
	    const x = sX + (tX - sX) * progress + Math.random() * 2;
	    const y = sY + (tY - sY) * progress + Math.random() * 2;

	    window.dispatchEvent(
	    new MouseEvent("mousemove", { clientX: x, clientY: y }));
	    await this.wait(20, 40); // small human-like pauses
	  }
	}

  // Click with a tiny human-like pause
  async click(el) {
    await this.moveToElement(el);
    window.dispatchEvent(new MouseEvent("mousedown"));
    await this.wait(50, 120);
    window.dispatchEvent(new MouseEvent("mouseup"));
  },

  // Full simulation: move → wait → click → wait
  async simulate(el) {
    await this.moveToElement(el);
    await this.wait(100, 250);
    await this.click(el);
    await this.wait(150, 300);
  }
};

// Example of calling it in puppeteer
await page.evaluate(() => {
  humanBehavior.simulate(document.querySelector("button.login"));
});
```

##### Human Interaction Flow

This compact sequence summarizes the pacing pattern shown in the previous example.

```md nocopy
Load → Wait → Scroll → Pause → Click → Pause → Navigate
```

#### 4. Challenge Handling: Working With Verification, Not Around It

At some point, your automation will hit verification, usually a CAPTCHA or JavaScript challenge. These systems are meant to stop harmful bots. The goal is not to beat challenges, it is to handle them responsibly.

Here is how ethical automation should approach verification:

##### Ask The Site For A Whitelist

If your automation has a legitimate purpose, many website owners will whitelist your crawler. This can remove unnecessary friction immediately.

##### Use API Keys Or OAuth When Available

Some websites already offer official developer APIs that expose the same data you are trying to access.

##### Use CAPTCHA Solvers Only As A Careful, Last-Resort Option

CAPTCHA-solving services exist, but ethical automation should treat them as a backup plan. Consider them only when:

- The Data Is Fully Public
- The Site Does Not Provide An API
- You Are Respecting Robots.txt
- You Are Staying Within Reasonable Rate Limits

Even in these situations, solving should remain rare, polite, and carefully controlled.

Not all CAPTCHA solvers work the same way. Some rely on human operators, some use machine learning, and others use large pools of automated browsers. Speed, accuracy, and cost vary by method.

### Where Ethical Automation Actually Helps the Web

Here are real, positive examples where automation must adjust to avoid false positives:

- **Search Engines:** Must crawl public pages without breaking sites.
- **AI Dataset Builders:** Collect public content, cite sources, and respect limits.
- **SEO / Accessibility Tools:** Run periodic checks on performance, metadata, and compliance.
- **Web Archiving Initiatives:** Preserve digital history responsibly.
- **Research Labs:** Analyze public content for trends, policy studies, and academic data.

### Conclusion: Responsible Automation Makes the Web Better

Automation powers the internet.

It indexes, analyzes, monitors, verifies, archives, and tests the web at a scale no human ever could. But because malicious bots abuse the same techniques, anti-bot systems are forced to be strict.

By understanding these systems, network checks, fingerprinting logic, behavior analysis, and verification flows, you can build automation that:

- Is respectful
- Is compliant
- Avoids false positives
- Plays nicely with servers
- And contributes positively to the web ecosystem

Done right, automation is not a threat, it is an essential tool that keeps the modern internet running.

## Blog: Notte on Steel: Browser Infrastructure for Agents

https://steel.dev/blog/notte-on-steel · Feb 17, 2026 · By Nikola Balic

> Connect Notte agents to Steel browser infrastructure via CDP. One line of code gives you cloud browsers with session replay and built-in CAPTCHA solving.

**TL;DR:** Notte agents can run on Steel cloud browsers through CDP: create a Steel session and pass its websocket URL as Notte's cdp_url. Notte handles task planning, navigation and form filling, and Steel provides browser provisioning, session state, CAPTCHA solving, traces and session replay.

It answers:

- How do I connect Notte agents to Steel browsers?
- What does Notte provide and what does Steel provide in the integration?
- Can other automation frameworks connect to Steel through CDP?

Our friends at [Notte](https://www.notte.cc/) published an integration guide showing how to [run Notte agents on Steel browsers](https://www.notte.cc/blog/notte-steel-bring-your-own-browser-infrastructure). We're excited to see this. Notte brings intelligent task planning and execution, and Steel provides the browser infrastructure underneath.

### How It Works

Steel creates a browser session and exposes a CDP endpoint. Notte connects to it and takes control. Your automation code stays the same. Just point it at Steel's infrastructure instead of a local browser.

```python
from steel import Steel
from notte_sdk import NotteClient

# Create Steel browser session
steel = Steel(api_key=os.getenv("STEEL_API_KEY"))
session = steel.sessions.create()

# Connect Notte to Steel via CDP
notte = NotteClient()
with notte.Session(cdp_url=session.websocket_url) as s:
    agent = notte.Agent(session=s)
    agent.run(task="extract pricing from example.com")
```

One parameter (`cdp_url`) and your Notte agents run on Steel's cloud browsers.

### What Each Layer Provides

| From Notte | From Steel |
| - | - |
| Task planning and execution | Browser provisioning |
| Navigation and form filling | Session state and persistence |
| Anti-detection logic | Built-in CAPTCHA solving |
| Agent orchestration | Traces and session replay |

Notte handles the "what": planning tasks, navigating pages, filling forms. Steel handles the "where": provisioning browsers, maintaining state, capturing traces.

### Get the Full Guide

Notte's [blog post](https://www.notte.cc/blog) walks through the complete integration with production patterns, error handling, and environment setup. Their [docs](https://docs.notte.cc/integrations/steel) cover the Steel-specific configuration details.

### The Broader Pattern

CDP is the interface between automation frameworks and browser infrastructure. Notte demonstrates one integration. The same pattern works with Playwright, Puppeteer, or custom agents. You bring the control layer, Steel provides the browser.

When you connect via CDP, Steel automatically captures your agent's actions. Preview any session in the Steel Dashboard and you'll see a complete agent log: every navigation, click, and form fill, replayable step by step.

### Ship Something Cool

- [Notte](https://notte.cc/): Intelligent browser automation
- [Steel Cookbook](https://github.com/steel-dev/steel-cookbook): Integration examples
- [Discord](https://discord.gg/steel-dev): Share what you're building

Humans use Chrome. Agents use Steel.

## Blog: How Websites Decide You're Human

https://steel.dev/blog/anti-bot-defense · Feb 16, 2026 · By Jagadesh P

> Modern anti-bot systems use layered network, device, behavioral, and challenge-based defenses to distinguish humans from increasingly sophisticated malicious bots.

**TL;DR:** Bots make up about 42% of web traffic per Akamai's 2024 report, nearly two-thirds of them malicious. Anti-bot systems tell humans from automation with four layers: network checks (IP reputation, rate limiting), browser and device fingerprinting, behavioral analysis, and challenges such as CAPTCHAs used only on high risk.

It answers:

- How do websites detect bots?
- What is browser fingerprinting and how does canvas fingerprinting work?
- What signals do anti-bot systems use to tell humans from bots?
- Why do anti-bot systems use multiple layers of detection?
- What percentage of web traffic comes from bots?
- What rate limiting techniques do websites use against bots?

Automated bots account for nearly half of all web traffic. According to Akamai's 2024 [State of the Internet report](https://www.akamai.com/newsroom/press-release/bots-compose-42-percent-of-web-traffic-nearly-two-thirds-are-malicious), bots make up about 42% of traffic, and nearly two-thirds of those are malicious. They scrape protected data, stuff credentials, hijack accounts, and exploit competitive advantages.

This article explains how anti-bot protection works under the hood: the signals collected, the layers involved, and the logic that separates humans from sophisticated automation. Understanding the machinery helps you evaluate solutions, debug issues, and appreciate what it takes to defend modern applications.

### Understanding the Bot Threat Landscape

#### Three Categories of Bot Traffic

Modern websites see three types of automated traffic.

![Depicting bot detection and management process, categorizing bots, intelligence gathering, risk scoring, and response strategies.](https://steel.dev/assets/framerusercontent.com/images/p5iOW24qfIBGkzMV0xcX23MJr8Y.jpeg)

**Friendly Bots**

Search engine crawlers, uptime monitors, feed aggregators, and copyright verification tools. They follow robots.txt, identify themselves, and behave predictably. Let them through.

**Jekyll and Hyde Bots**

Price comparison scrapers, social media automation tools, ticketing bots. Sometimes useful, sometimes abusive. Depends on frequency, context, and business impact.

**Malicious Bots**

Credential stuffing, DDoS attacks, payment fraud, account takeover, inventory hoarding, spam. This is what anti-bot systems exist to stop.

### Why Modern Anti-Bot Systems Need Multiple Layers

Bots range from simple scripts to full-blown headless browsers that mimic human behavior. No single detection method catches everything. Network-level checks stop basic automation but fail against residential proxies. Fingerprinting catches device anomalies but can be spoofed. Behavioral signals work well, but high-risk flows still need challenges.

Modern anti-bot systems layer these techniques so weaknesses in one area get covered by strengths in another. Websites evaluate risk dynamically and escalate friction only when something looks truly suspicious.

![Multi-layered bot detection workflow](https://steel.dev/assets/framerusercontent.com/images/sHWtMzbYAqZbnd2t8ytRMMgjE0.jpeg)

### Layer 1: Network-Level Detection

#### IP Reputation Analysis

Anti-bot systems check incoming IPs against global threat intelligence sources to identify datacenter IPs, proxy services, VPN endpoints, Tor exit nodes, and known malicious addresses. IPs with poor reputation get flagged for additional verification like CAPTCHA challenges.

#### Rate Limiting

Rate controls detect abnormal request patterns and prevent abuse. Common techniques:

- Fixed window: counters reset at fixed intervals, such as 100 requests per hour
- Sliding window: distributes limits over rolling time intervals for smoother traffic management
- Token bucket: allows short bursts while maintaining sustained rate constraints

When clients exceed limits, servers return HTTP 429 Too Many Requests. Advanced systems adapt limits based on authentication status, endpoint sensitivity, and past behavior.

### Layer 2: Browser and Device Fingerprinting

Browser and device fingerprinting generates stable identifiers by analyzing browser environment, operating system, and hardware characteristics. These identifiers don't rely on cookies, making them effective against bots that rotate identities, clear storage, or run in private mode.

![Browser fingerprinting techniques and how they combine to create unique device identifiers](https://steel.dev/assets/framerusercontent.com/images/pEkMOXNq7QwIc4BCgCYFsx7hM.jpeg)

#### Canvas Fingerprinting

Canvas fingerprinting uses the HTML5 canvas element to detect differences in GPU hardware, graphics drivers, and rendering engines. The system draws text or graphics on a hidden canvas and captures the pixel data. Small variations in hardware or driver configuration produce different pixel patterns, creating a unique fingerprint.

#### Conceptual example

```js
// Canvas fingerprint generation (conceptual example)
const canvas = document.createElement('canvas');
const ctx = canvas.getContext('2d');

ctx.textBaseline = 'top';
ctx.font = '14px Arial';
ctx.fillText('Browser fingerprint test', 2, 2);

const dataURL = canvas.toDataURL();
const fingerprint = hash(dataURL);
```

#### WebGL Fingerprinting

WebGL fingerprinting uses the browser's 3D rendering pipeline. It collects GPU vendor, renderer strings, supported shader extensions, and rendering behavior. These parameters differ across devices and help identify automation tools using virtual GPUs.

#### Audio Context Fingerprinting

The Web Audio API generates audio signals and measures how the device processes them. The resulting waveform varies across devices due to hardware audio pipelines, drivers, and browser implementations. These differences form a stable signature that's difficult for bots to spoof.

#### Font Enumeration

Font fingerprinting checks the list of installed system fonts. Each operating system, enterprise device, or custom environment tends to have a unique font combination. These lists help differentiate between real users, automated browsers, and headless environments.

#### Hardware and Environment Profiling

Anti-bot systems gather device metadata to build a broader fingerprint. Common signals:

- Screen size and pixel density
- Available memory
- CPU core count
- Color depth
- Battery status (on mobile)
- Installed plugins, MIME types, or extensions
- System locale and timezone

Bots often fail to replicate the full set of these attributes, and small inconsistencies can reveal automated behavior.

### Layer 3: Behavioral Analysis

Behavioral analysis identifies patterns that deviate from natural human interaction.

#### Mouse Movement Analysis

Systems track cursor paths, acceleration, hesitations, and micro-adjustments. Humans move their mouse with natural curves and irregular pauses. Bots generate straight, overly precise, or uniform movements.

#### Keyboard Dynamics

Systems evaluate typing cadence, key-press duration, rhythm variability, and error behavior. Human typing includes inconsistencies and occasional mistakes. Automated input shows perfectly uniform timing.

#### Navigation Patterns

Systems observe page sequence, dwell time, scroll depth, speed, and interaction timing. Warning signs include instant form submissions, zero page dwell time, or clicking elements immediately after load.

#### Session Consistency

Systems check whether user attributes stay stable during a session. Abrupt changes in fingerprints, IP, geolocation, or device traits indicate account takeover or bot-driven manipulation.

Modern anti-bot systems apply machine learning models trained on massive datasets of real user interactions to identify statistical anomalies in real time.

### Layer 4: Challenge Mechanisms

Challenge mechanisms act as the final barrier when a request appears risky. These controls require the client to prove a human or genuine browser environment operates it.

#### CAPTCHA Systems

CAPTCHAs remain the most well-known challenge method. Modern variants:

- Image-based CAPTCHAs where users read distorted text or pick the correct characters
- Object-recognition challenges that ask users to identify items like vehicles or signs
- Invisible CAPTCHAs that silently assess risk and only show a challenge when necessary

CAPTCHAs add friction and impact accessibility. Use them sparingly, only when risk is high.

#### Adaptive Interactive Challenges

Some systems present lightweight interactive puzzles: dragging sliders, matching shapes, completing simple tasks. These adapt to the perceived risk level, making them harder for automated tools but easy for humans.

#### JavaScript Execution Challenges

These challenges verify the environment supports full JavaScript execution and browser APIs. Examples include:

- Checking DOM manipulation behavior
- Requiring accurate execution of cryptographic or timing-based operations
- Creating dynamic elements that must be interpreted in a real browser

Bots running in incomplete or emulated environments fail these checks.

### The Constant Evolution of Bots and Defenses

Anti-bot engineering is a continuous arms race. As detection methods improve, attackers adapt with better browser automation tools, real-device spoofing, residential proxy networks, human-assisted solving, and AI-driven interaction patterns.

Anti-bot systems must evolve continuously, updating signals, tuning thresholds, combining heuristics with learned models. Static defenses don't last long. Layered and adaptive ones do.

### Conclusion

Modern anti-bot systems operate as a layered security pipeline, analyzing network signals, device characteristics, behavior patterns, and environmental clues to distinguish real users from sophisticated automation. No single technique stands alone. Effective defenses combine reputation data, fingerprinting, behavioral modeling, and adaptive challenges.

Understanding what happens behind the scenes demystifies why requests get flagged, why CAPTCHAs appear, and why bot mitigation is more complex than blocking IP ranges or checking user agents. Bots evolve quickly. Defending against them requires systems that evolve just as fast.

## Blog: Steel vs Kernel: a practical comparison

https://steel.dev/blog/steel-vs-kernel · Jan 20, 2026 · By Nikola Balic

> Steel and Kernel both provide remote browser infrastructure for automation and agent workflows.

**TL;DR:** Steel and Kernel both run remote browser sessions for Playwright and Puppeteer via CDP. Steel's runtime is open source and self-hostable, with profile-based state and tiered plans; Kernel is a managed platform of unikernel-based browsers with standby mode, co-located Playwright Execution and per-second usage pricing.

It answers:

- What is the difference between Steel and Kernel?
- Can Steel be self-hosted?
- What is Kernel's standby mode?
- What is Kernel's Playwright Execution?
- How does Steel pricing compare to Kernel pricing?

Steel and Kernel both provide remote browser infrastructure for automation and agent workflows. This page focuses on the differences that typically matter in production: deployment surface, state semantics, execution model, and cost model.

Both platforms support mainstream automation stacks and cover the common “cloud browser” requirements. The choice usually comes down to how you want to run the browser layer, how you persist state across sessions, and how you pay for capacity.

### At a glance

**Common ground**

- Remote browser sessions compatible with Playwright/Puppeteer-style workflows via CDP.
- Persistent state primitives for reuse across sessions (for example, profiles).
- Stealth/proxy/CAPTCHA options available as part of the platform story.

**Differences that matter**

- Open-source runtime, transparency and self-hosting surface area
- State semantics (profile reuse vs standby/snapshot-style persistence)
- Where your code runs (remote control vs co-located execution)
- Pricing model (tiered plans vs usage-based metering)

### Summary

| Topic | Steel | Kernel |
| - | - | - |
| Deployment surface | Open-source + self-hosting and managed platform with enterprise support | Managed platform built around unikernel-based browsers |
| State model | Profile-based persistence for reusable auth/state | Profile-based persistence plus standby mode for idle browsers |
| Execution model | Remote sessions with agent-oriented SDK/integrations | Remote sessions plus co-located Playwright execution option |
| Observability | Live view + recordings/logging tools | Live view + replay/recording features (plan-dependent) |
| Agent model approach | Agent-neutral browser API | Includes an MCP server and code-execution workflows |
| Bot mitigation | Stealth/proxy/CAPTCHA options, plan-dependent | Stealth mode that bundles proxy + reCAPTCHA solver |
| Pricing model | Tiered plans (predictable budgeting) | Usage-based metering (pay per second; standby reduces idle cost) |

### Differences that matter

#### 1) Deployment surface

**Steel**

- The core browser runtime is open source and can be self-hosted and transparently inspected.
- Steel also offers a fully managed platform and enterprise offering.
- Self-hosting docs cover common deployment paths (for example, Docker).

**Kernel**

- Kernel is primarily a managed platform with an architecture built around unikernel-based browsers.
- Usage and platform controls are expressed through Kernel’s hosted APIs and product surface.

#### 2) State and isolation

**Steel**

- Profiles are the durable unit for cross-session state (auth, cookies, browser configuration).
- Useful when workflows need consistent identity and repeatable reuse.

**Kernel**

- Profiles persist browser state (cookies and local storage) for reuse across sessions.
- Standby mode is designed for keeping browsers idle without losing state between active connections.

#### 3) Performance and reliability

- Benchmark reference: Steel publishes an open harness that includes Kernel in the provider set. See the repo for current results and rerun it in your own region and workload: <https://github.com/steel-dev/browserbench>

#### 4) Execution model

**Steel**

- Remote session control through a browser API, with agent-oriented SDKs and integrations.
- Designed to stay compatible with standard automation tooling and agent frameworks.

**Kernel**

- Standard remote control via CDP.
- Optional “Playwright Execution” runs Playwright code in the same VM as the browser to reduce latency on chatty workloads.

#### 5) Observability and debugging

**Steel**

- Live viewing and session recordings support fast failure diagnosis.
- Logs and traces are designed around quick iteration on flaky web workflows.

**Kernel**

- Live view is a first-class workflow.
- Replay/recording and debugging depth depend on plan features and how sessions are configured.

#### 6) Pricing model

**Steel**

- Billing unit: tiered plans with included usage.
- Typical fit: teams that want predictable monthly spend and straightforward capacity planning.

**Kernel**

- Billing unit: usage-based metering (per-second pricing).
- Typical fit: teams that want cost to track utilization closely, with standby reducing spend during idle periods.

### When Steel is a good fit

- You want an open, inspectable browser runtime with a clear self-hosting path.
- You want a vendor-neutral browser API that works with standard automation tooling.
- You want agent-oriented SDKs and integrations to reduce glue code.
- You want predictable spend and simple capacity planning.
- You want reproducible benchmarking you can rerun in your own region.

### Next step

- Start with Steel: [steel-docs](https://docs.steel.dev/)
- Reproduce lifecycle benchmarks: [steel-browserbench](https://github.com/steel-dev/browserbench)
- Self-host Steel Browser: [steel-self-host](https://docs.steel.dev/overview/self-hosting/docker)

## Blog: Steel vs Browserbase: a practical comparison

https://steel.dev/blog/steel-vs-browserbase-a-practical-comparison · Jan 14, 2026 · By Nikola Balic

> Steel and Browserbase both provide remote browser infrastructure for automation and agent workflows.

**TL;DR:** Steel and Browserbase both run remote browser sessions for Playwright-style workflows. Steel's runtime is open source and self-hostable, uses profiles for state, stays agent-neutral, and is faster in the open browserbench lifecycle benchmark; Browserbase is a managed platform with contexts, Stagehand and plan-based quotas.

It answers:

- What is the difference between Steel and Browserbase?
- Can Steel be self-hosted?
- Is Steel faster than Browserbase?
- How does Steel persist browser state compared to Browserbase?
- How does Steel pricing compare to Browserbase pricing?

Steel and Browserbase both provide remote browser infrastructure for automation and agent workflows. This page focuses on the differences that typically matter in production: deployment surface, observability defaults, and cost model.

Both platforms work with standard automation tooling and cover the common “cloud browser” requirements. The choice usually comes down to how much control you need over the browser layer and how you want to operate, debug, and budget for sessions at scale.

### At a glance

**Common ground**

- Remote browser sessions compatible with Playwright/Puppeteer/Selenium-style workflows.
- Persistent state primitives for reuse across sessions (for example, profiles/contexts).
- Stealth/proxy/CAPTCHA options available as part of the platform story.

**Differences that matter**

- Open-source runtime, transparency and self-hosting surface area
- Session lifecycle performance (benchmarkable via an open harness)
- Recording/replay and debugging defaults
- Packaging and plan boundaries (usage units and included quotas)

### Summary

| Topic | Steel | Browserbase |
| - | - | - |
| Deployment surface | Open-source + self-hosting and managed platform with enterprise support | Managed platform with enterprise deployment options |
| State model | Profile-based persistence for reusable auth/state | Context-style persistence for reuse across sessions |
| Execution model | Remote sessions with agent-oriented SDK/integrations | Remote sessions with platform tooling around sessions |
| Observability | Live view + recordings/logging tools | Inspector + recording/replay tooling (defaults vary by plan) |
| Agent model approach | Agent-neutral browser API | Includes Stagehand |
| Bot mitigation | Stealth/proxy/CAPTCHA options, plan-dependent | Stealth/proxy/CAPTCHA options, plan-dependent |
| Pricing model | Tiered plans (predictable budgeting) | Tiered plans with included quotas (plan boundaries matter) |

### Differences that matter

#### 1) Deployment surface

**Steel**

- The core browser runtime is open source and can be self-hosted and transparently inspected.
- Steel also offers a fully managed platform and enterprise offering.
- Self-hosting docs cover common deployment paths (for example, Docker).

**Browserbase**

- Browserbase is primarily a managed platform.
- Deployment options and controls are expressed through plan and enterprise offerings.

#### 2) State and isolation

**Steel**

- Profiles are the durable unit for cross-session state (auth, cookies, browser configuration).
- Useful when workflows need consistent identity and repeatable reuse.

**Browserbase**

- Context-style state persistence supports reuse across sessions.
- Useful when you want a clean default session model and explicit reuse when needed.

#### 3) Performance and reliability

- Performance: Steel is faster in the published lifecycle benchmark. See the open, reproducible harness (which includes Browserbase in the provider set) for current results and rerun it in your own region and workload: <https://github.com/steel-dev/browserbench>

#### 4) Observability and debugging

**Steel**

- Live viewing and session recordings support fast failure diagnosis.
- Logs and traces are designed around quick iteration on flaky web workflows.

**Browserbase**

- Browserbase emphasizes session inspection and recording/replay tooling.
- Debugging experience depends on plan features and defaults.

#### 5) Pricing model

**Steel**

- Billing unit: tiered plans with included usage.
- Typical fit: teams that want predictable monthly spend and straightforward capacity planning.

**Browserbase**

- Billing unit: tiered plans with included quotas across browser hours, bandwidth, and features.
- Typical fit: teams that want a managed platform where usage and feature access track plan levels.

### When Steel is a good fit

- You want an open, inspectable browser runtime with a clear self-hosting path.
- You want a vendor-neutral browser API that works with standard automation tooling.
- You want agent-oriented SDKs and integrations to reduce glue code.
- You want predictable spend and simple capacity planning.
- You want reproducible benchmarking you can rerun in your own region.

### Next step

- Start with Steel: [steel-docs](https://docs.steel.dev/)
- Reproduce lifecycle benchmarks: [steel-browserbench](https://github.com/steel-dev/browserbench)
- Self-host Steel Browser: [steel-self-host](https://docs.steel.dev/overview/self-hosting/docker)

## Blog: What is a CAPTCHA solver

https://steel.dev/blog/what-is-a-captcha-solver · Dec 27, 2025 · By Nikola Balic

> Learn what a CAPTCHA solver is, how Steel handles CAPTCHAs, supported services, setup patterns, and production limits before automating verification reliably.

**TL;DR:** A CAPTCHA solver observes the challenge lifecycle and returns the expected response token so an automated flow can continue. Steel prevents challenges with realistic browser profiles and solves the rest automatically (solveCaptcha: true) or through a manual solve endpoint. Success is not guaranteed, and solving needs a paid plan.

It answers:

- What is a CAPTCHA solver?
- How does Steel handle CAPTCHAs in a browser session?
- How do I enable automatic CAPTCHA solving in a Steel session?
- How do I solve a CAPTCHA manually with the Steel SDK?
- Which Steel plans include CAPTCHA solving?
- What are the limits of Steel's CAPTCHA solving?

You are running an automation flow and every few dozen requests the run stalls on a verification gate. Your retry logic repeats, and the job still misses its SLA.

Instead of rebuilding CAPTCHA tooling, do this: use Steel's CAPTCHA layer to prevent common challenges, solve when needed, and keep the session recoverable.

In the wild, this control loop commonly appears in:

- web scraping and browser automation jobs.
- login portals, account-creation flows, and payment checks.
- contact forms, polls, and dashboard actions protected by bot defenses.

### What a CAPTCHA solver is

A CAPTCHA solver is a mechanism that observes the challenge lifecycle and returns the expected response token so an automated flow can move forward. In production, this usually means a mix of:

- machine learning inference
- third-party solving services
- browser-level automation
- token flow handling when a challenge provides one

The goal is reliability, not just convenience. If automation depends on a challenge-heavy surface, this layer matters.

CAPTCHAs can be active, where a visible challenge appears, or passive, where behavior-based checks trigger friction before a widget is shown. Legacy formats still include text, image, and audio CAPTCHAs, while modern systems use behavioral scoring from movement and timing signals.

### What Steel says a CAPTCHA solver does

Steel uses a two-pronged model:

- Prevention first with realistic browser profiles that reduce challenge frequency.
- Automatic solving when a CAPTCHA still appears.

This matches the [anti-bot defense](https://steel.dev/blog/anti-bot-defense) model, where the protection stack often does much more than just showing a puzzle, including fingerprint, behavioral, and request signals before a challenge is even shown.

### How Steel handles CAPTCHAs inside a session

The docs describe this internal flow:

1. detect CAPTCHA elements with page signal checks.
2. track CAPTCHA state by page.
3. classify the challenge type.
4. solve using an internal route.
5. verify success before continuing.

Even with this structure, challenge handling is not guaranteed. Plans include operational limits and latency impact.

### Enable automatic solving in session creation

To enable autosolving, set `solveCaptcha: true`.

#### JavaScript (Node.js): Creating a Session with Captcha & Stealth Config

```ts
import Steel from 'steel-sdk';

const client = new Steel();

const session = await client.sessions.create({
  solveCaptcha: true
});
```

#### Python: Creating a Session with Captcha & Stealth Configuration

```python
from steel import Steel

client = Steel()

session = client.sessions.create(
    solve_captcha=True
)
```

To keep detection but avoid automatic solves, disable `autoCaptchaSolving` in `stealthConfig`.

#### JavaScript (Node.js) – Async Session Creation with Captcha & Stealth Config

```ts
const session = await client.sessions.create({
  solveCaptcha: true,
  stealthConfig: {
    autoCaptchaSolving: false
  }
});
```

#### Python – Session Creation with Captcha & Stealth Configuration

```python
session = client.sessions.create(
    solve_captcha=True,
    stealth_config={
        "autoCaptchaSolving": False
    }
)
```

### Manual solve for fine control

If automation should only solve when explicit signals happen, you can call the solve endpoint directly. The same target can be selected by session-level auto-detection, task ID, URL, or page ID.

#### JavaScript (Node.js) – Solving Captchas with Optional Parameters

```ts
await client.sessions.captchas.solve('sessionId');
await client.sessions.captchas.solve('sessionId', { taskId: 'task_123' });
await client.sessions.captchas.solve('sessionId', { url: 'https://example.com' });
await client.sessions.captchas.solve('sessionId', { pageId: 'page_123' });
```

#### Python – Solving Captchas with Optional Arguments

```python
client.sessions.captchas.solve("sessionId")
client.sessions.captchas.solve("sessionId", task_id="task_123")
client.sessions.captchas.solve("sessionId", url="https://example.com")
client.sessions.captchas.solve("sessionId", page_id="page_123")
```

The identifiers used in manual mode come from the CAPTCHA status response.

### Works for x, not yet for y

Works for:

- session automation with supported service types.
- teams that can budget extra timeout and retry logic around protected pages.
- Developer, Startup, and Enterprise plan users.

Not yet for:

- guaranteed 100% success.
- flows where policy explicitly bans automation or forbids any CAPTCHA solving.
- unsupported challenge systems such as enterprise-specific and specialized CAPTCHAs.
- free tier use, since solving is plan-gated.

### What to use with it

A practical setup still needs human review and controls around waits, retries, permissions, and request rhythm, plus verification and recovery checkpoints. This is a production reliability pattern, not a magic switch. Use this to reduce friction in real automations, not to bypass the intent of a security control. In sensitive environments, pair solving with manual approvals and policy checks so the execution stays auditable and compliant. This is the same control mindset used in [production agents](https://steel.dev/blog/production-agents), where reliability is managed with explicit guardrails and recovery loops.

When you want the current official behavior and edge-case notes read our docs: [CAPTCHA Solving Docs](https://docs.steel.dev/overview/stealth/captcha-solving).

Humans use Chrome. Agents use Steel.

## Blog: How to Run Headless Browsers in the Cloud for Web Scraping

https://steel.dev/blog/headless-browsers-cloud-scraping · Nov 17, 2025 · By Nikola Balic

> How to run headless browsers in the cloud for web scraping, what the options are, where they differ, and why Steel.dev is built for this workload.

**TL;DR:** Headless browsers can run in the cloud on a VM, in managed containers, in serverless functions or via a managed browser service. Self-hosting at scale brings memory leaks, zombie processes, lost cookies, cold starts and proxy work. Steel.dev exposes a CDP endpoint, so Playwright, Puppeteer or Selenium code connects unchanged.

It answers:

- How can I run headless browsers in the cloud for web scraping?
- What breaks when you self-host headless Chrome at scale?
- Can I use my existing Playwright or Puppeteer code with a cloud browser?
- How does Steel.dev compare to Browserbase, Kernel, and Browserless?
- When should I self-host headless browsers instead of using a managed service?
- Should I use Playwright, Puppeteer or Selenium for cloud scraping?

### How to Run Headless Browsers in the Cloud for Web Scraping

This guide explains why modern sites require real browsers, the deployment options available, where each approach breaks down, and why [Steel](https://steel.dev/) has become the default choice for production scraping teams.

### What “headless browser scraping in the cloud” actually means

A headless browser runs Chrome without a visible window while executing scripts just like a human-operated browser. You automate navigation, wait for dynamic content, extract data, and shut it down. Static HTTP clients return only the initial HTML, so they miss content rendered by frameworks like React or Vue. A real browser solves that gap but introduces CPU cost, RAM pressure, and operational complexity.

### Four ways to run headless browsers in the cloud

#### 1. Cloud VM (EC2, GCE, Azure VM)

Run Playwright or Puppeteer directly on a Linux VM when you want full control.

```ts
import { chromium } from "playwright";

const browser = await chromium.launch({ headless: true });
const page = await browser.newPage();
await page.goto("https://example.com");
const title = await page.title();
await browser.close();
```

*When this fits*

- Learning, prototypes, and small jobs
- Workloads with steady predictable traffic
- Teams that want full environment control

*What hurts*

- You manage scaling, failover, Chrome crashes, and proxy rotation

#### 2. Docker plus managed containers (Cloud Run, ECS/Fargate, Fly.io)

Package Chrome into a container for portable deployment.

```js
FROM mcr.microsoft.com/playwright:v1.40.0-jammy

WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .

CMD ["node", "scraper.js"]
```

Deploy to Cloud Run:

```sh
gcloud run deploy scraper --source . --region us-central1
```

*When this fits*

- Medium-scale scraping without full server management
- Container portability across clouds

*What hurts*

- Chrome memory leaks persist unless you recycle processes
- You still own browser lifecycle and cookie storage

#### 3. Serverless functions (Lambda, Cloud Functions)

Use a slim Chromium build for bursty or event-driven workloads.

```ts
const chromium = require("@sparticuz/chromium");
const { remote } = require("webdriverio");

exports.handler = async (event) => {
  const browser = await remote({
    capabilities: {
      browserName: "chrome",
      "goog:chromeOptions": {
        binary: await chromium.executablePath,
        args: chromium.args,
      },
    },
  });

  await browser.url("https://example.com");
  const title = await browser.getTitle();
  await browser.deleteSession();

  return { title };
};
```

*When this fits*

- Event-driven or bursty workloads
- Prototyping or low-frequency tasks

*What hurts*

- Hard timeout limits (15 minutes on Lambda)
- Cold starts add several seconds per invocation
- No persistent sessions, so authenticated scraping is painful

#### 4. Managed browser services

Managed browser services host Chrome for you and expose it through a WebSocket API. Steel.dev is the most flexible option in this category because it offers both a managed cloud and an open-source self-host version with the same API. You connect Playwright or Puppeteer over CDP, run your automation, and disconnect while the provider handles scaling, proxies, and observability.

*When this fits*

- Production scraping at scale without dedicated DevOps
- Authenticated or multi-step flows that need persistent cookies
- High concurrency (hundreds of sessions)

*Trade-off* You pay a service fee instead of investing engineering hours in infrastructure.

### What breaks when you self-host at scale

1. **Missing system libraries**: minimal containers often lack fonts, sandbox support, or `libgbm`.
2. **Memory growth**: Chrome leaks memory during long sessions and eventually hits container limits.
3. **Zombie processes**: crashed Chrome binaries leave orphaned processes that consume resources.
4. **Cookie and session storage**: stateless environments lose authentication state between runs.
5. **Cold starts**: serverless launches add several seconds to each invocation.
6. **Proxy management**: rotating residential IPs and handling bans becomes a full-time job.
7. **Difficult debugging**: without screenshots or replay, reproducing production failures is tough.

Managed services exist to absorb these failure modes and keep browsers healthy.

### How Steel.dev works

Steel.dev provides remote browser sessions that speak the Chrome DevTools Protocol, so your existing Playwright, Puppeteer, or Selenium code runs unchanged. Create a session, connect over WebSocket, execute your automation, then release the session.

```ts
import { chromium } from "playwright";
import Steel from "steel-sdk";

const steel = new Steel({ steelApiKey: process.env.STEEL_API_KEY });

const session = await steel.sessions.create({
  useProxy: true,
  solveCaptcha: true,
});

const browser = await chromium.connectOverCDP(
  `wss://connect.steel.dev?apiKey=${process.env.STEEL_API_KEY}&sessionId=${session.id}`
);
const page = browser.contexts()[0].pages()[0];

await page.goto("https://example.com/products");
await page.waitForSelector(".product-card");
const items = await page.locator(".product-card").allTextContents();

await browser.close();
await steel.sessions.release(session.id);
```

#### Session state and persistence

Steel sessions preserve cookies and local storage so you can log in once and reuse the context.

```ts
const session = await steel.sessions.create({
  sessionContext: savedContext,
  useProxy: true,
});
```

#### Concurrency example

```ts
const targets = ["https://site-a.com", "https://site-b.com", "https://site-c.com"];

const results = await Promise.all(
  targets.map(async (url) => {
    const session = await steel.sessions.create({ useProxy: true });
    const browser = await chromium.connectOverCDP(
      `wss://connect.steel.dev?apiKey=${process.env.STEEL_API_KEY}&sessionId=${session.id}`
    );
    const page = browser.contexts()[0].pages()[0];
    await page.goto(url);
    const data = await page.locator("h1").innerText();
    await browser.close();
    await steel.sessions.release(session.id);
    return { url, data };
  })
);
```

Each session is isolated and proxy, cookie, and storage data never leak between jobs.

### Playwright vs Puppeteer vs Selenium

All three frameworks connect to Steel over CDP. Choose the one that matches your language stack and tooling.

#### Playwright

Multi browser support (Chromium, Firefox, WebKit), robust waiting APIs, and active development from Microsoft.

```ts
const browser = await chromium.connectOverCDP(
  `wss://connect.steel.dev?apiKey=${process.env.STEEL_API_KEY}&sessionId=${session.id}`
);
```

#### Puppeteer

Chrome only, lighter dependencies, and deep ecosystem support.

```ts
const browser = await puppeteer.connect({
  browserWSEndpoint: `wss://connect.steel.dev?apiKey=${process.env.STEEL_API_KEY}&sessionId=${session.id}`,
});
```

#### Selenium

Uses the WebDriver protocol and supports Python, Java, C#, Ruby, and JavaScript, which is useful for existing QA stacks.

```python
from selenium import webdriver
from selenium.webdriver.chrome.options import Options

options = Options()
options.add_experimental_option("debuggerAddress", f"connect.steel.dev:443")
driver = webdriver.Chrome(options=options)
```

### Managed browser services comparison

#### Self-hosted vs Managed: the decision

| | Steel.dev | Browserbase | Kernel | Browserless.io | Self-hosted Playwright |
| - | - | - | - | - | - |
| **Framework support** | Playwright, Puppeteer, Selenium (CDP) | Playwright, Puppeteer, Selenium (CDP) | Playwright, Puppeteer, WebDriver BiDi | Playwright, Puppeteer, Selenium | Any |
| **Session persistence** | Yes (cookies, storage, auth context via Profiles) | Partial (context persistence available) | Yes (Browser Profiles) | Partial (Reconnect API) | You build it |
| **Managed proxies** | Yes (residential, BYO) | Yes | Yes (flexible network proxies) | Yes (residential) | BYO |
| **CAPTCHA solving** | Yes (built-in) | Yes | Yes | Add-on | BYO |
| **Concurrency** | 100+ (cloud plan) | Based on plan | Based on plan | Based on plan | Limited by your hardware |
| **Open source** | Yes (self-host available) | Stagehand framework is open source | Open-source browser image and SDKs | Open-source (self-host available) | Yes |
| **Anti-bot stealth** | Yes (advanced fingerprint config) | Yes (custom Chromium fork) | Yes (headful sessions) | Partial | You configure |
| **Compliance** | Roadmap inquiries | SOC2, HIPAA | Contact sales | SOC2 | You manage |
| **Pricing model** | Sessions-based | Sessions-based | No-idle billing (standby mode) | Minutes or unit-based | Infrastructure cost |

**Choose self-hosted when**

- Volume is low (under 100 pages/day)
- You have DevOps capacity
- Full control over infrastructure is required
- Cost sensitivity outweighs engineering time

**Choose managed when**

- Volume or scaling requirements are higher
- The team wants to focus on scraping logic, not infrastructure
- Session persistence matters (authenticated scraping)
- You need reliability and uptime SLAs

Steel supports both paths. The open-source Steel Browser lets you self-host, while Steel Cloud offers managed infrastructure. The API is the same; only the operational model differs.

#### Why Steel.dev is the default choice

Steel.dev works for most cloud scraping workloads because it combines CDP compatibility (works with existing Playwright/Puppeteer code), session persistence for authenticated scraping, managed residential proxies, and an open-source self-host option. The session-based pricing is predictable, and the open-source browser lets you start self-hosted and migrate to managed cloud without rewriting code.

#### When to consider alternatives

- **Browserbase**: if your team uses Stagehand for AI-powered automation or you need SOC 2 / HIPAA compliance for regulated industries
- **Kernel**: if your workload has high idle time between browser actions and you want no-idle billing
- **Browserless.io**: if you want BrowserQL for scraping-specific workflows
- **Self-hosting**: if you have low volume and in-house DevOps capacity

#### Other tools worth knowing

- **Apify**: end to end scraping platform with scheduling, storage, and marketplace actors.
- **ScrapingBee**: REST API that returns rendered HTML without giving you full browser control.
- **Hyperbrowser**: designed for Model Context Protocol agents that browse autonomously.
- **Anchorbrowser**: focuses on fingerprint and identity management for verified agents.

### Use cases

- JavaScript heavy sites where initial HTML is empty
- Paywalled dashboards and authenticated portals
- Dynamic ecommerce price and inventory monitoring
- Multi step form automation for quotes or onboarding
- Concurrent crawling that exceeds local hardware capacity
- Accessing anti bot protected sites with residential proxies
- Supplying AI agents with persistent browsers for research
- Hosting Chrome as a service inside larger automation stacks

Always prefer an official API when it exists. Use headless browsers when the DOM is the only reliable source.

### Honest limitations

**Detection involves more than infrastructure.** Managed proxies improve IP reputation, and stealth configuration reduces fingerprint surface, but traffic patterns, timing, and behavioral signals still factor in. Steel addresses the infrastructure side; your code's behavior remains your responsibility.

**CAPTCHA solving is not universal.** It improves reliability but will not solve every challenge type or provider.

**Sessions can expire.** Persistence is powerful for authenticated workflows, but targets can force logouts. Plan recovery paths and re-auth flows.

**Browser scraping is slower than API calls.** Expect higher latency per page versus direct HTTP requests. The trade-off is access to JavaScript-rendered content and complex interactions.

### Getting started

- Quickstart: <https://docs.steel.dev/overview/sessions-api/quickstart>
- Framework guides: [Playwright (Node)](https://docs.steel.dev/overview/guides/playwright-node) · [Puppeteer](https://docs.steel.dev/overview/guides/puppeteer) · [Selenium](https://docs.steel.dev/overview/guides/selenium)
- Self host first: <https://github.com/steel-dev/steel-browser>
- Working examples: <https://github.com/steel-dev/steel-cookbook>

### FAQ

**How can I run headless browsers in the cloud for web scraping?** You can run Playwright or Puppeteer on a cloud VM, package Chrome in containers and deploy to Cloud Run or ECS, use serverless functions with a custom Chromium build, or choose a managed browser service such as Steel.dev. Each model trades control, scale, and operational effort differently.

**Can I use my existing Playwright or Puppeteer code with a cloud browser?** Yes. Steel.dev exposes a CDP WebSocket endpoint, so `chromium.connectOverCDP()` and `puppeteer.connect()` work without code rewrites.

**How many concurrent headless browser sessions can I run in the cloud?** Steel Cloud supports 100 or more sessions on standard plans and scales further on enterprise tiers. Each session has isolated cookies, storage, and proxies.

**What is the difference between a headless browser API and a web scraping API?** A headless browser API gives you a full browser that you drive with Playwright, Puppeteer, or Selenium. A scraping API usually returns rendered HTML for a single URL with less control. Choose a browser API for multi step workflows or authentication.

**Does Steel work for scraping sites with anti-bot protection?** Steel ships with stealth fingerprints, managed residential proxies, and CAPTCHA solving. These tools reduce detection but do not replace responsible crawling strategies.

**How does Steel.dev compare to Browserbase, Kernel, and Browserless?** All four provide remote browsers, but they optimize for different things. Steel.dev focuses on flexibility with open-source self-hosting, persistent sessions for authenticated scraping, and predictable session pricing. Consider Browserbase if you need SOC 2 compliance or use Stagehand, Kernel for no-idle billing on bursty workloads, or Browserless for BrowserQL workflows.

**How much does Steel.dev cost?** Steel.dev uses session based pricing with proxies and stealth included. There are no per request or idle fees. The open source Steel Browser is free to self host. Current plans are listed at [https://steel.dev](https://steel.dev/).

**What is the easiest way to start with cloud headless browser scraping?** For quick experiments run Playwright in Docker locally. For production without DevOps overhead follow the Steel.dev quickstart to launch a managed browser in minutes. Self host the Steel Browser on a VM if you want to own infrastructure first and migrate later.

**Playwright vs Puppeteer: which should I use for cloud scraping?** Playwright is the modern default thanks to multi browser support and resilient waiting APIs. Puppeteer is lighter for Chrome only workloads and has a mature ecosystem. Selenium remains useful when you need different programming languages or WebDriver compatibility. Both Playwright and Puppeteer connect to Steel.dev over CDP.

### Start scraping with Steel.dev

Steel.dev gives you production-ready browser infrastructure in minutes. Connect your existing Playwright or Puppeteer code, enable managed proxies and CAPTCHA solving, and scale to hundreds of concurrent sessions without managing infrastructure.

- **Get started**: <https://docs.steel.dev/overview/sessions-api/quickstart>
- **Self-host first**: <https://github.com/steel-dev/steel-browser>
- **Examples and recipes**: <https://github.com/steel-dev/steel-cookbook>

## Blog: Remote Browser Benchmark

https://steel.dev/blog/remote-browser-benchmark · Nov 7, 2025 · By JunHyoung Ryu

> How fast is "Hello, browser?"

**TL;DR:** Over 5,000 runs per provider on AWS EC2 us-east-1, a create, connect, visit google.com and release flow averaged 0.89s on Steel with a p95 of 1.09s, 1.70x to 8.95x faster on average than Kernel, Browserbase, Hyperbrowser and AnchorBrowser. Steel's control-plane cost (create plus release) was about 229 ms.

It answers:

- Which remote browser provider has the fastest session lifecycle?
- How does Steel compare to Browserbase, Kernel, Hyperbrowser and AnchorBrowser on latency?
- How much of a remote browser session's time is control-plane overhead?
- What success rates did remote browser providers have over 5,000 runs?
- How was the remote browser benchmark measured?
- How can agent builders reduce browser session overhead?

### TL;DR

- Our minimal “hello, browser” flow (create → connect → visit [google.com](http://google.com/) → release) averages **0.89s on Steel** with a **p95 of 1.09s** (AWS EC2, us-east-1).
- Versus other providers we tested, Steel’s end-to-end time is **1.70×–8.95× lower on average**, and **1.61×–10.62× lower at p95**.
- The **control‑plane tax** (create + release) on Steel is ≈**0.229s** (≈**25.6%** of total). Elsewhere it ranges **0.367s → 6.557s** (≈**21.9% → 82.0%** of total).
- For AI agents (e.g. browser-use), the **create/connect/release** flow happens **a lot**, so shaving seconds here compounds across long runs and many workers.

![](https://steel.dev/assets/framerusercontent.com/images/BeULtOdcsdMi6k8uoo2ChvYWIwM.png)

> *Fig.1. Mean total duration (ms)*

**Full code & raw results:** <https://github.com/steel-dev/browserbench>

### Why this benchmark matters?

Agents don’t just “do work” on pages; they **start and stop** browsers over and over: new identities, clean slates, anti-bot resets, concurrency fan-out.

If you save **\~1s per loop** and your agent runs **20 loops**, you’ve just won **\~20s** on a single task. Multiply that across **hundreds of workers** and **thousands of tasks/day** and you either delight users or grow a queue.

So we asked a simple question: *How fast is “Hello, browser?”*, and how much of the time is **control plane** (session creation/release) vs **data plane** (connect + navigate)?

### What we measured

Provider-agnostic, minimal lifecycle with each vendor’s SDK:

- **Create** a session (cold start / scheduling / identity)
- **Connect** the driver (CDP handshake)
- **Navigate** to `google.com` (waits for `domcontentloaded`)
- **Release** the session (cleanup, quotas, accounting)

**Environment:** AWS EC2 **us-east-1**\
**Runs:** 5000 per provider

**Steel runner (TypeScript, abbreviated)**:

```ts
const session = await client.sessions.create();
const browser = await chromium.connectOverCDP(session.cdpUrl);
const page = await browser.newPage();
await page.goto("https://google.com", { waitUntil: "domcontentloaded" });
await client.sessions.release(session.id);
```

> We used Playwright over CDP for all vendors and mirrored the same four steps with each provider’s SDK. We did not supply any provider‑specific configuration, sessions ran on each vendor’s default settings

### Results at a glance

#### Total time (create → connect → goto → release)

| **Provider** | **Avg (ms)** | **Median (ms)** | **p95 (ms)** | **p99 (ms)** |
| - | - | - | - | - |
| **STEEL** | **894.13** | **867.0** | **1,090.0** | **1,340.05** |
| KERNEL | 1,518.53 | 1,485.0 | 1,752.10 | 1,992.04 |
| BROWSERBASE | 1,676.76 | 1,669.0 | 1,873.00 | 1,981.03 |
| HYPERBROWSER | 3,657.11 | 3,665.5 | 5,338.00 | 6,695.05 |
| ANCHORBROWSER | 8,001.29 | 7,919.0 | 11,561.00 | 13,957.14 |

![](https://steel.dev/assets/framerusercontent.com/images/tyWaeVbyvvalf2y4sCeRellzOOg.png)

> *Fig. 2. Total duration distribution (ms)*

**Steel speedup (avg / p95):**

- vs **Kernel**: **1.70×** / **1.61×**
- vs **Browserbase**: **1.88×** / **1.72×**
- vs **Hyperbrowser**: **4.09×** / **4.90×**
- vs **AnchorBrowser**: **8.95×** / **10.62×**

**Time saved for your agents (per 1,000 sessions):**

- **\~10.41 min vs Kernel**
- **\~13.05 min vs Browserbase**
- **\~46.06 min vs Hyperbrowser**
- **\~118.46 min vs AnchorBrowser** (\~1 hr 58 min)

> *Mind the tails. Some platforms show p99 spikes in the multi‑second range, the outliers users actually feel during bursts and autoscaling.*

#### Where the time goes (stage breakdown)

| **Provider** | **Create** | **Connect** | **Goto** | **Release** | **Create+Release** | **% of Total** |
| - | - | - | - | - | - | - |
| **STEEL** | **181.57** | **174.64** | **490.29** | **47.62** | **229.19 ms** | **25.6%** |
| KERNEL | 261.10 | 428.90 | 533.95 | 294.57 | 555.67 ms | 36.6% |
| BROWSERBASE | 188.18 | 517.37 | 792.27 | 178.99 | 367.17 ms | 21.9% |
| HYPERBROWSER | 1,731.63 | 347.60 | 377.89 | 1,199.98 | 2,931.61 ms | 80.2% |
| ANCHORBROWSER | 3,796.55 | 184.29 | 1,259.66 | 2,760.79 | 6,557.34 ms | 82.0% |

![](https://steel.dev/assets/framerusercontent.com/images/K4uMK30s1aihkKdZEOmmQUpA8w.png)

> *Fig. 3. Control-plane cost (create + release) (ms)*

**Takeaways**

- **Absolute control-plane cost is smallest on Steel**: \~**229 ms**. That’s **1.6×** lower than Browserbase, **2.43×** lower than Kernel, **12.8×** lower than Hyperbrowser, and **28.6×** lower than AnchorBrowser.
- **Who’s dominated by control plane?** Hyperbrowser and AnchorBrowser (≈80% of total). Kernel’s control plane is material (≈37%). Browserbase’s control plane share is small (≈22%), but still **\~1.6×** Steel in absolute terms.
- **Data-plane (connect + first goto)**: Steel = **\~665 ms**. Kernel \~**1.45×**, Browserbase \~**1.97×**, AnchorBrowser **2.17×** of Steel. Hyperbrowser’s data-plane is close to Steel (**1.09×**), but its control-plane tax overwhelms it.

#### Reliability (5,000 attempts/provider)

- **Steel**: **100%** success (0 failures)
- **Kernel**: **100%** success (0 failures)
- **Browserbase**: **99.96%** success (**2** failures)
- **Hyperbrowser**: **100%** success (0 failures)
- **AnchorBrowser**: **97.34%** success (**133** failures)

> Most SDKs perform **automatic retries** on certain errors (e.g., transient network, provisioning). Our “success” counts a run as successful **after retries**, so these rates may **overstate true first-attempt success** and **understate incident frequency**. Inspect per-stage error/retry telemetry in your traces for an accurate picture.

### Caveats

- This is a **cold lifecycle** for a single navigation. Real agents do auth, multi‑step forms, file uploads, and more.
- Results reflect **AWS EC2 us‑east‑1** and [google.com](http://google.com/) as the first page. Region, instance class, network and page choice influence numbers.

### Production guidance for agent builders

- **Amortize the handshake.** Batch multiple subtasks per session when safe, [reuse sessions](https://docs.steel.dev/overview/sessions-api/session-lifecycle) for longer flows.
- **Simplify the surface.** [**Mobile Mode**](https://docs.steel.dev/overview/sessions-api/mobile-mode) yields smaller DOMs and higher click accuracy for vision agents.
- **Watch the tails.** Track **p95/p99** per stage in your traces, optimize for outliers, not just averages.
- **Prefer headful when flaky.** **Headful Sessions** improve compatibility with sites that resist headless automation.
- **Debug faster.** **Agent Logs** give you action‑by‑action traces aligned to live view and MP4 replay.

### Build with Steel

Humans use Chrome. **Agents use Steel.**\
A headless browser API built for AI products: **fast session starts**, **persistent profiles**, **stealth & CAPTCHA**, **live viewers + MP4 replays**, and **scaling without the DevOps tax**.

- **Docs:** [https://docs.steel.dev](https://docs.steel.dev/)
- **Dashboard:** [https://app.steel.dev](https://app.steel.dev/)
- **Discord:** <https://discord.gg/steel-dev>
- **Full code & raw results:** <https://github.com/steel-dev/browserbench>

## Blog: Steel Launch Week v2: Everything We Shipped

https://steel.dev/blog/launch-week-v2-recap · Oct 21, 2025 · By Hussien Hussien

> Five features that make AI agents work in production.

**TL;DR:** Steel Launch Week v2 shipped five features: Profiles for persistent browser identities, Mobile Mode, Agent Logs on a session timeline, headful sessions by default with WebRTC streaming and MP4 recordings, and doubled concurrency limits on all Steel Cloud plans, for example Pro/Startups from 50 to 100 sessions.

It answers:

- What did Steel ship in Launch Week v2?
- What does a Steel Profile store?
- What are the new Steel Cloud concurrency limits per plan?
- Why did Steel move live view and replay from Chrome screencasting to WebRTC?

Launch Week v2 is done. Five days, five features.

We released production-ready updates that enable AI agents to work more reliably and effectively at scale.

Everything we shipped:

- [**Day 1:** Profiles](https://steel.dev/blog/profiles)
- [**Day 2:** Mobile Mode](https://steel.dev/blog/mobile-mode)
- [**Day 3:** Agent Logs](https://steel.dev/blog/agent-logs)
- [**Day 4:** Headful Sessions](https://steel.dev/blog/webrtc)
- [**Day 5:** Increased Concurrency Limits](https://steel.dev/blog/more-browsers)

### Day 1: Profiles

On Monday, we launched **Profiles** - persistent browser identities for your agents.

[Video on YouTube](https://www.youtube.com/watch?v=D2vG6K4skHg)

Before Profiles, every Steel session started fresh. Your agent would log in, complete a task, and when the session ended, everything was forgotten. Cookies cleared. Auth tokens gone.

Now your agents maintain persistent browser identities across sessions. A Profile stores cookies, extensions, credentials, localStorage, auth tokens, and fingerprints.

Your agent logs in once. Every subsequent session picks up with valid auth already in place.

[**Read more →**](https://steel.dev/blog/profiles)

### Day 2: Mobile Mode

On Tuesday, we added **Agent Logs** to the Steel dashboard.

[Video on YouTube](https://www.youtube.com/watch?v=mxRdCo3fjaA)

Pass `deviceConfig: { device: "mobile" }` when creating a session and the browser appears as a mobile device - user agent, viewport, touch capabilities, and browser characteristics all aligned.

Mobile sites present simpler DOMs, faster load times, and linear flows instead of nested menus. For AI agents, this simplification directly improves task completion rates and reduces token costs.

[**Read more →**](https://steel.dev/blog/mobile-mode)

### Day 3: Agent Logs

On Wednesday, we added **Agent Logs** to the Steel dashboard.

[Video on YouTube](https://www.youtube.com/watch?v=Vhx2u0Tynj0)

View every action your agent takes in a session (clicks, navigation, typing, scrolling) on a timeline next to the session viewer.

When your agent fails at a task, you can trace exactly where things went wrong. Click any event and the session viewer jumps to that point. You see what the agent saw, what it did, and what happened next.

No more watching entire session replays trying to spot the moment things broke.

[**Read more →**](https://steel.dev/blog/agent-logs)

### Day 4: Headful Sessions

On Thursday, we launched **Headful Sessions** as the default for all Steel sessions.

[Video on YouTube](https://www.youtube.com/watch?v=2ECtoukYN0M)

We rebuilt the entire live view and replay experience from the ground up. We moved from Chrome's screencasting to WebRTC-based streaming at 25fps and replaced RRWeb with MP4 recordings.

Now all sessions run headful with OS-level streaming that captures everything on screen: native OS alerts, dropdowns, PDF viewers, and dialogs. Recordings show exactly what happened with 1:1 accuracy.

[**Read more →**](https://steel.dev/blog/webrtc)

### Day 5: Increased Concurrency Limits

On Friday, we doubled concurrency limits across all Steel Cloud plans.

New limits:

- **Hobby:** 2 → 5 concurrent sessions
- **Starter:** 5 → 10 concurrent sessions
- **Developer:** 10 → 20 concurrent sessions
- **Pro/Startups:** 50 → 100 concurrent sessions

Run more agents in parallel without hitting rate limits or implementing complex queuing systems.

[**Read more →**](https://steel.dev/blog/more-browsers)

### That's a Wrap

Each of these features tackles a real problem we've seen teams struggle with: session state, debugging failures, performance bottlenecks, and scale constraints.

If you're building with any of these new features, we'd love to hear about it. Join us in [Discord](https://discord.gg/steel-dev) or tag us on X (Twitter) [@steeldotdev](https://twitter.com/steeldotdev).

Thanks for following along. Launch Week v3 coming soon.

## Blog: Doubled Concurrency Limits Across All Plans

https://steel.dev/blog/more-browsers · Oct 17, 2025 · By Hussien Hussien

> You get a browser! you get a browser!

**TL;DR:** Steel doubled concurrency limits on all Steel Cloud plans: Hobby 2 to 5, Starter 5 to 10, Developer 10 to 20, and Pro/Startups 50 to 100 concurrent sessions. The limits are live for all customers with no changes needed, so agents can run in parallel without queuing logic.

It answers:

- What are the concurrency limits on each Steel Cloud plan?
- Do I need to change anything to get Steel's higher concurrency limits?
- Why do concurrency limits matter for agent workloads?

Today we're doubling concurrency limits across all Steel Cloud plans. Run more agents in parallel without hitting rate limits or implementing complex queuing systems.

### New limits

- **Hobby**: 2 → 5 concurrent sessions
- Starter: 5 → 10 concurrent sessions
- **Developer**: 10 → 20 concurrent sessions
- **Pro/Startups**: 50 → 100 concurrent sessions

Higher concurrency means you can scale your agent workloads without waiting in queue or upgrading plans prematurely.

### Why this matters

Concurrency limits are the bottleneck for agent workloads. When you hit your limit, new session requests either queue or fail. This forces you to build queuing logic, throttle requests, or upgrade to higher tiers before you actually need the compute.

Doubled limits give you more headroom. You can handle traffic spikes, run batch jobs faster, and prototype new agents without worrying about hitting walls.

For production workloads, higher concurrency means lower latency for end users. Instead of waiting for a session slot to open up, requests get handled immediately.

### Get started

New concurrency limits are live now for all Steel Cloud customers. No changes needed. Your account automatically has access to the higher limits.

- [Dashboard](https://app.steel.dev/)
- [Pricing](https://docs.steel.dev/overview/pricinglimits)

Questions? [Discord](https://discord.gg/steel-dev) or [@steeldotdev](https://twitter.com/steeldotdev).

*Part of Steel's launch week. More at* [*steel.dev/launch-week*](https://steel.dev/blog/launch-week-v2-recap)*.*

## Blog: Headful Sessions: Real Streaming and Reliable Recordings

https://steel.dev/blog/webrtc · Oct 16, 2025 · By Hussien Hussien

> A complete rework of how you view and replay sessions.

**TL;DR:** All Steel sessions now run headful by default, with OS-level WebRTC streaming at 25fps in place of Chrome screencasting at 4-12fps. Replays are MP4 recordings in place of rrweb's event-based recreation, so they match what the agent saw, show native dialogs, and can be embedded through the session's HLS endpoint.

It answers:

- Why does Steel run sessions headful by default?
- How does Steel stream live browser sessions?
- Why did Steel replace rrweb recordings with MP4?
- How do I embed a Steel session recording in a web page?

Today we're launching headful sessions as the default for all Steel sessions. We've rebuilt our entire live view and replay experience from the ground up.

Before, we used Chrome's native screencasting for live views and rrweb for replays. Screencasting was slow, janky, and couldn't render OS elements or blocking flows. Rrweb's event-based recreation made replays unreliable - there was often a discrepancy between what your agent saw and what the recording showed.

**_Now, all sessions run headful with WebRTC-based streaming at 25fps and MP4 recordings that show exactly what happened._**

[Video on YouTube](https://www.youtube.com/watch?v=2ECtoukYN0M)

### What changed

**OS-level streaming**: We moved from Chrome's screencasting (4-12fps, unstable) to WebRTC-based streaming at the OS level at 25fps. Live views now capture everything on screen; native OS alerts, dropdowns, PDF viewers, and dialogs. Previously, these elements wouldn't render, breaking flows that required interaction with them.

**Recordings**: We replaced RRWeb's event-based recreation with MP4 recordings. Whatever happens on screen is in the recording. No more discrepancies between what your agent saw and what the replay shows. It's 1:1.

**Headful by default**: All sessions now run headful instead of headless. This means better compatibility with sites that detect headless browsers and more accurate rendering of complex UI states.

### Why this matters

The old system had fundamental issues. RRWeb recreates the DOM from events, which means if an event wasn't captured correctly, the replay would diverge from reality. Developers debugging agent failures couldn't trust what they saw in replays.

Chrome's screencasting was designed for DevTools, not production streaming. It couldn't handle OS-level elements like native alerts or permission dialogs. These would be invisible in the stream, causing flows to appear broken when agents tried to interact with them. Frame rates varied wildly depending on page complexity.

With MP4 recordings and OS-level WebRTC streaming, what you see is what actually happened. When an agent fails, you can replay the exact visual state it encountered. When it succeeds, you have a reliable record of how it navigated the task.

### Embedding recordings

You can now embed recordings anywhere by fetching the MP4 manifest from our API.

To get the playlist you can use our API:

```js
const playlist = await fetch('https://api.steel.dev/v1/sessions/123e4567-e89b-12d3-a456-426614174000/hls', {
  headers: {
    'steel-api-key': 'YOUR_API_KEY'
  }
});
// returns m3u8 file
```

But to embed the player in your page you can simply do the following:

```js
<!doctype html>
<html>
  <body>
    <video id="player" controls playsinline style="width:100%;max-width:900px;"></video>

    <script type="module">
      import Hls from 'https://cdn.jsdelivr.net/npm/hls.js@^1.5.0/dist/hls.mjs';
      const sessionId = "e4d682bb-a7f2-432c-ad13-8b116695d59e";
      const API_KEY = 'YOUR_API_KEY';
      const manifestUrl = 'https://api.steel.dev/v1/sessions/${sessionId}/hls';
      const video = document.getElementById('player');

      if (Hls.isSupported()) {
        const hls = new Hls({
          // add your header to every playlist/segment request
          xhrSetup: (xhr, url) => {
            xhr.setRequestHeader('steel-api-key', API_KEY);
          }
        });
        hls.loadSource(manifestUrl);
        hls.attachMedia(video);
      } else if (video.canPlayType('application/vnd.apple.mpegurl')) {
        // safari can do native HLS, but it won't send custom headers.
        // if your stream requires headers, prefer hls.js even on Safari
        // or serve a signed/tokenized URL without headers.
        video.src = manifestUrl; // works only if no header is required
      } else {
        video.outerHTML = '<p>Your browser does not support HLS.</p>';
      }
    </script>
  </body>
</html>
```

Recordings are durable and can be played in any standard video player. No custom player required, no event recreation, just reliable MP4 video.

### Get started

We'll be rolling out headful sessions with the new streaming and recording system for all Steel Cloud sessions. And shipping to steel-browser soon too. No changes needed to your code, existing sessions automatically use the new system.

- [API Docs](https://docs.steel.dev/overview)
- [Dashboard](https://app.steel.dev/)

Questions? [Discord](https://discord.gg/steel-dev) or [@steeldotdev](https://twitter.com/steeldotdev).

*Part of Steel's launch week. More at* [*steel.dev/launch-week*](https://steel.dev/blog/launch-week-v2-recap)*.*

## Blog: Agent Logs: Action Traces for Agent Actions

https://steel.dev/blog/agent-logs · Oct 15, 2025 · By Hussien Hussien

> Debug, trace and observe the actions your agents take with Agent Logs.

**TL;DR:** Steel added agent logs to its dashboard: a timeline of every action an agent takes in a session (clicks, navigation, typing, scrolling), shown next to the session viewer. Each event has a type, timestamp and target element, clicking an event seeks the viewer to that point, and events can be filtered by type.

It answers:

- How do I see what actions my browser agent took in a Steel session?
- How do I debug where a browser agent failed?
- What information does each agent log event show?
- Where do I find agent logs in the Steel dashboard?

Today we're adding agent logs to the Steel dashboard. View every action your agent takes in a session (clicks, navigation, typing, scrolling) on a timeline next to the session viewer.

When your agent fails at a task, you can trace exactly where things went wrong. When it succeeds, you understand why and can reproduce those results later.

[Video on YouTube](https://www.youtube.com/watch?v=Vhx2u0Tynj0)

### How it works

Agent logs appear alongside the session viewer in the Steel dashboard. Each action shows:

- **Event type**: Click, navigation, scroll, keyboard input
- **Timestamp**: When the action occurred
- **Target element**: What the agent interacted with

Click any event in the timeline and the session viewer jumps to that point. You can see what the agent saw, what it did, and what happened next.

### Why this matters

Most agent failures happen silently. Your agent clicks the wrong button, types in the wrong field, or navigates to an unexpected page. Without logs, you're replaying entire sessions trying to spot the moment things broke and matching those to a sea of console logs.

Agent logs give you the exact sequence of events. When a checkout fails, you see that the agent clicked "Express Checkout" instead of "Standard Checkout" at timestamp 00:47. When authentication breaks, you see it typed the password in the username field at 00:12.

For successful runs, logs show you the path your agent took. You can verify it followed the expected flow, identify optimization opportunities, or use the sequence to build more reliable automations.

### Debugging in practice

Before agent logs, debugging meant watching entire session replays and guessing where things went wrong. Now you scan the timeline for anomalies: unexpected navigation events, repeated clicks, or missing form inputs.

You can also filter events by type. Show only navigation events to trace the agent's path through a site. Show only click events to verify it's interacting with the right elements. Show only keyboard events to check what data it entered.

### Get started

Keep an eye on your sessions as this will be rolling out to Steel dashboards over the day. View them at app.steel.dev under any session's detail page.

- [Dashboard](https://app.steel.dev/)

Questions? [Discord](https://discord.gg/steel-dev) or [@steeldotdev](https://twitter.com/steeldotdev).

*Part of Steel's launch week. More at* [*steel.dev/launch-week*](https://steel.dev/blog/launch-week-v2-recap)*.*

## Blog: Mobile Mode: Simpler Interfaces for AI Agents

https://steel.dev/blog/mobile-mode · Oct 14, 2025 · By Hussien Hussien

> Run sessions with mobile UA and viewport for simpler DOMs, faster vision agents, and mobile-only auth paths. Keep separate profiles for clean context.

**TL;DR:** Steel sessions can run as a mobile device: pass deviceConfig: { device: "mobile" } and the user agent, viewport, touch events and fingerprint all match a phone. Mobile sites have simpler DOMs and linear flows, which can improve agent task completion and lower token costs, including for vision models.

It answers:

- How do I run a Steel browser session as a mobile device?
- Why do mobile sites help AI agents complete tasks?
- Why is overriding the user agent string not enough to look like a mobile device?
- Does Steel mobile mode work with proxies and CAPTCHA solving?

Today we're releasing mobile mode for Steel sessions. Pass `deviceConfig: { device: "mobile" }` when creating a session and the browser appears as a mobile device: user agent, viewport, touch capabilities, and browser characteristics all aligned to look like a phone instead of desktop.

Most websites serve fundamentally different experiences to mobile devices. Desktop sites have nested navigation, hover menus, and complex interactions. Mobile sites strip these away into linear flows and touch-optimized interfaces. For AI agents, this simplification can directly improve task completion.

### How it works

```ts
import Steel from 'steel-sdk';
import { chromium } from 'playwright';

const client = new Steel({ steelAPIKey: process.env.STEEL_API_KEY });

const session = await client.sessions.create({
  deviceConfig: { device: "mobile" }
});

const browser = await chromium.connectOverCDP(
  `wss://connect.steel.dev?apiKey=${process.env.STEEL_API_KEY}&sessionId=${session.id}`
);

const page = await browser.contexts()[0].pages()[0];
await page.goto('https://example.com');
```

The session automatically configures mobile viewport dimensions, touch events, and a full mobile device fingerprint. Sites see a consistent mobile device visiting from a browser app, not a desktop browser with a spoofed user agent. Before this, you could override the user agent string, but the rest of the fingerprint wouldn't match - sites would detect the inconsistency.

Mobile mode works with all existing features - proxies, CAPTCHA solving, and session persistence.

### Why this matters

Mobile sites present content sequentially rather than using nested menus or hover states. An e-commerce checkout that requires navigating dropdown menus on desktop becomes a vertical list on mobile. Fewer interactive elements means clearer action spaces and less chance of mistakes.

Mobile sites also load faster: fewer widgets, less aggressive lazy-loading, and have simpler DOM structures. Less HTML for your model to process means lower token costs. If you're using vision, it means fewer image token cost too.

Without mobile mode, your sessions use desktop fingerprints by default.

### Get started

Mobile mode is available now in Steel Cloud and will be in steel-browser v0.4.4.

- [API Docs](https://docs.steel.dev/overview/sessions-api/mobile-mode)
- [Examples](https://github.com/steel-dev/steel-cookbook/tree/main/examples/claude-computer-use-mobile)
- [Dashboard](https://app.steel.dev/)

Questions? [Discord](https://discord.gg/steel-dev) or [@steeldotdev](https://twitter.com/steeldotdev).

*Part of Steel's launch week. More at* [*steel.dev/launch-week*](https://steel.dev/blog/launch-week-v2-recap)*.*

## Blog: Profiles: Your Agent's Persistent Identity

https://steel.dev/blog/profiles · Oct 13, 2025 · By Hussien Hussien

> Persistent browser identities to keep auth, cookies, cache across sessions.

**TL;DR:** Steel Profiles store browser state (cookies, extensions, credentials, localStorage, auth tokens, fingerprints) so a session started with a profileId resumes still logged in. persistProfile controls whether changes write back. The Profiles API is live in Steel Cloud and the Python (v0.11.0+) and Node (v0.12.0+) SDKs.

It answers:

- How do I keep a browser agent logged in across Steel sessions?
- What browser state does a Steel profile store?
- What is the difference between persistProfile true and false?
- How do I set up a profile manually to handle 2FA or CAPTCHAs once?
- Which Steel SDK versions support the Profiles API?

Think Chrome profiles. You have one for work, one for personal browsing, maybe one for testing. Each remembers its own logins, cookies, and settings. Steel Profiles work the same way, but you can spin them up programmatically for your agents.

Before today, every Steel session started fresh. Your agent would log in, complete a task, and when the session ended, everything was forgotten. Cookies cleared. Auth tokens gone. Next run? Log in again.

Now your agents can maintain persistent browser identities across sessions.

[Video on YouTube](https://www.youtube.com/watch?v=D2vG6K4skHg)

### How It Works

A Profile stores browser state: cookies, extensions, credentials, localStorage, auth tokens, and fingerprints. When you start a session with a `profileId`, the browser loads that state. The agent picks up effectively where it left off, still logged in, still authenticated.

Here's the simplest case, an agent that needs to stay logged in across multiple runs:

```ts
// Day 1: Agent logs in and completes a task
const session = await client.sessions.create({ 
  persistProfile: true 
});

const browser = await chromium.connectOverCDP(
  `wss://connect.steel.dev?apiKey=${apiKey}&sessionId=${session.id}`
);
const page = await browser.contexts()[0].pages()[0];

await page.goto('https://app.example.com/login');
await page.fill('#email', 'agent@company.com');
await page.fill('#password', process.env.PASSWORD);
await page.click('#login-button');

// Session ends, state is saved
await client.sessions.release(session.id);
console.log(`Profile ID: ${session.profileId}`);

// Day 2: Resume where you left off
const resumedSession = await client.sessions.create({ 
  profileId: session.profileId  // Still logged in
});
```

### Persist or Read-Only

When using an existing profile, you control whether changes write back:

```ts
// Read from profile, build on its history
const session = await client.sessions.create({ 
  profileId: 'bc252fdd-0c22-43ae-9e53-c2ffaba1108a',
  persistProfile: true  // Appends new cookies, state changes
});

// Read from profile, keep it unchanged  
const session = await client.sessions.create({ 
  profileId: 'bc252fdd-0c22-43ae-9e53-c2ffaba1108a',
  persistProfile: false  // Default: no state mutation
});
```

Set `persistProfile: true` when you want to update the profile with new authentication state or app data. Keep it `false` for read-only operations or when running parallel sessions that shouldn't interfere with each other.

### Human-in-the-Loop Setup

For complex auth flows, you can set up profiles manually. Create a session, open the debug URL, and handle the tricky parts yourself:

```ts
const session = await client.sessions.create({ 
  persistProfile: true 
});

console.log(`Complete auth here: ${session.sessionViewerUrl}`);
// Open the URL, handle 2FA, solve CAPTCHAs, accept terms, etc.

// Wait for manual completion...
await new Promise(resolve => setTimeout(resolve, 60000));

// Release the session - your auth state is saved
await client.sessions.release(session.id);

// Now your agent uses your authenticated state
const agentSession = await client.sessions.create({ 
  profileId: session.profileId 
});
```

Handle 2FA, CAPTCHAs, or SSO flows once, then let your agent reuse that authenticated state for all future runs.

### Why This Matters

**No repeated authentication**: Your agent logs in once. Every subsequent session picks up with valid auth tokens and cookies already in place.

**Better stealth**: Profiles build browsing history and reputation. Sites see a returning user, not a fresh bot on every request. Fewer CAPTCHAs, less anti-bot friction.

**Multi-tenant workflows**: Each customer gets their own profile. One authentication per tenant, reused across all their agent operations.

**Parallel testing**: Fork a baseline profile to test different agent strategies without sessions interfering with each other's state.

**Simpler infrastructure**: No more managing cookie jars in Redis or session blobs in S3. Steel handles state persistence, encryption, and retrieval.

### Available Now

The Profiles API is live today in Steel Cloud, plus Python(v0.11.0+) and Node SDKs (v0.12.0+).

**Get started:**

- [Profiles API Documentation](https://docs.steel.dev/overview/profiles-api/overview)
- [Cookbook Example](https://github.com/steel-dev/steel-cookbook/)

Questions or want to share what you build? Join us in [Discord](https://discord.gg/steel-dev) or tag us on Twitter [@steeldotdev](https://twitter.com/steeldotdev).

*This is part of Steel's launch week. More features dropping daily at* [*steel.dev/launch-week*](https://steel.dev/blog/launch-week-v2-recap)*.*

## Blog: Launch Week v2: 5 Features That Make AI Agents Actually Work

https://steel.dev/blog/launch-week-v2 · Oct 12, 2025 · By Hussien Hussien

> Next week we're shipping five upgrades that eliminate the infrastructure headaches keeping your AI agents from production.

**TL;DR:** Steel announced Launch Week v2: five updates for browser automation at production scale. They address lost session state between runs, debugging failed agents, real-time streaming, session start time, scale to 100+ concurrent agents, and a simpler surface when vision models struggle with complex layouts.

It answers:

- What problems does Steel Launch Week v2 address?
- What is Steel?

If you've ever watched your AI agent fail a demo because of a session timeout, spent hours debugging why it clicked the wrong element, or rebuilt your entire automation stack to handle scale, this week is for you.

### What We're Shipping

We're releasing five updates that make browser automation actually work at production scale.

You'll stop losing session state between runs. You'll know exactly why something broke instead of guessing from vague errors. Your agents will respond in real-time instead of buffering through slideshow framerates. Sessions will start in milliseconds, not seconds, and they'll handle 100+ concurrent agents without falling over. And when vision models struggle with complex layouts, you'll have a simpler surface that just works.

Each release solves a problem that's cost you hours of debugging or forced architectural compromises. No more re-authentication flows. No more "it worked locally" mysteries. No more choosing between speed and observability.

### New to Steel?

We're browser infrastructure that lets you control cloud browsers with AI agents. You get fast sessions, proxy management, CAPTCHA solving, and recordings, without the DevOps nightmare.

Join our community [Discord](https://discord.gg/steel-dev) and follow along on our dedicated [Launch Week](https://steel.dev/blog/launch-week-v2-recap) page.

Each day includes setup steps, code samples, and patterns you can ship today.

## Blog: Ship Your AI Web Agent Faster: A Guide to Self-Hosting Steel Browser

https://steel.dev/blog/self-hosting-steel-browser · Jul 20, 2025 · By Nikola Balic

> Learn to self-host Steel Browser for AI web agents. Complete guide with 1-click deploy, Docker setup, and bare metal installation options.

**TL;DR:** Steel Browser, an open-source browser API, self-hosts four ways: a 1-click Railway deploy or pre-built Docker image, Docker Compose locally (API on port 3000, UI on 5173), bare metal with Node.js and Chrome, or a build from source with docker-compose.dev.yml. Any CDP client such as Puppeteer connects to ws://localhost:3000.

It answers:

- How do I self-host Steel Browser?
- How do I run Steel Browser locally with Docker Compose?
- How do I run Steel Browser without Docker using Node.js?
- How do I point Steel at a custom Chrome install path?
- How do I connect Puppeteer to a self-hosted Steel instance?
- How do I build Steel Browser from source to contribute?

You built an AI agent that works perfectly locally. Then you deploy it and everything breaks.

Cloudflare blocks your requests. Session state disappears. You spend days debugging browser infrastructure instead of shipping features.

We built Steel to solve this. Steel is an open-source browser API that handles web automation so you can focus on your agent logic.

While our [Steel Cloud](https://app.steel.dev/) is the fastest way to get started with zero infra management, we know that for many builders, control is everything. You want to run it on your own metal, in your own VPC, or just tinker with the code.

Here’s how to self-host Steel Browser, from a 1-click deploy to building from source. Choose your difficulty.

### Easy Mode: 1-Click Deploy

If you’re looking to deploy to a cloud provider, we’ve got you covered. You can use our [pre-built Docker image](https://github.com/steel-dev/steel-browser/pkgs/container/steel-browser-api) for API-only deployments or try our [1-click Railway deployment](https://railway.com/deploy/steelbrowser?referralCode=Jwc4kg\&utm_medium=integration\&utm_source=template\&utm_campaign=generic) for the simplest setup.

**The Lowdown:** This is the best of both worlds, you get a dedicated instance without the DevOps overhead. Perfect for hackathons, prototypes, or small-to-medium scale agents.

### Normal Mode: Docker on Your Machine

This is the canonical way to run Steel locally. You want a stable, production-equivalent environment on your dev machine without cloning the whole repo.

1. **Make sure you have Docker installed.**
2. **Create a** **`docker-compose.yml`** **file:**
   ```js
   services:
     api:
       image: ghcr.io/steel-dev/steel-browser-api:latest
       ports:
         - "3000:3000"    # API Server
         - "9223:9223"    # CDP Redirect
       networks:
         - steel-network

     ui:
       image: ghcr.io/steel-dev/steel-browser-ui:latest
       ports:
         - "5173:80"
       environment:
         - API_URL=http://api:3000
       depends_on:
         - api
       networks:
         - steel-network

   networks:
     steel-network:
       driver: bridge
   ```
3. **Spin it up:**
   ```js
   docker compose up
   ```

**The Lowdown:** This yanks our pre-cooked images from GitHub Container Registry. You get the Steel API at `http://localhost:3000` and the UI at `http://localhost:5173`. It’s fast, isolated, and just works. This is the way for 90% of local development.

### Hard Mode: Bare Metal with Node.js

You have Node.js and Chrome already installed and you just want to run the server directly. We respect it.

1. **Clone the repo:**
   ```js
   git clone https://github.com/steel-dev/steel-browser.git
   cd steel-browser
   ```
2. **Install dependencies and run:**
   ```js
   npm install
   npm run dev
   ```

**The Lowdown:** This starts the API and UI dev servers directly on your machine. It’s great for quick changes, but comes with a few gotchas.

⚠️ **Heads Up:** This method expects a Chrome executable to exist at a standard location. If you have a custom install path (or you’re using Chromium), you’ll need to tell Steel where to find it. Just set the `CHROME_EXECUTABLE_PATH` environment variable:

```js
export CHROME_EXECUTABLE_PATH=/path/to/your/chrome
npm run dev
```

### Nightmare Mode: Build From Source (For Contributors)

You’re not just here to use Steel, you’re here to cook. You’ve found a bug, want to add a feature, or just see how the sausage is made. This is your setup.

1. **Clone the repo:** (You already did this, right?)
   ```js
   git clone https://github.com/steel-dev/steel-browser.git
   cd steel-browser
   ```
2. **Use the developer Compose file:**
   ```js
   docker compose -f docker-compose.dev.yml up --build
   ```

**The Lowdown:** The `--build` flag is key. It tells Docker to rebuild the `api` and `ui` images from your local source code instead of pulling them. Any change you make to the code in the `api/` or `ui/` directories will be reflected the next time you run this command.

### The Payoff: Connecting to Your Instance

Okay, so you’ve got Steel running. Now what?

You get a WebSocket endpoint (`ws://localhost:3000`) that you can connect to with any CDP-compatible client, like Puppeteer or Playwright.

Here’s how easy it is. The `repl` package in the repo has this exact script:

```js
// repl/src/script.ts
import puppeteer from "puppeteer-core";

async function run() {
  // Point this to your new Steel instance
  const wsEndpoint = "ws://localhost:3000";
  const browser = await puppeteer.connect({ browserWSEndpoint: wsEndpoint });
  
  try {
    const page = await browser.newPage();

    await page.goto("https://steel.dev");
    console.log(`Page title: ${await page.title()}`);

  } finally {
    await browser.disconnect();  
  }
}

run().catch(console.error);
```

You just connect to your endpoint and use Puppeteer like normal. All the session management, proxying, and anti-detection is handled for you.

### Now Go Make Something

You’re all set up with a powerful, self-hosted browser API. What you build next is up to you.

- **Check out the** [**Cookbook**](https://github.com/steel-dev/steel-cookbook) for more examples.
- **Got questions?** Join us in the [Discord](https://discord.gg/steel-dev).
- **Find something cursed?** Open an issue on [GitHub](https://github.com/steel-dev/steel-browser/issues).

We’re excited to see what you ship. 🚀

## Blog: Steel Node SDK: Because Your Puppeteer Scripts Deserve Better Than localhost

https://steel.dev/blog/steel-node-sdk · Jul 20, 2025 · By Nikola Balic

> Steel Node SDK: Cloud browsers in 3 lines of code. Works with Puppeteer, Playwright. No Docker hell. TypeScript-first. Free 100hrs/mo.

**TL;DR:** The steel-sdk npm package is a TypeScript-first client for cloud browser sessions that Puppeteer or Playwright connect to, in Node, Deno, Bun or edge runtimes. It covers session context, files, typed errors, proxies, CAPTCHA solving and live viewing; sessions last up to 24 hours. The free Hobby plan gives 100 browser hours a month.

It answers:

- How do I create a cloud browser session with the Steel Node SDK?
- How do I connect Puppeteer or Playwright to a Steel session?
- How do I migrate a local Puppeteer script to Steel?
- How do I save and restore cookies and localStorage between Steel sessions?
- How long can a Steel session last?
- What does Steel's free plan include?

Steel Node SDK: Because Your Puppeteer Scripts Deserve Better Than localhost Your Puppeteer script works flawlessly on your MacBook. Push to prod? Instant Cloudflare ban. Install headless Chrome on your server? Welcome to dependency hell. Steel gives you cloud browsers that just work; in Node, Deno, Bun, or wherever JavaScript runs these days.

### When localhost:9222 Isn't Enough Anymore

Picture this: It's 3am. Your e-commerce scraper is down. Again. The Docker container crashed because Chrome ate all the RAM. Your proxy provider ghosted you. The site you're scraping now requires you to solve a picture puzzle of traffic lights.

You open GitHub and see 47 open issues on puppeteer-extra-plugin-stealth. The last commit was 8 months ago.

There has to be a better way.

**Enter Steel**: Cloud browsers with a proper API. No containers. No plugins. Just browsers that don't get detected.

### Zero to Browser in 30 Seconds

```sh
npm install steel-sdk
```

No post-install scripts downloading 300MB of Chromium. No "please install these fonts for emoji support." Just a lightweight SDK with minimal dependencies.

Here's your first cloud browser:

```ts
import Steel from 'steel-sdk';

async function main() {
  try {
    const steel = new Steel(); // reads STEEL_API_KEY from env
    
    const session = await steel.sessions.create();
    console.log(`Session ID: ${session.id}`);
    console.log(`Watch live: ${session.sessionViewerUrl}`);
    console.log(`WebSocket: ${session.websocketUrl}`);
    
    // That's it. You have a browser. In the cloud. Ready to connect.
    
    // Always clean up
    await steel.sessions.release(session.id);
    
  } catch (error) {
    console.error('Error:', error.message);
  }
}

main();
```

### The TypeScript Experience We Deserve

Remember wrestling with Puppeteer's types? `Page | null | undefined | ElementHandle<Element | null> | void`?

Steel's SDK is TypeScript-first with types that actually help:

```ts
import Steel from 'steel-sdk';
import type { Session, SessionCreateParams } from 'steel-sdk';

// Every option, fully typed
const config: SessionCreateParams = {
  dimensions: {                // ✓ viewport config
    width: 1920,
    height: 1080
  },
  timeout: 600000,             // ✓ session duration (10 min)
  sessionContext: {            // ✓ preload cookies & storage
    cookies: [/* ... */],
    localStorage: {/* ... */}
  },
  // Pro features (when you upgrade):
  useProxy: true,              // residential proxies
  solveCaptcha: true,          // beats reCAPTCHA
  region: 'us-east'            // geographic targeting
};

// Autocomplete everywhere
const session = await steel.sessions.create(config);
session.// ← Your IDE knows everything
```

No more `@ts-ignore`. No more "I hope this property exists." Just types that work.

### Puppeteer, But Make It Cloud Native

Your existing Puppeteer code? It just works:

```ts
import puppeteer from 'puppeteer-core'; // note: puppeteer-core, not puppeteer
import Steel from 'steel-sdk';

async function scrapeWithStyle() {
  const steel = new Steel();
  
  // Get a cloud browser with all protections
  const session = await steel.sessions.create({
    useProxy: true,
    solveCaptcha: true
  });
  
  // Connect Puppeteer like nothing changed
  const browser = await puppeteer.connect({
    browserWSEndpoint: session.websocketUrl
  });
  
  // Your code runs exactly the same
  const page = await browser.newPage();
  await page.goto('https://bot-protected-site.com');
  
  // Except now it doesn't get blocked 🎉
  const data = await page.evaluate(() => {
    return document.querySelector('.price')?.textContent;
  });
  
  // Always clean up
  await steel.sessions.release(session.id);
  
  return data;
}
```

Same API. Better infrastructure. Zero learning curve.

### Works With Your Entire Stack

#### Playwright? Obviously.

```ts
import { chromium } from 'playwright';
import Steel from 'steel-sdk';

async function usePlaywright() {
  const steel = new Steel();
  const session = await steel.sessions.create();

  try {
    const browser = await chromium.connectOverCDP(session.websocketUrl);
    const context = await browser.newContext();
    const page = await context.newPage();
    
    // Now use Playwright as normal
    await page.goto('https://example.com');
    const title = await page.title();
    console.log(`Title: ${title}`);
    
    await browser.close();
  } finally {
    await steel.sessions.release(session.id);
  }
}
```

#### Running on Vercel Edge? Cloudflare Workers? No problem.

```ts
// edge-function.ts
import Steel from 'steel-sdk';

export default async function handler(req: Request) {
  const steel = new Steel({
    steelAPIKey: process.env.STEEL_API_KEY
  });
  
  const session = await steel.sessions.create();
  // Steel handles the WebSocket → HTTP bridge automatically
  
  return Response.json({ 
    sessionId: session.id,
    viewerUrl: session.sessionViewerUrl 
  });
}
```

#### Bun? Deno? We don't discriminate.

```ts
// Works in Bun
import Steel from 'steel-sdk';

// Works in Deno
import Steel from 'npm:steel-sdk';

// Same API, same features, everywhere
```

### Session State That Persists (Like a Real Browser)

Remember implementing your own cookie jar? Managing localStorage across requests? Rebuilding browser state from scratch?

Steel sessions are stateful by default:

```ts
// Create a session with existing context
const session = await steel.sessions.create({
  sessionContext: {
    cookies: savedCookies,
    localStorage: {
      'example.com': {
        'auth_token': 'abc123',
        'user_prefs': JSON.stringify({ theme: 'dark' })
      }
    }
  }
});

// ... do your thing ...

// Save the context for next time
const context = await steel.sessions.context(session.id);
await saveToDatabase({
  cookies: context.cookies,
  localStorage: context.localStorage,
  sessionStorage: context.sessionStorage
});
```

Sessions last up to 24 hours. Perfect for long-running automations, multi-step workflows, or just keeping that login alive.

### When Your Automation Needs Files

Upload CSVs, download reports, handle PDFs, without the `fs.writeFileSync` dance:

```ts
// Upload a file to the session
const csv = await steel.sessions.files.upload(session.id, {
  file: Buffer.from('name,email\njohn,john@example.com'),
  path: 'data/users.csv'
});

// Your browser can now access it at file:///data/users.csv
await page.goto('file:///data/users.csv');

// Download files the browser created
const screenshot = await page.screenshot();
await steel.sessions.files.upload(session.id, {
  file: screenshot,
  path: 'screenshots/homepage.png'
});

// Get everything as a zip
const archive = await steel.sessions.files.downloadArchive(session.id);
```

No temp directories. No cleanup scripts. Just files that work.

### Error Handling for the Real World

Because `UnhandledPromiseRejectionWarning: Error: Protocol error (Target.createTarget): Target closed` isn't helpful:

```ts
import Steel from 'steel-sdk';

class ResilientScraper {
  private steel: Steel;
  
  constructor() {
    this.steel = new Steel();
  }
  
  async scrapeWithRetry(url: string, maxAttempts = 3) {
    for (let attempt = 1; attempt <= maxAttempts; attempt++) {
      const session = await this.createSessionWithBackoff(attempt);
      
      try {
        const result = await this.performScrape(session, url);
        return result;
        
      } catch (error) {
        // Actual useful error types
        if (error instanceof Steel.RateLimitError) {
          console.log(`Rate limited. Waiting ${error.headers['retry-after']}s`);
          await this.wait(parseInt(error.headers['retry-after']) * 1000);
          
        } else if (error instanceof Steel.APIConnectionTimeoutError) {
          console.log(`Timeout on attempt ${attempt}, retrying...`);
          
        } else if (error instanceof Steel.BadRequestError) {
          // Don't retry invalid requests
          throw new Error(`Invalid request: ${error.message}`);
        }
        
      } finally {
        // Always cleanup
        await this.steel.sessions.release(session.id).catch(() => {});
      }
    }
    
    throw new Error(`Failed after ${maxAttempts} attempts`);
  }
  
  private async createSessionWithBackoff(attempt: number) {
    const delay = Math.min(1000 * Math.pow(2, attempt - 1), 10000);
    if (attempt > 1) await this.wait(delay);
    
    return this.steel.sessions.create({
      useProxy: true,
      solveCaptcha: true
    });
  }
  
  private wait = (ms: number) => new Promise(r => setTimeout(r, ms));
}
```

Real error types. Real retry strategies. Real production code.

### The Features That Make You Go "Finally!"

#### Geographic Precision

```ts
const session = await steel.sessions.create({
  useProxy: {
    geolocation: {
      country: 'US',
      state: 'NY',
      city: 'NEW_YORK'
    }
  }
});
// Your browser is now a New Yorker 🗽
```

#### Human-Like Behavior

```ts
const session = await steel.sessions.create({
  stealthConfig: {
    humanizeInteractions: true // Mouse movements that don't scream "BOT"
  }
});
```

#### Auto-CAPTCHA Solving

```ts
// Encounters reCAPTCHA? No problem.
const session = await steel.sessions.create({
  solveCaptcha: true
});

// Check CAPTCHA status
const status = await steel.sessions.captchas.status(session.id);
```

#### Session Inspection

```ts
// Watch your automation live (seriously, try this)
console.log(`Debug live: ${session.sessionViewerUrl}`);

// Get all session events for playback
const events = await steel.sessions.events(session.id);
```

### Pricing That Doesn't Require a VC Round

**Hobby (Free)**: 100 browser hours/month

- Perfect for side projects
- Basic anti-detection
- Community Discord access

**Pro**: Pay for what you use

- Residential proxies
- CAPTCHA solving
- Geographic targeting
- Priority support

**Enterprise**: Let's talk

- Custom proxy pools
- Dedicated infrastructure
- SLAs that mean something
- A Slack channel where we actually respond

### Migration Guide: From Localhost to Cloud

Got an existing Puppeteer project? Here's your 5-minute migration:

#### Before (Your Current Setup)

```ts
import puppeteer from 'puppeteer';

const browser = await puppeteer.launch({
  headless: 'new',
  args: ['--no-sandbox', '--disable-setuid-sandbox']
});
const page = await browser.newPage();
// ... your automation ...
await browser.close();
```

#### After (With Steel)

```ts
import puppeteer from 'puppeteer-core';
import Steel from 'steel-sdk';

const steel = new Steel();
const session = await steel.sessions.create();

const browser = await puppeteer.connect({
  browserWSEndpoint: session.websocketUrl
});
const page = await browser.newPage();
// ... your automation (unchanged!) ...
await steel.sessions.release(session.id);
```

That's it. Your code stays the same. Your success rate goes through the roof.

Join our [Discord](https://discord.gg/steel-dev) where people actually help each other instead of just posting memes (okay, we post memes too).

### Let's Ship Something

```sh
# Install
npm install steel-sdk puppeteer-core dotenv

# Set your API key (get one at app.steel.dev)
echo "STEEL_API_KEY=your_api_key_here" > .env

# Run this quickstart
npx tsx quickstart.ts
```

```ts
// quickstart.ts
import 'dotenv/config';
import Steel from 'steel-sdk';
import puppeteer from 'puppeteer-core';

const steel = new Steel();

async function main() {
  let session;
  
  try {
    // Create a session
    session = await steel.sessions.create();

    console.log(`
🚀 Session ready!
📺 Watch live: ${session.sessionViewerUrl}
🔗 Session ID: ${session.id}
`);

    // Connect and scrape
    const browser = await puppeteer.connect({
      browserWSEndpoint: session.websocketUrl
    });

    const page = await browser.newPage();
    await page.goto('https://example.com');
    const title = await page.title();

    console.log(`\n✅ Scraped title: ${title}`);

    await browser.close();

  } catch (error) {
    console.error('Error:', error);
    process.exit(1);
  } finally {
    // Always cleanup
    if (session) {
      await steel.sessions.release(session.id);
      console.log('\n🧹 Session released. Happy scraping!');
    }
  }
}

main();
```

### Resources for the Curious

- [**GitHub**](https://github.com/steel-dev/steel-node) - Star it, fork it, break it, fix it
- [**API Docs**](https://docs.steel.dev/) - Every endpoint, every option
- [**Steel Cookbook**](https://github.com/steel-dev/steel-cookbook) - Copy-paste-ship recipes
- [**System Status**](https://status.steel.dev/) - We're transparent about uptime

### The Part Where We Get Real

Browser automation is hard. It shouldn't be. You came here to build something cool, not to become a Docker expert or a proxy specialist.

Steel handles the infrastructure so you can focus on the fun part, building things that matter.

No more "works on my machine." No more random bans. No more 3am debugging sessions.

Just `npm install steel-sdk` and start shipping.

**Ready?** [Grab your API key](https://app.steel.dev/sign-up) and let's build something the internet hasn't seen before.

*P.S. - If you build something cool, tell us in Discord. We love seeing what you ship with Steel. Plus, we might feature it (with your permission) and send you swag.*

## Blog: Steel Python SDK: Browser Automation That Actually Works

https://steel.dev/blog/steel-python-sdk · Jul 20, 2025 · By Nikola Balic

> Tired of wrestling with Selenium and Playwright infrastructure? Steel's Python SDK gives you cloud browsers in 3 lines of code. No Docker, no proxies, no pain.

**TL;DR:** Steel's Python SDK (pip install steel-sdk) creates cloud browser sessions with no Docker or browser downloads, and gives a WebSocket URL to connect automation tools and a live session viewer. Sessions last up to 24 hours; paid plans add proxies and CAPTCHA solving, and the free tier gives 100 browser hours per month.

It answers:

- How do I install the Steel Python SDK?
- How do I create a cloud browser session in Python with Steel?
- How do I get the WebSocket URL to connect Puppeteer to a Steel session?
- How long can a Steel browser session last?
- Which Steel features require a paid plan?
- How do I upload and download files in a Steel session from Python?

You know the drill. You need to scrape some data, automate a workflow, or test that cursed SPA that breaks every other week. You fire up Playwright, spend 2 hours configuring Docker, another hour debugging why your bot got blocked, and then realize you need to handle CAPTCHAs. **What if we just... didn't?** Steel's Python SDK is browser automation for people who want to ship, not spend their weekend becoming a DevOps expert.

### Installation (The Easy Part)

```sh
pip install steel-sdk
```

That's it. No Docker, no browser downloads, no "works on my machine" negative energy.

### Your First Steel Session

Here's how you create a cloud browser session in just a few lines:

```python
from steel import Steel
import os

# Initialize the client
api_key = os.getenv("STEEL_API_KEY")

client = Steel(steel_api_key=api_key)

try:
    # Create a browser session with anti-bot protection
    session = client.sessions.create()

    print(f"Session ID: {session.id}")
    print(f"Watch live at: {session.session_viewer_url}")
except Exception as e:
    print(f"Error creating session: {e}")
```

**No cap** - that's a full browser running in the cloud with anti-bot protection enabled. You can literally watch it live in your browser.

### Connect Your Favorite Tools

Steel provides WebSocket URLs that work with browser automation tools. Here's how to get the connection details:

```python
import asyncio
import os
from steel import Steel

async def get_browser_connection():
    api_key = os.getenv("STEEL_API_KEY")
    
    try:
        # Initialize Steel client
        client = Steel(steel_api_key=api_key)
        
        # Create a browser session
        session = client.sessions.create()
        
        print(f"Session ID: {session.id}")
        print(f"WebSocket URL: {session.websocket_url}")
        
        # Note: To connect Puppeteer (Node.js), use:
        print(f"\nFor Puppeteer connection:")
        print(f"browserWSEndpoint: '{session.websocket_url}'")
        
        # Clean up
        client.sessions.release(session.id)
        
    except Exception as e:
        print(f"Error: {e}")

# Run the async function
asyncio.run(get_browser_connection())
```

Same API you know, but now it's running on infrastructure that doesn't hate you.

### Real-World Examples That Actually Work

#### Price Monitoring (Because Everything's Expensive)

```python
import asyncio
import os
from steel import Steel

async def check_price(product_url):
    api_key = os.getenv("STEEL_API_KEY")
    
    try:
        # Initialize Steel client
        client = Steel(steel_api_key=api_key)
        
        # Create session with all the good stuff enabled
        # Note: use_proxy and solve_captcha require paid plan
        session = client.sessions.create(
            # use_proxy=True,      # Requires paid plan
            # solve_captcha=True   # Requires paid plan
        )
        
        print(f"Session created: {session.id}")
        print(f"WebSocket URL for browser connection: {session.websocket_url}")
        
        # Note: To implement full price monitoring, you would:
        # 1. Connect your browser automation tool to session.websocket_url
        # 2. Navigate to product_url
        # 3. Wait for price element
        # 4. Extract price data
        
        price_data = {
            "session_id": session.id,
            "product_url": product_url,
            "websocket_url": session.websocket_url,
            "status": "session_ready_for_browser_connection"
        }
        
        # Clean up
        client.sessions.release(session.id)
        
        return price_data
        
    except Exception as e:
        print(f"Error in price monitoring: {e}")
        return None

# Example usage
async def main():
    result = await check_price("https://example.com/product")
    print("Price monitoring result:", result)

asyncio.run(main())
```

#### Form Automation (For When You're Too Lazy to Click)

```python
import asyncio
import os
from steel import Steel

async def fill_application_form(form_url, user_data):
    api_key = os.getenv("STEEL_API_KEY")
    
    try:
        # Initialize Steel client
        client = Steel(steel_api_key=api_key)
        
        # Extended timeout because forms are complicated
        # Note: use_proxy and solve_captcha require paid plan
        session = client.sessions.create(
            # use_proxy=True,      # Requires paid plan
            # solve_captcha=True,  # Requires paid plan
            timeout=3600000  # 1 hour, because government websites
        )
        
        print(f"Session created: {session.id}")
        print(f"WebSocket URL: {session.websocket_url}")
        print(f"Form URL to automate: {form_url}")
        print(f"User data: {user_data}")
        
        # Note: With a browser automation library connected, you would:
        # 1. Connect to session.websocket_url
        # 2. Navigate to form_url
        # 3. Fill form fields with user_data
        # 4. Submit form and handle navigation
        
        form_automation_plan = {
            "session_id": session.id,
            "websocket_url": session.websocket_url,
            "form_url": form_url,
            "automation_steps": [
                f"Fill firstName with: {user_data.get('first_name', 'N/A')}",
                f"Fill lastName with: {user_data.get('last_name', 'N/A')}",
                f"Fill email with: {user_data.get('email', 'N/A')}",
                f"Select country: {user_data.get('country', 'N/A')}",
                "Submit form and wait for step-2"
            ]
        }
        
        # Clean up
        client.sessions.release(session.id)
        
        return form_automation_plan
        
    except Exception as e:
        print(f"Error in form automation: {e}")
        return None

# Example usage
async def main():
    sample_user_data = {
        'first_name': 'John',
        'last_name': 'Doe',
        'email': 'john.doe@example.com',
        'country': 'US'
    }
    
    result = await fill_application_form("https://example.com/application-form", sample_user_data)
    print("Form automation result:", result)

asyncio.run(main())
```

### The Secret Sauce: Built-in Anti-Bot Protection

Here's what you get with **paid plans**:

- **Residential proxy rotation** - No more IP bans
- **Automatic CAPTCHA solving** - For common types (sorry, no magic)
- **Browser fingerprint randomization** - Look like a different human every time
- **Human-like behavior simulation** - Mouse movements that don't scream "I'M A BOT"

All enabled with one flag: `use_proxy=True, solve_captcha=True`

**Note:** *These features require upgrading from the hobby (free) plan. The hobby plan still gives you cloud browsers with basic anti-detection.*

### Session Management That Makes Sense

Sessions stick around for **up to 24 hours** and maintain state across requests:

```python
try:
    # Create a session
    session = client.sessions.create(
        timeout=86400000  # 24 hours in milliseconds
    )

    print(f"Session created: {session.id}")
    print(f"Session URL: {session.session_viewer_url}")

    # Do some work
    # ... browser automation happens here ...
    print("Browser automation would happen here...")

    # Come back later and the session is still there
    session_details = client.sessions.retrieve(session.id)
    print(f"Status: {session_details.status}")

    # Clean up when done
    client.sessions.release(session.id)
    print("Session released successfully")

except Exception as e:
    print(f"Error in session management: {e}")
```

**Pro tip**: Use the session viewer URL to watch your automation live. It's surprisingly satisfying.

### Error Handling (Because Things Break)

```python
import asyncio
import time
import random
import os
from steel import Steel

async def scrape_the_thing(session, url):
    """Placeholder function for actual scraping logic."""
    print(f"Scraping {url} using session {session.id}")
    
    # Simulate some work and potential failure
    if random.random() < 0.3:  # 30% chance of failure for testing
        raise Exception("Simulated scraping failure")
    
    return {"url": url, "data": "scraped_data", "session_id": session.id}

async def robust_automation(url, max_retries=3):
    api_key = os.getenv("STEEL_API_KEY")
    
    if not api_key:
        raise Exception("STEEL_API_KEY environment variable is not set")
    
    client = Steel(steel_api_key=api_key)
    
    for attempt in range(max_retries):
        session = None
        try:
            # Create session
            session = client.sessions.create()
            
            print(f"Attempt {attempt + 1}: Created session {session.id}")
            
            # Your automation logic here
            result = await scrape_the_thing(session, url)
            
            # Clean up
            client.sessions.release(session.id)
            print(f"Success on attempt {attempt + 1}")
            return result
            
        except Exception as error:
            print(f"Attempt {attempt + 1} failed: {error}")
            
            # Clean up session if it was created
            if session:
                try:
                    client.sessions.release(session.id)
                except:
                    pass  # Ignore cleanup errors
            
            if attempt < max_retries - 1:
                # Exponential backoff with jitter (because we're not animals)
                delay = (2 ** attempt) + random.uniform(0, 1)
                print(f"Waiting {delay:.2f} seconds before retry...")
                await asyncio.sleep(delay)  # Use asyncio.sleep in async functions
    
    raise Exception(f"Failed after {max_retries} attempts")

# Example usage
async def main():
    try:
        result = await robust_automation("https://example.com", max_retries=3)
        print("Final result:", result)
    except Exception as e:
        print(f"Robust automation failed: {e}")

asyncio.run(main())
```

### File Management (Upload/Download Vibes)

Need to handle files? We got you:

```python
# Upload a file to your session
file_upload = client.sessions.files.upload(
    session_id=session.id,
    file=open('document.pdf', 'rb'),
    path='uploads/document.pdf'
)

# Download files from your session
file_data = client.sessions.files.download(
    session_id=session.id,
    path='downloads/result.pdf'
)

# Download everything as a zip
archive = client.sessions.files.download_archive(session_id=session.id)
```

### Quick Start for the Impatient

```python
from steel import Steel
import os

# Set your API key (get one at steel.dev)
client = Steel(steel_api_key=os.getenv("STEEL_API_KEY"))

# Create session with the works
session = client.sessions.create(
    use_proxy=True,
    solve_captcha=True,
    block_ads=True  # Because ads are annoying
)

print(f"✨ Session created: {session.id}")
print(f"🔗 Watch live: {session.session_viewer_url}")
print(f"🌐 WebSocket: {session.websocket_url}")

# Connect your favorite automation tool and go wild
```

### Next Steps (Ship Something Cool)

**Ready to build?** Check out:

- [Python SDK on GitHub](https://github.com/steel-dev/steel-python) - All the code and examples
- [Steel Cookbook](https://github.com/steel-dev/steel-cookbook) - Real examples that work
- [Discord Community](https://discord.gg/steel-dev) - Get help, share wins

**Free tier gives you 100 browser hours per month** - perfect for testing and small projects.

### The Bottom Line

Steel's Python SDK removes the infrastructure headaches so you can focus on building cool stuff. No Docker containers to manage, no proxy services to configure, no CAPTCHAs to solve manually.

Just `pip install steel-sdk` and start automating.

**Questions?** Hit us up in Discord or check the docs. We're here to help you ship faster.

Ready to try it? [Get your free API key](https://app.steel.dev/sign-up) and let's see what you build. 🚀

## Blog: From PHP Kid to AI Infrastructure: Dane's Journey to Steel

https://steel.dev/blog/dane-s-journey-to-steel · Jul 19, 2025 · By Nikola Balic

> From soldering circuits in NZ to building AI browser infrastructure at Steel: Meet Dane Wilson, the maker wiring tomorrow's web, one startup at a time.

**TL;DR:** Interview with Dane Wilson, Steel's founding engineer: he built PHP game server hosting at 11, worked years on a health-records database, contracted in Toronto, and shut down his canvas startup Sane after it failed to raise a seed round. He joined Steel for its open source work, and still barely uses AI tools himself.

It answers:

- Who is Dane Wilson at Steel?
- How did Dane Wilson come to join Steel?
- What advice does Dane Wilson give developers moving from enterprise to startups?

*Welcome to the very first edition of our new interview series, where we dive deep with the builders who are quietly wiring the future. Each episode spotlights one maker’s unfiltered journey; the wins, wipeouts, and wildcard detours that got them here.*

We caught up with [Dane Wilson](https://x.com/daneo_w), Steel's founding engineer, who went from soldering circuits in rural New Zealand to building browser infrastructure for the next billion AI agents. This is his story of failed startups, enterprise escapes, and why he barely uses AI despite helping build the future of it. This is the interview with the man who soldered his way to Steel.

**So I heard you were that kid who'd rather solder circuits than kick a ball?**

**Dane:** Yeah, guilty. Started messing with electronics when I was like 8 or 9. Building little robots, taking apart anything with a circuit board. My parents probably thought I was going to burn the house down. Then at 11, I discovered web development and that was game over -- I was fully cooked on building things online.

**11 years old and already coding? What were you building?**

**Dane:** Oh man, this is embarrassing but... game server hosting. PHP everything. I'd stay up until 3am FTP-ing files to some sketchy shared hosting, building these whole billing systems from scratch. The wild part? I didn't even know open source was a thing back then, so I literally built everything myself. No frameworks, no libraries. Just raw PHP and whatever I could figure out from random forums. Never made a cent, but I was absolutely obsessed.

**That's unhinged in the best way. How'd you go from that to "proper" computer science?**

**Dane:** University was... interesting. The CS degree was all theory and mathematics, barely any actual building. Like, we're learning about Turing machines and finite automata while I'm sitting there thinking "but can it ship?" The real education came from landing an internship pretty quick -- stayed there for like four or five years. That's where I actually learned software engineering. We were building this big data database for health records, critical infrastructure stuff. Learned about data structures, testing, what happens when your code actually matters.

**Enterprise life at 20-something -- that must've been a vibe shift.**

**Dane:** Man, the meetings. The meetings about meetings. I couldn't handle it. After a few years I was like "I gotta get out." So I moved to Toronto, started contracting. Complete 180 -- went from enterprise molasses to shipping something new every three months. Marketing sites, smart contracts, healthcare systems, whatever. Just this constant stream of problems to solve. That's where I learned to move fast and not overthink everything.

**Then COVID hit and you... started a startup while contracting? That's chaotic.**

**Dane:** Peak chaos. I'm working for this Toronto agency while also being founding engineer at a New Zealand startup. Time zones were absolutely cursed. But we grew that company from just three founders -- two non-technical and one fresh uni grad -- to like seven or eight people. Helped them raise a solid pre-seed round. They just raised their seed and are entering the US market now, which is wild for a company from the bottom of the world.

**That's a W. But then came Sane?**

**Dane:** Ah, Sane. My beautiful disaster. I'm super visual -- I draw everything out on paper, mind maps, diagrams. Can't think without sketching. So we built this 2D infinite canvas thing, like Pinterest meets Notion but spatial. You could create these blogs in 2D space, mood boards that were actually functional. I was so sure it was the future.

**Narrator (imagine Attenborough voice): It was not the future.**

**Dane:** Yeah, we couldn't secure our seed round. Ran out of money start of this year and had to shut it down. That one hit different. When you're watching your bank balance hit zero and you've put everything into this thing... that's your deepest hole right there.

**But plot twist -- that's when Steel entered the chat?**

**Dane:** Exactly. I'd kept in touch with Nas, and when Sane was clearly dying, he's like "yo, come build browser infrastructure for AI agents." The timing was perfect. Plus, Steel is everything I care about -- fully open source, building in public, solving real problems. Every company I've worked at, I've pushed for open source and engineering content. I learned from reading other people's deep dives on distributed systems, so I wanted to pay it forward.

**You mentioned you're building for AI but barely use it yourself. That's... ironic?**

**Dane:** I know, I know. I'm that guy still preferring to code everything myself. Autocomplete? Distracting. Copilot? Thanks but I'm good. I'll use Claude or ChatGPT for research or maybe some refactoring, but I'm not automating my life away. Which is funny because at Steel we're literally building the infrastructure for AI agents to use the web.

**So what's your take on where AI is heading?**

**Dane:** Look, I used to think I'd never have to worry about AI -- like, "I'll always have a job." Now? The developments are absolutely wild. But here's the thing. AI is just another tool. Same as blockchains, same as any other tech. The problem is always the same: how do you make it not suck for actual humans?

Like, my parents aren't technical. They don't care about LLMs or vector databases. But if AI can help them automate some annoying task using natural language? That's the win. That's what excites me about agents -- closing that gap between what people want to do and the technical knowledge needed to do it.

**What's cooking at Steel that you're excited about?**

**Dane:** We've got a bunch of internal packages I've been building that we're going to open source soon. Can't share all the details yet, but imagine making browser automation as simple as calling an API. No more fighting with Cloudflare, no more getting instabanned, just... it works.

Plus, working with browsers at scale is genuinely fascinating. Like, how do you keep a Chrome instance warm for 24 hours? How do you make fingerprinting detection think your bot is human? These are cursed problems with elegant solutions.

**Any advice for developers who want to make the jump from enterprise to startups?**

**Dane:** Ship things. Even if they're terrible. That PHP game hosting site I built at 11? Absolute garbage code. But I learned more from shipping that than from any CS course. Also, draw your systems before you build them. I know it sounds basic, but visualizing architecture saves so much pain later.

And honestly? Embrace the failures. Sane dying sucked, but it directly led to Steel. Every hole in that Vonnegut curve sets up the next climb. You just gotta keep building.

**Last question -- what's the endgame? Where's Dane in 5 years?**

**Dane:** Still shipping, hopefully. Maybe we've democratized web agents to the point where my parents are using them without even knowing it. Maybe I'll finally start using AI for more than just research. But seriously, I just want to keep building tools that make other builders' lives easier. Open source everything we can. Write those engineering blogs I wished existed when I was starting out.

The web's about to get real weird with agents everywhere. Someone's gotta build the infrastructure for it. Might as well be us.

*Dane's currently cooking something special at Steel. Follow the journey at* [*steel.dev*](https://steel.dev/) *or catch him in our* [*Discord*](https://discord.gg/steel-dev) *probably explaining why some browser behavior is cursed at 2am.*

## Blog: Beginner's Guide to Steel.dev Browser Automation

https://steel.dev/blog/beginner-s-guide-to-steel · Jul 9, 2025 · By Nikola Balic

> Steel.dev: AI-first browser automation with anti-bot protection, session persistence, and seamless integration. Free tier: 100 hours/month.

**TL;DR:** Steel.dev is a cloud browser API for AI agents with built-in proxies, CAPTCHA solving and sessions that last up to 24 hours, with sub-second startup and a free tier of 100 browser hours per month. The guide covers install, the first session, Puppeteer and Playwright connections, use cases, best practices and troubleshooting.

It answers:

- How do I get started with Steel.dev?
- How do I connect Puppeteer to a Steel browser session?
- How long can a Steel browser session last?
- How many free browser hours does Steel give each month?
- When should I use Steel instead of Playwright, Puppeteer or Selenium?
- What should I check when a Steel session fails to create?

Steel.dev is revolutionizing browser automation by providing a cloud-based browser API specifically designed for AI agents and modern web applications.

Simply put, **Chrome is designed for human browsing while Steel is engineered for AI agents** that need reliable, scalable web automation.

Unlike traditional tools that require complex infrastructure management, Steel offers a simplified approach with built-in anti-bot protection, session persistence, and seamless integration with existing automation frameworks.

### What Makes Steel.dev Different

Steel.dev stands out by addressing the specific needs of AI-powered applications. While tools like Puppeteer and Playwright require you to manage browser instances, handle proxies, and implement CAPTCHA solving yourself, **Steel provides these capabilities out of the box**.

The platform achieves **sub-second session startup times** and can maintain browser sessions for **up to 24 hours**, making it ideal for complex automation workflows that require persistent state.

The platform’s AI-first design optimizes for **token efficiency**, reducing LLM costs by up to 80% through intelligent content extraction and formatting. This makes Steel particularly valuable for developers building AI agents that need to interact with web content efficiently.

### Getting Started with Steel.dev

#### Installation and Setup

Getting started with Steel is remarkably straightforward. For Python developers:

```sh
pip install steel-sdk
```

For Node.js developers:

```sh
npm install steel-sdk
```

After installation, create a [**free account at steel.dev**](https://app.steel.dev/sign-up) to obtain your API key. Steel offers a generous **free tier with 100 browser hours per month**, perfect for testing and small projects.

**Set your API key as an environment variable:**

**Mac/Linux (bash)**:

```sh
export STEEL_API_KEY="your-api-key"
```

**Windows (CMD)**:

```sh
set STEEL_API_KEY=your-api-key
```

**Windows (PowerShell)**:

```sh
$env:STEEL_API_KEY="your-api-key"
```

Alternatively, add it directly to your project’s `.env` file.

#### Your First Steel Session

Here’s a simple example that demonstrates Steel’s power:

```python
from steel import Steel
import os

# Initialize the client
client = Steel(steel_api_key=os.getenv("STEEL_API_KEY"))

# Create a browser session with anti-bot protection
session = client.sessions.create()

print(f"Session ID: {session.id}")
print(f"Watch live at: {session.session_viewer_url}")
```

This simple code creates a cloud browser session.

### Core Features and Capabilities

#### Session Management

Steel’s [session API](https://docs.steel.dev/api-reference#tag/sessions) provides persistent browser instances that maintain cookies, local storage, and authentication state across requests. Sessions can run for up to 24 hours, enabling complex workflows like:

- Monitoring dashboards that require login
- Multi-step form submissions
- Shopping cart operations across multiple pages
- Long-running data extraction tasks

#### Browser Framework Integration

Steel works seamlessly with your favorite automation frameworks. Here’s how to connect with Puppeteer using JavaScript:

```js
import Steel from 'steel-sdk';
import puppeteer from 'puppeteer';

const client = new Steel();
const session = await client.sessions.create();

// Connect Puppeteer to Steel session
const browser = await puppeteer.connect({
    browserWSEndpoint: `wss://connect.steel.dev?apiKey=${process.env.STEEL_API_KEY}&sessionId=${session.id}`,
});

const page = await browser.newPage();
await page.goto('https://steel.dev/');
```

#### Built-in Anti-Bot Protection

Steel includes enterprise-grade anti-bot evasion techniques:

- Residential proxy rotation from a global network
- Automatic CAPTCHA solving for common types
- Browser fingerprint randomization
- Human-like behavior simulation
- Stealth mode configurations

### Real-World Use Cases

#### Price Monitoring System

Here’s a practical example of building a price monitoring system:

```js
async function monitorProductPrice(productUrl) {
    const session = await client.sessions.create({
        useProxy: true,
        solveCaptcha: true
    });

    const browser = await puppeteer.connect({
        browserWSEndpoint: `wss://connect.steel.dev?apiKey=${apiKey}&sessionId=${session.id}`,
    });

    const page = await browser.newPage();
    await page.goto(productUrl);
    
    // Wait for price element to load
    await page.waitForSelector('.price', { timeout: 10000 });
    
    const priceData = await page.evaluate(() => {
        const price = document.querySelector('.price')?.textContent;
        const title = document.querySelector('h1')?.textContent;
        const availability = document.querySelector('.in-stock') !== null;
        
        return {
            price: price?.replace(/[^0-9.]/g, ''),
            title: title?.trim(),
            available: availability,
            timestamp: new Date().toISOString()
        };
    });

    await browser.close();
    return priceData;
}
```

#### Form Automation

Automating complex forms becomes simple with Steel’s session persistence:

```js
async def automate_application_form(form_url, user_data):
    # Create session with extended timeout
    session = client.sessions.create(
        use_proxy=True,
        solve_captcha=True,
        session_timeout=3600000  # 1 hour for complex forms
    )
    
    # Connect with Playwright
    browser = await playwright.chromium.connect_over_cdp(
        f"wss://connect.steel.dev?apiKey={api_key}&sessionId={session.id}"
    )
    
    page = await browser.new_page()
    await page.goto(form_url)
    
    # Fill multi-step form
    await page.fill('input[name="firstName"]', user_data['first_name'])
    await page.fill('input[name="lastName"]', user_data['last_name'])
    await page.fill('input[name="email"]', user_data['email'])
    
    # Handle dynamic dropdowns
    await page.select_option('select[name="country"]', user_data['country'])
    
    # Navigate to next step
    await page.click('button[type="submit"]')
    await page.wait_for_url('**/step-2')
    
    # Continue with additional steps...
```

#### Extracting Data from JavaScript-Heavy Sites

Modern SPAs require sophisticated handling that Steel simplifies:

```js
async function extractSPAData(spaUrl) {
    const session = await client.sessions.create({
        useProxy: true,
        blockAds: true  // Improve performance
    });

    const browser = await puppeteer.connect({
        browserWSEndpoint: `wss://connect.steel.dev?apiKey=${apiKey}&sessionId=${session.id}`,
    });

    const page = await browser.newPage();
    
    // Navigate and wait for SPA to fully load
    await page.goto(spaUrl, { waitUntil: 'networkidle2' });
    
    // Wait for React/Vue/Angular to render content
    await page.waitForSelector('[data-loaded="true"]', { timeout: 15000 });
    
    // Extract rendered data
    const products = await page.evaluate(() => {
        return Array.from(document.querySelectorAll('.product-card')).map(card => ({
            name: card.querySelector('.name')?.textContent,
            price: card.querySelector('.price')?.textContent,
            rating: card.querySelector('.rating')?.getAttribute('data-score'),
            image: card.querySelector('img')?.src
        }));
    });

    await browser.close();
    return products;
}
```

### Steel.dev vs Other Browser Automation Tools

#### When to Choose Steel.dev

Steel excels in scenarios requiring:

- **Managed Infrastructure**: No need to handle browser installation or updates
- **Anti-Bot Protection**: Built-in proxies and CAPTCHA solving
- **Session Persistence**: Long-running tasks with maintained state
- **AI Integration**: Optimized for LLM-based applications
- **Rapid Development**: Get started in minutes, not hours

#### When to Choose Traditional Tools

Consider Playwright, Puppeteer, or Selenium when you need:

- **Offline Operation**: Running automation without internet dependency
- **Cross-Browser Testing**: Testing across multiple browser engines
- **Legacy System Support**: Working with older browser versions

#### Performance Comparison

In practical benchmarks, Steel shows significant advantages for cloud-based automation:

- Session startup: <1 second (vs 3-5 seconds for self-managed browsers)
- CAPTCHA solving: Automatic (vs manual implementation required)
- Proxy rotation: Built-in (vs third-party service integration)
- Infrastructure scaling: Automatic (vs manual orchestration)

### Best Practices for Success

#### Ethical Web Scraping

Always prioritize ethical considerations:

1. **Respect robots.txt**: Check and honor crawling directives
2. **Implement rate limiting**: Add delays between requests
3. **Use appropriate user agents**: Identify your bot transparently
4. **Handle errors gracefully**: Back off when encountering issues

```python
import time
import random

def respectful_scraping(urls):
    for url in urls:
        try:
            # Process URL
            result = scrape_page(url)
            
            # Add human-like delay
            delay = random.uniform(2, 5)
            time.sleep(delay)
            
        except Exception as e:
            print(f"Error scraping {url}: {e}")
            # Longer delay after errors
            time.sleep(10)
```

#### Security Best Practices

Protect sensitive data and credentials:

```python
# Never hardcode credentials
api_key = os.environ.get('STEEL_API_KEY')

# Use context managers for session cleanup
class SteelSession:
    def __init__(self, client):
        self.client = client
        self.session = None
    
    def __enter__(self):
        self.session = self.client.sessions.create()
        return self.session
    
    def __exit__(self, exc_type, exc_val, exc_tb):
        if self.session:
            self.client.sessions.release(self.session.id)

# Usage
with SteelSession(client) as session:
    # Use session safely
    pass  # Session automatically released
```

#### Error Handling Patterns

Implement robust error handling for production reliability:

```js
async function robustAutomation(url, maxRetries = 3) {
    let lastError;
    
    for (let attempt = 0; attempt < maxRetries; attempt++) {
        try {
            const session = await client.sessions.create({
                useProxy: true,
                solveCaptcha: true
            });
            
            // Your automation logic here
            const result = await performTask(session, url);
            
            await client.sessions.release(session.id);
            return result;
            
        } catch (error) {
            lastError = error;
            console.log(`Attempt ${attempt + 1} failed: ${error.message}`);
            
            // Exponential backoff
            const delay = Math.pow(2, attempt) * 1000;
            await new Promise(resolve => setTimeout(resolve, delay));
        }
    }
    
    throw new Error(`Failed after ${maxRetries} attempts: ${lastError.message}`);
}
```

### Troubleshooting Common Issues

#### Session Creation Failures

If sessions fail to create, check:

1. API key validity and permissions
2. Account limits and quotas
3. Network connectivity to Steel servers
4. Rate limiting (implement exponential backoff)

#### Element Not Found Errors

When elements aren’t found:

```js
// Instead of direct clicking
await page.click('#submit');  // May fail

// Use robust waiting
await page.waitForSelector('#submit', { 
    visible: true, 
    timeout: 30000 
});
await page.click('#submit');
```

#### CAPTCHA Handling Issues

While Steel handles most CAPTCHAs automatically, some complex types may require special handling:

```js
# Monitor CAPTCHA resolution
session = client.sessions.create(solve_captcha=True)

# Set appropriate timeouts for complex CAPTCHAs
page.set_default_timeout(60000)  # 60 seconds for CAPTCHA solving
```

### Performance Optimization

#### Efficient Resource Usage

Optimize your Steel usage for cost and performance:

```jsx
// Disable unnecessary resources
const session = await client.sessions.create({
    blockAds: true,
    // Smaller viewport for better performance
    dimensions: { width: 1280, height: 720 }
});

// Intercept and block images/CSS when not needed
page.on('request', (request) => {
    const resourceType = request.resourceType();
    if (['image', 'stylesheet', 'font'].includes(resourceType)) {
        request.abort();
    } else {
        request.continue();
    }
});
```

#### Parallel Processing

Process multiple URLs efficiently:

```python
import asyncio
from concurrent.futures import ThreadPoolExecutor

async def process_urls_parallel(urls, max_concurrent=5):
    semaphore = asyncio.Semaphore(max_concurrent)
    
    async def process_with_limit(url):
        async with semaphore:
            return await process_single_url(url)
    
    tasks = [process_with_limit(url) for url in urls]
    return await asyncio.gather(*tasks)
```

### Next Steps and Resources

#### Continue Learning

1. **Official Documentation**: [docs.steel.dev](https://docs.steel.dev/overview/intro-to-steel)
2. **GitHub Repository**: [github.com/steel-dev/steel-python](http://github.com/steel-dev/steel-python)
3. **Community Discord**: [Join for support and best practices](https://discord.gg/steel-dev)
4. **Cookbook Examples**: [github.com/steel-dev/steel-cookbook](http://github.com/steel-dev/steel-cookbook)

#### Building Your First Project

Start with these beginner-friendly projects:

1. **Price Tracker**: Monitor product prices and send alerts
2. **Form Filler**: Automate repetitive form submissions
3. **Content Scraper**: Extract articles from news websites
4. **Screenshot Service**: Generate website screenshots on demand

#### Scaling to Match Your Needs

As your automation requirements evolve, Steel grows with you:

- **Personal Projects**: Learning, prototyping, and small-scale automation
- **Production Applications**: Live services and regular automation workflows
- **Enterprise Development**: High-volume automation at scale
- **Custom Solutions**: Tailored configurations for specialized use cases

Steel’s **cloud-native design** automatically handles infrastructure scaling, session management, and performance optimization regardless of deployment size. Check your current usage and explore options in your [Steel dashboard](https://app.steel.dev/sessions).

Steel.dev democratizes browser automation by **removing infrastructure complexity** while providing enterprise-grade capabilities. Whether you’re building a simple scraper or a sophisticated AI agent, Steel’s combination of simplicity, power, and reliability makes it an excellent choice for modern web automation projects.