What happened
Perzian has published Mantis, described in its GitHub repository as “a lean browser interface for AI agents.” The project is available under the MIT license and is distributed as the mantis-browser npm package. The repository identifies the current release as v0.1.10, dated October 27, 2026, and characterizes the software as a small v0.1.x beta.
Mantis is intended to run as a Model Context Protocol server with Claude Code, Codex, Cursor, or a custom agent. Its central design choice is to represent a page as short numbered text rather than send screenshots or expose the whole accessibility tree. An agent can read a page, refer to numbered controls, and receive only the content that changed after an action. The project says it uses Chromium. It also provides a command for reading a URL outside an agent and installation commands for Claude-oriented setup; separate setup guidance is supplied for Windows, Linux servers, and other agents.
The repository frames this representation as an efficiency play for browser automation. In the published long-task comparison against the accessibility-tree interface used by Playwright MCP, Mantis reports 35 correct runs out of 42 for gpt-6-luna versus 34 out of 42 for the tree, and 40 out of 42 for both Mantis and the tree with claude-haiku-5-5. Median input tokens were reported as 244,000 versus 345,000 for Luna and 268,000 versus 506,000 for Haiku. Median tool calls were 17 versus 24 for Luna and 19 versus 30 for Haiku; median end-to-end times were 42 versus 66 seconds and 54 versus 85 seconds respectively. The project summarizes that as 29–47% fewer input tokens, 29–37% fewer calls, and roughly a third less time on long tasks.
For 30 short tasks, with 90 runs per condition, the repository reports equal or better correctness for Mantis compared with the accessibility tree and claims 35–57% fewer median input tokens. The screenshot comparison is less uniformly favorable: the repository says screenshots scored two runs higher for Luna but took more tokens and time, while screenshots used fewer tokens for Haiku. The stated scope is read, navigation, and form-fill work on public sites. Canvas, WebGL, maps, and drawing applications are not supported for coordinate interaction; login and bot walls require an ask_human step with a display.
The benchmark is published by the project itself. The repository further notes that short-task timing compares a newer Mantis build with earlier tree and screenshot runs, that two long iframe or tab tasks could not be keyed and were excluded from long-task counts, and that some tasks were swapped after results. Its final-page scoring uses deterministic answer keys. Those qualifications make the numbers useful as an implementation hypothesis, not as an independent purchasing-grade evaluation.
What the archive adds
This is a new fact on a known browser-agent and token-efficiency story. Improved token efficiency for longer agent runs observed Cursor’s reported 7% token-cost reduction and argued that harness design increasingly shapes agent economics. Mantis makes a narrower version of that proposition: page representation and incremental updates may change browser-agent context costs without changing the model.
Trend signal
Mantis supports Harness architecture outlives model choice. The same task was tested with two different models, while the claimed savings come from a layer between model and website: how the harness serializes the page, identifies controls, and returns state changes. The evidence is preliminary and self-reported, but the product boundary being tested is clearly the interface rather than a new model.
Why it matters
Browser work is unusually prone to context waste. A web page can contain a large accessibility tree, repeated navigation, dynamic content, and controls that an agent must repeatedly rediscover. If a tool can expose only actionable text and return a diff after each operation, a model may spend less of its context window rereading a mostly unchanged page. That can matter to teams paying for long agent runs, operating under token limits, or trying to lower the latency of routine research and form workflows.
The important practical distinction is not that Mantis has established a new benchmark leader. It has not: the available evidence is a project-authored test set, limited to public sites and two models. The useful signal is that browser representation is an adjustable engineering variable. Teams currently treating browser automation as a fixed Playwright-plus-model stack can compare representations, call counts, accuracy, retries, and human-intervention rates as separate design choices.
Limits and uncertainty
The repository does not establish that Mantis will deliver the reported savings on authenticated applications, enterprise sites, adversarial pages, or tasks requiring canvas interaction. It does not provide an independent benchmark, and its results cover only gpt-6-luna and claude-haiku-5-5. The project explicitly flags comparability limits in the short-task timing data and exclusions in long-task scoring. Similar final correctness counts also do not reveal differences in failure modes, recovery behavior, security posture, or the operational burden of running the server. Claims about efficiency should therefore be validated on a team’s own sites, policies, and model mix.
Skill to build now
Create a small browser-agent evaluation suite before changing tools. Select five to ten representative tasks that are legal and safe to automate, including navigation, extraction, and a form flow. Run the existing browser interface and Mantis with the same model, session conditions, and completion checks. Record completed-task rate, input tokens, tool calls, wall-clock time, retries, and cases that require a human. Treat CAPTCHA, payment, 2FA, and sensitive authenticated flows as explicit exclusions or supervised paths. This turns a headline token claim into a decision grounded in your workload.
Reader takeaway
Mantis is a compact MCP browser interface that is easy to trial with common coding agents and makes a credible, testable case for diff-based page context. Its published efficiency figures are not independent evidence, but they point builders toward a useful question: how much browser-agent cost is caused by the model, and how much by the interface around it?
Open question
Will the compact text representation retain its claimed efficiency and reliability on authenticated, highly dynamic production applications, where browser agents often encounter the most costly failures?