TL;DR

PageAgent is a JavaScript library from Alibaba’s open-source team that embeds an AI GUI agent directly inside your webpage. You drop in one <script> tag (or npm install page-agent), give it an LLM API key, and your web app gets a natural-language agent that clicks buttons, fills forms, and navigates — all by reading the live DOM as text. 26,542 stars, 1,950 added this week, MIT-licensed, and one of the most-discussed Show HNs of the last quarter (147 points, 76 comments).

The pitch is architecturally interesting: nearly every “browser agent” project — Browser-use, Playwright-based agents, Steel, Anthropic’s Computer Use, OpenAI’s Operator — runs outside the browser and drives it from the outside via CDP, screenshots, or a headless engine. PageAgent inverts that: it runs inside the page as a first-class client-side script, inherits the current user’s session automatically, and never needs Python, a headless browser, or multi-modal vision models.

Key facts:

  • 26,542 GitHub stars, 1,950 added this week, currently a top-5 trending TypeScript repo
  • 147 points on Show HN, 76-comment thread on the “inside-out” agent architecture
  • Built by Alibaba with primary work from /gaomeng1900, contributor credit to /JasonOA888 and others
  • Text-based DOM manipulation — no screenshots, no multi-modal LLMs, no special permissions
  • Bring your own LLM — works with Qwen, GPT, Claude, Gemini, DeepSeek, and locally-deployed models
  • Optional Chrome extension for cross-tab/multi-page agent tasks
  • MCP server (beta) — lets external agent clients (Claude Desktop, Cursor) drive an in-page PageAgent from outside
  • Builds on browser-use — DOM processing components and prompts are derived from Gregor Zunic’s browser-use project (MIT), which the README credits directly
  • Distributed via npm, jsDelivr, and npmmirror (China CDN), plus a Chrome Web Store listing for the extension
  • MIT License

The “inside-out” agent architecture

Every browser agent released in the past 18 months has been an outside-in system: a program running on your machine (or someone else’s server) that opens a headless Chromium, takes a screenshot or CDP snapshot, sends that to a multi-modal LLM, gets back an action, and dispatches it through the DevTools Protocol. Browser-use, Steel, Playwright-agents, Anthropic’s Computer Use, OpenAI’s Operator, and the entire “computer use” model class all share this shape.

That shape has three chronic problems the whole category quietly lives with:

  1. Auth is a nightmare. You have to either cookie-inject, run in the user’s actual profile (dangerous), or make the user log in inside the headless browser every session.
  2. You’re paying the multi-modal LLM tax. Screenshots + a vision-capable model means every agent step costs ~10× a text-only step, and latency doubles.
  3. You need infra. Something has to run the headless browser — a container, a local process, or a paid browser-cloud service like Browserbase or Steel.

Simon (the maintainer, simon_luv_pho) laid this out cleanly in his Show HN post:

“Most AI agents operate from external clients or server-side programs, effectively leaving web development out of the AI ecosystem. I’m experimenting with an ‘inside-out’ paradigm instead. By dropping the library into a page, you get a client-side agent that interacts natively with the live DOM tree and inherits the user’s active session out of the box, which works perfectly for SPAs.”

PageAgent doesn’t try to be a general “control any website” agent. It’s a library the site owner embeds to give their own app an AI copilot: no auth problem (the agent is the user’s session), no screenshot cost (the DOM is already text), no infra (it’s a <script> tag). The class of things it can’t do — control third-party sites, cross-origin work, agent-as-a-service — is exactly what the outside-in agents were built for. Complementary categories, not competitors.

Five-minute install

The 30-second version is genuinely 30 seconds — this is the demo the maintainer shows in the live demo and the top of the README:

<script
  src="https://cdn.jsdelivr.net/npm/[email protected]/dist/iife/page-agent.demo.js"
  crossorigin="anonymous"
></script>

That’s it — drop that into any static HTML file, load it, and you get a chat bubble powered by Alibaba’s free testing LLM. It can click, scroll, fill forms, and read your page. It’s meant strictly for evaluation (rate-limited, and by using it you agree to their terms), but for a “does this actually work” test it takes less time than reading this section.

For real usage, the npm install path is only slightly more work:

npm install page-agent
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 baseURL is any OpenAI-compatible endpoint, so it works with:

  • Qwen (Alibaba DashScope — obviously optimized for this)
  • OpenAI (GPT-4.1, GPT-5, etc.)
  • Anthropic (via an OpenAI-compat proxy)
  • DeepSeek
  • Google Gemini (via their OpenAI-compat endpoint)
  • Local models — Ollama, LM Studio, vLLM, llama.cpp — anything exposing OpenAI-compat

That last one is the reason self-hosted folks are excited. Because PageAgent only sends text (not screenshots), you can drive it entirely from a local model. A Qwen3.5-Coder-14B on Ollama is enough for most form-fill and click-flow tasks. That’s a real “no API costs” AI copilot in your own web app.

Real use cases from the community

Reading through the Show HN thread, the GitHub discussions, and Reddit responses in r/LocalLLaMA and r/webdev, four use cases keep coming up:

1. SaaS AI copilot (the maintainer’s headline case)

Instead of rewriting your product to embed an LLM backend (auth, tools, rate limits, streaming — the whole tool-use pipeline), you ship a copilot as a script tag. The agent already sees the current page state, is already authenticated as the user, and can act on their behalf. The engineering time compresses from months to an afternoon.

2. Smart form filling for ERP/CRM/admin systems

The “click 20 things to submit one record” problem is a huge productivity drag in enterprise software, and traditional automation (macros, RPA) breaks whenever the UI changes. PageAgent is UI-change-resistant because the LLM re-reads the DOM each step. Enterprise commenters on HN specifically pointed to this as the killer case — one Salesforce admin said “this is the first browser agent I could actually ship to non-technical users.”

3. Accessibility

Voice-command any web app, natural-language screen reader, or one-sentence-to-task interfaces for users who can’t navigate a mouse-driven UI. The DOM-native approach works with existing accessibility trees (aria-*, roles) instead of visually parsing UI.

4. MCP-driven external control

The MCP Server (Beta) lets an external MCP client (Claude Desktop, Cursor, Continue, or your own OpenClaw skill) attach to a page and drive PageAgent from outside — external agent, in-page execution. For AI-driven internal tools this is the compelling architecture.

Community reactions and criticism

The Show HN thread was substantive — 76 comments, mostly technical, and the maintainer replied to almost all of them. Recurring critical themes:

“Isn’t this just Browser-use in the browser?” Partially yes — the README credits browser-use directly for DOM code and prompt design. The novel part is the deployment model (in-page, not external) and session inheritance. Simon on HN: “browser-use is an amazing project, we borrowed heavily from their DOM serialization approach. What’s new is treating the page itself as the agent host — that changes auth, cost, and infra in ways that matter.”

Security worries. A natural-language agent with full DOM access is a big trust boundary. If a user types “delete my account,” and the LLM misinterprets, the agent will click it. There’s no confirmation layer by default — the site owner is expected to expose a limited action set, add confirmations, and sanitize what the LLM sees.

Prompt injection via DOM. The most sophisticated concern: if any part of your page is user-generated (comments, product descriptions), a malicious user can embed a prompt-injection payload the LLM will follow when the agent reads the DOM. PageAgent has no built-in defense yet — the maintainer’s note acknowledges it as an active research area.

“Why not just use function calling?” The counter from Simon: the DOM is already the most complete API description your app has. Every button, form, and link is a documented action with visible labels. Replicating that as a tool schema for every LLM request is duplicated work; the DOM is the tool schema.

Honest limitations

Text-only means no visual content. If your UI depends on canvas, images, or CSS-only widgets (drag-and-drop, custom sliders), the agent can’t see or use them. Charts, maps, image galleries — invisible.

LLM latency is the ceiling. Each agent action is one LLM round-trip. Even with a fast model (Qwen3.5-Turbo, GPT-4.1-mini), you’re looking at 1-3 seconds per click for a cloud model, 3-8 seconds for a local one. It’s a copilot pace, not an automation pace. Users notice.

Token cost scales with DOM size. Large React/Vue apps with thousands of DOM nodes send a lot of text on each step. On a complex admin dashboard, one step can be 20-50K input tokens. Multiply by your action count. PageAgent does prune and truncate, but it’s still meaningful — budget accordingly.

No cross-origin without the extension. Anything that requires switching tabs, opening new windows, or reading another site is blocked by browser security unless you install the Chrome extension. That’s a hard architectural boundary, not a bug.

Client-side only — the maintainer’s note is explicit: PageAgent is not for server-side web scraping. If that’s your use case, browser-use or Playwright is the right tool.

No “AI-only” contributions accepted. The CONTRIBUTING guide is explicit that fully-bot-generated PRs will be rejected. Human-in-the-loop only. Interesting policy signal.

PageAgent vs alternatives

ToolRuns whereNeeds headless browserMulti-modal LLMSession inheritanceBest for
PageAgentIn-page (client JS)❌ No❌ No (text only)✅ AutomaticSite-owned AI copilots
Browser-useExternal (Python)✅ YesOptional❌ ManualCross-site automation
Anthropic Computer UseExternal (any)✅ Yes✅ Required❌ ManualDesktop + web tasks
Playwright + LLMExternal✅ YesOptional❌ ManualCI/test automation
Browserbase / SteelExternal (hosted)ManagedOptional❌ ManualAgent-as-a-service
Chrome extensions (Rabbit, etc.)Browser extension❌ NoVaries✅ AutomaticEnd-user tools

The right column tells the story: PageAgent is the only one where the site owner is the integrator and the agent is a feature of the site itself. Everything else is agent-of-a-user (or agent-as-a-service). That’s not a spectrum — it’s a different product category.

Setup gotchas

Three things tripped up early adopters (based on the GitHub issues over the past two weeks):

1. CSP headers block the CDN. If your site has a strict Content-Security-Policy, the jsDelivr script won’t load. Fix: npm install page-agent and bundle it, or add cdn.jsdelivr.net to your script-src.

2. Model choice matters more than you think. The library works with any OpenAI-compatible model, but small local models (7B and below) get confused on complex DOMs. The maintainer recommends Qwen3.5-Plus, GPT-4.1, Claude 3.5 Sonnet, or DeepSeek-V3.5 as the “no headaches” tier. Qwen3.5-Coder-14B is the smallest local model that reliably works.

3. dashscope.aliyuncs.com is slow from outside China. Latency to the default endpoint is 500ms+ per token. Use dashscope-intl.aliyuncs.com or route to a different model.

Should you use it?

Yes if you’re building a SaaS product and want to ship an AI copilot without rebuilding your backend. This is the fastest path I’ve seen from “we should add AI” to “we have AI.” A working prototype in an afternoon is realistic.

Yes if you have internal admin tools (ERP, CRM, ops dashboards) and want power users to control them with natural language. The DOM-native, no-vision-needed approach is a huge win for latency and cost, and the DOM-change resilience beats every RPA product you’ve evaluated.

Yes if you’re prototyping agent architectures. The MCP server + Chrome extension combo is a genuinely new pattern, and it’s the cleanest example of the “inside-out agent” idea in production.

No if you need to automate third-party sites you don’t own. That’s browser-use / Playwright / Browserbase territory.

No if your UI is heavily visual (canvas apps, image editors, custom-drawn widgets). PageAgent literally cannot see those.

Not yet if your app has any user-generated content in the DOM and you need agent operations to be trustworthy. Wait for the prompt-injection story to mature, or invest in aggressive DOM sanitization at the agent boundary.

The 26K stars are earned. This is the first agent library that treats the browser as a host rather than a target, and that framing unlocks real deployment paths that outside-in agents can’t match. Combined with the MCP escape hatch (so external agents can still drive it), it’s the strongest bet in the “AI copilot for your web app” category right now.

FAQ

Is PageAgent free? Yes. The library is MIT-licensed and free forever. You pay only for whatever LLM you use — which can be $0 if you run a local model via Ollama. The demo LLM Alibaba provides is free for evaluation only.

Does PageAgent work with React / Vue / Angular / Svelte? Yes, all of them. PageAgent reads the live DOM, so it doesn’t care about the framework that rendered it. It works especially well with SPAs because it inherits the user’s session and page state automatically.

Can PageAgent replace Browser-use or Playwright? No — different tool for a different job. Browser-use and Playwright control browsers from outside and are the right choice for cross-site automation, scraping, testing, and any workflow that spans multiple websites. PageAgent lives inside one site and is the right choice when that site is one you own.

Is my LLM API key exposed to end users? Yes — that’s a real concern for client-side deployments. Options: (1) proxy LLM calls through your backend and pass a short-lived session token to PageAgent; (2) use the MCP server mode so the API key lives with the external agent client; (3) restrict the API key to your domain via your LLM provider’s origin controls (OpenAI and Anthropic both support this).

Does PageAgent send my page content to the LLM? Yes — a serialized version of the visible DOM is sent to the LLM on each agent step. If your page contains sensitive user data (PII, financial info, medical records), you need to think carefully about your LLM provider’s data policy, or use a local model so nothing leaves the browser.

Can I use PageAgent with Claude or GPT? Yes. Anything with an OpenAI-compatible endpoint works — direct OpenAI/Anthropic/Google endpoints, LiteLLM proxies, or self-hosted gateways. The README ships with a Qwen example because Alibaba built it, but the model config is a one-line change.

Sources