Writing Tools: systemweite KI-Schreibhilfe mit eigenem API-Schlüssel

Ein Hotkey, der den markierten Text ersetzt

Das Problem, das Writing Tools adressiert, ist der Kontextwechsel: Man schreibt in einem beliebigen Programm, will einen Absatz verbessern und wechselt dafür in einen Browser, ein Chat-Fenster oder eine zweite Anwendung. Writing Tools bleibt im Hintergrund und wird per Tastenkürzel aufgerufen, ohne die Zwischenablage zu benutzen. Laut README ruft `ctrl+space` das Werkzeug auf, der markierte Text wird durch die LLM-Ausgabe ersetzt, und `ctrl+z` macht die Änderung rückgängig. Ohne markierten Text startet derselbe Hotkey einen Chat mit dem Modell.

Die Zielgruppe ist eng umrissen: Menschen, die viel in fremden Anwendungen tippen und dafür keine Subscription abschließen wollen. Das README nennt als Alleinstellungsmerkmal, dass es das einzige Programm dieser Art für Windows und Linux sei und der einzige Weg, Apples Writing Tools auf einem Intel-Mac oder in der EU zu nutzen. Diese Aussage stammt vom Projekt selbst, nicht von einer unabhängigen Prüfung. Wer sie als Kriterium heranzieht, sollte sie selbst nachvollziehen.

Der Funktionsumfang geht über Grammatik hinaus. Vorgefertigte Aktionen heißen Proofread, Rewrite, Friendly, Professional, Concise und Summary, Key Points, Table. Dazu kommt ein Freitextfeld mit der Bezeichnung `Describe your change...`, in das sich Anweisungen wie Übersetzungen oder Code-Kommentare schreiben lassen. Die Zusammenfassung erscheint in einem eigenen Fenster mit Markdown-Darstellung und lässt sich dort weiter befragen.

Zwei Codebasen, ein Repository

Die Versionsnummern im Repository verraten mehr über die Struktur als das README. Die Releases heißen `Win_v9+mac_OS_v6.1`, `Win_v8+mac_OS_v6.1` und `Win_v8+mac_OS_v6.0`. Windows und macOS werden also getrennt gezählt und getrennt ausgeliefert, obwohl sie im selben Repository liegen. Die primäre Sprache ist Swift, was zur macOS-Portierung passt: Das README schreibt Arya Mirsepasi den Aufbau des gesamten macOS-Ports zu, während Jesai Tarun das Projekt gegründet hat und zusammen mit Beitragenden pflegt.

Für die Praxis bedeutet diese Aufteilung, dass ein Fehlerbericht oder eine Erwartung an die Windows-Version nicht automatisch für macOS gilt und umgekehrt. Die Versionsnummern laufen auseinander, die Plattformen haben unterschiedliche Betreuer. Wer das Projekt in einer Umgebung mit gemischten Arbeitsplätzen einsetzen will, muss mit zwei Pflegeständen rechnen.

Dass macOS als nativer Swift-Port läuft, während Windows und Linux die ursprüngliche Anwendung nutzen, ist eine Architekturentscheidung mit Folgen für die Fehlersuche. Ein Problem mit der Texteinfügung in eine bestimmte Anwendung kann auf der einen Plattform an der Zwischenablage-freien Einfügelogik liegen, auf der anderen an einer anderen Implementierung desselben Gedankens. Das README liefert dazu keine Details, und aus dem Repository-Aufbau allein lässt sich nicht ableiten, wie viel Code beide Zweige teilen.

Modellanbindung über OpenAI-kompatible Endpunkte

Writing Tools bringt kein eigenes Modell mit. Es spricht mit einem Backend, das der Nutzer auswählt. Das README nennt drei Wege: die kostenlose Gemini-API mit Gemini 2.0, lokale LLMs über Ollama, llama.cpp, KoboldCPP, TabbyAPI oder vLLM, und Cloud-Anbieter wie ChatGPT oder Mistral AI über eine OpenAI-API-kompatible Schnittstelle.

Das ist der eigentliche Mechanismus des Projekts: eine systemweite Oberfläche für Textoperationen, gekoppelt an einen konfigurierbaren HTTP-Endpunkt. Alles, was diese Schnittstelle spricht, lässt sich anschließen. Die Qualität der Ausgabe hängt damit vollständig am gewählten Modell, nicht an Writing Tools. Das README argumentiert an dieser Stelle mit Modellgrößen: Apple nutze ein Modell mit 3 Milliarden Parametern, Gemini 2.0 Flash liege bei etwa 30 Milliarden. Solche Zahlen sind eine Momentaufnahme und werden im README nicht belegt. Sie taugen als Hinweis auf die Richtung, nicht als Messergebnis.

Für lokale Modelle verweist das README auf eine gesonderte Ollama-Anleitung, die ab Windows/Linux v7 gilt. Wer ein Modell auf dem eigenen Rechner betreibt, hält den Text auf dem eigenen Gerät und arbeitet ohne Internetverbindung. Wer die Gemini-API nutzt, sendet den markierten Text an einen Cloud-Dienst. Diese Unterscheidung ist die wichtigste Datenschutzentscheidung bei der Einrichtung, und sie wird nicht von der Anwendung getroffen, sondern vom Nutzer über die Konfiguration.

Installation in einer Minute, mit einer Ausnahme

Unter Windows ist der Ablauf laut README: die Datei `Writing.Tools.zip` von der Releases-Seite laden, an einen Ort wie `Documents` oder `App Data/Local` entpacken, `Writing Tools.exe` starten. Das Programm ist portabel. Liegt es in einem geschützten Verzeichnis wie `Program Files`, muss es beim ersten Start als Administrator ausgeführt werden, damit es seine Konfigurationsdateien im selben Ordner wie die ausführbare Datei anlegen kann. Autostart wird über das Einstellungsfenster im Tray aktiviert, nicht über einen Installer.

Für Linux beschreibt das README die Version als work-in-progress und verweist auf eine Anleitung, die im vorliegenden Material abgeschnitten ist. Wer Linux einsetzen will, muss diesen Abschnitt in der aktuellen README-Fassung selbst nachlesen. Aus dem Repository-Ausschnitt lässt sich kein vollständiger Linux-Installationsweg rekonstruieren, und ich gebe hier bewusst keinen an.

Die relevanten Konfigurationswerte liegen in Dateien neben der Anwendung: API-Schlüssel, Modell-Endpunkt, Hotkey und Theme. Das README nennt namentlich zwei Themes (ein verschwommenes Farbverlaufs-Theme und ein schlichtes im Stil des Windows+V-Fensters), Dark Mode und die Möglichkeit, den Hotkey zu ändern. Die genauen Schlüsselnamen der Konfigurationsdatei gehen aus dem vorliegenden Material nicht hervor. Wer sie braucht, findet sie in der README oder im Quelltext, nicht in diesem Artikel.

Wo das Werkzeug an seine Grenzen stößt

Der schwerwiegendste Vorbehalt steht im README selbst: Linux ist als work-in-progress markiert. Ein Werkzeug, das systemweit in fremde Anwendungen schreibt, hängt von den Eingabemechanismen des jeweiligen Desktops ab. Unter Windows und macOS sind diese Pfade vergleichsweise einheitlich, unter Linux verteilen sie sich auf X11 und Wayland sowie auf verschiedene Toolkits. Wer Writing Tools auf einem Linux-Arbeitsplatz als festen Bestandteil einplant, plant gegen eine Baustelle.

Der zweite Vorbehalt betrifft die Textersetzung selbst. Das Werkzeug schreibt in das aktive Fenster zurück. Bei Anwendungen mit eigenen Eingabemodellen, etwa Terminals, Editoren mit mehreren Cursorn oder Formularen mit eingeschränkter Zeichenmenge, kann eine Ersetzung unerwünscht sein. Das README verspricht Rückgängig machen per `ctrl+z`, aber dieses Versprechen gilt nur, solange die Zielanwendung einen eigenen Undo-Stack führt und der Fokus beim Zurückschreiben noch im richtigen Feld steht. Ein systemweites Werkzeug kann diese Bedingungen nicht garantieren.

Drittens die Kostenfrage. Das Projekt ist kostenlos, die Gemini-API hat aber Kontingente, und Cloud-Anbieter verlangen Geld. Wer die kostenlose Variante wählt, bekommt nicht dieselbe Zuverlässigkeit wie bei einem bezahlten Kontingent. Das README nennt die API kostenlos, ohne die Bedingungen zu nennen. Wer darauf baut, sollte die aktuellen Limits beim Anbieter prüfen.

Was ein lokales Modell anders macht als Grammarly

Die naheliegende Alternative ist Grammarly, und der Unterschied liegt nicht im Funktionsumfang, sondern im Verfahren. Grammarly arbeitet nach eigener Beschreibung des Writing-Tools-READMEs mit regelbasierter NLP-Verarbeitung. Solche Systeme erkennen Muster, die vorher definiert wurden, und liefern deshalb gleichbleibende, vorhersagbare Korrekturen. Sie können aber keine Anweisung wie „add comments to this code" oder „make it title case" ausführen, weil diese Anweisung nicht in ihrer Regelmenge steht.

Ein LLM-Backend verhält sich umgekehrt. Es versteht freie Anweisungen, produziert aber variable Ausgaben. Derselbe Absatz kann bei zwei Durchläufen unterschiedlich umgeschrieben werden. Für jemanden, der eine verlässliche Rechtschreibprüfung will, ist das ein Nachteil. Für jemanden, der einen Absatz umformulieren, kürzen oder übersetzen will, ist es der eigentliche Zweck.

Die zweite Alternative ist der Verzicht auf ein eigenes Werkzeug und die Nutzung des Chat-Fensters eines Anbieters. Der Unterschied liegt im Kopieren und Einfügen: Writing Tools ersetzt den markierten Text an Ort und Stelle, ohne die Zwischenablage zu belegen. Das README hebt das ausdrücklich hervor. Für kurze Textmengen ist der Unterschied gering, für wiederkehrende Korrekturen in vielen Anwendungen summiert er sich.

Lizenz, Pflege und der Preis der Portabilität

Writing Tools steht unter GPL-3.0. Wer die Anwendung unverändert weitergibt, gibt sie unter derselben Lizenz weiter. Wer sie in ein eigenes Produkt einbaut oder den Code verändert und verteilt, muss die Bedingungen der GPL-3.0 einhalten, insbesondere die Offenlegung des Quellcodes abgeleiteter Werke. Das ist eine technische Einordnung, keine Rechtsberatung; für den eigenen Fall gehört eine Prüfung durch eine sachkundige Person dazu.

Der Wartungsaufwand liegt bei einem Projekt dieser Bauart nicht nur beim Entwickler. Portabel zu sein heißt, dass die Anwendung ihre Konfiguration selbst verwaltet und kein Installer Versionen nachzieht. Ein Update ist ein manueller Austausch des entpackten Ordners. Wer mehrere Arbeitsplätze betreut, muss diesen Schritt selbst skripten oder wiederholen.

Die Release-Historie zeigt zwei getrennte Versionslinien mit unterschiedlichem Takt. Zwischen `Win_v8+mac_OS_v6.0` und `Win_v8+mac_OS_v6.1` lag ein macOS-Sprung, Windows blieb stehen; zwischen `Win_v8+mac_OS_v6.1` und `Win_v9+mac_OS_v6.1` umgekehrt. Solche Sprünge sind normal, wenn zwei Personen getrennte Plattformen pflegen. Sie bedeuten aber, dass ein Fehler auf der einen Seite länger offen bleiben kann als auf der anderen. Wer Writing Tools produktiv einsetzt, sollte die Releases-Seite beider Linien beobachten und nicht annehmen, dass ein Update für Windows auch die macOS-Version mitbringt.

Redaktionelles Fazit

Wer unter Windows oder Linux einen Hotkey für Proofreading und Zusammenfassungen will und einen eigenen Gemini-Schlüssel oder ein lokales Modell mitbringt, findet hier ein portables Werkzeug. Wer eine fertig betreute Desktop-Anwendung mit Support sucht, sollte zuerst die Release-Assets für die eigene Plattform prüfen: Die Linux-Version ist laut README ausdrücklich als work-in-progress markiert, und die macOS-Portierung ist ein separater Swift-Zweig mit eigener Versionsnummer.

Offizielle Quellen

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. theJayTea/WritingTools on GitHub