PullMD Teil 5: Reddit-Tag und die ersten Issues
Am 27. April um 09:32 morgens lief gh repo create durch. Das Repo war öffentlich. Ein Nacht später: ein paar Stars, vierzehn Unique Cloner laut GitHub Insights, kein einziges Issue. Das war das erste Mal, dass ich morgens frühstückte und nebenbei auf ein Projekt schaute, das nicht mehr nur meins war — und nichts Unerwartetes passiert war.
Der Post auf r/ClaudeAI
Am 28. April um kurz nach Mittag schrieb ich einen Reddit-Post auf r/ClaudeAI. Titel: „PullMD - gave Claude Code an MCP server so it stops burning tokens parsing HTML“.
Zwei Frust-Trigger als Aufhänger — die ich wirklich hatte und nicht konstruiert habe:
1. Mobile Copy-Paste ist furchtbar. Langer Reddit-Thread oder Blogartikel auf dem Handy, ich will Claude etwas darüber fragen. Long-Press, Selection-Handles über Navigation und Sidebar ziehen, kopieren, App wechseln, einfügen. Nichts davon ist schwer. Aber es nervt genug, dass ich es eines Tages einfach fixen wollte.
2. Claude Code verbrennt Token auf HTML-Boilerplate. Ein typischer Artikel ist 80% Navigation, Cookie-Banner und Footer — 20% eigentlicher Inhalt. Den Agenten damit ringen zu lassen, bevor er meine Frage beantwortet, war ineffizient. Auf eine unangenehme Art, die man schlechter ignorieren kann, je mehr man das System kennt.
Der Post ging live. Ich hatte keine besonderen Erwartungen — ein Post unter ein paar Tausend in einem aktiven Sub, gepostet am Mittag eines Werktags.
Was über den Tag passierte
Zum Zeitpunkt dieses Artikels: 387 Upvotes, 58 Comments. Das war mehr als alles, was ich vorher auf Reddit gepostet hatte.
Der erste Kommentar, den ich morgens las, war von u/CloisteredOyster:
“What is this!? A useful and novel tool on an AI sub? Amazing!” — u/CloisteredOyster (+108)
„Was ist das!? Ein nützliches und neues Tool in einem AI-Sub? Erstaunlich!“ — u/CloisteredOyster (+108)
Das war früh genug am Tag, dass ich mich freuen konnte, ohne zu wissen, ob mehr kommt.
Was Reddit mir über mein eigenes Tool beibrachte
Der interessanteste Comment kam von u/blin787 — ein Side-by-Side-Vergleich mit Claude Codes eigenem WebFetch:
“Claude code’s webfetch works differently. It passes page to Haiku model which then returns very small result which is actually added to context of Opus/Sonnet. So the reduction is not as drastic as it seems when using with agents which solved this problem.” — u/blin787 (+35)
„Claude Codes WebFetch funktioniert anders. Es leitet die Seite an ein Haiku-Modell weiter, das ein sehr kleines Ergebnis zurückgibt, welches dem Kontext von Opus/Sonnet hinzugefügt wird. Die Reduktion ist also nicht so drastisch, wie sie wirkt, wenn man Agents nutzt, die dieses Problem schon gelöst haben.“ — u/blin787 (+35)
Ich hatte nicht tief in die WebFetch-Interna geschaut, weil ich ein anderes Problem löste. Nach dem Comment recherchierte ich nach. WebFetch fetcht die Seite via Axios, startet dann eine sekundäre Haiku-Konversation mit dem rohen HTML und folgendem Prompt:
Provide a concise response based only on the content above.
- Enforce a strict 125-character maximum for quotes
Der Hauptagent sieht die Seite nie — nur Haikus reduzierte Antwort. PullMD gibt dagegen verbatim Markdown zurück, ohne LLM-Calls überhaupt.
Der Tradeoff ist damit klar: WebFetch ist billiger und schneller, weil der Kontext klein bleibt. PullMD ist vollständig — was im Markdown steht, ist was auf der Seite steht, nicht was Haiku darüber gedacht hat. Für „gib mir den genauen Wortlaut“, strukturierte Daten (Listen, Tabellen, Links) oder JS-lastige Seiten, auf denen WebFetch sowieso nur ein leeres React-Shell sieht, ist PullMD die richtigere Wahl. Für „ich brauche nur die Grundaussage“ reicht WebFetch.
Vergleichsfragen als Geschenk
Zwei weitere Comments, die ich als Vergleichsfragen und nicht als Angriffe gelesen habe:
u/KnackeHackeWurst:
“Isn’t that just like firecrawl?” — u/KnackeHackeWurst (+11)
„Ist das nicht einfach wie firecrawl?“ — u/KnackeHackeWurst (+11)
Ehrliche Abgrenzung: firecrawl ist ein vollständiger Crawler — Sitemap, Tiefe, Batch, AI-Extraktion. Die AI-Features brauchen OpenAI oder Ollama selbst im Self-Hosted-Betrieb. PullMD ist Single-URL, ohne LLM-Calls überhaupt, dafür mit MCP-Server und Claude-Code-Skill out of the box. Für „crawl eine komplette Docs-Site mit strukturierter LLM-Extraktion“: firecrawl. Für „URL-zu-Markdown in 30 Sekunden, kein Account, kein API-Key“: PullMD.
u/ardicli2000:
“Would not it be better to run a bash script as a skill which operates on your browser or headless or even with wget rather than on a server?” — u/ardicli2000 (+3)
„Wäre es nicht besser, ein Bash-Skript als Skill zu betreiben, das mit deinem Browser, Headless oder sogar mit wget arbeitet, statt auf einem Server?“ — u/ardicli2000 (+3)
Das ist eine valide Architektur-Frage. Ein Bash-Skript reicht für Single-User, Single-Machine. Der Server-Mode wird interessant, sobald mehrere Clients ins Spiel kommen: Caching über Sessions und Clients hinweg (6–13 ms warm statt bis zu 6 s cold), Claude Code auf mehreren Rechnern, Claude Desktop, die mobile PWA — alle treffen denselben Cache. Playwright als Sidecar einmal hosten kostet 3,7 GB Chromium-Binaries, einmal, nicht pro Skill-Aufruf. Refreshable Share-Links funktionieren, weil eine stabile URL auf dem Server lebt. Für alles davon brauchst du den Server.
Token-Benchmarks
Reddit fragte nach Zahlen. Also hängte ich abends einen EDIT an den Post — eigene Benchmarks von meiner Homelab-Instanz. Token-Counts sind tiktoken cl100k_base-Approximationen, keine exakten Claude-Tokens — die Größenordnung stimmt, die genaue Zahl nicht unbedingt.
| Quelle | Roh | PullMD | Reduktion |
|---|---|---|---|
| GitHub README | 141.599 | 3.125 | 97,8% |
| MDN Reference | 63.979 | 16.093 | 74,8% |
| Reddit Thread | 3.264 | 320 | 90,2% |
Der eigentliche Punkt steht in der rechten Spalte: je nach Quelle drei Viertel bis fast 98 Prozent weniger Token. Genau dafür ist PullMD da.
Das erste externe Issue
Am 28. April um 22:56 öffnete ein User namens andrewthetechie Issue #1:
MCP: remove structuredContent — Claude Code displays it instead of content[0].text
Zum ersten Mal hatte jemand Fremdes sich die Mühe gemacht, einen Bug-Report zu schreiben, weil mein Code etwas falsch macht. Das ist anders als ein Upvote: ein Issue ist Arbeit. Jemand hat das Tool installiert, das Problem reproduziert, formuliert, abgeschickt. Das kostet Zeit.
Gut eine halbe Stunde später, um 23:29: Issue #2 von einem anderen User — „Unable to open database file when running docker compose up“. Zwei Issues am selben Abend. Das Repo war seit weniger als 48 Stunden öffentlich.
Die Issue-Flut am 29. April
In den 24 Stunden danach: dreizehn Issues im Tracker. Kein stetiger Zustrom — ein Block, der entstand, während der Reddit-Post noch oben war. Die meisten kamen von fremden Usern; zwei davon (#5 und #6) habe ich selbst angelegt, um das Feedback zu bündeln — dazu gleich mehr.
Eine Auswahl der externen Meldungen, um das Spektrum zu zeigen:
- #7 — Add
DISABLE_PUBLIC_HISTORYenv var to hide history/archive on shared instances - #8 — MCP/REST: mojibake on ISO-8859-1 pages without explicit charset (z.B. winfuture.de)
- #9 — MCP: include full share URL in read_url response (LLMs hallucinate pullmd.com)
- #10 — Claude Desktop custom connector: how to authenticate (UI only supports OAuth)?
- #12 — Reddit threads with images: only image shows in markdown, header/comments missing
- #13 — Container images not published to GHCR
Sebastian WinFuture23 tauchte in diesen ersten Tagen mehrfach auf — er brachte Issue #8 mit winfuture.de als Testfall, und er wird in dieser Serie noch eine Rolle spielen. Ein konkreter Fall, den ich ohne diesen Hinweis vermutlich nicht so früh gefunden hätte.
GitHub Insights für diese 14-Tage-Periode: 397 Unique Visitors, 320 Unique Cloner. reddit.com als Top-Referrer mit 165 Views, 105 Unique.
Wie das Feedback meine Roadmap umstellte
Zwei der Issues kamen nicht von außen: #5 und #6 habe ich selbst angelegt, mit Claude Code, um zu bündeln, was der Thread an Hinweisen und Wünschen hervorgebracht hatte — zusammen mit meinen eigenen Überlegungen:
Architecture: Phase 1 — Multi-user system with sessions + API keys Architecture: Phase 2 — OAuth authorization code flow for claude.ai web connector
Multi-User war für mich bis dahin Phase 2 oder 3, irgendwo auf der Roadmap, für später. Aber das Feedback aus dem Thread — mehrere Clients, geteilte Instanzen, der Wunsch nach Authentifizierung — machte deutlich, dass „später“ nicht mehr stimmte. Also schrieb ich es auf und sortierte es nach oben.
Genau das passiert, wenn man eine Software public macht: die Reihenfolge der Features ist nicht mehr ausschließlich die eigene. Nicht weil Fremde sie diktieren, sondern weil ihr Feedback die eigene Einschätzung verschiebt.
Was danach passierte, ist Teil 6.
Teil 5 von 9 der PullMD Serie.
← PullMD Teil 4: Vom Tool für mich zum OSS-Projekt | PullMD Teil 6: Multi-User-Pivot →