Diktat, das das Terminal überlebt

Entwickler, die Diktierwerkzeuge ausprobieren, stoßen oft auf ein Scheitern mit sehr spezifischer Form. Das Werkzeug funktioniert in der Demo hervorragend. Es funktioniert in Notizen, in Slack, im Browser. Dann fokussieren Sie ein Terminal, diktieren einen Satz, und entweder erscheint nichts, oder es erscheint etwas, das Sie nicht gesagt haben, oder die Hälfte erscheint und die andere Hälfte liegt jetzt rätselhafterweise in Ihrer Zwischenablage. Manchmal klappt es lokal und stirbt in dem Moment, in dem Sie sich per SSH auf eine Maschine verbinden.

Das Muster ist konsistent genug, dass ich es nicht für einen Bug in einem einzelnen Produkt halte. Es ist eine Folge davon, wie diese Kategorie Text einfügt — und es scheitert genau an den Orten, an denen ein Entwickler lebt.

Das zählt heute mehr als vor zwei Jahren. Wenn Sie Claude Code per Stimme steuern — der Workflow, den ich in Claude Code mit der Stimme steuern beschrieben habe —, dann ist das Terminal nicht eine App unter vielen. Es ist die App. Dort landen Ihre Prompts, dort warten Ihre Agents auf Kurskorrekturen, dort funktioniert die ganze Parallel-Lane-Sache oder eben nicht. Ein Diktierwerkzeug, das in Terminals unzuverlässig ist, ist für einen Vibecoder bei seiner einzigen Aufgabe unzuverlässig.

Warum scheitert Einfügen genau dort, wo Entwickler leben?

Hier die Mechanik auf Kategorieebene. Die meisten Diktierwerkzeuge fügen Text auf dieselbe Weise ein: Sie legen Ihren transkribierten Satz in die System-Zwischenablage und synthetisieren dann einen Cmd+V-Tastenanschlag an der fokussierten App. Das ist ein vernünftiger Standard — Einfügen ist sofort da, es funktioniert in fast jedem GUI-Textfeld, und es brauchte kaum App-spezifische Entwicklung.

Das Problem ist alles, worauf diese Annahme stillschweigend baut.

Sie baut darauf, dass die fokussierte App Cmd+V als „einfügen“ versteht. Terminals tun das oft nicht — viele belegen Cmd+V anders oder gar nicht, tmux und vim haben eigene Vorstellungen davon, was Einfügen bedeutet, und eine entfernte SSH-Session kann einen Schwall eingefügten Texts auf eine Weise interpretieren, die die lokale Maschine nicht vorhersagen kann. Bracketed Paste, Copy-Mode, Insert-Mode gegen Normal-Mode: Die Terminal-Welt ist voller Zustände, in denen ein synthetisches Einfügen falsch oder gar nicht landet.

Sie baut darauf, dass die Zwischenablage verfügbar und ungeschützt ist. Clipboard-Manager schreiben sie um. Passwort-Manager leeren oder schützen sie absichtlich — ein Sicherheitsfeature, das aus „mein Diktat einfügen“ lautlos „nichts einfügen“ macht. Und selbst wenn alles funktioniert, hat das Werkzeug gerade überschrieben, was Sie kopiert hatten. Der Commit-SHA, den Sie zwischen Fenstern trugen, ist weg, ersetzt durch Ihren eigenen Satz. Für jemanden, der mehrere Lanes jongliert, ist das kein Kratzer; die Zwischenablage hatte eine Aufgabe.

Und sie baut — das ist der Punkt, der Leute überrascht — auf Ihrem Tastaturlayout. Wenn ein Werkzeug auf simulierte Tastenanschläge zurückfällt, ist der naive Weg, Key-Codes zu senden: die physischen Tastenpositionen. Key-Codes werden über Ihr Layout auf Zeichen abgebildet. Auf QWERTY erzeugt der Code für „V“ ein V. Auf Dvorak ist dieselbe physische Position ein anderer Buchstabe. Ein Werkzeug, das auf einem Dvorak-, AZERTY- oder Colemak-Layout Scancodes simuliert, produziert also Text, der wie durch eine Ersetzungschiffre gelaufen aussieht. Nutzer melden Kauderwelsch und nehmen an, die Spracherkennung habe versagt. Hat sie nicht — die Erkennung war perfekt, das Einfügen hat sie verwürfelt.

Nichts davon ist Bosheit oder Faulheit auf irgendjemandes Seite. Einfügen per Zwischenablage ist der richtige Standard für die 90-Prozent-Fälle. Es ist nur so, dass Entwickler ihren Tag in den anderen 10 Prozent verbringen.

Was „tipp es stattdessen“ tatsächlich bedeutet

Keebye hat eine Einstellung namens insert_mode mit zwei Werten: paste, dem Standard, und type.

Der Typing-Modus fügt nicht ein. Auf macOS nutzt er CGEventKeyboardSetUnicodeString — eine API, die den tatsächlichen Unicode-Text an ein synthetisches Tastenereignis hängt. Das Zeichen wird im Ereignis selbst mitgeführt, nicht über Ihr Tastaturlayout nachgeschlagen. Das macht ihn konstruktionsbedingt layout-unabhängig: Dvorak, AZERTY, Colemak, worauf auch immer Sie tippen — der ankommende Text ist der transkribierte Text, weil es nie eine Scancode-zu-Zeichen-Übersetzung gab, die schiefgehen konnte.

Die zweite Eigenschaft des Typing-Modus ist die, die Terminal-Nutzern wichtig ist: Er fasst die Zwischenablage nie an. Null Zwischenablage-Operationen auf diesem Codepfad. Der Inhalt Ihrer Zwischenablage bleibt Ihrer — der SHA überlebt, der Passwort-Manager hat nichts abzuwehren, der Clipboard-Manager hat nichts zu protokollieren.

Und weil Terminals und Remote-Sessions sich an Text verschlucken können, der schneller ankommt als jeder Mensch tippt, taktet sich der Typing-Modus bewusst: Text geht in 16-Zeichen-Blöcken hinein, mit 4 Millisekunden Abstand zwischen den Blöcken. Schnell genug, dass ein Satz deutlich unter einer Sekunde landet; maßvoll genug, dass ein tmux-Pane über SSH ihn als Tastenanschläge empfängt, mit denen es Schritt halten kann, und nicht als Klumpen, den es interpretieren muss.

Der Paste-Modus ist weiterhin da und weiterhin Standard, weil er für große Textblöcke in gewöhnlichen GUI-Apps wirklich schneller ist — eine dreiabsätzige Slack-Nachricht kommt als ein Einfügevorgang an statt als Strom von Blöcken. Auch der Paste-Modus hat die Layout-Lektion gelernt: Das synthetische Cmd+V nutzt den physischen V-Keycode, damit Einfügen selbst auf Nicht-QWERTY-Layouts nicht so bricht, wie es bei zeichenbasierten Ansätzen passieren kann.

Die praktische Einrichtung für Agent-Arbeit ist einfach: insert_mode auf type stellen, das Terminal mit Claude Code fokussieren, die Taste halten, die Kurskorrektur sprechen, loslassen. Der Prompt kommt an, wie es Tastenanschläge täten, denn soweit das Terminal es beurteilen kann, sind es welche. Eine Schritt-für-Schritt-Fassung dieser Einrichtung, samt SSH- und tmux-Details, steht in Sprachdiktat für das macOS-Terminal.

Die ehrlichen Grenzen

Der Typing-Modus ist bei langem Text langsamer als Einfügen — das ist Arithmetik, kein Defekt. Getaktete Tastenanschläge in Blöcken brauchen länger als ein einzelner Einfügevorgang, und wenn Sie mehrere Absätze in ein Dokument diktieren, wird sich der Paste-Modus flotter anfühlen. Genau deshalb bleibt Einfügen der Standard und der Typing-Modus etwas, das Sie in den Einstellungen aktivieren; der richtige Modus hängt davon ab, wohin Ihr Text geht.

Manche Anwendungen drosseln oder filtern synthetische Eingaben, meist aus Sicherheitsgründen, und keine Einfügestrategie entkommt dem vollständig — eine App, die synthetische Ereignisse ablehnt, lehnt sie von jedem Diktierwerkzeug ab.

Und um klar zu sagen, was dieser Artikel behauptet und was nicht: Die Beschwerde, dass Einfügen in Terminals scheitert, ist ein Muster in der gesamten Diktat-Kategorie, kein Defekt, der einem Wettbewerber allein anhaftet. Andere Werkzeuge haben eigene Antworten und eigene Stärken — wir haben ehrliche Vergleiche geschrieben unter Keebye vs Superwhisper und Keebye vs Wispr Flow, einschließlich der Punkte, an denen sie besser zu Ihnen passen könnten.

Das Einfügen ist die unglamouröse Hälfte des Diktierens

Alle Aufmerksamkeit bekommt die Spracherkennung — Modellnamen, Genauigkeitsversprechen, Sprachzahlen. Aber ein Diktierwerkzeug hat zwei Aufgaben: Sie richtig zu hören und den Text dann dorthin zu bringen, wo Ihr Cursor steht, ohne ihn zu verlieren oder zu verstümmeln. Die zweite Aufgabe klingt trivial und ist die, an der die Kategorie stillschweigend an Entwicklern scheitert, denn die zweite Aufgabe ist in TextEdit leicht und in einem tmux-Pane auf einer entfernten Maschine unter einem Dvorak-Layout schwer.

Wenn Ihre Prompts in Terminals landen — und wenn Sie Coding-Agents steuern, tun sie das —, ist das Einfügen keine Fußnote. Es ist der Unterschied zwischen einem Werkzeug, das man vorführt, und einem, das man benutzt. Verwandte Fehlerbilder haben übrigens denselben Charakter: Dass das erste Wort eines Diktats vom Kaltstart des Mikrofons gefressen wird, ist eine weitere kategorieweite Beschwerde mit einer mechanischen Erklärung, und die haben wir in Warum Diktier-Apps Ihr erstes Wort fressen aufgeschrieben.

Keebye ist im Early Access für macOS. Wenn Ihr Diktat je irgendwo zwischen Ihrem Mund und einem Terminal verschwunden ist, starten Sie unten Ihre kostenlose Testphase, aktivieren Sie den Typing-Modus und wiederholen Sie denselben Prompt. Ihr kopierter SHA bleibt in der Zwischenablage, während die Wörter als getipptes Unicode ankommen.