A friend who runs a logistics SaaS called me last week with a selection problem. His customers key in dozens of waybills a day: pick a shipper, choose a region, set a date range, confirm. Fifteen clicks for something that should take one sentence. He wanted a box at the top of the page where someone types “export last month’s freight bills for East China” and the interface moves on its own.
He found two repositories on GitHub, both around thirty thousand stars, both promising to let an AI operate a web page. One is page-agent, from Alibaba. The other is OpenCLI, built by an individual developer. He installed both in an afternoon and came back the next day saying the hard part wasn’t installation. It was that the two projects give opposite answers to a simple question: where does the AI actually live?
That sounds abstract until you try to ship something. It decides whether the next three months go into product logic or into fighting a browser.
One lives inside the page, one stands outside it
page-agent’s answer is direct. The AI lives in the page.
You add one script tag and the page grows its own agent. No browser extension, no Python, no separate headless browser. It reads the DOM from inside, turns buttons, inputs and links into text descriptions, and hands them to a language model that decides what to click next. Because it works from text rather than screenshots, it doesn’t need a multimodal model or screen-recording permissions.
The call looks almost too simple for infrastructure:
“`javascript
const agent = new PageAgent({
model: ‘qwen3.5-plus’,
baseURL: ‘https://dashscope.aliyuncs.com/compatible-mode/v1’,
apiKey: ‘***’,
language: ‘en-US’
})
await agent.execute(‘Click the login button’)
“`
You bring your own model. Mainstream providers work, and locally deployed models are supported too. The project is written in TypeScript under the MIT license, created in September 2025, and currently sits at roughly 29,492 stars, 2,834 forks and 112 open issues.
OpenCLI takes the other road. The page has no idea it is being operated. The AI stays outside and drives the Chrome you are already logged into, through a command line.
Setup goes like this: install @jackwener/opencli globally through npm (Node.js 20.18.1 or newer), or install the OpenCLIApp desktop build. Then add a Browser Bridge extension to Chrome. A small local daemon starts when needed and connects the two sides. Run opencli doctor and it tells you which link in the chain is broken.
It attaches to your existing browser profile. That detail matters more than it sounds. For sites that require a login, you don’t rebuild cookie jars, re-scan QR codes or solve captchas. Whatever state the browser is in is the state the command sees.
Commands and conversation are different interfaces
OpenCLI has three layers, and the separation is clean.
At the top are built-in adapters. Bilibili, Zhihu, Xiaohongshu, Reddit, Hacker News and Twitter/X already have commands; a single opencli hackernews top returns data. In the middle are browser primitives: open, click, fill, extract, inspect, screenshot, network, state. An agent can combine them against any site. At the bottom is adapter authoring. adapter init, adapter check and adapter test take you from first reconnaissance to working code, and a finished adapter can ship as a plugin installable from GitHub or npm.
The piece worth studying is the command contract. Every command returns JSON by default. Success is {ok: true, data: ...}. Failure is {ok: false, error: {code, message, hint}} with a non-zero exit code, and logs go to stderr.
That looks like formatting discipline. It is really a design for automation. A script reading the output knows from the code whether to retry or stop, and from the hint whether the session expired or the page changed. A tool that answers in free-form prose leaves the caller guessing.
The project is JavaScript under Apache-2.0, created in March 2026, at roughly 30,412 stars, 3,045 forks and 265 open issues. It covers more ground than page-agent, and it carries more open work. Those two facts belong together.
The same job, two ways
Take a concrete task: pull every order number out of yesterday’s unread customer emails and put them in a spreadsheet.
With page-agent, you open the mailbox, create an agent in the console, and describe the job. It reads the page, works out which block is the message list, which rows are unread, and which string of digits in the body looks like an order number, then opens each one, copies, and assembles. If the page structure shifts, its next attempt shifts with it. On a good run it finishes in under a minute. On a deeply nested page it slows down, and it may wander into the spam folder before finding its way back.
With OpenCLI, if that mailbox has an adapter, one command ends the job. The output is stable JSON with the same field names every time, ready to pipe into the next step. Without an adapter, you write a short script with the browser primitives: open the list, grab the rows, filter for unread, enter each message, pull the body, extract the pattern. The first version costs you an afternoon. After that it runs on a schedule, and when something breaks the exit code tells you which step died.
That is the trade. One approach hands judgment to a model at runtime. The other writes the judgment down as code ahead of time. The first starts faster. The second runs longer.
What thirty thousand stars does not tell you
Both projects are young. page-agent was created in September 2025, OpenCLI in March 2026, and both had code pushed on October 17, 2026. Neither is abandoned.
Their maintenance shapes differ. page-agent comes out of Alibaba with a documentation site, a live demo, CI, and a Hacker News thread linked from the README. Its scope is narrow and its issues cluster accordingly; 112 open issues is modest for a project this size. OpenCLI grew from an individual effort and spread wide: adapters, browser primitives, a plugin system, a desktop app, skills for coding agents. Every one of those surfaces needs upkeep, which explains the 265 open issues. Anyone adopting it should know they depend on a set of interfaces that is still moving quickly.
Licensing gets skipped in most comparisons and matters in company procurement. page-agent is MIT; OpenCLI is Apache-2.0. Both allow commercial use and modification. The difference is the patent clause: Apache-2.0 includes an explicit patent grant, MIT does not. For teams with a legal review step, that can weigh more than a star count.
Here is what the two projects look like side by side.
| page-agent | OpenCLI | |
|---|---|---|
| Form | In-page JavaScript library | CLI + browser extension + local daemon |
| Setup | One script tag or npm | Global npm or desktop app, plus extension |
| Where the AI runs | Inside the page | Outside, driving logged-in Chrome |
| Model required | Yes, one inference per action | No, for built-in adapters |
| Determinism | Probabilistic; runs can differ | Fixed commands with a JSON contract |
| Cross-tab / cross-site | Optional extension | Native |
| License | MIT | Apache-2.0 |
| Community | ~29,492 stars, 112 issues | ~30,412 stars, 265 issues |
| Typical fit | Embedded copilots, forms, accessibility | Batch jobs, scraping, agent tooling |
A table shows shape, not feel. The feel comes from where the uncertainty lands.
Where the uncertainty goes
page-agent’s flexibility comes from re-reading the page every time. You say “mark the unshipped orders as urgent” and it finds the table, the filter, the button, and gets through. Add a modal the next day and it may route around the modal or click the wrong thing. That variance is not a bug in the implementation; it is a property of the approach. What you can do is make the page easier to read. Adding aria-labels to buttons and semantic names to form fields, habits that felt dated a few years ago, pay off again here.
OpenCLI’s stability comes from adapters written in advance. The same command behaves the same way on the hundredth run and returns the same structure. The cost is that an unadapted site needs either primitive-by-primitive scripting or a purpose-built adapter. The first stays flexible but depends on your own logic. The second trades upfront effort for long-term consistency.
Failures look different too. When page-agent fails, it usually misunderstood something, so you revise the prompt or the page semantics. When OpenCLI fails, a selector usually broke after a redesign, and the error points at the step that died. Fix the adapter and move on.
Cost splits the same way. page-agent spends a model call per interaction, so heavy users generate a token bill and latency that stack on every click. OpenCLI’s built-in adapters spend almost nothing on inference; the cost sits in development and maintenance instead.
The real question is who carries the complexity
Back to my friend. He needs a feature for his customers, running in their browsers against his own admin panel, where one sentence files a waybill. page-agent fits. The project says plainly that it is built for client-side web enhancement, not server-side automation. One script inside the product, with permissions, sessions and page state all on the user’s side, keeps the boundary clean.
The opposite case is just as common. Every morning you pull data from five dashboards, merge it, deduplicate, push it to a sheet. Or you are building your own agent and need a dependable set of hands for the web. OpenCLI fits better. It was designed for batch work and for agents that need tools, especially on pages that require a session, where reusing a logged-in Chrome beats maintaining a separate authentication path.
You can run both. page-agent ships an MCP server in beta for outside agents to drive the browser, and OpenCLI ships skills for Claude Code and Cursor. One handles the experience inside the product; the other handles the batch work behind it.
If I had to reduce the decision to one question, it would be this: do you want the AI inside the page or outside it? Inside points to page-agent, which is light, embeds deep, and grows with the product. Outside points to OpenCLI, which brings commands, a contract, and something you can orchestrate.
Two projects crossing thirty thousand stars at the same moment is not a coincidence. Model capability has reached the point where “let the AI click through the page” is an engineering choice rather than a demo. The first step in that choice is not comparing feature grids. It is deciding who should carry the complexity.
Sources: OpenCLI, page-agent.
Related reading
- Tracecat Alternatives: Best Open Source Security Automation Platforms 2026
- n8n vs Activepieces: Choosing an Open-Source Workflow Automation Tool for Self-Hosted Teams
- Plausible vs Umami vs Fathom: Choosing a Privacy-First Web Analytics Tool
Stay updated with our latest AI insights
