Hakaru Lab | Published: 2026-09-03 | Review
Who this is for: Practitioners in small teams or individual developers who want AI agents to read web pages, and those gathering information to compare such tools. This is suitable for those who want to reduce the preprocessing required to pass the main text of heavy pages bloated with tags and decorative scripts to AI. This is not suitable for those who want to strictly read tabular data or want to know the exact impact on task time reduction or costs—this article is limited to the hands-on verification of the input size (token count) to AI and does not verify the latter. "Being able to try for free" is different from "achieving results upon implementation," and this article does not guarantee the latter.
Key points (3 lines)
・We measured the token counts for "Opera Browser CLI," which compresses web pages for AI agents, using three output streams: raw HTML, default output, and `--full` output; we found the reduction rate remained at 10.5% for light pages, while for heavy pages we confirmed an 81.3–94.9% reduction in tokens when using `--full`. Concurrently, we confirmed that using the default settings with a 12,000-character limit may result in the main text being truncated.
・This provides material for practitioners in small teams and individual developers who frequently have AI agents read web pages to decide whether to use the default output or the `--full` option. It is not suitable for strictly reading tabular data or for compressing pages that are already lightweight.
・The results are empirical values (N=1 for each condition) across four pages selected by our lab (one article from our own site and three heavy pages from GitHub, note.com, and Rewardful), and the comparison basis differs from the provider's published figures (66% and 80%). Reviewed on August 30, 2026, targeting `opera-browser-cli` 0.1.49.
Basis of this review
・Reviewed on: 2026-08-30
・Conflicts of interest: No advertising or affiliate links (not participating in the Opera affiliate program)
This article is the first in our lab's research review series based on hands-on verification. We are not currently participating in Opera's affiliate program, and there are no advertising or affiliate links in the text.
As it becomes more common to have AI agents conduct web research, feeding the page's HTML as-is tends to bloat the context size passed to the AI. If the passed volume expands, critical information may be buried and overlooked. "Opera Browser CLI," distributed by Opera, is a tool that returns compressed content when an AI agent retrieves a page via a browser. Used well, it has the potential to significantly reduce the page size passed to the AI; however, there is a caveat that using the default settings may result in passing partially truncated text. Our lab verified both the effectiveness and the caveats by directly measuring the token counts. Note that this article measures a proxy metric for the input size passed to the AI and does not measure actual usage fees, overall task costs, or task success rates.
First, let's clarify the terminology.
Opera Browser CLI is a command-line tool officially distributed via npm (a Node.js package distribution service). With a single command like `open` (open a page) or `snapshot` (retrieve the current page state), it returns page information compressed into an AI-readable format via a headless browser. While the basic browsing and extraction commands appeared designed to run without the Opera Neon app, higher-level AI features like `invoke-do` and `research` assume the presence of the Opera Neon app and require a sign-in, which we left unverified this time.
Before discussing the effectiveness of Opera Browser CLI in isolation, let's map out its position relative to major tools used for similar purposes. The following is a structural comparison based on the official information for each tool, not hands-on verification.
| Tool | Primary purpose | Execution location & data path | Cost | Suitable use case | Reason for non-selection |
|---|---|---|---|---|---|
| Opera Browser CLI (GitHub) | Page retrieval and compressed output for AI | Directly operates a local headless browser (reuses existing Chrome). Does not send retrieved pages to external servers | Basic commands are free. Only higher-level AI features of the Opera Neon app require a paid plan and sign-in | When you want to operate an existing local browser and receive compressed main text as-is | (Target of this selection) |
| Jina Reader (GitHub) | Markdown conversion of a single URL | Cloud API (sends target URL to `r.jina.ai`) | Free tier + pay-as-you-go, rate-limited | One-off retrieval from curl, etc., and quick Markdown conversion | Sending to an external cloud is assumed rather than being local-only, and continuous operation is not the main focus |
| Firecrawl (Official Document) | Scrape/crawl/structured extraction | Cloud API (self-hosting also optional), retrieves target site externally | Pay-as-you-go (free tier available) | Crawling entire sites or extracting structured data | Scope is too broad for single-page compression verification, and often assumes a cloud pathway |
| Cloudflare Browser Run (Official Document) | Browser execution platform using remote Chrome | Remote browser on Cloudflare Workers (executed at the edge) | Pay-as-you-go for Workers | Integration into proprietary platforms requiring highly parallel, remote execution | Requires separate Worker implementation and cannot be simply compared as a local compression CLI |
| Playwright CLI / MCP (Official Document) | Stateful continuous browser operation and automated testing | Directly operates local (or CI) headless browser | OSS / Free | When connecting multi-step operations like clicks and form inputs to an AI agent | Compressed output of the main text itself is not the primary purpose, thus excluded from our hands-on verification comparison this time |
The table above is a structural comparison based on public information (confirmed on August 31, 2026). Hands-on verification comparisons will be covered in a separate article.
We chose Opera Browser CLI to measure the hypothesis that outputs can be reduced while operating an existing local browser. It does not claim overall superiority over other tools.
Opera's official resource page displays the following test results (Source):
These 66% and 80% figures are not a range of numbers spanning the same scale. The former compares against "uncompressed raw output," while the latter compares against "standard retrieval methods via MCP," making them two distinct values against different baselines. Therefore, expressing them as a "66–80% range" would be inaccurate; this article treats these two values distinctly.
The testing conditions consisted of 7 browser tasks adopted from the `bench-browser` suite based on AXI (Agent eXperience Interface, a CLI design principle for AI). Each condition involved 7 tasks × 5 repetitions = 35 trials, conducted across 4 conditions including `opera-compact`, `opera-raw`, and `mcp-raw`, totaling 140 trials (Technical documentation). The provider's page itself explicitly states that it is a test using "a single model on 7 fairly restricted tasks," noting that the targets were primarily document-centric pages like GitHub, MDN, and Wikipedia.
Regarding basic functionality, an announcement on August 14, 2026, indicated that the free Opera Neon plan and CLI connectivity are available without a subscription (Announcement). The structure remains such that only Neon's proprietary AI features, like autonomous browsing, require a paid plan and sign-in.
Since the provider's tests were limited to document-centric pages, our lab broadened the scope and performed hands-on verification on four pages likely to be read by AI in practical scenarios.
We compared the following three output streams:
Important note (clarification for expected reader questions): The figures in this article are machine counts of fixed command outputs. The model or effort of the execution agent is not a factor influencing the numbers themselves, but merely a record (provenance information) indicating who performed the task. What matters for reproducibility are the commands, target URLs, and counting methodology.
Undisclosed items (redacted for security reasons, not because a problem occurred): Internal save paths and authentication credentials are redacted in this article, but this does not affect the measurement results or reproducibility.
Initially, we compared byte counts (`wc -c`), but since the actual processing load on AI is determined by token counts rather than byte counts, we re-measured the actual token counts. For token conversion, we used the `o200k_base` encoding from tiktoken (OpenAI's official Python tokenizer library), which is the vocabulary table used by the GPT-4o family (see also the explanation on the limits of token counting). Please note that we did not directly measure the actual consumed tokens in Claude; this measurement is a proxy metric based on the `o200k_base` conversion and does not perfectly align with the actual token counts in Claude. We adopted this converter as there were no other equivalent public reference points available.
For all four pages, we sequentially retrieved each condition ("Raw HTML -> Default output -> `--full` output") once in the same session, saved each file, and then machine-counted the byte and token counts using `tiktoken`. Google Chrome was already installed in the execution environment, and we launched it headlessly by reusing that existing binary. We did not verify the behavior of new downloads in environments devoid of Chromium-based browsers. The retrieved files for raw HTML, default output, and `--full` output are all saved within our lab and can be cross-referenced later. The "Readability of main text" in the table below was determined by visually checking whether the main headings and body sections from the raw HTML were present in each output.
Note that this measurement is not an independent replication of the 66% and 80% token reduction rates presented by the provider. The provider's test is a comparative experiment under identical tasks and models, whereas our lab's measurement is a hands-on verification of output volume targeting four actual web pages, meaning the comparison conditions themselves differ.
| Target page | Raw HTML (bytes / tokens) | Default output (bytes / tokens, byte reduction / token reduction) | `--full` output (bytes / tokens, byte reduction / token reduction) | Readability of main text |
|---|---|---|---|---|
| Own site article (lightweight/static) | 17,352 / 4,922 | 15,817 / 4,406 (8.8% reduction / 10.5% reduction) | 15,817 / 4,406 (Same as default. No truncation) | Readable without issues |
| GitHub README (apify/mcpc) | 732,874 / 277,950 | 11,596 / 3,574 (98.4% reduction / 98.7% reduction) | 139,562 / 39,089 (81.0% reduction / 85.9% reduction) | Default truncates text; readable with `--full` |
| note.com article | 356,655 / 116,638 | 17,122 / 5,350 (95.2% reduction / 95.4% reduction) | 19,149 / 5,955 (94.6% reduction / 94.9% reduction) | Readable with default |
| Rewardful report | 141,341 / 51,931 | 12,313 / 2,970 (91.3% reduction / 94.3% reduction) | 40,722 / 9,726 (71.2% reduction / 81.3% reduction) | Readable with default, but tables are serialized |
Measurement date & time: August 30, 2026, around 23:50–23:58 (JST). Token counts are converted using the `tiktoken` `o200k_base` encoding.
For inherently light pages like our own site, the token-based reduction rate remained at 10.5% (8.8% based on bytes). This was because the target page only had 858 characters of inline CSS and 255 characters of JS, meaning it had virtually no "fat" to trim. Conversely, across the three pages from GitHub, note.com, and Rewardful measured this time, we observed token-based reductions of 81.3–94.9% (71.2–94.6% based on bytes) using the `--full` baseline. In all 8 patterns measured this time (4 pages × default/`--full`), the token-based reduction rate equaled or exceeded the byte-based rate. We hypothesize this trend occurs because raw HTML, laden with tags and attributes, has a relatively higher token count per byte, whereas the human-readable text returned by Opera lowers the token density; however, this causal relationship was not individually verified this time. What is certain from this observation is that viewing only byte counts tended to understate the actual effectiveness.
What we confirmed here are strictly empirical output values from four pages selected by our lab. They cannot be directly compared side-by-side with the provider's 66% and 80% figures, which rely on different baselines.
What required the most caution in this measurement was not the reduction rate itself, but the "default output character limit."
The default output of Opera Browser CLI has a 12,000-character limit, and for pages exceeding this, the main text is truncated mid-way. If you retrieve the GitHub README page using the default, looking purely at the token count shows a remarkably large 98.7% reduction, dropping from 277,950 to 3,574. However, confirming the actual contents revealed that it only successfully retrieved up to the navigation and file list, leaving the Motivation and Usage sections—the core of the README body—missing.
The tool itself appends a note stating `(truncated, N chars total)` to the output when this truncation occurs. The danger lies not in the tool failing to notify, but in the AI agent potentially overlooking or ignoring this note and proceeding with the task under the assumption that "the page was read." Re-retrieving with `--full` solved the truncation caused by the limit; for the GitHub example, it yielded 39,089 tokens—an 85.9% reduction—resulting in readable content for the Motivation and Usage sections we targeted for confirmation. In the note.com and Rewardful examples, the outline of the main text was readable even with the default output, and the truncation was confined to peripheral parts like embedded videos and related links.
The practical countermeasure derived from this is clear. When seeing extremely high reduction rates, it is crucial to first verify what was trimmed. You can prevent this oversight by integrating an operational rule: if the output displays `(truncated, N chars total)`, automatically re-retrieve it with `--full`.
What was interesting about this observation was where the truncation occurred. In the note.com and Rewardful examples, the outline of the main text remained readable even in the default output, with trims isolated to peripheral areas like embedded videos and related links. This suggests a hypothesis: in environments where AI agents read web pages, structures that rely solely on videos or decorative embeds for information are less robust. Instead, a structure centered around text—where summaries, figures, and captions are co-written as text within the body—might be less susceptible to truncation and more easily picked up. However, this is strictly a hypothesis derived from observing these four pages, and we have not measured its effectiveness in AI search in general.
Uses we felt are suitable
Uses we felt are not suitable, or require caution
Adoption (Our lab's decision)
Starting September 1, 2026, our lab will adopt Opera Browser CLI (0.1.x) for a limited trial as a pre-processing step for passing the main text of heavy public documents to AI during our crawling and research tasks. The condition is to automatically re-retrieve with `--full` if the truncation note `(truncated, N chars total)` is detected. We will not use it for applications requiring strict table reading, for already lightweight pages, or for Opera Neon's paid features. We will re-evaluate it in four weeks based on the hands-on verification logs from this period.
Recommendation for readers (As of August 31, 2026)
The target audience is practitioners in small teams and individual developers who frequently have AI agents read the main text of heavy web pages like GitHub READMEs or note.com articles. We believe it is worth trying for this readership, provided they incorporate the condition confirmed by our lab: coupling it with an operational rule to re-retrieve with `--full` upon detecting `(truncated, N chars total)`. However, we cannot yet recommend it for applications needing strict reading of tabular data or for the purpose of compressing already lightweight pages. This recommendation is based on our lab's hands-on verification as of August 31, 2026, and the premises may change due to tool specification changes or version updates.