browser: A Chinese Translation of Lightpanda, the Zig Headless Browser for AI Agents
Lightpanda's own README makes a specific claim: 933 real web pages, fetched over the network on an AWS EC2 m5.large instance, peak memory around 123MB against roughly 2GB for Headless Chrome, execution time around 5s against roughly 46s. Those are the numbers the project publishes, and they are the reason a translation of its documentation is worth talking about at all.
The project is lightpanda-io/browser, 38165 stars, written in Zig, licensed AGPL-3.0. It is not a Chromium fork and not a WebKit patch. It is a new headless browser built from scratch for AI agents and automation workloads.
A Chinese translation of that documentation now exists: yangshun2005/browser-cn. It is new — published today, zero stars. This article is about what is in it and why the translation matters more than it might sound.
What the Chinese repository actually contains
Two distinct layers, and the repository is explicit about the separation:
1. A translated README (README.md), described as a faithful Chinese translation of the original project documentation. The original English README is kept alongside as README_en.md.
2. A "中文快速上手" (Chinese quick start) section at the top, marked as supplementary editorial content that is not part of the original README. Its stated purpose: get you running without reading the whole document first.
That second layer is the interesting one. A pure translation of a README assumes you already know what you want to do with the tool. A quick-start layer assumes you don't — which is the realistic state of most people arriving at a headless browser repository for the first time.
The repository also states its own fallibility: translation inaccuracies are to be reported via Issue or PR. Given the translation date listed as 2026-10-31 and the fast-moving nature of the upstream project, expect drift over time.
The quick start, condensed
The Chinese page lists every install path the upstream README offers. Reproduced here as they appear:
Homebrew:
brew install lightpanda-io/browser/lightpanda
Arch Linux AUR:
yay -S lightpanda-nightly-bin
Linux x86_64 binary:
curl -L -o lightpanda https://github.com/lightpanda-io/browser/releases/download/nightly/lightpanda-x86_64-linux && \
chmod a+x ./lightpanda
macOS aarch64 binary:
curl -L -o lightpanda https://github.com/lightpanda-io/browser/releases/download/nightly/lightpanda-aarch64-macos && \
chmod a+x ./lightpanda
Docker:
docker run -d --name lightpanda -p 127.0.0.1:9222:9222 lightpanda/browser:latest
Then verify the binary runs:
./lightpanda version
Fetch a URL and dump HTML:
./lightpanda fetch --obey-robots --dump html --log-format pretty --log-level info https://demo-browser.lightpanda.io/campfire-commerce/
The --dump flag has other modes worth knowing about, all documented in the translated README: --dump markdown for Markdown output, --dump png > page.png and --dump pdf > page.pdf for text-rendered output, and --dump structured_data for JSON-LD and OpenGraph structured data.
Start the CDP server:
./lightpanda serve --obey-robots --log-format pretty --log-level info --host 127.0.0.1 --port 9222
Then point Puppeteer at browserWSEndpoint: "ws://127.0.0.1:9222". The upstream README includes a full example script; the translation carries it over.
Why a Chinese quick-start layer is not just a nicety
Headless browser setup is a category of task where documentation friction compounds. You are usually doing three things at once: choosing an install method, confirming your platform is supported, and figuring out what the tool's output modes are. Every one of those steps has a failure mode that costs time.
The Chinese page front-loads exactly those failure modes. Three of them are worth calling out because they are the ones people hit.
No native Windows binary. The supported platforms are Linux (x86_64, aarch64) and macOS (aarch64, x86_64). Windows requires WSL2, following the Linux steps. The page notes wsl --install as the entry point. Android/Termux has no native build.
musl distributions break. The Linux release binaries link glibc. On Alpine and other musl-based systems you get cannot execute: required file not found because the glibc dynamic linker is absent. The fix is a glibc base image such as debian:bookworm-slim or ubuntu:24.04, or building from source. This is a genuinely annoying error message — it says nothing about glibc — and having it pre-explained in your first language is a real saving.
Building from source is slow. The Makefile comments note that compiling V8 from source takes more than 10 minutes. make download-v8 pulls a precompiled V8 archive instead. The translated page flags this; the exact build commands are not fully reproduced in the material available.
There is also a network note: installs pull from GitHub Releases, ziglang.org, and Docker Hub, so users on mainland Chinese networks may need mirror sources or download acceleration. That is the kind of sentence that never appears in an upstream README written for a global audience, and it is precisely the kind of sentence that saves an afternoon.
What the translation does not claim
Worth being clear about the boundaries, because the repository is:
- The star count of 38165 refers to the original project. The Chinese repository has zero stars as of writing.
- The benchmark figures (123MB vs ~2GB, 5s vs ~46s) are the upstream project's published results on AWS EC2 m5.large, not independently reproduced by the translator.
- The translation does not state a minimum Zig version, because the upstream README does not list one in its body. The Dockerfile reads minimum_zig_version from build.zig.zon.
- It does not state hardware requirements beyond the benchmark instance type.
- It does not describe what happens if you omit --obey-robots. Every example command includes the flag; the behavior without it is undocumented in the source material.
That last point deserves a moment. Every fetch and serve example carries --obey-robots. If you are crawling at any scale, whether the flag is on by default and what it does when absent is a question you should answer before pointing the tool at a target, not after.
Where this fits
Lightpanda's pitch is narrow and concrete: a browser for agents that does not carry Chromium's memory footprint. The benchmark gap — roughly 16x on memory, roughly 9x on time — is the whole argument. If your crawler runs in a container with a memory limit, or if you are paying per-instance-hour for a fleet of them, that gap is the difference between a viable architecture and an expensive one.
The Chinese translation does not change any of that. What it changes is the number of people who can evaluate the claim quickly. A developer who can read the install matrix, spot the musl incompatibility, and know to use make download-v8 in their first ten minutes is a developer who gets to the actual benchmark question — does this work for my pages — much sooner.
My sample here is one repository published today, so I can't tell you how the translation holds up over time or how responsive the maintainer will be to corrections. The structure is right, though: original preserved as README_en.md, translation clearly labeled, editorial additions clearly separated from translated content. That is the correct way to do this, and it is more than many translation repositories bother with.
If you have been meaning to try Lightpanda and the English README was the thing you kept tabbing away from, the Chinese version is at yangshun2005/browser-cn. The upstream project is at lightpanda-io/browser.
---
*Chinese documentation: yangshun2005/browser-cn*
I'm an independent enterprise AI delivery consultant — private LLM deployment, RAG, agent workflows, AIOps. If your team is stuck somewhere in that stack, my inbox is open.
What Obscura is, the Rust headless browser for AI agents
---
title: What Obscura is, the Rust headless browser for AI agents
published: true
description: Obscura is a headless browser engine written in Rust and released under Apache-2.0. It runs JavaScript on V8, speaks the Chrome DevTools Protocol and
tags: ai, rust, agents, opensource
canonical_url: jacar.es
cover_image: media.jacar.es
---
Obscura landed on GitHub in April 2026 and has collected 24,624 stars in five months. Cloudflare’s engineering team credits it as the starting point for their own agent browser, and the project already advertises a managed version. Here is what it actually does, what the numbers looked like when I ran it on my own machine, and where it genuinely replaces headless Chrome.
Key takeaways
- Obscura is a headless browser engine written in Rust under an Apache-2.0 licence. It runs JavaScript on V8 and speaks the Chrome DevTools Protocol.
- Playwright and Puppeteer connect without a single code change: point connectOverCDP at the port obscura serve opens.
- Its reproducible advantage is memory. In my tests it used about 38 MB per session against 532 MB for headless Chromium on the same page.
- The speed advantage depends on the page: obvious on static HTML, absent on a real site where network latency dominates.
- Since version 0.2.0 (August 2026) it renders and captures without Chromium, but it does not match Chromium yet, and I hit that on the first page I gave it.
What Obscura is and what problem it solves
Obscura is a browser engine with no graphical interface, written from scratch in Rust. It is not a Chromium fork or a WebKit patch. It embeds V8 to run the page’s JavaScript, builds its own DOM, and exposes the Chrome DevTools Protocol so existing automation tools treat it as if it were Chrome. The official documentation defines it this way: "Obscura is an open-source headless browser engine written in Rust. It runs JavaScript via V8, speaks the Chrome DevTools Protocol, and works as a drop-in replacement for headless Chrome with Puppeteer and Playwright".
The problem it attacks is cost, not capability. Headless Chrome automates a page perfectly well, but it was designed for one person looking at one tab.
When a swarm of agents opens thousands of concurrent sessions, every process drags along a compositor, a rendering stack and dozens of subsystems no agent ever touches. You pay for that in gigabytes of memory and in seconds of startup. Obscura’s proposal is to keep only the part that matters for reading data: run the JavaScript, build the DOM, hand it back.
The Cloudflare connection is the strongest signal that the idea holds up. In the Kitesurf announcement, describing their agent browser built on Workers, the team writes: "We got the initial inspiration from obscura, a headless engine written in Rust for AI automation that has ‘no Chrome, no Node.js, no dependencies’". Cloudflare ported Obscura to Workers as a first proof of concept in May 2026 and built the product from there. Kitesurf is still a Cloudflare service in free beta; Obscura is the engine you can download today.
How it works inside
The binary bundles three pieces. The first is V8, the same JavaScript engine Chrome uses, embedded directly in the Rust process. The second is its own implementation of the DOM and the web APIs a modern page needs: fetch, XHR, observers, Shadow DOM, custom elements, WebCrypto and the rest. The third is the CDP server, which translates Puppeteer or Playwright calls into operations on that DOM.
Since version 0.2.0, released on 8 August 2026 with 449 accumulated commits, there is a fourth piece. It is a layout and paint engine also written in Rust, which allows screenshots, screencasting and PDF export without starting Chromium. Version 0.2.1, from 23 August, added dedicated V8 realms for child iframes.
Installing it needs neither Node.js nor Chrome. The project publishes binaries for Linux, macOS and Windows, in variants with and without rendering and with and without stealth mode, plus an official image on Docker Hub with 45,789 pulls.
curl -LO https://github.com/h4ckf0r0day/obscura/releases/latest/download/obscura-aarch64-linux.tar.gz
tar xzf obscura-aarch64-linux.tar.gz
./obscura fetch https://example.com --eval "document.title"
./obscura fetch https://example.com --dump markdown
./obscura serve --port 9222 --stealth
Stealth mode is a separate build variant. According to the project README it randomises the GPU, screen, canvas, audio and battery fingerprint on every session, leaves navigator.webdriver undefined and blocks 3,520 tracking domains. Those are the project’s own figures, not a third party’s.
It also ships an embedded Model Context Protocol server with fourteen browser tools an assistant can call directly. If you have built your own servers before, the complete MCP guide has the context for that protocol.
What happened when I ran it on my own machine
I downloaded the aarch64-linux variant of v0.2.1 and ran it in an ARM64 Linux container on 4 September 2026, measuring wall time and peak resident memory across the process tree. Facing it I put headless Chromium driven by Playwright, on the same URLs and the same network. Three passes per combination.
| Page | Obscura v0.2.1 | Headless Chromium |
| --- | --- | --- |
| example.com | 92 ms, 13 MB | 237 ms, 510 MB |
| news.ycombinator.com | 1,550 ms, 38 MB | 1,430 ms, 532 MB |
The honest reading of those numbers has two halves. The memory advantage is huge and it holds: roughly thirteen times less on the real page.
The speed advantage evaporates as soon as the page stops being a static 500-byte file. On Hacker News, Chromium was even slightly faster, because what dominates the median is the network, not the engine. Dropping --wait to zero changed nothing.
The project’s own benchmark repository reaches the same conclusion with more data. Over a corpus of 98 real public pages, Obscura rendered 94 and headless Chrome rendered 85. Median memory was 64.2 MB against 201.2 MB, but median latency was 5.2 seconds against Chrome’s 2.1 seconds. That is how the cards actually fall.
Playwright compatibility turned out to be literal. I started obscura serve --port 9333 and connected with chromium.connectOverCDP('ws://127.0.0.1:9333') without touching anything else: navigation, page.title() and page.evaluate() all answered in 100 milliseconds.
Then I tried the new rendering path on the front page of a Tailwind-based WordPress site. The capture took 587 milliseconds and produced a valid PNG, but with clear differences against Chromium.
!Side-by-side comparison of the same page rendered by Obscura and by headless Chromium, where Obscura paints tooltips visible that the CSS declares with zero opacity.
The most concrete difference: the theme declares its navigation-bar labels as ::after pseudo-elements with content: attr(data-tooltip) and opacity: 0, visible only on hover. Obscura painted the pseudo-element but ignored the opacity, so the header came out covered in overlapping labels. The search panel also rendered open and the cookie notice was missing. This is exactly the class of gap the project declares in its release notes, found on the first page I fed it.
How it compares with headless Chrome and Lightpanda
There are four families of solutions and it is worth keeping them apart, because they solve different things. GitHub figures from 4 September 2026.
| Option | Engine | Licence | Stars | What it solves |
| --- | --- | --- | --- | --- |
| Obscura | Own, in Rust | Apache-2.0 | 24,624 | Memory cost per session |
| Lightpanda | Own, in Zig | AGPL-3.0 | 34,414 | The same, with more history |
| Headless Chrome with Playwright | Chromium | Apache-2.0 | 95,604 | Full rendering fidelity |
| Steel Browser or Browserless | Wrapped Chromium | Apache-2.0 or custom | 7,591 and 13,658 | Running the infrastructure |
Lightpanda is the direct rival: same premise of a new engine, written in Zig, two years older and with more stars. The difference that ends up deciding it is legal rather than technical.
Lightpanda uses AGPL-3.0, which propagates to any service that exposes it over the network. Obscura uses Apache-2.0, which does not. If you plan to embed it in a closed product, that line in the LICENSE file weighs more than any benchmark.
Steel Browser and Browserless do not compete with Obscura: they wrap Chromium with queues, sessions and an API. They solve operations, not cost per session. Browserless is also not open source, it is free only for non-commercial use.
Then there is the agent ecosystem that already drives a browser. If what you want is an agent that browses for you, Browser Use works one layer above; if what you want is clean web data, Firecrawl does the extraction for you. Obscura lives underneath all of them, as an engine replacement.
What it does not do well yet
The rendering path is less than a month old and does not reach Chromium parity. The v0.2.0 notes say so plainly: long-tail CSS, some web APIs, native media playback and GPU compositor effects may still differ. My test confirmed it on the first try. The PDF output is also raster-backed, so the text cannot be selected.
Conformance is not complete either. The benchmark repository publishes an 83.3% subtest pass rate on the Core tier of the Web Platform Tests (318,916 of 382,891) and 60.0% on the full suite. That 60% is not a hidden defect, it is the consequence of deliberately not implementing whole layers of the platform, and the project documents it.
The README figures age. It advertises a 70 MB binary, but the ARM64 build with rendering that I downloaded takes 100 MB unpacked, plus another 92 MB for the worker process. The Docker image went from 53.2 MB in 0.1.11 to 87.1 MB in 0.2.1. None of this is serious, but measure on your own platform before quoting the table.
The project is young and highly concentrated. It was created on 13 April 2026 and, of the twenty contributors the GitHub API lists, a single one accounts for 733 commits. Stealth mode reduces automation signals, but it does not prevent blocks based on IP reputation or behaviour patterns. And Obscura Cloud, the managed version, is still a waiting list rather than a product you can buy.
When it is worth it and when it is not
It is worth it when your bill is a memory bill. If you run hundreds or thousands of concurrent sessions extracting data, going from 500 MB to 38 MB per session changes machine sizing in a way no code optimisation can match. It is also worth it when you want to package a browser inside a small image with no Node.js and no Chrome, or when you need genuinely clean, reproducible sessions.
It is not worth it if your workload is a few dozen pages and already works. The per-page latency gain on real sites is zero or negative, and you would be swapping a mature engine for a five-month-old one. It is also not worth it if you depend on visual fidelity: visual regression testing, client-facing captures, anything where the pixel matters, all of that remains Chromium territory. And if your problem is getting blocked, the engine is not the lever; proxies and request pacing are.
My practical advice: run it alongside. Start obscura serve next to your current headless Chrome, point a percentage of traffic at it with connectOverCDP and compare results on your own target pages for a week. Migration costs one environment variable, so the experiment is cheap. If you are curious about the language underneath, Rust for backend work with Axum and Tokio has the context for why this class of project gets written that way.
Frequently asked questions
Does Obscura replace Playwright or Puppeteer?
No, it complements them. Playwright and Puppeteer are the libraries you write the automation script in; Obscura is the browser that script drives. You keep the same Playwright code and only change the connection target, from a Chromium launched by the library to an obscura serve listening over CDP.
Can I use Obscura in a closed commercial product?
Yes. The licence is Apache-2.0, which permits commercial use and integration into proprietary software with no obligation to publish your code. That is the most practical difference against Lightpanda, which uses AGPL-3.0 and requires releasing the source of any networked service that embeds it.
Is Obscura good enough for reliable screenshots?
Only with caution. Since v0.2.0 it does screenshots, screencasting and PDF without Chromium, and they work. But the paint engine is new and the project itself warns that it does not match Chromium: in my test it ignored an opacity rule on a pseudo-element and rendered the header wrong. For visual regression testing, stay on Chromium.
Conclusion
Obscura solves a specific problem and solves it well: the memory cost of giving every agent its own browser. Thirteen times less RAM per session is a figure that changes architecture decisions, and CDP compatibility makes trying it almost free. What you should not expect is the speed gain the home page advertises, because it does not appear on real pages. Nor rendering fidelity equal to Chromium, because the project itself warns that it is not there yet.
That Cloudflare started from this code to build Kitesurf says a good deal about the quality of the idea. Five months of life says a good deal about the risk. Measure it against your own pages before moving anything.
Sources: [1] Obscura, official GitHub repository, [2] Obscura, published release notes, [3] obscura-benchmark, measured conformance and performance, [4] Official Obscura documentation, [5] Cloudflare, introducing Kitesurf, [6] Official Obscura image on Docker Hub, [7] Official Obscura website, [8] wpt.fyi, Web Platform Test results by engine.
Spanish version: Qué es Obscura, el navegador headless en Rust para agentes de IA.
---
Originally published on jacar.es.
Mentions
我先说一个暴论啊！ 未来 AI Agent 可能真的不需要传统浏览器了。 今天在 GitHub 看到 Lightpanda，一个专门为 AI 自动化设计的无头浏览器。 作者自己用 Zig 从头开发，重点就是降低资源消耗、提高速度。 这个方向挺有意思！ lightpanda-io/browser
browser — Lightpanda: the headless browser designed for AI and automation Link: lightpanda-io/browser #OpenSource #GitHub #DevTools
Headless Chrome eats 2GB just to scrape 100 pages. Lightpanda is a from-scratch Zig browser for AI agents — CDP/Puppeteer-compatible, ~16× less RAM, ~9× faster. 38.7k stars. lightpanda-io/browser #GitHub #OpenSource t.co
browser: A Chinese Translation of Lightpanda, the Zig Headless Browser for AI Agents Lightpanda's own README makes a specific claim: 933 real web pages, fetched over the network on an AWS EC2 m5.large instance, peak memory around 123MB against roughly 2GB for Headless Chrome, execution time around 5s against roughly 46s. Those are the numbers the project publishes, and they are the reason a translation of its documentation is worth talking about at all. The project is lightpanda-io/browser, 38165 stars, written in Zig, licensed AGPL-3.0. It is not a Chromium fork and not a WebKit patch. It is a new headless browser built from scratch for AI agents and automation workloads. A Chinese translation of that documentation now exists: yangshun2005/browser-cn. It is new — published today, zero stars. This article is about what is in it and why the translation matters more than it might sound. What the Chinese repository actually contains Two distinct layers, and the repository is explicit about the separation: 1. A translated README (README.md), described as a faithful Chinese translation of the original project documentation. The original English README is kept alongside as README_en.md. 2. A "中文快速上手" (Chinese quick start) section at the top, marked as supplementary editorial content that is not part of the original README. Its stated purpose: get you running without reading the whole document first. That second layer is the interesting one. A pure translation of a README assumes you already know what you want to do with the tool. A quick-start layer assumes you don't — which is the realistic state of most people arriving at a headless browser repository for the first time. The repository also states its own fallibility: translation inaccuracies are to be reported via Issue or PR. Given the translation date listed as 2026-10-31 and the fast-moving nature of the upstream project, expect drift over time. The quick start, condensed The Chinese page lists every install path the upstream README offers. Reproduced here as they appear: Homebrew: brew install lightpanda-io/browser/lightpanda Arch Linux AUR: yay -S lightpanda-nightly-bin Linux x86_64 binary: curl -L -o lightpanda https://github.com/lightpanda-io/browser/releases/download/nightly/lightpanda-x86_64-linux && \ chmod a+x ./lightpanda macOS aarch64 binary: curl -L -o lightpanda https://github.com/lightpanda-io/browser/releases/download/nightly/lightpanda-aarch64-macos && \ chmod a+x ./lightpanda Docker: docker run -d --name lightpanda -p 127.0.0.1:9222:9222 lightpanda/browser:latest Then verify the binary runs: ./lightpanda version Fetch a URL and dump HTML: ./lightpanda fetch --obey-robots --dump html --log-format pretty --log-level info https://demo-browser.lightpanda.io/campfire-commerce/ The --dump flag has other modes worth knowing about, all documented in the translated README: --dump markdown for Markdown output, --dump png > page.png and --dump pdf > page.pdf for text-rendered output, and --dump structured_data for JSON-LD and OpenGraph structured data. Start the CDP server: ./lightpanda serve --obey-robots --log-format pretty --log-level info --host 127.0.0.1 --port 9222 Then point Puppeteer at browserWSEndpoint: "ws://127.0.0.1:9222". The upstream README includes a full example script; the translation carries it over. Why a Chinese quick-start layer is not just a nicety Headless browser setup is a category of task where documentation friction compounds. You are usually doing three things at once: choosing an install method, confirming your platform is supported, and figuring out what the tool's output modes are. Every one of those steps has a failure mode that costs time. The Chinese page front-loads exactly those failure modes. Three of them are worth calling out because they are the ones people hit. No native Windows binary. The supported platforms are Linux (x86_64, aarch64) and macOS (aarch64, x86_64). Windows requires WSL2, following the Linux steps. The page notes wsl --install as the entry point. Android/Termux has no native build. musl distributions break. The Linux release binaries link glibc. On Alpine and other musl-based systems you get cannot execute: required file not found because the glibc dynamic linker is absent. The fix is a glibc base image such as debian:bookworm-slim or ubuntu:24.04, or building from source. This is a genuinely annoying error message — it says nothing about glibc — and having it pre-explained in your first language is a real saving. Building from source is slow. The Makefile comments note that compiling V8 from source takes more than 10 minutes. make download-v8 pulls a precompiled V8 archive instead. The translated page flags this; the exact build commands are not fully reproduced in the material available. There is also a network note: installs pull from GitHub Releases, ziglang.org, and Docker Hub, so users on mainland Chinese networks may need mirror sources or download acceleration. That is the kind of sentence that never appears in an upstream README written for a global audience, and it is precisely the kind of sentence that saves an afternoon. What the translation does not claim Worth being clear about the boundaries, because the repository is: - The star count of 38165 refers to the original project. The Chinese repository has zero stars as of writing. - The benchmark figures (123MB vs ~2GB, 5s vs ~46s) are the upstream project's published results on AWS EC2 m5.large, not independently reproduced by the translator. - The translation does not state a minimum Zig version, because the upstream README does not list one in its body. The Dockerfile reads minimum_zig_version from build.zig.zon. - It does not state hardware requirements beyond the benchmark instance type. - It does not describe what happens if you omit --obey-robots. Every example command includes the flag; the behavior without it is undocumented in the source material. That last point deserves a moment. Every fetch and serve example carries --obey-robots. If you are crawling at any scale, whether the flag is on by default and what it does when absent is a question you should answer before pointing the tool at a target, not after. Where this fits Lightpanda's pitch is narrow and concrete: a browser for agents that does not carry Chromium's memory footprint. The benchmark gap — roughly 16x on memory, roughly 9x on time — is the whole argument. If your crawler runs in a container with a memory limit, or if you are paying per-instance-hour for a fleet of them, that gap is the difference between a viable architecture and an expensive one. The Chinese translation does not change any of that. What it changes is the number of people who can evaluate the claim quickly. A developer who can read the install matrix, spot the musl incompatibility, and know to use make download-v8 in their first ten minutes is a developer who gets to the actual benchmark question — does this work for my pages — much sooner. My sample here is one repository published today, so I can't tell you how the translation holds up over time or how responsive the maintainer will be to corrections. The structure is right, though: original preserved as README_en.md, translation clearly labeled, editorial additions clearly separated from translated content. That is the correct way to do this, and it is more than many translation repositories bother with. If you have been meaning to try Lightpanda and the English README was the thing you kept tabbing away from, the Chinese version is at yangshun2005/browser-cn. The upstream project is at lightpanda-io/browser. --- *Chinese documentation: yangshun2005/browser-cn* I'm an independent enterprise AI delivery consultant — private LLM deployment, RAG, agent workflows, AIOps. If your team is stuck somewhere in that stack, my inbox is open.
Just came across a headless browser library called lightpanda that doesn't graphically render pages. Saves a ton of time and RAM. lightpanda-io/browser
Lightpanda: The headless browser built from scratch for AI agents and automation (37k stars) What it does All text below is quoted directly from the project README. >Lightpanda: the headless browser designed for AI and automation Status: - CORS - HTTP loader (Libcurl) - HTML parser (html5ever) - Javascript support (v8) - CDP/websockets server - Network interception - Respect robots.txt with option --obey-robots - CDP and Webdriver Bidi >Not a Chromium fork. Not a WebKit patch. A new browser, written in Zig. 16x lighter and 9x faster than Chromium. Repository lightpanda-io/browser Repository stats |Metric|Value| |:-|:-| |Stars|37,014| |Forks|1.8k| |Last release|1.0.2 (2026-10-23)| |Languages|Zig 75.4%, HTML 20.5%, Linker Script 2.4%| |Contributors|85| |AI contributor accounts (Claude / Codex / Cursor / Copilot)|@claude (128 commits), @Copilot (2 commits)| |AI co-authored commits|Claude: 128, Copilot: 2| Main contributor |Field|Value| |:-|:-| |Name|Karl Seguin| |GitHub|@karlseguin| |Commits to this repo|4,800 (top contributor)| |Company / Location|Singapore| |X / Twitter|@karlseguin| |Followers|2.6k| ────────────────────────────── 📌 How many great GitHub repos have you discovered and completely forgotten about? Don't let another useful tool disappear into your Reddit feed. Get the community's best repos, organized by category, plus key takeaways from real developer discussions, delivered to your inbox twice a week. 📬 Never lose track of great repos again. Subscribe free.
Lightpanda's browser agent now uses a small decision model to find login fields github.com/lightpanda-io/browser/tree/jev-fallback The agent hands a decision model the page's interactive elements and it picks the username field, password field and submit button. Their numbers: 0.53 s and 2 calls, versus 7.83 s and 8 tool calls for Claude Haiku 5.5 with browser tools. A small model for one narrow step, instead of a full agent loop.
Things are getting serious @typesafeai Jev now handles logins in Lightpanda's agent. It picks the username field, password field and submit button from the page. > Jev: 0.53s, 2 calls > Claude Haiku 5.5 with browser tools: 7.83s, 8 tool calls github.com/lightpanda-io/browser/tree/jev-fallback t.co
@typesafeai This is on a separate branch for now: > github.com/lightpanda-io/browser/tree/page-classi… > Python example: github.com/lightpanda-io/lightpanda-python/blob/p…
What Obscura is, the Rust headless browser for AI agents --- title: What Obscura is, the Rust headless browser for AI agents published: true description: Obscura is a headless browser engine written in Rust and released under Apache-2.0. It runs JavaScript on V8, speaks the Chrome DevTools Protocol and tags: ai, rust, agents, opensource canonical_url: jacar.es cover_image: media.jacar.es --- Obscura landed on GitHub in April 2026 and has collected 24,624 stars in five months. Cloudflare’s engineering team credits it as the starting point for their own agent browser, and the project already advertises a managed version. Here is what it actually does, what the numbers looked like when I ran it on my own machine, and where it genuinely replaces headless Chrome. Key takeaways - Obscura is a headless browser engine written in Rust under an Apache-2.0 licence. It runs JavaScript on V8 and speaks the Chrome DevTools Protocol. - Playwright and Puppeteer connect without a single code change: point connectOverCDP at the port obscura serve opens. - Its reproducible advantage is memory. In my tests it used about 38 MB per session against 532 MB for headless Chromium on the same page. - The speed advantage depends on the page: obvious on static HTML, absent on a real site where network latency dominates. - Since version 0.2.0 (August 2026) it renders and captures without Chromium, but it does not match Chromium yet, and I hit that on the first page I gave it. What Obscura is and what problem it solves Obscura is a browser engine with no graphical interface, written from scratch in Rust. It is not a Chromium fork or a WebKit patch. It embeds V8 to run the page’s JavaScript, builds its own DOM, and exposes the Chrome DevTools Protocol so existing automation tools treat it as if it were Chrome. The official documentation defines it this way: "Obscura is an open-source headless browser engine written in Rust. It runs JavaScript via V8, speaks the Chrome DevTools Protocol, and works as a drop-in replacement for headless Chrome with Puppeteer and Playwright". The problem it attacks is cost, not capability. Headless Chrome automates a page perfectly well, but it was designed for one person looking at one tab. When a swarm of agents opens thousands of concurrent sessions, every process drags along a compositor, a rendering stack and dozens of subsystems no agent ever touches. You pay for that in gigabytes of memory and in seconds of startup. Obscura’s proposal is to keep only the part that matters for reading data: run the JavaScript, build the DOM, hand it back. The Cloudflare connection is the strongest signal that the idea holds up. In the Kitesurf announcement, describing their agent browser built on Workers, the team writes: "We got the initial inspiration from obscura, a headless engine written in Rust for AI automation that has ‘no Chrome, no Node.js, no dependencies’". Cloudflare ported Obscura to Workers as a first proof of concept in May 2026 and built the product from there. Kitesurf is still a Cloudflare service in free beta; Obscura is the engine you can download today. How it works inside The binary bundles three pieces. The first is V8, the same JavaScript engine Chrome uses, embedded directly in the Rust process. The second is its own implementation of the DOM and the web APIs a modern page needs: fetch, XHR, observers, Shadow DOM, custom elements, WebCrypto and the rest. The third is the CDP server, which translates Puppeteer or Playwright calls into operations on that DOM. Since version 0.2.0, released on 8 August 2026 with 449 accumulated commits, there is a fourth piece. It is a layout and paint engine also written in Rust, which allows screenshots, screencasting and PDF export without starting Chromium. Version 0.2.1, from 23 August, added dedicated V8 realms for child iframes. Installing it needs neither Node.js nor Chrome. The project publishes binaries for Linux, macOS and Windows, in variants with and without rendering and with and without stealth mode, plus an official image on Docker Hub with 45,789 pulls. curl -LO https://github.com/h4ckf0r0day/obscura/releases/latest/download/obscura-aarch64-linux.tar.gz tar xzf obscura-aarch64-linux.tar.gz ./obscura fetch https://example.com --eval "document.title" ./obscura fetch https://example.com --dump markdown ./obscura serve --port 9222 --stealth Stealth mode is a separate build variant. According to the project README it randomises the GPU, screen, canvas, audio and battery fingerprint on every session, leaves navigator.webdriver undefined and blocks 3,520 tracking domains. Those are the project’s own figures, not a third party’s. It also ships an embedded Model Context Protocol server with fourteen browser tools an assistant can call directly. If you have built your own servers before, the complete MCP guide has the context for that protocol. What happened when I ran it on my own machine I downloaded the aarch64-linux variant of v0.2.1 and ran it in an ARM64 Linux container on 4 September 2026, measuring wall time and peak resident memory across the process tree. Facing it I put headless Chromium driven by Playwright, on the same URLs and the same network. Three passes per combination. | Page | Obscura v0.2.1 | Headless Chromium | | --- | --- | --- | | example.com | 92 ms, 13 MB | 237 ms, 510 MB | | news.ycombinator.com | 1,550 ms, 38 MB | 1,430 ms, 532 MB | The honest reading of those numbers has two halves. The memory advantage is huge and it holds: roughly thirteen times less on the real page. The speed advantage evaporates as soon as the page stops being a static 500-byte file. On Hacker News, Chromium was even slightly faster, because what dominates the median is the network, not the engine. Dropping --wait to zero changed nothing. The project’s own benchmark repository reaches the same conclusion with more data. Over a corpus of 98 real public pages, Obscura rendered 94 and headless Chrome rendered 85. Median memory was 64.2 MB against 201.2 MB, but median latency was 5.2 seconds against Chrome’s 2.1 seconds. That is how the cards actually fall. Playwright compatibility turned out to be literal. I started obscura serve --port 9333 and connected with chromium.connectOverCDP('ws://127.0.0.1:9333') without touching anything else: navigation, page.title() and page.evaluate() all answered in 100 milliseconds. Then I tried the new rendering path on the front page of a Tailwind-based WordPress site. The capture took 587 milliseconds and produced a valid PNG, but with clear differences against Chromium. !Side-by-side comparison of the same page rendered by Obscura and by headless Chromium, where Obscura paints tooltips visible that the CSS declares with zero opacity. The most concrete difference: the theme declares its navigation-bar labels as ::after pseudo-elements with content: attr(data-tooltip) and opacity: 0, visible only on hover. Obscura painted the pseudo-element but ignored the opacity, so the header came out covered in overlapping labels. The search panel also rendered open and the cookie notice was missing. This is exactly the class of gap the project declares in its release notes, found on the first page I fed it. How it compares with headless Chrome and Lightpanda There are four families of solutions and it is worth keeping them apart, because they solve different things. GitHub figures from 4 September 2026. | Option | Engine | Licence | Stars | What it solves | | --- | --- | --- | --- | --- | | Obscura | Own, in Rust | Apache-2.0 | 24,624 | Memory cost per session | | Lightpanda | Own, in Zig | AGPL-3.0 | 34,414 | The same, with more history | | Headless Chrome with Playwright | Chromium | Apache-2.0 | 95,604 | Full rendering fidelity | | Steel Browser or Browserless | Wrapped Chromium | Apache-2.0 or custom | 7,591 and 13,658 | Running the infrastructure | Lightpanda is the direct rival: same premise of a new engine, written in Zig, two years older and with more stars. The difference that ends up deciding it is legal rather than technical. Lightpanda uses AGPL-3.0, which propagates to any service that exposes it over the network. Obscura uses Apache-2.0, which does not. If you plan to embed it in a closed product, that line in the LICENSE file weighs more than any benchmark. Steel Browser and Browserless do not compete with Obscura: they wrap Chromium with queues, sessions and an API. They solve operations, not cost per session. Browserless is also not open source, it is free only for non-commercial use. Then there is the agent ecosystem that already drives a browser. If what you want is an agent that browses for you, Browser Use works one layer above; if what you want is clean web data, Firecrawl does the extraction for you. Obscura lives underneath all of them, as an engine replacement. What it does not do well yet The rendering path is less than a month old and does not reach Chromium parity. The v0.2.0 notes say so plainly: long-tail CSS, some web APIs, native media playback and GPU compositor effects may still differ. My test confirmed it on the first try. The PDF output is also raster-backed, so the text cannot be selected. Conformance is not complete either. The benchmark repository publishes an 83.3% subtest pass rate on the Core tier of the Web Platform Tests (318,916 of 382,891) and 60.0% on the full suite. That 60% is not a hidden defect, it is the consequence of deliberately not implementing whole layers of the platform, and the project documents it. The README figures age. It advertises a 70 MB binary, but the ARM64 build with rendering that I downloaded takes 100 MB unpacked, plus another 92 MB for the worker process. The Docker image went from 53.2 MB in 0.1.11 to 87.1 MB in 0.2.1. None of this is serious, but measure on your own platform before quoting the table. The project is young and highly concentrated. It was created on 13 April 2026 and, of the twenty contributors the GitHub API lists, a single one accounts for 733 commits. Stealth mode reduces automation signals, but it does not prevent blocks based on IP reputation or behaviour patterns. And Obscura Cloud, the managed version, is still a waiting list rather than a product you can buy. When it is worth it and when it is not It is worth it when your bill is a memory bill. If you run hundreds or thousands of concurrent sessions extracting data, going from 500 MB to 38 MB per session changes machine sizing in a way no code optimisation can match. It is also worth it when you want to package a browser inside a small image with no Node.js and no Chrome, or when you need genuinely clean, reproducible sessions. It is not worth it if your workload is a few dozen pages and already works. The per-page latency gain on real sites is zero or negative, and you would be swapping a mature engine for a five-month-old one. It is also not worth it if you depend on visual fidelity: visual regression testing, client-facing captures, anything where the pixel matters, all of that remains Chromium territory. And if your problem is getting blocked, the engine is not the lever; proxies and request pacing are. My practical advice: run it alongside. Start obscura serve next to your current headless Chrome, point a percentage of traffic at it with connectOverCDP and compare results on your own target pages for a week. Migration costs one environment variable, so the experiment is cheap. If you are curious about the language underneath, Rust for backend work with Axum and Tokio has the context for why this class of project gets written that way. Frequently asked questions Does Obscura replace Playwright or Puppeteer? No, it complements them. Playwright and Puppeteer are the libraries you write the automation script in; Obscura is the browser that script drives. You keep the same Playwright code and only change the connection target, from a Chromium launched by the library to an obscura serve listening over CDP. Can I use Obscura in a closed commercial product? Yes. The licence is Apache-2.0, which permits commercial use and integration into proprietary software with no obligation to publish your code. That is the most practical difference against Lightpanda, which uses AGPL-3.0 and requires releasing the source of any networked service that embeds it. Is Obscura good enough for reliable screenshots? Only with caution. Since v0.2.0 it does screenshots, screencasting and PDF without Chromium, and they work. But the paint engine is new and the project itself warns that it does not match Chromium: in my test it ignored an opacity rule on a pseudo-element and rendered the header wrong. For visual regression testing, stay on Chromium. Conclusion Obscura solves a specific problem and solves it well: the memory cost of giving every agent its own browser. Thirteen times less RAM per session is a figure that changes architecture decisions, and CDP compatibility makes trying it almost free. What you should not expect is the speed gain the home page advertises, because it does not appear on real pages. Nor rendering fidelity equal to Chromium, because the project itself warns that it is not there yet. That Cloudflare started from this code to build Kitesurf says a good deal about the quality of the idea. Five months of life says a good deal about the risk. Measure it against your own pages before moving anything. Sources: [1] Obscura, official GitHub repository, [2] Obscura, published release notes, [3] obscura-benchmark, measured conformance and performance, [4] Official Obscura documentation, [5] Cloudflare, introducing Kitesurf, [6] Official Obscura image on Docker Hub, [7] Official Obscura website, [8] wpt.fyi, Web Platform Test results by engine. Spanish version: Qué es Obscura, el navegador headless en Rust para agentes de IA. --- Originally published on jacar.es.