6 Open-Source-AI-Projekte auf GitHub, die ich wirklich getestet habe

Ich hätte das erste Repository fast nicht geklont.

Es war ein Sonntagmorgen, ich hatte drei Kaffees bereitstehen und einen halb geschriebenen Agenten, der ständig Tool-Argumente halluzinierte, und mein GitHub-Tab „Trending“ machte wieder dieses Ding, bei dem jedes Projekt wie derselbe Screenshot aussieht – dunkles Terminal, lila Farbverlauf, „autonomous“ im Slogan. Ich war kurz davor, den Browser zu schließen und meinen kaputten Agenten mit Claude Code und roher Gewalt zu reparieren. Dann sah ich Hermes Agent, schaute mir das Diagramm der Speicherarchitektur an und dachte: Moment, das könnte tatsächlich das Problem lösen, das ich gerade mit Gewalt zu knacken versuche.

So fing dieser Beitrag an.

In der folgenden Woche habe ich sechs Open-Source-AI-Projekte geklont, die im März und Anfang April 2026 auf GitHub in den Trending-Charts nach oben geklettert sind. Nicht, um sie wie ein Tourist anhand von Pressemitteilungen zu bewerten. Sondern um sie wirklich auf meinem Rechner auszuführen, sie kaputt zu machen, die Teile zu testen, die im README übersprungen werden, und herauszufinden, welche davon dein Wochenende wert sind. Einige davon haben meine Sicht darauf verändert, wo KI eigentlich lebt (Tipp: nicht immer im Rechenzentrum). Eines davon implementiert Agenten-Memory auf eine Weise, die ich jetzt schamlos in meinen eigenen Stack übernehme. Und eines ist eine winzige CLAUDE.md-Datei, die vielleicht still und leise das nützlichste Tool ist, das ich diesen Monat installiert habe.

Bevor wir zu den sechs Projekten kommen, ein Gedanke, der mir beim Testen immer wieder kam: Die spannende Grenze bei Open-Source-AI ist aktuell nicht das größere Modell. Es geht um kleinere, spezialisiertere, lokalere Lösungen, die ehrlicher damit umgehen, was LLMs eigentlich sind. Jedes Projekt auf dieser Liste bewegt sich in diese Richtung – weg von „ein riesiges Cloud-Modell macht alles“ und hin zu „kleine Bausteine, lose verbunden, laufen dort, wo du tatsächlich arbeitest“.

Los geht’s.

Warum sich dieses Roundup von den anderen unterscheidet, die du schon gelesen hast

Ich weiß. Noch ein Beitrag über „trending GitHub Repos“. Ich scrolle auch daran vorbei.

Das Problem bei den meisten dieser Roundups ist, dass sie direkt aus dem README geschrieben werden. Jemand öffnet das Repo, liest die angepinnte Beschreibung, schnappt sich den Screenshot und paraphrasiert die Feature-Liste in fünfzehn Absätze AI-ähnlichen Prosa. Am Ende des Artikels hast du keine Ahnung, wie es wirklich ist, das Tool zu benutzen.

Ich bin einen anderen Weg gegangen. Für jedes dieser sechs Projekte habe ich drei Dinge gemacht:

Das Repo geklont und lokal zum Laufen gebracht – oder es so installiert, wie es ein normaler Nutzer tun würde (die Edge Gallery landete auf meinem iPhone, das Karpathy-Skill wurde als echtes Plugin in Claude Code integriert).
Eine konkrete Aufgabe ausgeführt, die meinem realen Arbeitsalltag entspricht – nicht die ausgewählte Demo aus dem Readme.
Das erste notiert, was kaputtging, verwirrte oder nicht zum Marketing passte.

Genau dieser dritte Punkt ist der Grund, warum dieser Beitrag seine Wortzahl verdient. Die ersten beiden Dinge bekommst du in jedem Blog. Der dritte Teil ist das, was dir einen vergeudeten Samstag erspart.

Ein kurzer Hinweis: Ich schreibe schon eine Weile über das Open-Source-Agenten-Ökosystem, und einige dieser Projekte überschneiden sich mit Themen, die ich bereits behandelt habe – etwa das Agenten-Skillsystem von Claude Code, Open-Source-Alternativen zu Claude wie OpenClaw und das Management von Multi-Agenten-Workflows mit Kanban-Tools. Wo es einen direkten Link gibt, verweise ich dich auf den ausführlicheren Beitrag, statt alles zu wiederholen.

Also gut. Sechs Projekte. Fangen wir mit dem an, das still und heimlich am disruptivsten ist.

1. Google AI Edge Gallery — Der App Store für winzige LLMs in deiner Hosentasche

Das erste Mal, wenn du die Google AI Edge Gallery installierst und dein WLAN ausschaltest, fühlt es sich an wie ein kleiner Zaubertrick.

Du öffnest die App. Du lädst ein Modell – zum Beispiel eine der Gemma-4-Varianten mit kleinem Footprint aus dem integrierten Katalog. Du tippst auf „Chat“. Du stellst eine Frage. Es antwortet. Kein Lade-Spinner, der auf einen Server wartet. Kein „Verbindung wird überprüft...“-Banner. Kein Token-Zähler irgendwo in der Cloud, der hochzählt. Nur ein Modell, das Silizium deines Smartphones und eine Antwort.

Das ist das Versprechen – und es ist Realität.

Was es eigentlich ist

AI Edge Gallery ist eine Open-Source-Referenz-App von Google – Kotlin auf Android, Swift auf iOS – gebaut auf LiteRT-LM, Googles neuer High-Performance-Inferenz-Engine für LLMs am Edge. Stell dir die Gallery als Schaukasten und Entwickler-Tool in einem vor: eine ausgereifte Endnutzer-App, die du direkt auf deinem Smartphone laufen lassen kannst, und ein Open-Source-Codebase, das du forken, abspecken und für dein eigenes Mobile-AI-Projekt wiederverwenden kannst.

Das Repository findest du unter google-ai-edge/gallery auf GitHub. Die iOS-Version gibt es im App Store als „Google AI Edge Gallery“. Und das Entscheidende: Die komplette Referenzimplementierung – Modellauswahl-UI, lokale Inferenz, strukturierte Ausgaben, sogar agentische Tool-Calls – ist im Codebase enthalten und kann von dir eingesehen werden.

Was ich getestet habe

Ich habe die App in drei konkreten Richtungen getestet:

Test 1: Flugmodus, Long-Form-Generierung. Ich habe eine kleine Gemma-Variante geladen, mein iPhone in den Flugmodus versetzt und es gebeten, aus einer Bullet-Liste eine dreiparagrafische Release-Note zu verfassen. Die Antwort war vielleicht 40 % langsamer als ein Cloud-Call vom selben Ort aus, aber – und das ist der Punkt – sie kam überhaupt, auf einem Gerät, das für das Netzwerk praktisch ein Ziegelstein war. Für unterwegs, wenn Privatsphäre zählt (medizinische Notizen, Kundenbriefings, alles, was nicht durch eine Drittanbieter-API laufen soll), ist das schon jetzt nützlich.

Test 2: Agentenfähigkeiten mit Tool-Calls. Laut Google Developers Blog unterstützt Gemma 4 am Edge jetzt sogenannte „agentische Fähigkeiten“ – also Grounding via Wikipedia, interaktive Karten, Summary Cards. Ich habe den Wikipedia-basierten Flow ausprobiert und er funktionierte im Großen und Ganzen wie angekündigt, auch wenn die Zuverlässigkeit der Tool-Calls sichtbar wackeliger war als bei größeren Cloud-Modellen. Für ein Demo okay. Für Produktion noch nicht.

Test 3: Forken des Codes in mein eigenes Mobile-Projekt. Hier zahlt sich die Gallery aus. Weil es eine echte, ausgelieferte Referenz-App ist, kannst du genau nachvollziehen, wie Google sich On-Device-LLM-Inferenz vorstellt – Modellverwaltung, Speicherhandling, Prompt-Konstruktion, der ganze Stack. Ich habe eine Stunde lang die Inferenz-Pipeline gelesen und dabei mehr über praktische Edge-AI-Architektur gelernt als in drei Wochen Blogposts.

Was noch nicht passt (oder zumindest holprig ist)

Zwei ehrliche Einschränkungen. Erstens: Die Modelle, die du heute realistisch auf einem Smartphone laufen lassen kannst, sind wirklich klein – und ihre Schwächen sind sichtbar. Erwarte selbstbewussten Unsinn bei allem, was breites Weltwissen oder mehrstufiges Denken erfordert. Zweitens: Der agentische Tool-Call-Pfad ist neu und noch etwas fragil – wenn er scheitert, dann meist stillschweigend, was ein schlechteres Fehlerbild ist als ein lauter Fehler.

Das eigentliche Fazit

On-Device-AI ist kein „cooles Demo aus einem Forschungspaper“ mehr. Sie wird ausgeliefert, als Open Source, mit einer produktionsreifen Referenz-App, die du sofort nutzen kannst. Jeder Mobile-Entwickler, den ich kenne, sollte einen Abend investieren, dieses Repo zu klonen und den Inferenz-Code zu lesen. Die Zukunft, in der jede App ein kleines lokales Modell hat, das 80 % der Arbeit erledigt, bevor sie überhaupt eine Cloud-API anruft, ist gerade deutlich näher gerückt.

Und das war Projekt eins. Wenn es bei der Edge Gallery darum geht, wo KI läuft, geht es beim nächsten Projekt darum, wie wir von ihr lernen.

2. DeepTutor — Open-Source, Agent-Native Learning Assistant

Ich sage jetzt etwas, das für ChatGPT unfair klingen mag: Um wirklich aus einem Dokument zu lernen, ist das reine Chatfenster die falsche Oberfläche.

Du kennst das: Du lädst ein PDF hoch, stellst Fragen, bekommst Antworten, aber du lernst das Dokument nie wirklich. Es gibt keine Struktur. Kein Fortschritt. Kein „Das hast du verstanden, das ist noch unsicher, hier eine Übungsfrage zum Überprüfen.“ Das Dokument und der Chat existieren in zwei verschiedenen Universen, und du kopierst hektisch zwischen ihnen hin und her.

DeepTutor aus dem Data-Science-Labor der Universität Hongkong ist der ernsthafteste Open-Source-Versuch, den ich bisher gesehen habe, um dieses Problem zu lösen.

Was es ist

DeepTutor bezeichnet sich selbst als „agent-native personalisierter Lernassistent“. Übersetzt: Es ist ein Open-Source-Multi-Agenten-System, das auf der Idee basiert, dass Lernen ein Workflow ist – kein Chat. Du lädst PDFs, TXT- oder Markdown-Dateien hoch. Es erstellt daraus eine durchsuchbare Wissensdatenbank. Dann laufen darauf verschiedene Agenten: einer für Dokumenten-Q&A mit korrekten Zitaten, einer für die Generierung von Übungsfragen, einer für geführte, mehrstufige Lernpfade, einer für den Aufbau eines Wissensgraphen, der Entitäts- und Relationszuordnungen über dein Material hinweg abbildet.

Der für mich spannendste Teil: Es pflegt ein persistentes „Profil“ von dir – deine Ziele, Präferenzen, deinen Lernfortschritt – und eine fortlaufende „Zusammenfassung“ dessen, was du gelernt hast. Genau dieser Feedback-Loop fehlt Chat-Oberflächen.

Laut den Maintainers hat das Projekt innerhalb der ersten Woche nach Release über 1.400 GitHub-Sterne gesammelt und wächst weiter. Die aktuelle Sternzahl habe ich nicht unabhängig überprüft, aber die Aktivität im Repository ist offensichtlich real.

Was ich getestet habe

Ich habe es auf einen Stapel losgelassen, den ich tatsächlich verstehen musste: die Anthropic Agent SDK-Dokumentation plus zwei lange technische PDFs zur Speicherarchitektur für Agenten. Insgesamt etwa 180 Seiten in drei Dateien. Das ist passiert:

Ich habe die Dateien hochgeladen, auf das Indexieren gewartet (überraschend schnell – unter zwei Minuten auf einem Mittelklasse-Rechner) und eine Frage gestellt, mit der ich mich schon länger herumgeschlagen hatte: „Wann greift die Speicherkompaktierung des SDK, und was sind die Trade-offs zwischen eager und lazy compaction?“ Die Antwort kam mit konkreten Zitaten aus den exakten Passagen der PDFs zurück, keine vagen Umschreibungen. Allein das war schon besser als jede Chat-mit-PDF-Erfahrung, die ich zuvor ausprobiert hatte.

Dann habe ich den Übungsfragen-Generator getestet. Er hat fünf Fragen auf ungefähr dem richtigen Schwierigkeitsgrad erstellt, von denen drei wirklich hilfreich waren (die anderen beiden waren eher Trivia). Der geführte Lernpfad war dann das eigentliche Highlight – er hat aus den drei Dokumenten einen groben Lehrplan mit Checkpoints gemacht.

Wo es schwächelt

Das Setup ist aufwendiger als „App installieren“. Es handelt sich um ein Open-Source-Multi-Agenten-System, das heißt, du musst Modelle, Umgebungsvariablen und eine lokale Laufzeitumgebung einrichten. Das ist ein Projekt für Entwickler und Power-User, nicht für deinen nicht-technischen Freund, der einfach einen besseren PDF-Chat sucht. Außerdem schwankt die Qualität der Übungsfragen und des Wissensgraphen stark, je nachdem, welches LLM du einbindest.

Warum es wichtig ist

DeepTutor zeigt auf etwas, das größer ist als das Projekt selbst. Die Zukunft des „Lernens mit KI“ ist kein Chatfenster, das an einen PDF-Viewer angeflanscht ist. Es sind speziell entwickelte Agenten-Workflows, bei denen die KI deine Ziele, deinen Fortschritt und das Material kennt – und alles orchestriert. DeepTutor ist eine frühe, noch unvollkommene, aber sehr vielversprechende Version dieser Zukunft – und komplett Open Source. Wenn du unterrichtest, Nachhilfe gibst, Kursmaterial schreibst oder einfach nur intelligenter aus deinem Dokumentenstapel werden willst, klone es.

Das waren zwei Projekte darüber, wo KI lebt und wie wir von ihr lernen. Jetzt kommen wir zu dem, das meine Sicht auf Agenten-Memory leise, aber grundlegend verändert hat.

3. Hermes Agent — Ein KI-Agent, der sich wirklich erinnert

Okay. Das ist der Agent, der mich dazu gebracht hat, meine eigene Agenten-Architektur neu zu überdenken.

Hier ist das Problem, auf das jeder Entwickler von Open-Source-KI-Agenten früher oder später stößt: Speicher. Man startet mit einem sauberen Prompt, baut im Verlauf einer Session Kontext auf, und alles funktioniert. Dann versucht man, den Agenten dazu zu bringen, sich auch über mehrere Sessions hinweg zu erinnern. Der erste Impuls: Alles in den System-Prompt stopfen — vergangene Gespräche, Nutzerpräferenzen, Projektdetails. Das klappt. Bis es nicht mehr klappt. Bis der Prompt ins Unermessliche wächst, die Kosten explodieren, die Latenz in den Keller geht und das Modell beginnt, mit voller Überzeugung Dinge falsch zu erinnern, die es eigentlich wissen sollte.

Ich habe dieses Muster ein Dutzend Mal gesehen. Ich habe dieses Muster ein Dutzend Mal gebaut. Hermes Agent von Nous Research ist das erste Open-Source-Framework, das Speicher als ein zentrales Architekturproblem behandelt und es so löst, wie es gelöst werden sollte: mit spezialisierten, abrufbaren Speicherebenen statt Prompt-Stuffing.

Was steckt wirklich im Speichersystem?

Laut Projektdokumentation nutzt Hermes eine mehrstufige Speicherarchitektur (das Marketing spricht mal von drei Ebenen, mal von Multi-Level — ich halte mich an die Beschreibung in den Docs). Mindestens unterscheidet Hermes:

Session-Speicher — der laufende Kontext der aktuellen Interaktion.
Permanenter Speicher — Fakten, Präferenzen und Projektdetails, die über Sessions hinweg erhalten bleiben.
Skill-Speicher — wenn der Agent eine nicht-triviale Aufgabe löst, schreibt er ein wiederverwendbares „Skill-Dokument“, das beschreibt, wie er vorgegangen ist. Dieses Dokument wird zu einem abrufbaren Element, auf das der Agent später zurückgreifen kann.

Unter der Haube nutzt die permanente Ebene FTS5 Full-Text-Suche plus LLM-basierte Zusammenfassungen. Statt jede vergangene Konversation in den Prompt zu stopfen, ruft der Agent nur die relevanten Ausschnitte ab, wenn sie gebraucht werden. Außerdem kommt ein dialektisches User Modeling (übernommen von Honcho) zum Einsatz, um ein lebendiges Nutzerprofil zu pflegen, statt eines statischen „Über mich“-Blocks.

Nous Research nennt das „einen Agenten, der mit dir wächst“. Nach meinen Tests ist diese Beschreibung durchaus gerechtfertigt.

Was ich getestet habe

Ich habe Hermes in einem Szenario getestet, das ich gut kenne: ein langfristiges Coding-Projekt, bei dem der Agent sich an Architekturentscheidungen über mehrere Sessions hinweg erinnern muss, ohne jedes Mal neu gebrieft zu werden. Ich habe ihm eine fiktive SaaS-Codebasis beschrieben, ein Designgespräch geführt, die Session beendet, bin drei Stunden später zurückgekommen und habe eine Folgefrage gestellt, die von einer früheren Entscheidung abhing.

Er hat sich erinnert. Nicht, indem der gesamte vorherige Chat im Kontext lag — sondern indem er das spezifische Entscheidungsdokument abgerufen, präsentiert und darauf aufgebaut hat. Das ist das richtige Verhalten, und es ist das erste Mal, dass ich das in einem Open-Source-Agenten-Framework so sauber gesehen habe.

Ich habe auch die Skill-Generierung getestet: Ich habe Hermes durch eine etwas komplexere Aufgabe geführt (Gerüst für ein TypeScript-CLI), und nach Abschluss geprüft, ob er sich selbst einen Skill geschrieben hat. Das hatte er. Das Skill-Dokument war nicht perfekt — es war etwas zu spezifisch auf die konkrete Aufgabe zugeschnitten — aber der Loop funktionierte. Beim nächsten Mal, wenn ich ihn bitte, etwas Ähnliches zu scaffolden, kann er auf diesen Skill zurückgreifen.

Worauf ich achten würde

Hermes ist jung, entwickelt sich schnell und die Architektur ist ambitioniert. Ein paar Dinge, auf die man achten sollte: Die Qualität des Retrievals hängt stark davon ab, wie gut der FTS5-Index gebaut ist, Skill-Dokumente können sich mit Ballast anreichern, wenn man sie nicht gelegentlich ausmistet, und weil das System sich selbst modifiziert (Skills werden im Laufe der Zeit hinzugefügt), sollte man den Skill-Store wie ein Code-Repository behandeln — also prüfen, was geschrieben wird, und nicht blind vertrauen.

Wer einen persistenten KI-Agenten baut, sollte sich dieses Projekt diesen Monat anschauen. Nicht unbedingt, um es komplett zu übernehmen, sondern um daraus zu lernen. Das mentale Modell — Speicher als Retrieval über spezialisierte Ebenen, nicht als Prompt-Stuffing — ist das richtige Modell, und Hermes ist die sauberste Open-Source-Implementierung, die ich bisher gefunden habe.

Und das führt direkt zum nächsten Problem: Wenn man erst einmal smarte Agenten hat, wie betreibt man mehr als zwei davon, ohne den Verstand zu verlieren?

4. Multica — Projektmanagement für Mensch-Plus-Agent-Teams

Ich habe ein Geständnis. Monatelang bestand mein „Multi-Agent-Workflow“ aus sechs Claude-Code-Terminals in einem Tiling-Window-Manager, benannt von agent-1 bis agent-6, und einem Notion-Dokument, das ich gelegentlich manuell aktualisierte. Das ist kein Workflow. Das ist ein Bewältigungsmechanismus.

Multica versucht genau dieses Problem zu lösen.

Was es ist

Multica bezeichnet sich selbst als „die Open-Source-Plattform für gemanagte Agents“ — eine Orchestrierungs- und Projektmanagementschicht für AI-Coding-Agents. Anders als Tools, die selbst der Agent sein wollen, legt sich Multica um die Agents, die du bereits nutzt (Claude Code, Codex, OpenClaw, OpenCode — der Daemon erkennt automatisch CLIs auf deinem PATH) und bietet dir ein Kanban-ähnliches Interface, um Aufgaben zuzuweisen, zu verfolgen und die Arbeit zwischen ihnen zu koordinieren.

Das Versprechen in einfachen Worten: „Behandle deine Coding-Agents wie Teamkollegen.“ Du erstellst eine Aufgabe. Du weist sie einem Agent zu. Der Agent nimmt sie an, meldet den Status, markiert Blocker und aktualisiert das Board während der Bearbeitung. Du bekommst ein Mission-Control-Dashboard, das in Echtzeit zeigt, was jeder Agent gerade macht, und einen Aufgaben-Lebenszyklus, der dem tatsächlichen Ablauf in menschlichen Engineering-Teams entspricht.

Multica ist selbst-hostbar via Docker Compose oder Kubernetes; es gibt aber auch eine verwaltete Cloud-Version, falls du keine eigene Infrastruktur betreiben willst.

Was ich getestet habe

Ich habe die selbstgehostete Docker-Compose-Version auf meiner Entwicklungsmaschine laufen lassen, sie mit meiner lokalen Claude-Code-Installation verbunden und drei kleine Aufgaben eingespielt: einen Rate Limiter zu einer Express-API hinzufügen, eine GitHub Action für ein Node-Projekt schreiben und eine unübersichtliche React-Komponente refaktorisieren. Standardaufgaben, die jeder vernünftige Coding-Agent bewältigen sollte.

Was mir gefallen hat: Zu sehen, wie die Kanban-Spalten in Echtzeit aktualisiert wurden, während der Agent Tickets von „queued“ → „in progress“ → „needs review“ verschob. Als der Agent beim Refactoring der React-Komponente hängen blieb, weil die Komponente komplizierter war als im Ticket beschrieben, hat er einen Blocker markiert, statt stillschweigend Unsinn zu generieren. Genau dieses Verhalten wünscht man sich von einem gemanagten System.

Was mir weniger gefallen hat: Das initiale Setup hat länger gedauert als erwartet. Die automatische Erkennung meines Claude-Code-CLI war problemlos, aber damit die Runtime mit meinem bevorzugten Projektverzeichnis kommunizierte, waren ein paar Konfigurationsanpassungen nötig. Nicht schwierig, aber eben auch nicht „One Click“.

Wo es glänzt — und wo nicht

Multica spielt seine Stärken aus, wenn du tatsächlich mehrere Agents parallel an verwandten Aufgaben arbeiten lässt. Sobald du drei oder mehr Agents über ein Projekt orchestrierst, wird ein Tool wie Multica von „schönes UI“ zu „wirklich notwendig“. Wenn du nur einen Agent auf eine Aufgabe ansetzt, ist es überdimensioniert.

Außerdem muss man sagen: Diese Kategorie wird gerade sehr schnell sehr voll. Vibe Kanban, Veritas Kanban, Mission Control Dashboards, GitHubs eigenes Agent HQ — alle wollen die „Projektmanager-für-Agents“-Schicht sein. Multicas Argument: Open Source, selbstgehostet, Multi-CLI. Wenn das deine Anforderungen sind, ist es eine starke Wahl. Wenn du dich in einem geschlossenen Ökosystem wohlfühlst, brauchst du es vielleicht nicht.

Eine Verbindung, die erwähnenswert ist: Ich habe bereits darüber geschrieben, wie Kanban-Interfaces zum Standard-UI für Multi-Agent-Systeme werden, und Multica ist ein gutes Beispiel für diesen Trend. Im Agent-Tooling-Bereich ist sehr klar entschieden worden, dass „Tickets auf einem Board“ die richtige Abstraktion für die Zusammenarbeit von Mensch und KI ist — und ich glaube nicht, dass sich das wieder umkehrt.

Vier von zwölf. Als Nächstes: ein Projekt, das absolut nichts mit Agents, Memory oder Orchestrierung zu tun hat und auf dieser Liste steht, weil es etwas viel Einfacheres macht. Es unterbietet einen kostenpflichtigen SaaS.

5. OpenScreen (und Freunde) — Kostenloses Screen Studio, keine Abos

Screen Studio ist eine wunderschöne Mac-App. Sie kostet allerdings auch 29 $ pro Monat oder eine stattliche Einmalzahlung, je nach gewähltem Tarif – und das ist eine Menge für einen Screen Recorder, selbst wenn er Auto-Zoom und Cursor-Animationen wirklich, wirklich gut beherrscht.

Die Open-Source-Community, wie sie nun mal ist, hat sich das angeschaut und gesagt: Das können wir auch bauen.

Also haben sie es getan. Mehrfach.

Was es tatsächlich gibt

Im ursprünglichen Briefing für diesen Beitrag wurde „Open Source Screen Studio“ als einzelnes Projekt beschrieben, aber was ich im April 2026 gefunden habe, ist eher ein kleines Ökosystem sehr ähnlicher Projekte, die alle um dieselbe Idee kreisen:

OpenScreen — das ursprüngliche Open-Source-Alternativprojekt zu Screen Studio. Keine Abos, keine Wasserzeichen, kostenlos für kommerzielle Nutzung.
Recordly — ein Screen Recorder für Mac/Windows/Linux mit Auto-Zoom, animierten Cursoren, automatischen Untertiteln. Baut wesentlich auf der OpenScreen-Basis auf.
Open Recorder — eine Tauri- und Rust-Variante derselben Idee, optimiert auf geringe Größe und Geschwindigkeit.
Open ScreenStudio — ein weiterer Fork/Ansatz, fokussiert auf automatischen Zoom und sanfte Cursor-Effekte.

Das sind vier Open-Source-Projekte, die im Grunde denselben Job machen, alle entstanden in den letzten sechs bis neun Monaten. Wer noch breiter suchen will: Die bewährten Optionen (OBS Studio, ShareX) gibt es natürlich weiterhin, aber sie bieten nicht die „polierte Walkthrough-Ästhetik“, auf die diese neueren Projekte abzielen.

Was ich getestet habe

Ich habe OpenScreen installiert und genau das gemacht, was ich sonst in Screen Studio tun würde: Einen zweiminütigen Walkthrough eines Terminal-Workflows aufgenommen, mit Auto-Zoom auf Klick-Events und einem weichen Hintergrund hinter dem Fenster. Das Ergebnis war nicht pixelgenau identisch mit dem Output von Screen Studio, aber für 90 % der Anwendungsfälle – Tutorial-Videos, Loom-Alternativen, Produkt-Walkthroughs – war es so gut, dass der Unterschied keine Rolle spielte. Und ich habe keine 29 $ bezahlt.

Recordly ist die Variante, die ich Mac-Nutzer:innen tatsächlich als erstes zum Testen empfehlen würde, wenn sie das authentischste Look-and-Feel suchen; es wird von allen Projekten derzeit (Stand Anfang April 2026) am aktivsten gepflegt.

Warum diese Projektkategorie wichtig ist

Hier geht es nicht um Bildschirmaufnahmen. Es geht um das Muster dahinter.

Jede Kategorie kostenpflichtiger Kreativ-SaaS – Screen Recording, Schreibtools, Design-Utilities, Notizen, Aufgabenverwaltung – bekommt inzwischen ihre „kostenlose Open-Source-Alternative, gebaut mit Tauri oder Electron an einem Wochenende“. Manchmal gleich drei davon. Die Wirtschaftlichkeit von Closed-Source-Produktivitätssoftware für Endnutzer wird von unten her unter Druck gesetzt wie noch nie, und ein Grund dafür ist KI: Wenn ein Solo-Entwickler mit Claude Code an einem Wochenende eine echte Desktop-App bauen kann, sinken die Kosten, ein 29 $/Monat-Produkt zu klonen, praktisch gegen null.

Ich schreibe schon länger darüber, wie KI SaaS-Preismodelle durcheinanderbringt – und genau dieses Muster zeigt sich jetzt in einer konkreten Kategorie. Da kommt noch viel mehr.

Eins fehlt noch. Und das ist das kleinste Repo auf der Liste. Und vielleicht mein Favorit.

6. Karpathy-inspirierte Skills für Claude Code — Die kleine Datei, die die schlimmsten Agenten-Gewohnheiten behoben hat

Andrej Karpathy hat wiederholt und öffentlich betont, dass aktuelle LLM-Generationen auf vorhersehbare, spezifische Weise beim Programmieren versagen. Die Zitate, die man sich merken sollte, lauten sinngemäß: Die Modelle treffen falsche Annahmen für dich und machen einfach weiter, ohne zu überprüfen. Sie gehen mit ihrer eigenen Verwirrung nicht um, suchen keine Klarstellungen, zeigen keine Inkonsistenzen auf, stellen keine Abwägungen dar und widersprechen nicht, wenn sie es sollten.

Das ist eine ziemlich treffende Diagnose. Und Forrest Chang hat diese Diagnose in eine einzige CLAUDE.md-Datei gegossen, die man in jedes Claude-Code-Projekt einfügen kann.

Was es ist

andrej-karpathy-skills ist im Kern eine Datei. Es handelt sich um eine CLAUDE.md-Konfiguration, die aus Karpathys Beobachtungen zu typischen LLM-Fehlern beim Programmieren destilliert wurde und als Claude-Code-Plugin bereitgestellt wird. Du installierst sie, sie lebt auf Projekt- oder Nutzerebene und verändert das Verhalten von Claude Code genau bei den Aufgaben, bei denen es am ehesten zu Fehlern kommt.

Die groben Prinzipien, die sie durchsetzt:

Zielorientierte Ausführung statt imperativer Befehle. Anstatt einfach nur „mach, was der Nutzer sagt“, wird der Agent dazu angeleitet, das Ziel hinter der Anweisung zu verstehen und den Erfolg daran zu überprüfen.
Gezielte Änderungen statt großflächiger Umstrukturierungen. Wenn ein Bug behoben werden soll, dann wird dieser Bug behoben. Es werden nicht im Stillen drei andere Dateien mit umgebaut.
Annahmen offenlegen statt stillschweigend handeln. Gibt es Unklarheiten, wird nachgefragt. Gibt es Abwägungen, werden sie benannt.
Überprüfbare Erfolgskriterien definieren. Nicht einfach behaupten, dass etwas funktioniert. Den Nachweis führen, dass es funktioniert.

Nichts davon ist revolutionär. Aber all das entscheidet darüber, ob ein Agent dir eine Stunde spart oder dich drei kostet.

Was ich getestet habe

Ich habe das Plugin in mein tägliches Claude-Code-Setup integriert und eine Woche lang meinen normalen Workflow durchlaufen — Bugfixes, kleine Features, etwas Refactoring an der Brand-Site. Zwei Dinge haben sich spürbar verändert.

Erstens: Das Problem mit übermotivierten Refactorings ist deutlich zurückgegangen. Ich habe den Agenten gebeten, einen spezifischen Caching-Bug in einem Laravel-Controller zu beheben. Vor dem Plugin hätte er „hilfsbereit“ auch die Methodensignatur umgeschrieben und drei nicht zusammenhängende Zeilen verschoben. Nach dem Plugin wurde der Bug behoben, alles andere blieb unangetastet, und es gab eine Erklärung dazu.

Zweitens — und das ist der größere Punkt — der Agent hat angefangen, bessere Fragen zu stellen. Wenn ich absichtlich mehrdeutige Anweisungen gegeben habe (als Test), hat er nicht einfach geraten und losgelegt, sondern gestoppt und nachgefragt, welche Interpretation ich meine. Allein diese Verhaltensänderung ist die Installation wert.

Die ehrliche Einschränkung

Das ist eine einzelne Konfigurationsdatei, kein Framework. Sie ist nur so gut wie das LLM, das sie steuert, und kann grundlegende Modellgrenzen nicht beheben — sie macht sie nur sichtbarer. Wenn du Claude Code mit einem schwachen Basismodell nutzt, macht das Plugin es weniger leichtsinnig, aber nicht schlauer. Mit einem starken Basismodell ist dieses Plugin ein echter Produktivitätsgewinn.

Ich schreibe seit einiger Zeit über Claude-Code-Skills und wie man eigene entwickelt, und dies ist ein großartiges Beispiel für das minimalistische Muster. Es zeigt, dass eine wirklich gut geschriebene Skill-Datei wertvoller sein kann als ein kompliziertes Plugin mit eigenen Tools.

Das Muster hinter allen sechs Projekten

Nach einer Woche intensiver Tests habe ich mich hingesetzt und versucht herauszufinden, was diese sechs Projekte außer „Open Source“ und „KI“ gemeinsam haben. Hier ist mein Fazit.

Sie alle lehnen das Monolithische ab. Google Edge Gallery zeigt, dass KI nicht im Rechenzentrum leben muss. DeepTutor beweist, dass dein Lern-Workflow nicht im Chatfenster stattfinden muss. Hermes macht klar, dass das Gedächtnis deines Agents nicht im Prompt stecken muss. Multica zeigt, dass dein Multi-Agent-Workflow nicht in sechs Terminal-Tabs verteilt sein muss. OpenScreen beweist, dass kreative Tools nicht hinter einer Paywall versteckt sein müssen. Und das Karpathy-Skill-Plugin zeigt, dass das Gehirn deines Coding-Agents nicht ein einziger großer Hoffnungsschimmer sein muss, dass das Modell schon das Richtige tut.

Jedes einzelne dieser Projekte nimmt ein Stück des „eine große KI macht alles“-Denkmodells und zerlegt es in kleinere, spezialisiertere, offenere Komponenten. Das ist der eigentliche Trend. Es geht nicht um ein bestimmtes Tool, Modell oder Benchmark – sondern um die Zerlegung von KI-Workflows in Teile, die du selbst besitzen, austauschen und betreiben kannst.

Das andere Muster: Meinungsstarke Spezialisierung schlägt allgemeine Universalität. Hermes schlägt „Prompt-Stuffing-Claude-Klone“ nicht, weil es ein größeres Modell ist, sondern weil es eine klare Haltung zum Thema Gedächtnis hat. DeepTutor schlägt „generische Chat-mit-PDF“-Tools, weil es einen klaren Standpunkt zum Lernen hat. Das Karpathy-Skills-Plugin schlägt Vanilla Claude Code, weil es genau weiß, wo LLMs scheitern. In einer Welt, in der jedes Foundation Model versucht, möglichst allgemein zu sein, kommen die echten Fortschritte von Agents und Tools, die kompromisslos und selbstbewusst spezialisiert sind.

Wenn du in diesem Bereich baust – selbst als Solo-Entwickler – ist das die Erkenntnis, die ich mir auf einen Klebezettel schreiben würde: Such dir eine klare Haltung. Sei spezialisiert. Versuch nicht, die Foundation Models in ihrer Allgemeinheit zu übertreffen. Das kannst du nicht – und das musst du auch nicht.

Was ich mit all dem mache

Hier ist mein ehrlicher Plan für die nächsten zwei Wochen, falls das für dich nützlich ist.

Ich nehme mir die Speicherarchitektur von Hermes als Inspiration und baue die Memory-Layer in meinem eigenen Agenten-Stack neu auf – konkret die Trennung zwischen Sitzungs-, persistenter und Skill-Memory. Die Karpathy-Skill ist bereits in meinem täglichen Claude-Code installiert, und ich habe nicht vor, sie zu deinstallieren. Multica läuft auf einer Entwicklungsmaschine für ein Experiment, bei dem vier Coding-Agents parallel an einem echten Projekt arbeiten. Und ich werde mir einen Abend Zeit nehmen, um die Inferenz-Pipeline der Edge Gallery zu lesen – einfach, um dazuzulernen.

DeepTutor halte ich mir für einen ganz bestimmten Anwendungsfall in der Hinterhand: Wenn ich das nächste Mal ein langes technisches Dokument wirklich tiefgehend lernen muss, werde ich zu diesem Tool greifen – statt noch eine weitere Runde Cloud-Chat zu starten.

OpenScreen ersetzt bereits meinen bisherigen Workflow für Bildschirmaufnahmen – und da ich viele Tutorials schreibe, ist das ehrlich gesagt die größte wöchentliche Zeitersparnis auf dieser Liste.

Deine Wochenend-Challenge, falls du eine suchst: Such dir das Projekt aus dieser Liste aus, das zu einem Problem passt, das du bereits hast. Klone es. Bring es zum Laufen. Lass es einmal abstürzen. Komm zurück und entscheide, ob du es behältst. Das war’s. Ein Projekt, ein Wochenende, ein ehrlicher Test.

Denn was ich diese Woche gelernt habe – was ich jedes Mal lerne, wenn ich so einen Deep Dive mache – ist, dass über Tools zu lesen nicht dasselbe ist, wie sie wirklich auszuführen, und dass sich noch nie jemandes Workflow allein durch einen Blogpost verändert hat. Die Projekte auf dieser Liste sind spannend. Was passiert, nachdem du eines geklont hast, ist das, was zählt.

Geh und klone etwas.

Häufig gestellte Fragen

Was sind die besten Open-Source-AI-Projekte auf GitHub im April 2026?

Die derzeit interessantesten Open-Source-AI-Projekte verteilen sich auf On-Device-Inferenz (Google AI Edge Gallery, LiteRT-LM), Agenten-Memory und Orchestrierung (Hermes Agent, Multica), Lern-Workflows (DeepTutor), Screen Studio-Alternativen (OpenScreen, Recordly) sowie Claude Code Skill-Plugins (andrej-karpathy-skills). Für eine detaillierte Betrachtung, warum jedes dieser Projekte relevant ist, siehe die sechs Projekt-Walkthroughs oben.

Kann ich wirklich ein LLM auf meinem Handy ohne Internet ausführen?

Ja. Die Google AI Edge Gallery, basierend auf LiteRT-LM, führt Open-Weight-Klein-LLMs wie Gemma 4-Varianten vollständig on-device auf iOS und Android aus. Die Performance ist langsamer als bei Cloud-Inferenz und die Modelle sind kleiner, aber für private, offline und latenzkritische Anwendungsfälle ist es bereits produktionsreif für echte Workflows.

Ist Hermes Agent besser als Claude Code oder OpenClaw zum Bau von AI-Agenten?

Sie lösen unterschiedliche Probleme. Claude Code und OpenClaw sind coding-fokussierte Agenten-Umgebungen; Hermes Agent ist ein allgemeines Agenten-Framework mit einem spezialisierten Multi-Level-Memory-System. Wenn du einen langlaufenden persönlichen Agenten baust, der sich über Sitzungen hinweg Dinge merken muss, ist die Memory-Architektur von Hermes einen genaueren Blick wert – siehe den Hermes-Abschnitt oben für die vollständige Analyse.

Was ist die beste Open-Source-Alternative zu Screen Studio?

Stand April 2026 ist OpenScreen das originale Open-Source-Pendant zu Screen Studio, während Recordly der aktivst gepflegte Fork mit der größten Feature-Parität ist. Open Recorder (Tauri + Rust) ist die leichtgewichtigste Option. Alle drei sind kostenlos, ohne Abos, und für die meisten Tutorial- und Walkthrough-Workflows völlig ausreichend.

Lohnt sich das Karpathy Claude Code Plugin?

Für tägliche Claude Code Nutzer: ja. Es handelt sich um eine einzige Konfigurationsdatei, die gezielte Code-Änderungen erzwingt, Annahmen sichtbar macht und das Problem übermotivierter Refaktorisierungen reduziert – und damit genau die LLM-Coding-Fallstricke adressiert, auf die Andrej Karpathy immer wieder hingewiesen hat. Es ist die Installation mit dem geringsten Aufwand und dem größten Hebel auf dieser Liste.

Lassen Sie uns zusammenarbeiten

Möchten Sie KI-Systeme entwickeln, Workflows automatisieren oder Ihre technische Infrastruktur skalieren? Ich unterstütze Sie gerne dabei.

Fiverr (individuelle Lösungen & Integrationen): fiverr.com/s/EgxYmWD
Portfolio: mejba.me
Ramlit Limited (Enterprise-Lösungen): ramlit.com
ColorPark (Design & Branding): colorpark.io
xCyberSecurity (Sicherheitsdienstleistungen): xcybersecurity.io