Where the old approach's cost goes

To see what Page Agent actually saves, first look at how much baggage external tools carry just to operate one webpage. They never enter the page — they can only stand outside and direct it through a pane of glass.

This externally-driven approach still works well for cross-site scraping and end-to-end testing. What Page Agent is trying to fix is a different kind of hassle: when the webpage is your own product and you can edit its code, why go through all that trouble at all.

Compressing an entire webpage into a text list

A modern webpage can have thousands of nodes, and handing the raw HTML straight to a model is slow and expensive. Page Agent's approach is to "dehydrate" the page first, keeping only the handful of things that can actually be operated on.

How different what the model sees is, before and after dehydration

The original demo page lays this loop out directly: a "Dehydrated DOM" panel shows the list the model is reading, while an "Action trace" panel next to it updates step by step as the instruction executes — you can watch it click through the sequence.

What happens once the instruction comes in

From a single sentence of natural language to an actual click on the page, there's a fixed closed loop in between. The dirty work is handled by a component called PageController.

PageController exposes exactly these actions, operating on elements by index:

await this.pageController.updateTree()
await this.pageController.clickElement(index)
await this.pageController.inputText(index, text)
await this.pageController.scroll({ down: true, numPages: 1 })

The whole monorepo splits responsibilities across three small packages:

Three guardrails in the developer's hands

Against other tools, who should use it

This comparison table is about scenario, not speed. The four approaches run in different places and read the page in different ways — each has its own turf.

The conclusion comes down to scope of use: Page Agent fits inside a product you control and can edit; if you need to scrape someone else's site, or work against a locked-down environment, external driving still wins.

What you can actually do with it

Because it lives right inside your application, it can actually finish an operation for the user, not just tell them beside it how to click. The original piece gives four concrete examples.

The lowest-cost path is a single script tag

If you just want to get a feel for it, one script tag loads Page Agent bundled with a free test model, ready to try right on the page.

<script src="https://cdn.jsdelivr.net/npm/page-agent@1.10.0/dist/iife/page-agent.demo.js" crossorigin="true"></script>

For production use, install the package and swap in your own endpoint:

import { PageAgent } from 'page-agent'

const agent = new PageAgent({
  model: 'qwen3.5-plus',
  baseURL: 'https://dashscope.aliyuncs.com/compatible-mode/v1',
  apiKey: 'YOUR_API_KEY',
  language: 'en-US',
})

await agent.execute('Click the login button')

The model and baseURL accept any OpenAI-compatible provider — switching models is basically just swapping the base URL and key.

What it can't do

This "live inside the webpage" approach comes with its own inherent trade-offs, and the official docs are upfront about the limits. These points need to be on the table before you use it.

Safety rules written into the prompt are only a suggestion

Rules like "never auto-submit a payment form" are placed in the system prompt. They're persuasive guidance, not a hard guarantee. For sensitive or destructive operations, server-side validation still has to stay in place — instructions in the prompt can't be your only line of defense.

The core library only handles a single page

The core library targets interaction within a single view; on its own it can't move between tabs or windows. For cross-page automation, you need the optional Chrome extension, which requires its own installation and authorization. There's also a Beta-stage MCP server that lets external agents like Claude Desktop or Copilot drive it in reverse.

Back to the opening line: Page Agent and mainstream tools take two different roads — one embeds itself inside the webpage to read text, the other stands outside and remotely operates via screenshots and protocols. It extends where browser automation can actually land, from "an external script controlling someone else's webpage" to "a natural-language operating layer built right into the product."

This time, Alibaba turned the agent into a piece of JavaScript embedded right in the webpage. It lives inside the page like a real user, reading the page's text structure to click and fill things in — so it can be dropped into your own product as an operating assistant. The most immediate change is what the model sees on every click:

Reading text is more accurate than looking at an image, and cheaper too — no need to keep a pricier vision-capable model around. So how does that indexed text list get squeezed out of one whole, messy webpage?

The signature move is called DOM dehydration (the DOM is the element tree the browser breaks a webpage into; dehydrating means pulling the handful of genuinely clickable things out of a page's thousands of parts, tagging each with an index, and compressing it into a lean text list). Same scenario, clearest when placed side by side with the old approach:

What people feel most viscerally about "how much this saves" is how much stuff they have to prep by hand. Take "adding an AI assistant that can operate the UI on the user's behalf to a product" and compare directly:

These are the project's publicly stated facts — license, version, integration method — not a performance benchmark; "reads only text, so it's more cost-efficient on inference" is a design inference, and the official docs give no third-party benchmark for it. Going to production still means swapping in your own model and moving the key to the backend — don't ship the demo key baked into the front end.