Moli Browser: So nutzt du die Rust-Engine für KI-Agenten

Was ist Moli Browser?

Ein Headless-Browser arbeitet ohne sichtbares Browserfenster. Du steuerst ihn über Befehle oder eine Automationsbibliothek, um Seiten zu laden, JavaScript auszuführen, Inhalte auszulesen oder Formulare zu bedienen. Moli bietet dafür ein eigenständiges Binary und einen Automationsserver. Das Open-Source-Projekt ist ohne Lexmount-Cloudkonto nutzbar; das verwaltete Cloudangebot ist ein separates Produkt.

Moli ist Browser-Infrastruktur, nicht selbst der Nachweis eines erfolgreichen KI-Agenten. Welche Aufgabe ausgeführt wird, welche Daten ins Modell gelangen und wann eine Aktion eine Freigabe braucht, entscheidet die darüberliegende Steuerung. Diese Trennung erläutert der Guide zum AI Harness.

Kerndatum	Stand der Untersuchung	Quelle
Herausgeber und Hauptsprache	Lexmount, Rust	Repository
Lizenz	Apache-2.0 oder MIT nach Wahl; abweichende Bedingungen einzelner Dateien und Drittkomponenten beachten	Release-README
Geprüftes Release	v1.1.17, veröffentlicht am 12. Oktober 2026	Release Notes
GitHub-Snapshot	18.179 Stars und 474 Forks am 14. Oktober 2026, 11:35:17 CEST; kein Live-Zähler	GitHub-Repository
Vorgebaute Plattformen	Linux GNU, macOS und Windows; x86_64 und aarch64	Release-Build-Matrix
Schnittstellen laut Projekt	CLI, CDP, WebDriver Classic und WebDriver BiDi	Release-README

Die folgenden Beispiele und Befunde beziehen sich auf dieses Release, nicht auf einen späteren Entwicklungsstand von main. Ausgeführt wurden Linux-CLI und ausgewählte CDP-Abläufe; eine eigene WebDriver-Abnahme gehört nicht zum Testumfang.

Wie funktioniert die eigenständige Engine?

Eigenständig bedeutet nicht, dass Moli jede Komponente neu entwickelt. Der Architekturabschnitt des Release-README nennt bestehende Bausteine:

Ebene	Verwendete Komponenten
Netzwerk und HTML	libcurl und html5ever
JavaScript	rusty_v8 und V8
CSS-Selektoren, Kaskade und Styles	Servo/Stylo
Box- und Textlayout	Taffy und Parley
Software-Rendering	AnyRender/Vello CPU, usvg und Rust-Bildkomponenten

V8 macht Moli nicht zu Chromium. Ebenso macht die Verwendung von Stylo daraus nicht die vollständige Servo-Engine. Moli verbindet diese Komponenten mit eigenen Regeln für DOM, Laufzeit und Lebensdauer des Browserzustands.

Der entscheidende Unterschied ist das Layoutmodell: Moli pflegt laut Dokumentation keinen kontinuierlichen Layoutbaum und keinen GPU-Compositor. Eine reine DOM- oder JavaScript-Abfrage braucht deshalb nicht automatisch einen gerenderten Seitenzustand. Bei visuellem Bedarf baut die Engine Arbeitszustand auf, speichert die berechnete Geometrie als eingefrorenen Snapshot und verwirft temporären Layout- beziehungsweise Paintzustand wieder.

Was ändern Layout- und Ressourcenflags?

Die dokumentierten Betriebsmodi solltest du getrennt betrachten:

Einstellung	Wirkung	Praktische Konsequenz
Standard ohne --layout	Mock-Geometrie, kein echtes Layout oder Paint	Für strukturierte Abfragen erproben; nicht als CSS-korrekte Klickgeometrie behandeln
--layout	Echtes Box- und Textlayout, Hit-Testing und visuelle Ausgabe bei Bedarf	Für die hier gezeigten Formularaktionen und Screenshots aktivieren
--resource	Alle optionalen Bild-, Font-, Audio-, Video-, Medien- und Texttrack-Ressourcen nachladen	Kein JavaScript-Schalter; kann Darstellung und Ladeverhalten verändern
Einzelne Ressourcenflags	Beispielsweise --image oder --font	Nur die für den Auftrag benötigten Ressourcen einschalten
Profil-, Cache- und Cookieoptionen	Persistenz selektiv aktivieren	Kein automatisch vorhandenes angemeldetes Browserprofil voraussetzen

JavaScript und ein einfacher fetch() funktionierten in unserer lokalen Untersuchung (siehe „Quellen → Eigene Untersuchung“) auch ohne --resource. Daraus folgt nicht, dass jede Anwendung auf Bilder, Fonts oder deren Ladeereignisse verzichten kann.

Wichtig: Auch mit Layout bleibt die Geometrie ein Snapshot. Gewöhnliche Geometrieabfragen dürfen ihn nach einer DOM-Änderung weiterverwenden; Screenshots bauen ihn neu auf. Das steht ausdrücklich im README und beeinflusst dynamische Oberflächen, nicht nur die Bildausgabe.

Wie startest du Moli per CLI?

Der Einstieg besteht aus einem fest gepinnten Binary, einer lokalen Testseite und einer konkreten Bereitschaftsprüfung. Du brauchst dafür Linux x86_64 mit passender GNU/glibc-Laufzeit, curl, tar, sha256sum und Python mit HTTP-Servermodul. Andere Plattformen benötigen ihr passendes Release-Asset.

Die Beispiele sind eine portable Darstellung der ursprünglichen Probes. Zusätzlich wurden die exakt hier gezeigten HTML-/JSON-Dateien, der CLI-JavaScript-Aufruf und beide Clients mit dem vorhandenen v1.1.17-Binary und den bereits installierten, gepinnten Abhängigkeiten einmal ausgeführt. Download, Prüfsummenbefehl, Neuinstallation und die zusätzlichen Exportbefehle wurden dabei nicht erneut Ende zu Ende geprüft. Die gekürzte Formularseite ersetzt nicht die umfangreichere Mess-Fixture.

Release herunterladen und prüfen

Nutze in einem neuen Arbeitsordner das offizielle Linux-Asset von v1.1.17. Die Verkettung stoppt bei einem Fehler, insbesondere bei einer abweichenden Prüfsumme:

mkdir moli-demo &&
cd moli-demo &&
curl --proto '=https' --tlsv1.2 -fL \
  https://github.com/lexmount/moli/releases/download/v1.1.17/moli-x86_64-unknown-linux-gnu.tar.gz \
  -o moli.tar.gz &&
printf '%s  %s\n' \
  e338cdd2ab6e3e6262117e56aba625bf6c71c44fd72ac3870bbd9c0e6c1ec351 \
  moli.tar.gz | sha256sum --check - &&
mkdir bin &&
tar -xzf moli.tar.gz --strip-components=1 -C bin &&
./bin/moli --version

Der Digest stimmte beim untersuchten Download mit dem GitHub-Asset-Digest überein. Das belegt die Integrität dieses Downloads, keine separat geprüfte Herausgebersignatur. Ein lokaler Rust-Build oder eine systemweite Installation ist für dieses Beispiel nicht nötig.

JavaScript-Inhalt auslesen

Speichere im Arbeitsordner die Datei demo.html:

<!doctype html>
<html>
<head><meta charset="utf-8"><title>Moli Demo</title></head>
<body>
  <h1>Moli Demo</h1>
  <p id="result">Noch nicht fertig</p>
  <script>
    Promise.resolve().then(() => {
      document.querySelector('#result').textContent = 'Moli bereit';
      window.demoReady = true;
    });
  </script>
</body>
</html>

Starte in einem zweiten Terminal im selben Ordner einen lokalen HTTP-Server. Der gewählte Port muss frei sein:

python3 -m http.server 18764 --bind 127.0.0.1

Zurück im ersten Terminal liest du den durch JavaScript veränderten Text:

./bin/moli fetch \
  --wait-script 'window.demoReady===true' \
  --eval 'document.querySelector("#result").textContent' \
  http://127.0.0.1:18764/demo.html

Der ursprüngliche Quickstart-Probe endete erfolgreich und gab Moli bereit aus. Das konkrete Prädikat wartet auf die Promise-DOM-Änderung. Ein HTTP-Erfolg oder das load-Ereignis allein wäre dafür keine ausreichende Kontrolle.

Für Exporte dokumentiert das Release-README unter anderem diese Bedienmuster:

./bin/moli fetch --dump markdown --wait-until done \
  http://127.0.0.1:18764/demo.html
./bin/moli fetch --layout --dump screenshot \
  http://127.0.0.1:18764/demo.html > page.png
./bin/moli fetch --layout --dump pdf \
  http://127.0.0.1:18764/demo.html > page.pdf

Diese Exportzeilen übertragen dokumentierte Optionen auf die Demo. Markdown, Screenshot und PDF wurden in der Untersuchung an eigenen Testseiten geprüft. --eval allein gibt den Ausdruckswert aus; zusammen mit --dump wird dieser Wert verworfen und anschließend der Seitenexport erzeugt. --wait-until ist ein gültiger Alias von --wait, kein Versionsfehler.

Wie verbindest du Moli mit Playwright und Puppeteer?

CDP, das Chrome DevTools Protocol, ist die gemeinsame Steueroberfläche. Moli implementiert sie selbst. Du verbindest den Client mit einem laufenden Moli-Server, statt Chrome über launch() oder einen Chrome-executablePath zu starten.

Die Einschränkung gehört direkt dazu: Playwright dokumentiert den CDP-Anschluss nur für Chromium-basierte Browser und beschreibt ihn als deutlich weniger vollständig als die Playwright-Protokollverbindung. Erfolgreiche Moli-CDP-Aufgaben sind daher kein Nachweis offizieller Playwright-Unterstützung oder vollständiger API-Parität. Den allgemeinen Bedienweg erklärt der Playwright-Guide.

Server und Formular vorbereiten

Starte in einem dritten Terminal im Arbeitsordner den Moli-Server mit Layout:

./bin/moli serve --host 127.0.0.1 --port 18765 --layout

HTTP-Testseite und Browserserver sind getrennte Prozesse. Die Ports oben sind bewusst unterschiedlich. Überprüfe im ersten Terminal die dokumentierte CDP-Discovery:

curl --fail --silent http://127.0.0.1:18765/json/version

Die Antwort liefert den Browser-WebSocket-Endpunkt. /json/list listet Targets, /json/protocol beschreibt das angebotene Protokoll. Errate keinen WebSocket-Pfad.

Speichere neben demo.html eine kompakte dynamic.html. Sie enthält die Selektoren und asynchronen Schritte des getesteten Formularablaufs, aber nicht dessen zusätzliche Layout- und Berechtigungskontrollen:

<!doctype html>
<html>
<head><meta charset="utf-8"><title>Moli Formular</title></head>
<body>
  <ul id="items">
    <li>First</li>
    <li>Second</li>
  </ul>
  <form id="form">
    <input id="name" name="name" value="">
    <button id="submit" type="submit">Submit</button>
  </form>
  <output id="result"></output>
  <script>
    window.fixtureReady = false;
    document.getElementById('form').addEventListener('submit', event => {
      event.preventDefault();
      document.getElementById('result').textContent =
        'submitted:' + document.getElementById('name').value;
    });
    Promise.resolve().then(() => {
      document.getElementById('items').insertAdjacentHTML(
        'beforeend', '<li>Third JS</li>'
      );
    });
    fetch('/data.json').then(response => response.json()).then(data => {
      document.getElementById('result').textContent = data.marker;
      window.fixtureReady = true;
    });
  </script>
</body>
</html>

Daneben brauchst du die Datei data.json:

{"marker":"FETCH_OK"}

Die Clients warten auf fixtureReady, damit die JSON-Antwort nicht nachträglich das Formularergebnis überschreibt. Beide Server müssen weiterlaufen. Für diese Loopback-Demo darfst du --block-private-networks nicht hinzufügen: Genau solche privaten Ziele soll es blockieren.

Playwright mit Python anschließen

Die eigene Untersuchung (siehe „Quellen → Eigene Untersuchung“) verwendete Playwright Python 1.61.0. Installiere denselben Client in einer virtuellen Umgebung; Python muss venv und pip unterstützen:

python3 -m venv .venv
.venv/bin/python -m pip install 'playwright==1.61.0'

Ein playwright install chromium ist für diesen Anschluss nicht erforderlich. Speichere moli_playwright.py:

from playwright.sync_api import sync_playwright

with sync_playwright() as pw:
    browser = pw.chromium.connect_over_cdp("http://127.0.0.1:18765")
    context = browser.new_context(
        viewport={"width": 800, "height": 600}, device_scale_factor=1
    )
    try:
        page = context.new_page()
        page.set_default_timeout(2500)
        page.goto("http://127.0.0.1:18764/dynamic.html", wait_until="load")
        page.wait_for_function("window.fixtureReady===true")
        print(page.locator("#items li").all_text_contents())
        page.locator("#name").fill("Ada")
        page.locator("#submit").click()
        print(page.locator("#result").text_content())
    finally:
        context.close()
        browser.close()

.venv/bin/python moli_playwright.py

In der ursprünglichen Suite wurden die Listeneinträge First, Second, Third JS gelesen und mit Layout submitted:Ada erreicht. Ohne Layout scheiterte der Klick. pw.chromium bezeichnet hier den CDP-Clientpfad, nicht Molis Engine.

Puppeteer Core mit Node.js anschließen

Alternativ verwendest du Node.js und npm. Im ursprünglichen Einzellauf (siehe „Quellen → Eigene Untersuchung“) kam Puppeteer Core 24.30.0 zum Einsatz. Die Clientinstallation lädt keinen zusätzlichen Browser:

npm init -y
npm install --ignore-scripts --save-exact puppeteer-core@24.30.0

Speichere moli_puppeteer.cjs:

const puppeteer = require("puppeteer-core");

(async () => {
  const browser = await puppeteer.connect({
    browserURL: "http://127.0.0.1:18765"
  });
  const page = await browser.newPage();
  try {
    await page.setViewport({ width: 800, height: 600 });
    await page.goto("http://127.0.0.1:18764/dynamic.html", {
      waitUntil: "load"
    });
    await page.waitForFunction("window.fixtureReady===true");
    await page.type("#name", "Puppeteer");
    await page.click("#submit");
    console.log(await page.$eval("#result", node => node.textContent));
  } finally {
    await page.close();
    browser.disconnect();
  }
})().catch(error => {
  console.error(error);
  process.exitCode = 1;
});

node moli_puppeteer.cjs

Der ursprüngliche Probe lieferte submitted:Puppeteer. Das war ein einzelner Lauf, keine breite Kompatibilitätssuite. Führe die Clients nacheinander aus und beende anschließend nur deine beiden Server mit Strg+C in deren Terminals.

Bei Problemen gilt: laufenden Server und Discovery prüfen, Verbindung statt Browserstart verwenden, Clientversion prüfen, bei Klicks Layout aktivieren und erst danach benötigte Ressourcen ergänzen. Eine explizite Unsupported-Antwort ist eine Funktionsgrenze, keine Einladung, einen Erfolg zu simulieren.

Wofür lohnt sich Moli bei KI-Agenten?

Der plausibelste Einstieg sind Aufgaben, deren Erfolg du anhand strukturierter Daten prüfen kannst. Wenn du Artikeltext, Tabellenwerte oder DOM-Attribute benötigst, ist dauerhaftes visuelles Rendering möglicherweise unnötiger Aufwand. Molis Architektur bietet hier eine andere Kostenstruktur, aber noch keine gemessene Verbesserung deiner Agentenqualität.

Aufgabe	Warum Moli dafür interessant ist	Was du vor einer Umstellung prüfen musst
JavaScript-Inhalte extrahieren	DOM und JavaScript ohne obligatorisches echtes Layout	Relevante Inhalte vollständig, richtige Wartebedingung, versteckte Texte
Retrieval- oder Crawling-Pipeline	CLI-Exporte und explizite Selektor-/Script-Waits	Zielseiten, Extraktionsqualität, Timeouts und zulässige Abrufrate
Bestehende Automation erproben	CDP lässt Teile des Clientcodes weiterverwenden	Jede benötigte Interaktion und Protokollfunktion
Gelegentliche visuelle Kontrolle	Software-Screenshot erst bei Bedarf	Layout, Fonts und Abweichungen gegenüber deiner Referenz
Viele parallele Browseraufträge	Weniger gepflegter Browserzustand könnte Ressourcen sparen	Gesamtprozessbaum, erfolgreiche Aufgaben, Wiederholungen und Fallbackkosten

Eine geringere Browserlast hilft wenig, wenn inkompatible Seiten Wiederholungen oder einen zweiten Browser erzwingen. Entscheidend ist deshalb nicht allein der Speicher eines Prozesses, sondern der Aufwand pro erfolgreich abgeschlossener Aufgabe. Parallelität, Modellkosten und Ende-zu-Ende-Agentenerfolg wurden hier nicht gemessen.

Was zeigen die Tests gegen Chromium tatsächlich?

Die eigene Untersuchung (siehe „Quellen → Eigene Untersuchung“) umfasste fünf frische Moli-Prozesse je Mock- und Layoutmodus sowie fünf funktionale Chromium-Gegenläufe über ein isoliertes Browser-Tool. Verwendet wurden kontrollierte lokale HTML-/JavaScript-Testseiten mit gleichem Viewport. Optionale Bild-, Font- und Medienressourcen blieben bei Moli ausgeschaltet.

Kontrolle	Moli	Chromium-Gegenkontrolle
Promise-DOM-Änderung und JSON-Fetch	Erwartete Listeneinträge und FETCH_OK	Erwartete Inhalte ebenfalls vorhanden
Einfaches Formular	Mit Layout fünf von fünf erfolgreich; Mock kein erfolgreicher Lauf	DOM-Füllung und Klick fünf von fünf erfolgreich
Geometrie	Mit Layout passende Boxgrößen und horizontale Abstände; kleine vertikale Differenz	Referenzgeometrie der kontrollierten Seite
DOM-Mutation nach Geometrieabfrage	Neue Knoten zunächst ohne korrekte Geometrie; Screenshot erneuerte den Snapshot	Geometrie unmittelbar aktualisiert
Camera-Permissions-Query unter sperrender Policy	prompt	denied

Die Zahlen dieser Tabelle stammen ausschließlich aus den eigenen Tests. Die Chromium-Steuerung verwendete Browserhelper statt desselben lokalen Playwright-Clients. Das ist eine Funktionsgegenkontrolle, kein vollständig symmetrischer Clientvergleich und kein Nachweis allgemeiner SPA-Kompatibilität.

Wie hoch war Molis Ressourcenbedarf?

Die folgenden lokalen Messwerte (siehe „Quellen → Eigene Untersuchung“) betreffen nur Moli, seriell auf Linux x86_64. Jeder Modus wurde fünfmal gestartet:

Modus	CDP-ready, Median in ms	Sampled Peak RSS, Median in MiB	Sampled Peak PSS, Median in MiB
Mock	18,80	72,89	68,67
Layout	17,40	82,63	77,43

RSS zählt residenten Speicher; PSS verteilt geteilte Speicherseiten proportional. Gemessen wurde Molis Prozessbaum über /proc/smaps_rollup mit einer Abtastung alle 30 ms. Kurze Spitzen zwischen Samples können fehlen. Client, HTTP-Server und übrige Infrastruktur sind nicht enthalten.

CDP-ready bedeutet Prozessstart bis zur erfolgreichen Antwort von /json/version, geprüft mit 10-ms-Polling, nicht fertig geladene Website oder abgeschlossene Aufgabe. Die Messung verwendete frische Prozesse, aber keinen geleerten Betriebssystem-Pagecache. Aus den kleinen Startzeitunterschieden lässt sich kein belastbarer Vorteil eines Modus ableiten.

Warum gibt es keinen eigenen Chromium-Speicherfaktor?

Der lokale Start von Chrome for Testing scheiterte unter den unveränderten Sandboxbedingungen. Die Untersuchung umging das nicht mit --no-sandbox. Der anschließend tatsächlich verwendete Chromium-Browser lief außerhalb des lokal messbaren Prozessbaums.

Damit fehlen vergleichbare Chromium-RSS-, PSS- und Startzeitwerte. Die Moli-Zahlen belegen keinen festen RAM- oder Geschwindigkeitsfaktor gegenüber Chromium. Eine saubere Ressourcenvergleichsreihe müsste auf einem sandboxfähigen, unprivilegierten Host mit identischen Clients, Aufgaben und Prozessbaum-Messungen stattfinden.

Wie belastbar sind die Herstellerbenchmarks?

Das Release-README berichtet einen Crawl über 192 öffentliche URLs: Moli habe 103 brauchbare Seiten geliefert, Chrome 101. Für beide nennt der Hersteller eine mediane Zeit von 1,43 Sekunden, bei medianem RSS von 73 beziehungsweise 773 MiB. Das sind Herstellerwerte für diesen Korpus, keine hier replizierten Ergebnisse und kein allgemeiner Ressourcenfaktor.

Der historische Lexbench-Ressourcenreport vom 12. August 2026 hat einen anderen Nenner: 557 Aufgaben mit fünf Versuchen je Engine, also 2.785 Task-Attempts. Seine Ressourcenwerte beziehen sich auf die gemeinsame erfolgreiche Schnittmenge von 1.045 Task-Attempts und einen warmen Engine-Prozessbaum. Das ist weder der gesamte Aufgabenkorpus noch automatisch der Stand des hier getesteten Releases.

Ein unabhängiger Implicator-Einzellauf mit v1.1.16 fand JavaScript-generierte Inhalte auf einer Testseite. Der Bericht nennt 0,62 Sekunden und ungefähr 56 MiB Peak Resident Memory auf einem M3 Ultra, ausdrücklich ohne Chrome-Messung. Er ist ein zusätzliches Praxissignal, keine unabhängige Bestätigung von Vergleichsfaktoren.

Wo liegen die Kompatibilitätsgrenzen?

Dynamische Geometrie kann veraltet sein

Die Snapshot-Grenze ist im Release-README dokumentiert und wird in Issue #1080 konkret beschrieben. Unsere Mutation nach einer vorherigen Geometrieabfrage passte zu diesem Verhalten: Text war im DOM auffindbar, die Geometrie neuer Knoten aber zunächst nicht korrekt.

Das trifft potenziell Dialoge, nachgeladene Listen und Formulare mit dynamisch eingefügten Feldern. Ein Screenshot erneuerte in unserem Probe den Zustand. Daraus folgt keine Empfehlung, jede Mutation mit einem zusätzlichen Screenshot zu reparieren. Prüfe stattdessen, ob dein Ablauf ohne kontinuierlich aktuelle Geometrie auskommt.

Markdown ist nicht automatisch sichtbarer Seitentext

Unsere CLI-Ausgabe enthielt auch einen per CSS ausgeblendeten Testtext. Das ist für Retrieval und Agentenkontext relevant: Du solltest nicht ungeprüft annehmen, dass Markdown nur Inhalte umfasst, die ein Nutzer sehen würde.

Verwende gezielte Selektoren und kontrolliere die Extraktion anhand deiner Zielseiten. Versteckter Text kann ein Modell beeinflussen; ein Prompt-Injection-Angriff wurde hier allerdings nicht getestet.

CDP-Verbindung bedeutet keine vollständige Interaktionsparität

Der separate Raw-CDP-Aufruf Input.setInterceptDrags wurde ausdrücklich als nicht unterstützt beantwortet. Issue #1101 beschreibt dazu einen fremden Drag-and-drop-Ablauf. Unsere eigene Prüfung bestätigt den fehlenden Protokollpfad, nicht eine vollständig ausgeführte Drag-and-drop-Suite.

Auch vorhandene API-Namen für Worker, Storage oder WebGL sind kein Funktionsnachweis. Das Projekt grenzt Pixelparität und High-Fidelity-Canvas-/WebGL-/Medienausgabe selbst aus. Für entsprechende Aufgaben brauchst du konkrete Prüfungen und gegebenenfalls Chromium als Fallback.

PDFs sind versionsabhängig, nicht pauschal Rasterbilder

Die Release Notes von v1.1.17 nennen durchsuchbare PDFs. In unserer einfachen Ausgabe war Text extrahierbar. Eine pauschale Beschreibung als reines Raster-PDF wäre für diesen Befund falsch.

Das PDF-Backend dokumentiert native Text- und Fontfunktionen, aber auch Grenzen: keine umfassende CSS-Fragmentierung mit Tabellenumbrüchen und @page, kein Tagged PDF beziehungsweise PDF/UA. Die Lesereihenfolge folgt Paint Order; komplexe Textauslese hängt auch vom Reader ab. Ein erfolgreicher einfacher Export ist keine Freigabe für barrierefreie Dokumente.

Wie betreibst du Moli mit klaren Sicherheitsgrenzen?

Halte den CDP-Server auf Loopback. Der Endpunkt ermöglicht Browsersteuerung und sollte nicht ungeschützt öffentlich erreichbar sein. Verwende separate Testprofile statt ungeprüft dein produktives Loginprofil zu importieren.

Die CLI-Netzwerkpolicy bietet --block-private-networks und zusätzliche CIDR-Sperren. Ihre clientseitige Prüfung betrifft direkt verbundene Ziele; vom Proxy aufgelöste Ziele benötigen eigene Proxy- beziehungsweise Egress-Regeln. Das ist kein nachgewiesener vollständiger SSRF-Schutz.

Bei der Permissions-Query zeigte sich trotz sperrendem Permissions-Policy-Header eine Abweichung zu Chromium, passend zum Thema von Issue #805. Geprüft wurde die Antwort prompt statt denied, kein tatsächlicher Kamerazugriff.

Rust und ein erfolgreicher Browserstart belegen außerdem keinen gleichwertigen Chromium-Sandboxvertrag. Betreibe unbekannte Seiten unprivilegiert, ohne Secrets, mit minimalem Dateizugriff und separater äußerer Isolation. Das ist eine Betriebsempfehlung, keine getestete Moli-Sicherheitsgarantie. Ohne Cloudkonto zu arbeiten bedeutet auch nicht, dass kein Webseiten- oder Proxynetzverkehr den Rechner verlässt.

Wie unterscheidet sich Moli von Chromium, Lightpanda und Servo?

Die Projekte liegen nicht vollständig auf derselben Ebene. Die folgende Einordnung ist keine Rangliste und enthält keine eigenen Lightpanda- oder Servo-Messungen:

Projekt	Technische Einordnung	Entscheidungsrelevanter Unterschied
Moli	Eigenständiger Rust-Kernel mit V8 und Stylo; DOM-first und optionales Layout	Kontrolliert für strukturierte Aufträge testen; Snapshot- und CDP-Grenzen berücksichtigen
Chromium / Chrome Headless	Referenzbrowser der hier ausgeführten Funktionsgegenkontrollen	Als geprüften Fallback für benötigte Web- und Interaktionssemantik behalten; hier kein lokaler Ressourcenvergleich
Lightpanda	Laut eigener Dokumentation eigenständiger Browser in Zig, kein Chromium-Fork	Alternative CLI-/CDP-Runtime; dokumentierte PNG-/PDF-Ausgabe als Text-only-Rendering ist keine Zusage visueller Parität
Servo	Laut eigener Dokumentation prototypische Browserengine in Rust	Engineprojekt mit eigenem Entwicklungsweg, nicht automatisch derselbe CDP-Runtime-Vertrag wie Moli

Grundlagen: Moli-Architektur, revisionsgebundenes Lightpanda-README und revisionsgebundenes Servo-README.

Für deine Auswahl zählt zuerst, welche Aufgabe richtig abgeschlossen wird. Starzahlen und Anbieterfaktoren ersetzen diesen Nachweis nicht. Beginne mit einem lesenden DOM-Auftrag, ergänze anschließend isolierte Formularaktionen und definiere vorab, welche Fehler einen Chromium-Fallback auslösen.

FAQ: Häufig gestellte Fragen zu Moli Browser

Ist Moli ein Chromium-Wrapper?

Nein. Das Projekt beschreibt einen eigenständigen Rust-Browserkernel, der V8, Stylo und weitere vorhandene Komponenten integriert. CDP-Kompatibilität macht daraus keine Chromium-Engine.

Brauche ich ein Lexmount-Konto?

Für das Open-Source-Binary nicht. Das Cloudangebot ist getrennt; eigene Infrastruktur- und Betriebskosten bleiben.

Warum verbindet sich Playwright, aber der Klick scheitert?

Verbindung und Featureparität sind unterschiedliche Dinge. Prüfe gemäß CDP-Guide zunächst --layout, anschließend Snapshotzustand und den konkret benötigten Protokollpfad.

Muss ich für JavaScript --resource einschalten?

Nein. Laut Modusdokumentation aktiviert es optionale Ressourcenfamilien, nicht JavaScript. Unsere Promise-/Fetch-Testseite funktionierte ohne dieses Flag.

Spart Moli immer denselben RAMfaktor gegenüber Chrome?

Das ist nicht belegt. Die eigene Untersuchung (siehe „Quellen → Eigene Untersuchung“) enthält Moli-Werte ohne fair messbares lokales Chromiumgegenstück; Herstellerreihen verwenden andere Aufgaben, Versionen und Messdefinitionen.

Kann Moli durchsuchbare PDFs erzeugen?

Für das geprüfte Release und unsere einfache Testseite ja. Daraus folgt keine allgemeine Reader-Kompatibilität oder PDF/UA-Unterstützung; das Backend nennt diese Grenzen ausdrücklich.

Kann ich Chromium vollständig ersetzen?

Nicht aufgrund dieser Befunde. Prüfe deine Zielseiten und benötigten Interaktionen; bei Unsupported-CDP-Pfaden oder kritischer visueller Semantik sollte ein geprüfter Chromium-Workflow verfügbar bleiben.

Fazit

Moli Browser ist für definierte DOM-first-Aufgaben einen kontrollierten Versuch wert, nicht für einen pauschalen Austausch von Chromium. Beginne mit überprüfbarer Extraktion, aktiviere Layout für die hier gezeigten Klickabläufe und behalte einen Fallback für inkompatible Seiten und Protokollpfade. Plane Ressourcen nach erfolgreichen Aufgaben statt nach ungeprüften Anbieterfaktoren. Für die Clientseite hilft der Playwright-Guide; die darüberliegende Agentensteuerung ordnet der AI-Harness-Artikel ein.

Quellen

Primärquellen und Produktdokumentation

• Moli-README am getesteten Release-Commit: Architektur, Lizenz, Betriebsmodi und ausdrückliche Projektgrenzen.
• Moli-Release v1.1.17: veröffentlichter Versionsstand, Asset und PDF-Änderungen.
• GitHub-Repository: Stars und Forks als eingefrorener Snapshot aus der Recherche, nicht als Echtzeitangabe.
• CLI-Implementierung am Release-Commit: Flags, Warteoptionen und Grenzen der Netzwerkpolicy.
• CDP-Server-Guide am Release-Commit: Discovery, Clientanschluss und Troubleshooting.
• PDF-Backend am Release-Commit: native Ausgabe, Textauslese und verbleibende Druck-/Readergrenzen.
• Release-Build-Matrix: vorgebaute Plattformen.
• Playwright: connectOverCDP: offizielle Chromium-Beschränkung und geringere Vollständigkeit der Verbindung.
• Lightpanda-README, eingefrorene Revision und Servo-README, eingefrorene Revision: ausschließlich Projektklassifikation, keine eigenen Vergleichstests.

Herstellerbenchmarks

• Benchmarkabschnitt im Moli-Release-README: öffentlicher Crawl; nicht unabhängig repliziert.
• Lexbench Resource Card, eingefrorene Revision: historische Warm-Prozessbaum-Messung in einer gemeinsamen erfolgreichen Task-Attempt-Schnittmenge, keine Übertragung auf alle Websites.

Externe Beobachtungen und Fehlerberichte

• Implicator Repo Radar: zugänglicher Bericht eines unabhängigen Einzellaufs ohne Chrome-Gegenmessung.
• Issue #1080: fremder Bericht über veraltete Geometrie nach DOM-Mutation.
• Issue #805: fremder Bericht zur Permissions-Policy-Semantik.
• Issue #1101: fremder Drag-and-drop-Bericht und fehlender CDP-Pfad; keine eigene vollständige Drag-Suite.

Eigene Untersuchung

Redaktionelle lokale Prüfung am 14. Oktober 2026 mit dem offiziellen Linux-x86_64-GNU-Binary von Moli v1.1.17, Release-Commit cac20d15b83892d71fa8efc27d1e802002a4d68e. Je fünf frische Moli-Prozesse pro Modus, kontrollierte Loopback-Testseiten, Viewport 800 × 600 CSS-Pixel und DPR 1, optionale Ressourcen ausgeschaltet. Clients: Playwright Python 1.61.0 sowie ein separater Puppeteer-Core-24.30.0-Lauf. Fünf funktionale Gegenläufe mit Chrome 145.0.7632.6 über ein isoliertes Browser-Tool; kein lokal messbarer Chromiumprozessbaum.

Die lokalen Rohdaten wurden für diese Fassung gegen Vorlage und Untersuchungsbericht geprüft. Sie haben keine öffentliche Artefakt-URL. RSS/PSS wurden alle 30 ms abgetastet; CDP-ready erfasst nur die Verfügbarkeit der Discovery mit 10-ms-Polling. Kein breiter Website-/SPA-Test, keine vollständige API-/Security-Suite und keine Messung von Agentenqualität oder Modellkosten. Ein zusätzlicher Smoke-Test führte die exakt hier gezeigten HTML-/JSON-Dateien, den CLI-JavaScript-Aufruf und die Python-/Nodeclients mit dem vorhandenen Moli-1.1.17-Binary, Playwright Python 1.61.0 und Puppeteer Core 24.30.0 aus: Moli bereit, First, Second, Third JS, submitted:Ada und submitted:Puppeteer, jeweils mit Exit 0. Der Moli-Server blieb nach dem Pythonclient für den Nodeclient erreichbar. Das ist kein erneut ausgeführter Download-, Prüfsummen-, Fresh-Install- oder Exportworkflow und keine weitere Ressourcen- oder Kompatibilitätssuite.

Quellenstand: 14. Oktober 2026. Die verlinkten Moli-Code- und Dokumentationsquellen sind an den getesteten Release-Commit gebunden; historische Herstellerbenchmarks und fremde Fehlerberichte wurden nicht als aktuelle eigene Ergebnisse übernommen.