1. Eine KI erfindet eine Figur, obwohl sie nur nach einer Website gefragt wurde
Eine kleine Website veröffentlichte mit KI-Unterstützung immer mehr Artikel. Einige verglichen Persönlichkeitstypen mit Figuren aus Chiikawa, besonders mit Hachiware. Als eine andere KI nach dem Maskottchen der Website gefragt wurde, schlug sie vor, es handle sich um einen angeblichen „anstrengenden Hachiware“ aus der Serie.
Wer soll das denn sein?
Die eigene Website-Figur war plötzlich in eine fremde Geschichte versetzt worden. Ohne Bewerbung, ohne Vorstellungsgespräch. Die KI stellte sie einfach ein.
Gesichert ist lediglich, dass die KI diese Antwort gab. Ob sie die Artikel tatsächlich gelesen, nur Namen miteinander verknüpft oder frei erfunden hat, wissen wir nicht. Es gibt hier auch keinen Beleg dafür, dass die angebliche Figur offiziell existiert. Selbstbewusst formuliert heißt nicht überprüft.
2. Im Hintergrund arbeitet die Artikelfabrik weiter
Der Ablauf schreibt Texte, macht sie verständlicher, erstellt vollständige Fassungen in zwölf Sprachen, prüft, veröffentlicht und verteilt Links. Wenn etwas stehen bleibt, wird die Ursache gesucht, repariert und das Ergebnis erneut geprüft.
Irgendwann werden die Fortschrittsberichte zum eigenen Fortsetzungsroman.
KI A: „Der Veröffentlichungsfehler ist behoben.“
KI B: „Alle Prüfungen bestanden.“
KI C: „Ich habe einen weiteren Grund für den Stillstand gefunden.“
Leitung: „Dann holen wir noch jemanden für die Reparatur.“
Leserschaft: „Demnächst ist der Statusbericht länger als der eigentliche Artikel.“
Der entscheidende Unterschied: Eine gespeicherte Reparatur ist noch keine nachweislich funktionierende öffentliche Seite. Eine Inhaltsfabrik braucht oft auch eine Reparaturwerkstatt.
3. „Schon 1.900 Artikel?“ Zuerst muss klar sein, was gezählt wird
Hinter einer Artikelzahl können mindestens fünf Dinge stecken:
- Originalartikel: eigenständige Inhalte und Ideen.
- Sprachversionen: Übersetzungen desselben Originals.
- Fertige, unveröffentlichte Texte: noch in Prüfung oder Warteschlange.
- Veröffentlichte Seiten: für Leser tatsächlich erreichbare Texte.
- Website-Pfade: möglicherweise einschließlich Menüs, Anwendungen und anderen Seiten.
1.000 Originalartikel, die vollständig in zwölf Sprachen veröffentlicht werden, können bis zu 12.000 Sprachseiten ergeben. Das sind nicht 12.000 unterschiedliche Ideen.
In einer Betriebsaufnahme standen 15.862 Website-Pfade. Das bedeutete nicht 15.862 japanische Originalartikel. Für Aussagen wie „1.900 Artikel“ braucht man Datum, Zähleinheit und Veröffentlichungsstatus. Sonst wächst die Statistik schneller als das Verständnis dafür.
4. Das GitHub-Repository war etwa 2,46 GB groß
Bei einem anonymisierten Beispiel meldete GitHub 2.400.972 KiB. Das entspricht ungefähr 2,29 GiB beziehungsweise 2,46 GB in dezimalen Einheiten. Die Angabe stammt vom 8. Oktober 2026.
„Sind Artikel nicht einfach nur Text?“
In einem Repository können außerdem Programmcode, Übersetzungen, Veröffentlichungslisten, Prüfergebnisse, Bilder, Audio und frühere Versionen liegen. Aus der Gesamtgröße allein lässt sich aber nicht ableiten, was wie viel Platz belegt. Dafür wäre eine separate Analyse nötig. Die GitHub-Angabe ist auch nicht automatisch mit der Größe eines lokalen Ordners identisch.
Artikel: „Ich brauche nur ein paar KB.“
Verlauf: „Ich habe alle alten Fassungen aufgehoben.“
Übersetzungen: „Wir sind zu zwölft gekommen.“
Lager: „Hat mich eigentlich jemand gefragt?“
5. Die Antwort: GitHub Free bedeutet nicht „insgesamt 5 GB, danach bezahlen“
Für gewöhnliche Git-Repositories nennt GitHub kein einziges allgemeines Gesamtvolumen in GB, nach dessen Überschreitung im kostenlosen Tarif automatisch eine Rechnung beginnt. 5 GB sind eine starke Größenempfehlung und keine Zahlungsschwelle.
Die offizielle Dokumentation bezeichnet unter 1 GB als ideal und empfiehlt nachdrücklich, unter 5 GB zu bleiben. Ein weiteres Dokument empfiehlt für die komprimierten Git-Daten eine maximale Größe von 10 GB auf dem Datenträger. Auch das ist keine Garantie für 10 GB freien Speicher.
Belastet ein Repository die Infrastruktur übermäßig, kann GitHub Korrekturen verlangen. „Ab 5 GB kostet es Geld“ ist falsch, aber „kostenlos heißt unbegrenztes Lager“ ebenso.
6. Die tatsächlichen Grenzen betreffen unterschiedliche Bereiche
| Bereich | Grenze oder kostenlos enthaltene Nutzung |
|---|---|
| Gewöhnliches Git-Repository insgesamt | Keine einheitliche Gesamt-GB-Abrechnungsgrenze; ideal unter 1 GB, dringend empfohlen unter 5 GB |
| Git-Daten auf dem Datenträger | Empfohlene Obergrenze 10 GB, keine Preisschwelle |
| Eine gewöhnliche Datei | Warnung über 50 MiB, Ablehnung über 100 MiB; im Browser höchstens 25 MiB |
| Eine einzelne Übertragung | Grenze von 2 GiB |
| Git LFS für große Dateien | GitHub Free enthält 10 GiB Speicher und 10 GiB Datenübertragung; getrennt vom normalen Git |
| Ergebnisse von GitHub Actions | GitHub Free enthält 500 MB Speicher sowie üblicherweise 2.000 Ausführungsminuten pro Monat |
Das ist kein gemeinsamer Speicherpool. Für Mehrverbrauch bei LFS, Actions und anderen Diensten gelten eigene Abrechnungs- und Budgetregeln. Ein normales Repository mit 2,46 GB verbraucht dadurch nicht automatisch die 500 MB für Actions-Ergebnisse. Umgekehrt können andere Kontingente erschöpft sein, obwohl das Repository noch unter 5 GB liegt.
7. Warum ein Repository schneller wächst als die Artikelzahl
Git bewahrt nicht nur aktuelle Dateien auf, sondern auch ihre Änderungen. Wird eine riesige Übersicht stündlich neu geschrieben, erscheint in der neuesten Version weiterhin nur eine Datei, während ältere Fassungen in der Historie verbleiben können. Dazu kommen überarbeitete Artikel, neu erzeugte Übersetzungen, Prüfprotokolle und wiederholt gespeicherte Ergebnisse. Der Platzbedarf wächst deshalb nicht einfach proportional zur Zahl der neuen Artikel.
Allerdings komprimiert Git Daten und kann ähnliche Versionen effizient speichern. Eine Bearbeitung verdoppelt den Speicherbedarf keineswegs automatisch. Die wirklichen Platzfresser müssen gemessen werden.
Quelltexte und Programmcode gehören in Git, wenn ihre Entwicklung nachvollziehbar bleiben soll. Häufig neu erzeugte Ausgaben und große Medien können je nach Bedarf außerhalb von Git aufbewahrt werden.
8. Schreibkonflikte können früher auftreten als Platzmangel
Wenn mehrere KI-Agenten nahezu gleichzeitig dieselbe Datei bearbeiten, geraten ihre Änderungen in Konflikt. Eine Reparatur ist fertig, während ein anderer Prozess noch eine veraltete Veröffentlichungsliste liest. Der Artikel ist bereit, doch auf der Website steht weiterhin die alte Fassung.
Nicht jeder Stillstand bedeutet „GitHub ist voll“. Dateigröße, Änderungsrate, parallele Zugriffe und Veröffentlichungskonsistenz sind unterschiedliche Probleme.
Eine sinnvolle Prüfung hat vier Schritte: Liegt der neueste Quelltext vor? Hat er die Prüfungen bestanden? Wurde er ausgeliefert? Zeigt die öffentliche Seite tatsächlich genau diese Fassung? Erst nach Schritt vier sollte man den Bericht „behoben!“ feiern.
9. Vier Maßnahmen für einen langfristig gesunden Gratisbetrieb
Erst messen, dann löschen. Große Dateien und historische Daten untersuchen, nicht nur die Gesamtzahl anschauen. GitHub verweist dafür auch auf Hilfsmittel wie git-sizer.
Wegwerf-Ergebnisse auslagern. Immer wieder erzeugte Indizes, kurzlebige Protokolle sowie Bild- und Audiodateien müssen nicht zwangsläufig dauerhaft Teil der Git-Historie sein.
Überflüssige Änderungen vermeiden. Eine fachlich unabhängige Kleinigkeit sollte nicht jedes Mal eine große gemeinsame Datei neu aufbauen. Bei Konflikten den aktuellen Zustand erneut einlesen und das reale Ergebnis prüfen.
Historie nicht leichtfertig umschreiben. Das Löschen einer Datei aus dem neuesten Stand entfernt sie nicht unbedingt aus älteren Commits. Änderungen an gemeinsamer Historie können Verweise und Kopien beschädigen. Vorher Auswirkungen prüfen und Sicherungen anlegen.
10. Entscheidend ist nicht die Menge, sondern der Nutzen für Leser
Tausende Originalartikel und Zehntausende Übersetzungsseiten garantieren keine Besucher. Können Leser die Seiten finden? Stimmen die Fakten? Klingen die Texte in jeder Sprache natürlich? Bieten sie eigene Gedanken statt bloßer Wiederholung?
Googles öffentliche Empfehlungen betonen hilfreiche, eigenständige Inhalte für Menschen. Die Richtlinien wenden sich auch gegen die massenhafte Herstellung wertarmer Seiten, deren Hauptzweck die Manipulation von Suchergebnissen ist. Nicht der Einsatz von KI an sich ist das Problem, sondern Massenproduktion ohne echten Nutzen.
Der angebliche „anstrengende Hachiware“ ist das passende Schlussbild: Als Witz ist eine KI-Erfindung ausgezeichnet. Als offizielle Figurenbeschreibung taugt sie ohne Beleg nicht.
Artikelfabrik: „Ich vermehre die Artikel.“
GitHub: „Ich speichere mehr Historie.“
Prüfung: „Ich reduziere die Fehler.“
Such-KI: „Ich vermehre die Figuren!“
Alle: „Diese Vermehrung war nicht bestellt!“
Fazit: 5 GB sind keine Bezahlschranke von GitHub Free. Speicherbedarf, Veröffentlichung, Qualität und KI-Behauptungen müssen jeweils gesondert geprüft werden. Der wirkliche Erfolg besteht in verlässlichen Inhalten, die Leser tatsächlich erreichen – nicht nur in gespeicherten Dateien.
