Text Generator für Obsidian: Prompts, Templates und Provider im Vault
Text Generator is a versatile plugin for Obsidian that allows you to generate text content using various AI providers, including OpenAI, Anthropic, Google and local models.
Auf einen Blick
- Was ist das?
- Das Plugin holt OpenAI, Anthropic, Google und lokale Modelle direkt in Obsidian und steuert sie über Prompt-Templates plus Frontmatter-Konfiguration. Wer seinen Vault ohnehin als Schreibwerkzeug nutzt, bekommt damit Generierung ohne Kontextwechsel, bezahlt aber mit einer Beta-Versionslinie und dünner Fehlerdokumentation.
- Für wen ist es gedacht?
- Sinnvoll ist das Plugin für Leute, die ihren Obsidian-Vault bereits als Schreib- und Denkwerkzeug nutzen und Prompts als Dateien im Vault verwalten wollen, statt sie in zwanzig Browser-Tabs zu verlieren. Wer generative Textarbeit nur gelegentlich braucht, fährt mit einem normalen Chat-Interface billiger, weil er dann weder Plugin-Build noch Provider-Keys pflegen muss.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 41 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich TypeScript, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welche Lücke im Vault das Plugin füllt
Obsidian speichert Notizen als Markdown-Dateien auf der Platte. Es gibt darin keine eingebaute Möglichkeit, einen Absatz an ein Sprachmodell zu schicken und das Ergebnis an derselben Stelle einzufügen. Der übliche Umweg läuft über einen Browser-Tab: Text markieren, kopieren, in ein Chat-Fenster wechseln, Prompt tippen, Antwort zurückkopieren. Bei kurzen Notizen ist das erträglich. Bei einem Vault mit hunderten Notizen, aus denen Zusammenfassungen, Titel oder Gliederungen entstehen sollen, wird der Kontextwechsel zum eigentlichen Kostenfaktor.
Das Plugin setzt genau dort an. Laut README dient es dazu, Ideen, Titel, Zusammenfassungen, Gliederungen und ganze Absätze auf Basis der eigenen Wissensdatenbank zu erzeugen. Die Zielgruppe sind also nicht Entwickler, die eine API anbinden wollen, sondern Autoren, Forschende und Leute mit einem persönlichen Wissensmanagement, die generative Textarbeit in denselben Werkzeugkasten holen wollen, in dem ihre Notizen schon liegen. Der Anspruch ist Integration, nicht Modellqualität: Welches Modell antwortet, ist eine Konfigurationsfrage, nicht Teil des Plugins.
Prompt-Templates als Dateien, Provider per Frontmatter
Zwei Mechanismen tragen die Architektur. Der erste ist die Template Engine. Wiederkehrende Aufgaben werden als Templates hinterlegt, statt bei jedem Lauf neu getippt zu werden. Das README nennt Templates und Community-Templates als getrennte Punkte, es gibt also einen Weg, Vorlagen zu teilen und fremde zu übernehmen. Für die Praxis heißt das: Der Prompt liegt als Datei vor, ist versionierbar und unterscheidet sich zwischen zwei Läufen nur in den eingesetzten Werten.
Der zweite Mechanismus ist die Frontmatter-Konfiguration. Laut README lässt sich darüber einstellen, welcher Dienst antwortet, und genannt werden Google Generative AI mit Gemini-Pro, OpenAI und HuggingFace. Die Beschreibung des Repositories erweitert das auf Anthropic und lokale Modelle. Der Provider ist damit keine Einstellung, die global im Plugin-Fenster klebt, sondern eine Eigenschaft des Dokuments oder des Templates. Das ist der eigentliche Unterschied zu einem Chat-Interface: Ein Template, das eine Zusammenfassung mit einem günstigen Modell erzeugt, und eines, das eine Gliederung mit einem stärkeren Modell erzeugt, können nebeneinander existieren.
Das README spricht außerdem von einem Considered Context, über den der Prompt-Kontext zusammengestellt wird. Wie dieser Kontext im Einzelnen befüllt wird, welche Selektoren es gibt und wie groß das Kontextfenster ausfällt, lässt sich aus dem vorliegenden Material nicht ableiten. Wer das Plugin auswerten will, sollte diesen Punkt in der Dokumentation unter bit.ly/tg_docs nachlesen, bevor er Templates für lange Notizen baut.
Installation über die Community-Liste oder aus dem Quelltext
Der reguläre Weg läuft über Obsidian selbst: Einstellungen öffnen, zu Community plugins gehen, den Safe mode abschalten, auf Browse klicken, nach Text Generator suchen, dann Install und Enable. Mehr ist nicht nötig, und dieser Weg liefert die veröffentlichte Version.
Der manuelle Weg ist für die Entwicklungsversion gedacht. Das Repository wird in den Plugin-Ordner des Vaults geklont, danach folgen drei Befehle:
git clone https://github.com/nhaouari/obsidian-textgenerator-plugin.git cd obsidian-textgenerator-plugin pnpm install pnpm run build
Für die laufende Entwicklung nennt das README pnpm run dev als Alternative zum Build. Danach muss Obsidian neu gestartet und das Plugin unter Settings > Community plugins aktiviert werden. Wer den Neustart vermeiden will, kann das Hot-Reload-Plugin von pjeby einsetzen, das das README verlinkt.
Bemerkenswert ist die Paketwahl: pnpm, nicht npm oder yarn. Wer den manuellen Weg geht, braucht pnpm auf dem Rechner. Ein Detail, das in der Fehlersuche gern übersehen wird, wenn ein Build mit einem Modul-Fehler abbricht, obwohl die Ursache nur der falsche Paketmanager ist. Für die Fehlersuche verweist das README auf die Dokumentation, den Discord-Server und die GitHub-Issues. Eine eigene Fehlerliste mit bekannten Symptomen gibt es im README nicht.
Beta-Versionslinie und was das für den Vault bedeutet
Die letzten drei Releases tragen alle das Suffix beta: 0.8.11-beta vom 6. August 2026, 0.8.10-beta vom 16. Mai 2026 und 0.8.9-beta vom 15. Mai 2026. Zwischen 0.8.9 und 0.8.10 liegen weniger als 24 Stunden, zwischen 0.8.10 und 0.8.11 knapp drei Monate. Das Muster deutet auf einen schnellen Fix nach dem vorherigen Release und danach eine längere ruhige Phase hin. Ob die Version aus der Community-Liste dieselbe ist wie die Beta auf GitHub, lässt sich aus dem Material nicht beantworten. Wer den manuellen Weg wählt, sollte das vorher klären, weil er sonst unbemerkt eine Vorabversion in einem Vault laufen lässt, in dem echte Arbeit liegt.
Daraus folgt eine praktische Konsequenz: Das Plugin schreibt in Markdown-Dateien. Ein fehlerhaftes Template oder ein Lauf über eine falsche Auswahl kann Inhalte überschreiben. Wer den Vault nicht ohnehin in Git hält, hat dann keinen sauberen Rückweg. Das ist keine Eigenheit dieses Plugins, sondern eine Eigenschaft jedes Werkzeugs, das schreibend in Notizen eingreift. Bei einer Beta-Versionslinie wiegt sie schwerer.
Wann ein Chat-Interface das bessere Werkzeug bleibt
Die naheliegende Alternative ist der Provider selbst. OpenAI, Anthropic und Google betreiben jeweils eigene Web-Oberflächen, in denen sich dieselben Modelle ohne Plugin, ohne Build-Schritt und ohne Obsidian-Neustart ansprechen lassen. Der Unterschied liegt nicht in der Antwortqualität, sondern im Kontext: Ein Chat-Fenster kennt den Vault nicht. Wer eine Zusammenfassung über zwanzig Notizen braucht, muss sie dort einzeln hineinkopieren.
Genau diese Grenze macht die Entscheidung einfach. Für gelegentliche Einzelanfragen ist das Chat-Interface billiger, weil es keinen Wartungsaufwand erzeugt. Sobald dieselbe Anfrage aber regelmäßig über wechselnde Notizen laufen soll, kippt das Verhältnis: Dann ist der Aufwand, den Prompt jedes Mal neu zusammenzusetzen, größer als der Aufwand, ein Template einmal zu schreiben. Ein zweiter Unterschied ist die Abrechnung. Beide Wege laufen über einen API-Key und werden nach Verbrauch abgerechnet, nicht über ein Abonnement. Wer eine Flatrate gewohnt ist, sollte das vor dem ersten längeren Template-Lauf einplanen.
Eine dritte Option sind die Modell-Funktionen, die Obsidian selbst oder andere Plugins mitbringen. Dazu liegt hier kein Material vor, ein Vergleich wäre also Spekulation. Festhalten lässt sich nur, dass Text Generator seinen Wert aus der Template- und Frontmatter-Schicht zieht, nicht aus dem Zugang zu einem bestimmten Modell.
Lizenz und laufende Kosten
Das Projekt steht unter MIT. Das ist eine der permissivsten Lizenzen: Nutzung, Änderung und Weitergabe sind erlaubt, solange der Copyright-Hinweis und der Lizenztext erhalten bleiben. Für Anwender im privaten Vault ändert das praktisch nichts. Wer das Plugin forkt und weiterverbreitet, muss die Lizenzbedingungen einhalten. Das ist eine Einordnung, keine Rechtsberatung; wer das Plugin in einem kommerziellen Umfeld einsetzt, sollte die Bedingungen selbst prüfen.
Die relevante Kostenfrage liegt nicht bei der Lizenz, sondern beim Provider. Das Plugin selbst ist laut README kostenlos und quelloffen. Die Generierung läuft über API-Keys, und die Abrechnung erfolgt beim jeweiligen Anbieter. Das README nennt dazu keine Zahlen, und ich habe keine gemessen. Wer lokale Modelle einsetzt, verschiebt die Kosten auf Hardware und Betrieb, spart aber die API-Gebühren. Wie gut dieser Weg in der aktuellen Version funktioniert, geht aus dem Material nicht hervor.
Der Wartungsaufwand liegt woanders: bei den Provider-Schnittstellen. Anbieter ändern Endpunkte, Modellnamen und Authentifizierung. Jede solche Änderung muss im Plugin nachgezogen werden, und die drei Beta-Releases im Jahr 2026 zeigen, dass daran gearbeitet wird. Wer das Plugin produktiv nutzt, sollte die Release-Notizen verfolgen und vor einem Update prüfen, ob sein Provider und sein Modell noch unterstützt werden.
Redaktionelles Fazit
Sinnvoll ist das Plugin für Leute, die ihren Obsidian-Vault bereits als Schreib- und Denkwerkzeug nutzen und Prompts als Dateien im Vault verwalten wollen, statt sie in zwanzig Browser-Tabs zu verlieren. Wer generative Textarbeit nur gelegentlich braucht, fährt mit einem normalen Chat-Interface billiger, weil er dann weder Plugin-Build noch Provider-Keys pflegen muss. Prüfe zuerst, ob dein Ziel-Provider in der Frontmatter-Konfiguration der aktuellen Version auftaucht, ob die installierte Version aus der Community-Liste stammt oder ein Beta-Build ist, und ob dein Vault ein Git-Repository ist, damit du den Zustand vor dem ersten Template-Lauf zurückrollen kannst.
Community-Notizen