PullMD Teil 9: Reddit-Tag und die ersten Issues – Einfach erklärt
Am 27. April morgens war das Repo öffentlich. (Ein Repo ist der Ort, an dem ein Softwareprojekt mit all seinen Dateien auf GitHub lebt.) Über Nacht passierte: fast nichts. Ein paar Sterne, vierzehn Leute, die sich das Projekt heruntergeladen hatten. Kein einziger Fehlerbericht, kein Kommentar.
Das war das erste Mal, dass ich beim Frühstück nebenbei auf ein Projekt schaute, das nicht mehr nur meins war.
Der Reddit-Post
Am 28. April schrieb ich einen Beitrag in r/ClaudeAI, einem großen Reddit-Forum für Leute, die mit Claude arbeiten. Der Titel: „PullMD - gave Claude Code an MCP server so it stops burning tokens parsing HTML“. Sinngemäß: Ich habe Claude einen kleinen Helfer gebaut, damit er beim Lesen von Webseiten nicht mehr so viel Energie verschwendet.
Zwei Frustrationen als Aufhänger, echte, nicht erfundene:
Erstens: Auf dem Handy einen langen Artikel zu kopieren ist eine Plackerei. Lange auf den Text drücken, die kleinen Auswahl-Anker vorbei an Werbebannern und Menüleisten ziehen, kopieren, App wechseln, einfügen. Nichts davon ist schwer. Aber es nervt jeden einzelnen Tag.
Zweitens: Wenn ein KI-Assistent eine Webseite liest, kämpft er sich erst durch Navigation, Cookie-Hinweise und Fußzeilen, bevor er zum eigentlichen Inhalt kommt. Token (die Bausteine, in die Computer Text zerlegen) werden an Ballast verschwendet, bevor die eigentliche Frage überhaupt anfängt.
Ich hatte keine besonderen Erwartungen. Ein Post unter Tausenden, mitten am Werktag.
Was über den Tag passierte
Zum Zeitpunkt dieses Artikels: 387 Upvotes, 58 Kommentare. Das war mehr als alles, was ich vorher auf Reddit gepostet hatte.
Der erste Kommentar, den ich las:
“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)
Was die Kommentare mir über mein eigenes Tool beibrachten
Der spannendste Kommentar kam von u/blin787. Er erklärte, wie eine ähnliche Funktion in Claude selbst schon eingebaut ist:
“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)
Auf Deutsch: Claude hat schon einen eingebauten Weg, Webseiten zu lesen. Dabei schickt er die Seite kurz an ein kleineres, günstigeres KI-Modell, das eine knappe Zusammenfassung zurückgibt. Diese Zusammenfassung sieht dann das große Modell. Schnell und günstig, aber eben nur eine Zusammenfassung, nicht der echte Wortlaut.
PullMD gibt den echten Seiteninhalt zurück. Wortgetreu, sauber als Text, kein zwischengeschaltetes Modell, das vielleicht etwas wegkürzt. Beide Wege haben ihren Platz: wenn du den genauen Wortlaut brauchst (Listen, Tabellen, Zitate), ist PullMD die bessere Wahl. Wenn dir die grobe Aussage reicht, tut es die eingebaute Variante.
Vergleichsfragen als Geschenk
Zwei weitere Kommentare las ich als ehrliche Vergleichsfragen, nicht als Angriffe.
“Isn’t that just like firecrawl?” — u/KnackeHackeWurst (+11)
„Ist das nicht einfach wie firecrawl?“ — u/KnackeHackeWurst (+11)
Firecrawl ist ein größerer Werkzeugkasten: es kann ganze Webseiten mitsamt allen Unterseiten herunterladen, dazu KI-Funktionen, die einen externen KI-Zugang brauchen. PullMD ist eine einzelne Adresse, eine einzelne Antwort, keine KI dazwischen. Für eine komplette Dokumentation in Stücke zerlegen: Firecrawl. Für eine einzelne Seite in dreißig Sekunden in sauberen Text verwandeln, ohne Konto, ohne Schlüssel: PullMD.
“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)
Die Frage ist berechtigt. Für eine einzelne Person auf einem einzelnen Rechner reicht ein kleines Skript völlig. Ein Server lohnt sich erst, sobald mehr ins Spiel kommt: derselbe Zwischenspeicher für mehrere Geräte, Handy und Laptop greifen auf dieselbe Datenbasis zu, und der Browser, der Webseiten unsichtbar lädt, läuft einmal an einem Ort statt zigfach lokal. Sobald man einen Link teilen will, der auch in zwei Tagen noch funktioniert, braucht es eine stabile Adresse irgendwo im Netz.
Reddit fragte nach Zahlen
Mehrere Leute wollten konkrete Zahlen sehen. Wie viel spart das Tool eigentlich ein?
Drei Beispiele, jeweils die Roh-Webseite gegen das, was PullMD daraus macht. Die „Roh“-Spalte zeigt die Token-Anzahl des originalen HTML, die „PullMD“-Spalte das, was nach der Verarbeitung übrig bleibt:
| 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% |
Die Zahlen sind Schätzwerte, keine perfekt exakten Werte. Aber die Größenordnung stimmt: drei Viertel bis fast 98 Prozent weniger Datenmenge. Genau darum geht es.
Das erste Issue von außen
Am selben Abend öffnete jemand namens andrewthetechie das erste Issue. Ein Issue ist eine Art Fehler- oder Wunsch-Zettel auf GitHub: jemand meldet ein Problem oder schlägt eine Verbesserung vor.
Zum ersten Mal hatte jemand Fremdes sich die Mühe gemacht, einen Fehlerbericht zu schreiben, weil mein Code etwas falsch macht. Das fühlt sich anders an als ein Daumen-hoch. Ein Issue ist Arbeit. Jemand hat das Tool installiert, das Problem nachgestellt, formuliert, abgeschickt.
Gut eine halbe Stunde später: Issue Nummer zwei, von jemand anderem. Zwei Issues am selben Abend. Das Repo war seit weniger als 48 Stunden öffentlich.
Die Welle am Tag danach
In den 24 Stunden danach: dreizehn Issues im Tracker. Kein gleichmäßiger Strom, sondern ein Block, der entstand, solange der Reddit-Beitrag noch sichtbar war. Die meisten kamen von fremden Nutzern. Zwei davon habe ich selbst angelegt, dazu gleich mehr.
Eine Auswahl, um zu zeigen, wie breit das Spektrum war:
- Eine Schalter-Option, um die öffentliche Verlauf-Liste auf geteilten Servern auszublenden
- Manche älteren Webseiten zeigen kaputte Sonderzeichen, weil die Zeichenkodierung nicht erkannt wird
- Reddit-Threads mit Bildern verschluckten Überschrift und Kommentare
- Die fertigen Installations-Pakete waren nicht an der erwarteten Stelle abrufbar
Einer der Melder tauchte in diesen ersten Tagen mehrfach auf. Er brachte einen konkreten Fall von einer deutschsprachigen Nachrichtenseite mit. Ohne seinen Hinweis hätte ich das Problem mit den Sonderzeichen vermutlich noch wochenlang nicht entdeckt.
Die Statistik-Seite von GitHub für diese zwei Wochen: knapp 400 verschiedene Besucher, gut 300 Leute, die das Repo heruntergeladen haben. Reddit war mit Abstand die häufigste Quelle.
Wie das Feedback meine Reihenfolge umwarf
Zwei der Issues kamen nicht von außen. Die habe ich selbst angelegt, um all die Hinweise und Wünsche aus dem Reddit-Thread zu bündeln. Das wichtigere davon: „Mehrere Menschen sollen das Tool gleichzeitig nutzen können.“ Sitzungen, Zugangsschlüssel, getrennte Daten pro Person. Eine ganze kleine Architektur, nüchtern als „Phase 1“ notiert.
Mehrere Nutzer gleichzeitig: das war für mich eigentlich Phase 2 oder 3, irgendwo auf der Liste für später. Aber das Feedback aus dem Thread machte klar, dass „später“ nicht mehr stimmte. Also schrieb ich es auf und sortierte es nach oben.
Genau das passiert, wenn man eine Software öffentlich macht: die Reihenfolge der Features bestimmt man nicht mehr allein. Nicht weil Fremde sie vorschreiben, sondern weil ihr Feedback die eigene Einschätzung verschiebt.
Was danach passierte, ist Teil 10.
Teil 9 von 15 der PullMD Serie.
← PullMD Teil 8: Vom Tool für mich zum OSS-Projekt | PullMD Teil 10: Absichern, aber richtig →