Stealth is a speed problem

The web your agent sees

An agent that reasons perfectly is still only as good as the pages it can open. That half of the stack gets treated as solved, and it is the half that quietly fails.

Most pages with information worth reading are defended. Prices, listings, job posts, terminal schedules, business directories, anything with commercial value has something standing in front of it: Cloudflare, DataDome, PerimeterX, Akamai, a proof-of-work wall, a login. Those systems were built to stop scrapers, and they can’t tell your agent apart from one, because at the level they inspect there is nothing to tell apart.

What comes back is a page. Cloudflare’s “Just a moment,” DataDome’s “please enable JavaScript,” Amazon’s “Continue shopping.” Twenty-odd kilobytes of HTML with a 200 or a 403 attached. Retry logic sees a request that finished. A model sees text, so it reads the text, summarizes it, and hands back an answer assembled from a wall. We measured that across eight sites in July: naive fetches got a summarizable body eight times out of eight, and a signal the agent could use to know it had failed zero times out of eight.

So the working state of agents on the web is that they perform well on the cooperative half and hallucinate quietly through the rest.

And the defended half is growing

Cloudflare switched on default AI-crawler blocking for new domains in July 2025 and has turned away hundreds of billions of bot requests since. Proof-of-work interstitials went from a curiosity to something you hit on ordinary open-source infrastructure; we wrote about Anubis when it started showing up in front of things our own agents needed. Every month there is more web that a plain fetch() cannot read.

The number of agents pointed at that web is going up much faster. Two lines heading for an awkward crossing: most software traffic agentic, most valuable pages set to reject non-humans on sight.

The optimistic resolution is a protocol, where sites publish agent-readable endpoints with a payment rail attached. Some will. The sites with the most to lose from being read will be last, and those are the sites your agent most wants. Until then the only thing that works is a browser that looks like a person using a browser.

Two constraints

Getting through is stealth. Getting through fast is speed. Nearly every browser infrastructure company is built to win exactly one of them, and the reason is that the currency you pay stealth in is time.

You buy stealth with a real Chrome. With a warm profile carrying history and cookies, which costs memory, which keeps pools small. With residential egress, which adds round trips. And with waiting, because a JS challenge is a delay by design and a proof-of-work wall charges you CPU seconds before it opens.

You buy speed by deleting all of that. Thin headless browsers, cold and stateless, on datacenter IPs, with no time budget for challenges. It’s fast because there’s nothing there, and nothing there is exactly what the defense scans for.

That trade is why the stealth half of the field spreads out the way it does. Eight hosted browsers, 71 sites with live commercial anti-bot in front of them, scored on whether the real content came back:

Several of the providers at the bottom of that chart are faster than the ones at the top. They made the other trade.

Why a looping agent can afford neither

If an agent fetched one page, you could pick a side. Agents loop: search, open, read, follow a link, check a second source, compare. A modest research task is twenty page loads with a person waiting at the end of them.

Both constraints compound over that loop, and they compound differently.

Latency multiplies. Six seconds a page across twenty pages is two minutes of dead air per task, and at any real concurrency it is also your infrastructure bill, because the meter runs while the browser waits.

Blocks multiply worse. A 95% per-page success rate reads as fine on a dashboard. Across twenty pages it is a 36% chance of a clean run. Roughly two tasks in three contain at least one page the agent read as content when it was a wall, and nothing in the transcript marks which one.

The loop is what turns this into a both-or-nothing problem. Slow and unblockable is a batch job, useful overnight. Fast and blocked is confident nonsense, delivered promptly.

What we built

Tilion’s bet is that you can pay for stealth somewhere other than latency. Concretely, in four places.

Fingerprint and TLS are matched to a real desktop Chrome, so a session looks right on the first packet and skips the negotiation. Profiles stay warm and persisted, so a session that already cleared a challenge keeps the clearance. Interstitials get handled inside the session, which is where most of the wall-clock time in a blocked fetch goes once it escapes into a retry loop. And headless is the default path, because most of what makes a browser slow under concurrency is the desktop wrapped around it.

Here is where that shows up. Create, connect, navigate, release, the full session lifecycle, median over 100 iterations:

130 milliseconds to create a session, connect to it, drive it to a page, and tear it down. The next provider takes 240, and most of the field spends between half a second and 1.3 seconds. Most of that spread is setup, which is dead time the agent pays again on every step of the loop.

The runs came from our machines, and site defenses change week to week, so treat both charts as a snapshot. If you want a version you can trust, run it against your own targets. That is most of the reason we are giving credits away.

Tilion Cloud is live today

The hosted version is open as of today. No waitlist, no sales call. A REST API, CDP passthrough so Playwright and Puppeteer connect directly, and an MCP server if your agent speaks that instead. Fortress, the engine underneath, stays open source.

Pricing is $0.03 per browser-hour. Every new account starts with free credits, a few hundred hours of browser time, with no card required to find out whether the numbers above hold on the sites you care about.