How Jev Acts on the Web: Running Browser Actions in the Cloud

What Can Jev Actually Do in a Browser?

It can answer one bounded question about a page you have already fetched and converted to text. That is the entire contribution. If you have not met the model yet, what is Jev covers the three question types and the calibration argument behind them.

Mapped onto browsing, the three primitives cover the decisions a navigation loop actually makes:

• Choice - which of these links moves me closer to the goal. This is the primitive the Wikipedia Game demo leans on, and the one that runs into the cardinality ceiling first.
• Score - how close is this page to what I was asked to find, on a rubric you write out as ordered levels.
• Noul - is this a login wall, is this a cookie banner, did this page report an error, have I arrived. One probability each, and you can ask all of them in the same request as the Choice.

That last point is worth designing around. TypeSafe's speculative fan-out pattern recommends putting every question your system might need into a single call and letting code discard the irrelevant answers, because questions are evaluated in parallel and extra ones barely change response time. A browser step is a good fit: ask about arrival, obstacles, and the next link at once, then branch on whichever answers turn out to matter.

What Crosses the Boundary on Each Step?

The payload going out is the page reduced to text, a list of candidate actions, the goal, and whatever history you choose to carry. What comes back is a typed value and a probability, with no explanation attached.

In code against a real Browser Cloud session, one step looks like this. The session gets created once and reused across every step, which is the part that governs latency:

import { Browser } from '@testmuai/browser-cloud';

const client = new Browser();

const session = await client.sessions.create({
  lambdatestOptions: {
    'LT:Options': {
      username: process.env.TESTMU_USERNAME,
      accessKey: process.env.TESTMU_ACCESS_KEY,
      build: 'Jev browser loop',
      name: 'navigation step',
    },
  },
});

const browser = await client.puppeteer.connect(session);
const page = (await browser.pages())[0];

await page.goto('https://www.testmuai.com/selenium-playground/', {
  waitUntil: 'domcontentloaded',
});

// The browser's half of the contract: page in, agent state out.
const state = await page.evaluate(() => ({
  url: location.href,
  title: document.title,
  text: document.body.innerText.slice(0, 20000),
  links: Array.from(document.querySelectorAll('a[href]'))
    .map((a) => ({ label: a.innerText.trim(), href: a.getAttribute('href') }))
    .filter((l) => l.label && !l.href.startsWith('#'))
    .slice(0, 255), // Choice cardinality ceiling
}));

// state now goes to Jev as the 'state' field, with a Choice over state.links,
// plus speculative Nouls for arrival and obstacles, in one request.
// Jev returns a typed choice and a probability. Your code decides whether to act.

await browser.close();
await client.sessions.release(session.id);

Two details in that snippet decide whether the loop works. The slice(0, 255) is not defensive styling, it is the hard ceiling on a Choice question. And the cleanup is two calls rather than one: closing the browser and releasing the session are separate operations.

Note: One correction worth knowing before you build this. The quick-action helper client.scrape() does not run on Browser Cloud unless a session page is registered first; the shipped SDK otherwise launches a local Chrome. Create a session and connect an adapter, as above. Start a free TestMu AI account

How Did I Measure This?

I ran the whole thing on one Browser Cloud session and reused it across all five pages, driving it through the Puppeteer adapter rather than spinning up a fresh browser each time. If you want to check my working, the run is logged as session session_1789825377735_y2lihi under build 105551715.

On each page I did the same five things:

• Navigate with waitUntil: domcontentloaded and time the call.
• Take extracted text as document.body.innerText, which is what a text-only model can consume.
• Take raw markup as document.documentElement.outerHTML for the comparison.
• Count links as unique a[href] values, excluding in-page anchors and javascript URLs.
• Compare against characters rather than tokens, because TypeSafe publishes no tokenizer.

TypeSafe's model card for jev-1.13 gives the budget in tokens, at 64k per request and 32k for the state plus the longest question.

Its primitives documentation glosses the state budget as roughly 150,000 characters of English.

The token figure and the character figure do not reconcile cleanly, and TypeSafe publishes no tokenizer to settle it. Characters are the honest unit here, so that is what every percentage below is measured against.

I got this wrong the first time, and the way it went wrong is worth passing on. My first pass used the SDK's client.scrape() helper and produced a clean-looking table that was entirely local: the helper resolves a page through an internal getPage() call that launches a transient Chrome when no session page is registered, so the cloud credentials I passed were ignored. I discarded that run. The numbers below come from a session that appears in the TestMu AI dashboard.

What Do Real Pages Cost?

Extracted text fit the state budget on all five pages I ran through TestMu AI Browser Cloud. Raw HTML failed on three of them, and the gap between the two turned out to be the largest number in this study, running from 9x to 183x.

All percentages here run against the 150,000-character budget, on the TestMu AI session above. The Ecommerce Playground makes the clearest case for extraction as a hard requirement: 3,039 characters of text a human would read, wrapped in 557,414 characters of markup. Hand the second number to a model with a bounded context and the page does not fit. Hand it the first and the page uses two percent of the budget.

The link column is the constraint that surprised me. The Wikipedia article on software testing offers 932 unique navigable links, against a Choice ceiling of 255. Our own Selenium Playground offers 259, which is four more than one question can take. A page does not have to be unusual to present more paths than one question can hold.

Latency divided the same way, with the fixed cost dominating:

TypeSafe's launch announcement puts Jev at 40x to 200x faster than frontier language models on System One shaped queries.

The decision is the cheapest thing in the loop, so in a browser agent almost none of that speed reaches the user, because a single connect costs more than twenty decisions and every step pays a navigation that outweighs the model call. The lever is session reuse, which is also why how parallel browser sessions are provisioned matters more to an agent's wall-clock time than the model behind it.

Where Does the Contract Break?

Budget overflow, cardinality overflow, staleness, and option-label injection. The measurements above predict the first three; the fourth they cannot see. Each has a fix that lives in your code rather than in the model.

The last one deserves more weight than it usually gets. TypeSafe's jaggedness page for jev-1.13 states that state is not treated as hostile by default, that content written to steer the model can move the answer, and that the mitigations are precise criteria plus testing edge cases before deployment.

A browser sharpens that. Ordinary prompt injection puts hostile text near a decision; here the hostile text is the option set, and the edge cases are supplied by whoever controls the page.

A second-order problem follows from the model's own design, and it is the subject of why Jev returns a type, not a sentence. Jev returns no reasoning, so after a bad step there is nothing to read back. The probability distribution tells you how certain it was, not what it saw. The only record of what it saw is the one your infrastructure kept.

Which Tasks Fit This Loop?

Tasks where the next action is already on the page as one of a set of options, and where being wrong once is cheap to retry. Nathan Drezner, the LangChain engineer who built the demo, reported two shapes that worked well: playing the Wikipedia Game, and what he called "folding laundry" tasks such as finding cheap flights.

Both are navigation problems from the outside, but they stress the loop in different places, which is why they are worth separating.

Link navigation, as in the Wikipedia Game. The player starts on one article and has to reach a target article using only links found along the way. Every step is one Choice over on-page links, arrival is a single Noul, and nothing in the task ever needs a sentence written. The state budget is never the constraint here: the two Wikipedia articles I extracted on the TestMu AI Browser Cloud session above used 8.3% and 55.0% of it. The constraint is the option set, since one of those pages offered 932 unique links against a ceiling of 255. Wrong turns are also cheap, which is what makes a probabilistic chooser safe to run unattended.

Repetitive errands, as in fare hunting. The laundry-folding class is different: the same small judgment repeats across many near-identical pages. Is this result acceptable, which of these fares clears the bar, did the filter actually apply. Score fits that better than Choice, because the question is degree rather than identity, and speculative fan-out lets one request carry the arrival check, the obstacle checks, and the pick together.

This second class is also where three of the four failure modes land hardest:

• Staleness - fares and availability change between the moment you extract the page and the moment you act on the decision, so the snapshot expires faster than it does on a reference article.
• Session state - these flows sit behind logins, carts, and multi-step wizards, which is the case session persistence exists for. An agent that re-authenticates on every run will not finish.
• Option-label injection - a booking page puts sponsored results and ad frames into the same list as real ones, so the untrusted labels are not hypothetical, they are the business model of the page.

Three shapes do not fit at all. Anything that needs prose out, because the model writes nothing. Anything that turns on arithmetic or date comparison on the page, which TypeSafe's own jaggedness list flags as unreliable. And anything where a wrong action is expensive and irreversible, such as submitting a purchase, unless a confidence threshold gates it and a person is on the other side of that gate.

Where Does It Fail First in a Real Loop?

Three places, and they arrive in roughly this order: state drift, auth, and evaluation coverage. None of them is specific to Jev. They are what separates a browser agent that works in a recording from one that works on a Tuesday afternoon against a site nobody controls.

That three-way split is a framing rather than a taxonomy anyone has established, so treat it as a place to start looking rather than a complete list.

State drift. The agent reads the page, spends seconds deciding, then acts, and nothing in that sequence guarantees the page it acts on is the page it read. This is a time-of-check-to-time-of-use race rather than a flaky selector, and it long predates agents: the WebDriver specification carries a dedicated stale element reference error, and Playwright's documentation steers people toward locators precisely because they resolve at action time instead of holding a reference captured earlier. What model-driven loops changed is the size of the window. A scripted test closes it in milliseconds; a loop that pauses to think leaves it open for seconds, which is long enough for a carousel to rotate, a banner to mount, or a list to reflow under the index the agent chose.

Auth. An agent borrows an identity it does not own and cannot inspect. The damaging case is not the login page, which is at least visible; it is the session that lapses without saying so, because a site will usually answer with a 200 and a plausible anonymous page rather than an error. The run continues, the extraction succeeds, and every decision after that point is made against a page the user would never have seen. Bot challenges compound it: the authors of Online-Mind2Web excluded CAPTCHA-protected sites from their benchmark outright, on the grounds that websites with strong bot protection prevent agents from completing the task at all.

I hit exactly this while researching this article. Trying to read a public discussion thread from a cloud browser returned the page and none of the content, twice, the second time with stealth enabled. The request succeeded. The thing I wanted was behind a login the agent had no way to satisfy, and a loop that trusted the 200 would have carried on reasoning about an empty page.

Evaluation coverage. The published success rates are mostly produced by proxies, and the proxies are weaker than the numbers suggest. In An Illusion of Progress, the authors sampled 650 tasks from an established web-agent dataset and found 47% were either invalid or had outdated ground-truth trajectories. On another widely used benchmark they showed a naive agent that only issues a Google query and clicks a returned link, with no further interaction, already solves up to 51% of the tasks. Their own improved automatic judge reaches around 85% agreement with human judgment, which is a real advance and still leaves roughly one verdict in seven disputed.

That paper was presented at COLM 2025, which is worth noting because a lot of what circulates on agent reliability is unreviewed preprint material.

Put those together and the shape of the problem is clear enough. A run can act on a page that has already changed, against an identity that has already expired, and be graded by a check that was never strict enough to notice either.

What Does the Browser Side Have to Provide?

Enough of the three problems above to change what they cost you, and no more than that. Infrastructure does not make an agent succeed more often. It changes the class of failure, turning silent and unreproducible into loud and inspectable, which is the difference between a bug you can fix and a bug you never hear about.

TestMu AI Browser Cloud describes itself as scalable browser infrastructure for AI agents, and its named features line up against those three problems more directly than the marketing order suggests:

• Browser Scaling - sub-second starts, sessions up to 24 hours, and scaling from one agent to thousands without queues or capacity planning. The 24-hour ceiling is what makes session reuse a real strategy rather than a trick.
• Session Persistence - cookies, local storage, and login state travel with every session, so an agent resumes where it left off instead of re-authenticating on every run.
• Built-in Tunnel - reaches localhost, internal apps, and VPN-gated services with zero setup, which is the difference between an agent that can only see the public web and one that can work against your staging environment.
• Observability - live view, video replay, network logs, and console output, all captured automatically.
• Stealth Mode - best-effort fingerprint masking, CAPTCHA solving, and ad blocking. Best-effort is the platform's own word for it, and it is the right expectation to carry into a loop that will meet bot challenges.
• Geo Proxies - 180+ geolocations, so a page that varies by region can be evaluated from the region it is meant for.

TestMu AI Browser Cloud connects through Playwright, Puppeteer, or Selenium, or through your own agent via the SDK, and it runs on infrastructure serving 3M+ users and 1.5B+ tests annually across 18,000+ enterprises.

Set against the three failure modes, that maps roughly like this. Session Persistence and the Built-in Tunnel take most of the auth problem off the table by letting an agent authenticate once and reach environments that are not on the public web, while Stealth Mode and Geo Proxies improve the odds on bot challenges and region-varying pages. Observability is what turns state drift from an unexplained wrong answer into a video and a network log you can step through. Session isolation and cheap parallel repetition are what make it affordable to run the same task twenty times, which is how you find out whether a pass was real.

What none of that does is stop the agent being wrong. Refusing an action because the page moved is the framework's job rather than the platform's, since only your code knows what the plan assumed. Stealth is best-effort by the platform's own description. And a session that drops into a logged-out view still returns a 200, so the loud auth failures become catchable while the quiet one stays yours to detect. The honest summary is that the platform makes failures visible and repeatable, and deciding what counts as a failure stays with you.

The transparency piece carries unusual weight in a Jev loop. With a language model you can at least ask it to explain itself afterwards, however unreliable that explanation is. With a System One model there is no explanation to request, so the session recording is the only account of what the page looked like at the moment of the decision. The Browser Cloud documentation covers session configuration and the artifacts each run produces.

Three notes from my own run, since this is a measurement piece. Creating the session took 6ms, and the 11,237ms in the table above is the separate cost of the adapter connecting and completing its handshake from my machine, so the two numbers describe different things and only the first is a session start. The Puppeteer adapter completed that handshake while the Playwright adapter timed out at its 60,000ms default against the same account on the same machine, so the adapter choice is worth testing rather than assuming. And the SDK prints the session WebSocket URL to standard output on connect; that URL carries credentials, so it belongs out of shared logs and CI output.

Getting Started

Start by measuring your own target pages before you write any loop. Run the extraction in the snippet above against the five or ten pages your agent will actually visit, and check two numbers: the character count of the extracted text against the state budget, and the count of candidate actions against 255. Those two numbers decide your architecture, and they take about ten minutes to get.

If the pages are yours, the same session that measures them can run the agent against staging through the built-in tunnel. Browser Cloud sessions are created and released from the SDK shown above, and if you would rather drive a browser from natural language than from an extraction script, Kane CLI runs the same infrastructure from the terminal. For a loop you assemble in a workflow tool rather than in code, the n8n Browser Cloud integration covers the same session model with the decision step left open.