vim-ai: OpenAI-Aufrufe aus der Vim-Kommandozeile

Ein Editor-Plugin, kein Assistent mit eigenem Kontext

Die meisten KI-Werkzeuge für Entwickler arbeiten als eigene Anwendung neben dem Editor. vim-ai geht den umgekehrten Weg: Es bleibt im Editor und macht die API über Ex-Befehle erreichbar. Der Nutzer tippt :AI, :AIEdit, :AIChat oder :AIImage, optional mit visueller Auswahl und einer Instruktion. Das Plugin liest die Auswahl, schickt sie zusammen mit dem Prompt an den Endpunkt und schreibt die Antwort zurück in den Buffer.

Das README formuliert die Zielgruppe indirekt: Wer Vim oder Neovim mit python3-Unterstützung kompiliert hat und einen OpenAI-Account besitzt, ist der Adressat. Wer den Editor ohnehin als Kommandozeile begreift, bekommt hier keinen Chat-Dialog, sondern Befehle, die sich mit Ranges kombinieren lassen. Die Dokumentation nennt als Beispiel :%AIE fix grammar für den gesamten Buffer. Das ist ein anderes Modell als ein Seitenpanel, in dem man einen Verlauf durchblättert.

Python-Schicht, Ex-Befehle und ein Token pro Aufruf

Der Datenfluss ist im README nur grob beschrieben, aber die Bausteine sind erkennbar. Vim ruft einen Ex-Befehl auf. Eine Python-Schicht im Plugin nimmt Prompt, Auswahl und Rollenoptionen entgegen, setzt daraus eine HTTP-Anfrage an die OpenAI-API zusammen und gibt die Antwort an den Editor zurück. Bei :AIChat läuft das als fortlaufende Konversation, die sich mit :AIStopChat abbrechen lässt.

Zwei Aussagen aus dem README sind für die Bewertung wichtig. Erstens: Das Plugin sendet nichts im Hintergrund. "You only share and pay for what you specifically select, for prompts and chat content." Zweitens: Die API ist kostenpflichtig, abgerechnet nach Tokens, also nach Textmenge in beide Richtungen. Wer :%AIE auf eine große Datei anwendet, bezahlt für den gesamten Buffer, nicht nur für die geänderte Zeile. Das ist keine Fußnote, sondern die zentrale Kostenentscheidung bei der Nutzung.

Die Anbindung an andere Anbieter läuft nicht über eigene Adapter im Kern, sondern über OpenAI-kompatible Proxies. Das README nennt OpenRouter und LiteLLM als Beispiele und verweist auf einen Abschnitt zu Custom Roles. Für Gemini existiert ein separates Provider-Plugin (vim-ai-provider-google), daneben listet das README zwei weitere Provider-Plugins Dritter.

Installation: Token-Datei, Plug-Manager oder Vim-Pakete

Die Einrichtung beginnt mit einem API-Schlüssel. Das README zeigt drei Varianten. Entweder legt man die Datei ~/.config/openai.token mit dem Schlüssel an, oder man setzt die Umgebungsvariable OPENAI_API_KEY, oder man kombiniert beides mit einer Organisations-ID im Format SCHLUESSEL,ORG_ID. Der Pfad zur Tokendatei lässt sich über g:vim_ai_token_file_path in der .vimrc verschieben.

Die Installation selbst erfolgt entweder über vim-plug mit der Zeile Plug 'madox2/vim-ai' oder manuell über die eingebauten Vim-Pakete. Für Vim klont das README das Repository nach ~/.vim/pack/plugins/start/vim-ai, für Neovim nach ~/.local/share/nvim/site/pack/plugins/start/vim-ai. Beide Wege setzen voraus, dass der Editor mit python3-Unterstützung gebaut wurde. Das ist die häufigste Fehlerquelle bei Distribution-Paketen, weil viele Vim-Builds ohne dieses Flag ausgeliefert werden.

Für die Konfiguration von Rollen verweist das README auf g:vim_ai_roles_config_file mit einem Pfad zu einer .ini-Datei. Das ist der eigentliche Konfigurationsmechanismus des Plugins, nicht eine Sammlung von Einzelvariablen.

Rollen als versionierbare Prompt-Konfiguration

Rollen sind der interessanteste Teil des Designs. Eine Rolle ist eine wiederverwendbare Instruktion plus Modelloptionen, definiert in einer .ini-Datei. Das README zeigt eine Rolle grammar mit prompt = fix spelling and grammar und options.temperature = 0.4, außerdem eine Rolle o1-mini, die Modell, max_completion_tokens und temperature für alle Befehle setzt. Über den Abschnitt [o1-mini.chat] lassen sich Optionen nur für den Chat überschreiben, etwa options.stream = 0 und ui.populate_all_options = 1.

Aufgerufen wird das mit :AIEdit /grammar oder kombiniert als :AI /o1-mini /grammar helo world!. Rollen sind damit Textdateien, die man in ein Repository legen und mit anderen teilen kann. Das unterscheidet vim-ai von Assistenten, deren Prompt-Bibliothek in einer Datenbank oder einem proprietären Format liegt. Der Preis dafür ist eine eigene Syntax, die man lernen muss, inklusive der Frage, welche Optionen pro Befehl überschreibbar sind.

Das README erwähnt außerdem spezielle Rollen wie /right, /below und /tab, die steuern, wo der Chat geöffnet wird, sowie /populate und /populate-all für die Anzeige der Optionen im Chat-Header. Das sind UI-Konventionen, die in der Rollendatei wie normale Rollen behandelt werden.

Provider-Plugins: erweiterbar, aber noch dünn besetzt

Das README enthält eine ausdrückliche Ankündigung: vim-ai lässt sich über eigene Provider-Plugins erweitern, aber es gibt noch nicht viele davon, und neue sind willkommen. Genannt werden drei: ein Google-Provider für Gemini-Modelle, ein Provider für die OpenAI Responses API und ein OpenAI-Provider mit MCP-Unterstützung. Als Referenz für eigene Implementierungen verweist das README auf das Google-Provider-Repository.

Das ist eine ehrliche Selbsteinschätzung. Wer heute einen Anbieter außerhalb dieses Spektrums nutzen will, muss entweder einen OpenAI-kompatiblen Proxy dazwischenschalten oder selbst ein Provider-Plugin schreiben. Der Proxy-Weg ist der dokumentierte Standardpfad und funktioniert ohne Plugin-Entwicklung. Der Plugin-Weg verspricht tiefere Integration, kostet aber Einarbeitung in eine Schnittstelle, die laut README noch wenig erprobt ist.

Bemerkenswert ist, dass der Kern des Plugins offenbar auf OpenAI-kompatible Endpunkte ausgerichtet bleibt. Alles andere läuft über Erweiterungen. Das hält den Kern klein, verschiebt aber die Vielfalt in Code, der nicht im Hauptrepository gepflegt wird.

Wo vim-ai die falsche Wahl ist

Die erste Einschränkung steht im README selbst: python3-Unterstützung im Editor ist Pflicht. Auf Systemen, deren Vim ohne dieses Flag gebaut wurde, hilft keine Plugin-Konfiguration. Man muss den Editor neu bauen oder auf eine Distribution mit passendem Paket wechseln. Das ist ein realer Aufwand, der vor der Installation geprüft werden sollte.

Die zweite Einschränkung ist der Kostenmechanismus. Es gibt im Material keinen Hinweis auf eine eingebaute Obergrenze für Token-Verbrauch, kein Budget-Limit und keine Warnung vor großen Auswahlen. Die Verantwortung liegt beim Nutzer, der den Umfang seiner Auswahl kontrolliert. Wer gewohnt ist, großzügig Kontext an ein Modell zu geben, sollte das hier bewusst tun.

Die dritte Einschränkung betrifft den Reifegrad der Erweiterungsschnittstelle. Das README sagt selbst, dass es noch nicht viele Provider-Plugins gibt und dass neue willkommen sind. Wer auf eine stabile Schnittstelle mit Zusagen zur Abwärtskompatibilität angewiesen ist, findet dazu im vorliegenden Material keine Aussage. Auch zu Release-Zyklen oder Wartungszusagen enthält der Text nichts. Das Repository ist nicht archiviert und wurde zuletzt am 11. März 2026 aktualisiert, was auf Aktivität hindeutet, aber keine Aussage über Supportmodelle erlaubt.

Alternative: Copilot und editorintegrierte Assistenten

Der naheliegende Vergleich ist GitHub Copilot in seiner Vim-Erweiterung. Der Unterschied liegt im Interaktionsmodell. Copilot arbeitet primär als Inline-Vervollständigung: Man tippt, und der Vorschlag erscheint im Text, ohne dass ein Befehl aufgerufen wird. vim-ai arbeitet befehlsgesteuert: Man wählt aus, formuliert eine Instruktion und ruft einen Ex-Befehl auf, der die Auswahl ersetzt oder ergänzt.

Das führt zu unterschiedlichen Kostenprofilen. Copilot wird als Abonnement abgerechnet, unabhängig davon, wie viel man nutzt. vim-ai rechnet pro Token ab, was bei sparsamer Nutzung günstig und bei großflächigen Buffer-Operationen teuer werden kann. Wer den Buffer regelmäßig vollständig umschreiben lässt, fährt mit einem Abonnement möglicherweise besser. Wer gezielt einzelne Absätze überarbeitet, hat bei tokenbasierter Abrechnung die feinere Kontrolle.

Ein zweiter Unterschied ist die Anbieterbindung. Copilot ist an GitHub und dessen Modellauswahl gebunden. vim-ai spricht OpenAI-kompatible Endpunkte, sodass OpenRouter, LiteLLM oder ein lokaler Proxy dazwischenpassen. Wer aus Datenschutzgründen ein lokal laufendes Modell bevorzugt, hat bei vim-ai einen dokumentierten Pfad dorthin, bei Copilot nicht.

Lizenz, Wartung und was vor dem Einsatz zu prüfen ist

vim-ai steht unter der MIT-Lizenz. Das ist permissiv: Nutzung, Änderung und Weitergabe sind erlaubt, solange der Lizenztext und der Urheberrechtshinweis beibehalten werden. Für die meisten Nutzer bedeutet das keine Einschränkung. Wer das Plugin forkt und kommerziell weiterverbreitet, muss die Lizenzbedingungen einhalten. Das ist keine Rechtsberatung, sondern eine Einordnung des Lizenzidentifiers aus dem Repository.

Zusätzlich zur MIT-Lizenz des Plugins gelten die Bedingungen des API-Anbieters, den man konfiguriert. Wer OpenRouter oder einen lokalen LiteLLM-Proxy nutzt, unterliegt deren jeweiligen Regeln. Das Plugin selbst vermittelt diese Bedingungen nicht.

Zur Wartung lässt sich aus dem Material nur wenig sagen. Es gibt keine abgerufenen Releases, also keine Versionsnummern, an denen man Upgrade-Aufwand festmachen könnte. Das Repository ist nicht archiviert und wurde im März 2026 aktualisiert. Wer das Plugin einsetzt, sollte vor einem Update die Änderungen an der Rollen-Konfiguration und an der Provider-Schnittstelle prüfen, weil beide als erweiterbar und in Bewegung beschrieben sind. Konkret: :AIUtilDebugOn einschalten, einen Aufruf mit der eigenen Rollendatei ausführen und im Log prüfen, welche Optionen tatsächlich gesetzt werden. Danach :AIUtilDebugOff.

Redaktionelles Fazit

Wer Vim oder Neovim mit python3-Support nutzt und Prompts über .ini-Rollen versionieren will, findet in vim-ai ein schlankes Werkzeug mit klarer Trennung zwischen Editor und API. Wer keinen API-Schlüssel verwalten will, keinen Token-Verbrauch kontrollieren kann oder auf eine stabile Plugin-Schnittstelle angewiesen ist, sollte warten. Vor dem ersten produktiven Einsatz lohnt sich ein Test mit :AIUtilDebugOn, um zu sehen, welche Daten tatsächlich an den Endpunkt gehen.

Offizielle Quellen

1. Issues
2. License: MIT
3. madox2/vim-ai on GitHub
4. README